| CARVIEW |
W3C Delivery Context Workshop
4/5 March 2002
Collected Discussion Notes
See Final Agenda for further links
Delivery Context and Device Independence
Roger Gimson
Notes Taken by Luu Tran
- W3C Device Independence Working Group
- set up around ~1 year following DI authoring workshop (Bristol 10/2000)
- lots of concern about how to make information accessible to more and more devices
- initial charter to study current issues, review specifications, define requirements for further developments
- weren't setting out to make a recommendation for a standard
- initial deliverable: W3C working draft: DI Principals
- DI Principles document
- trying to set out what the common terminology
- identify current issues
- access mechanism: some device or combination of devices (e.g. PC with an attached printer); user perspective is an interaction mechanism
- delivery context: attributes that characterize the capabilities of the access mechanism, along with preferences; part of the users' request will include delivery context information that is used to choose the right kind of presentation
- adaptation: selection/transformation/transcoding/etc. - some
process to product relevant presentation dependent on delivery
context
- e.g. adaptation in the browser, HTML + CSS (called media type)
- e.g. adaptation at the server, XML + XSL; server select appropriate stylesheet based on user-agent HTTP header
- e.g. adaptation at intermediary, HTML transcoded to WML by intermediary like a WAP gateway using UAProf
- delivery context requirements
- DC attributes may relate to capabilities of device or network or user-preferences or user environment or user application preferences, DIWG focuses on first three
- DC attributes may vary dynamically, e.g. display area (resizing windowing interface), bandwidth, audio enablement (turn off audible ring of mobile phone)
- How DI is practiced
- representation of DC attributes: HTTP headers (language preferences, user-agent identification), CC/PP (based on RDF), UAProf (based on CC/PP)
- vocabulary for DC attributes: CONNEG media features, CC/PP example vocabularies, UAProf vocabulary
- protocol for exchanging DC: HTTP, HTTP-ex, W-HTTP
- hope is to achieve consensus on how to do DI, allowing practices to complement each other as opposed to everyone doing their own thing incompatibly
- Outstanding issues of DI
- composing a profile from different sources; the client doesn't necessarily have all the information
- decomposing a profile for different targets; web server doesn't necessarily have capability to process all the information
- delivery context modularity; e.g. device capabilities very different from location information, how do you keep these things separate?
- vocabulary definition; must be general enough to be useful - chicken or egg problem, clients must have incentive to provide the information while servers must have incentive to process the information
- extensible vocabularies; must prevent unbounded proliferation of vocabularies while accepting that no one today can provide a perfect vocabulary that's future-proof
- common core vocabularies
- mapping into CSS media queries/XSLT parameters; must tie in to existing content delivery systems
- protocols; which of the various ways should be used?
- this workshop hopes to identify issues for DI that will help drive the forming of a new charter for the DIWG, the charter is proposed by the DIWG and approved by the W3C Advisory Committee
- Q&A
- Q: must make sure that DI concerns are represented early in other groups; too often, standards need to be fixed, e.g. I18N and accessibility requirements clean up problems from other groups' specifications. A: agreed
- Q: why isn't authoring part of the definition of DI? ?DI seems to only focusing on detection? ?A: authoring sets requirements, perhaps another workshop in June/July, authoring considered as part of DIWG charter
Delivery Context in Network Protocols
Larry Masinter
Notes Taken by Luu Tran
- Larry's background: chaired HTTP working group (1995-1999), struggled with DI issues
- side note: vocabulary
- sender: agent with content
- receiver: agent that gets content
- client: initiator, transient agent
- server: accepts requests
- history (what people have done and why it didn't work, lessons to be
learned)
- fax: content negotiation (bandwidth, resolution, compression methods, etc.) typically happens before content is created (paper is scanned)
- System 33: Xerox PARC project (1988-1994), document storage & content adaptation
- postscript printer descriptions (PDP files); capabilities (color space, memory, fonts), characteristics (resolution), initialization; usage evolved over time
- color management: calibration, characterization, matching, gamut (range of capabilities), device profile, generic device profile, custom device profile, render intent
- HTTP content negotiation: HTTP/1.0 RFC 1945, accept headers (charset, language) defaults/pattern matching/parameters, HTTP 1.1 RFC 1945 (Jan 1997) q and other parameters
- HTTP extensions
- experimental, browser manufacturers didn't want to implement
- RFC 2295 TCN, alternates response, negotiate request, TCN response, variant-vary response
- RFC 2296 RVSA, let intermediaries participate in algorithm for varying content, most web traffic goes to a few sites (top 5 sites account for ~75% of traffic) so intermediaries are a large part of the web
- HTTP today
- accept useless
- accept-language widely implemented but rarely used
- accept-encoding sometimes useful
- no interest in CNor RVSA
- user-agent most frequent use, but everyone is "Mozilla (compatible)"
- detection, when needed, done by JavaScript, Java "sniffers"
- IPP Internet Print Protocol RFC 2910, 2911: never made it into popular OS's even though printer manufacturers are very interested
- SIP Session Initiation Protocol RFC 2543 and others: currently being defined in the marketplace
- EMail extensions: address book, internet fax, VPIM, draft IETF doc
- RESCAP (resource capability protocol): URI in a directory, currently stalled in the IETF
- CONNEG - vocabulary for media features
- Warning: terminology discrepency, e.g. capabilities, characteristics, preferences, content's characteristics, content preference for device capabilities
- content negotiation failures
- origin-server adaptation doesn't scale
- origin-unaware adaptation works poorly
- "best viewed by" problem: websites require certain browsers
- authors pushing back, want device independent content delivery
- vocabularies should be standards, listing/registering/pointing to URI's is not enough
- device independent content, self-adaptive, embedded vocabularies in scripting language/media queries need to be standards
- Q&A
- Q: too much information for content negotiation, how do you make it work? A: higher bandwidth will help, local application based adaptation
- Q: is PDF self-adaptive content? A: yes, but even with PDF, some documents won't look good on some devices
- Q: does content negotiation work in a digital rights managed environment? A: still under development
- Q: what are some examples of problems with content adaptation? A: generally, after receiving adaptive content, user doesn't know what's been lost, translators don't know how to handle errors from inability to transcode; digital signatures don't make there way through the adaptation environment
- Q: what if the document source is available, is the problem eliminated? A: not really because the content is no longer there
CC/PP
Johan Hjelm
Notes Taken by Luu Tran
- Johan: chair of CC/PPWG since 1998
- trying to solve immediate problem of device proliferation and varying capabilities coming out of mobile access interest group
- initially, document profiles were going to be done using RDF, so it would be natural to merge with device capabilities in RDF, but document profiles never happened
- capability chaining is a key feature of CC/PP, allows adding/subtracting of capabilities by intermediaries - much like chaining of web services, but will probably be ignored since it isn't required
- candidate recommendation pending, proposed recommendation step should follow shortly, if anyone is aware of commercial implementations, please let Kaz know
- why no vocabulary: couldn't agree within WG, wanted to focus on the framework
- R380 changes it's capabilities (PDA or phone) with a flip of the lid (user initiated)
- see WWRF document: https://www.wireless-world-research.org/
- context is a large space: everyone can define new ones, infinite possible combinations with growing number of context properties
- industry ignorance: analogy with printed media is widely believed by web page designers, but users don't care
- CC/PP implementations exist, but scaling is very difficult
- DI authoring is critical
- interacting XML applications: the device can handle all the content negotiation/adaptation, but with limited devices and bandwidth, it's more efficient to decouple these tasks to backend intermediaries, moving the processing into the network where many benefits abound, e.g. latency is lower, nodes can be specialized, etc.
- issue: authors have the right to define the representation of their content, users have the right to view content the way they want, how does content adaptation mitigate these possibly conflicting rights
- education is extremely important to eliminate ignorance of many of the issues
- futures, what hasn't been done yet
- need to go beyond presentation, take into account other context parameters, e.g. temperature, location, etc.
- content adaptation must deal with more than just presentation/formatting, data within documents must be analyzed for relevance to a given context
- need to reconcile inifinite profiles, identifying which ones are relevant for a given document, perhaps with taxonomies
- personalization in multiple dimensions: in a serial process, which order is correct? ?should privacy be applied at each step or only at the endpoint?
- business model has relevance since companies will make it happen
- choice of mobile vs. fixed platform is correlated with the task at hand, long-term tasks go with fixed platform, short-term tasks go with mobile platform
- Q&A
- Q: who's dealing with the proliferation of profiles? Web Ontology WG? A: not entirely, only within the languages that they're concerned with
WAP UAProf
Mikael Nilsson
Notes Taken by Luu Tran
- WGP: Wap Gateway Profile
- architecture 1.x
- gateway handles all optimizations
- device (mobile terminal, MT) establishes long-term session with gateway
- format converting proxy can modify the profile to indicate added capabilities, e.g. with transcoding
- HTTP-ex framework
- architecture 2.0
- switched to x-wap-profile framework because HTTP-ex was experimental
- Q: any plans to propose W-HTTP to IETF? A: haven't considered it yet, but probably should
- CC/PP protocol semantecs retained, syntax changed to not rely on HTTP-ex framework
- comment: HTTP-ex spec literally requires servers to not honor additional headers unless request was m-get or m-put, this leads to a backward compatibility problem
- comment: current HTTP doesn't allow extensibility to arbitrarily define new headers, thus the motivation for HTTP-ex
- WP-TCP/IP isn't a new TCP/IP, just a mandate to use certain RFC's that optimize TCP in a wireless network
- WBXML - binary XML optimization
- WSP - binary HTTP optimization
- use cases
- Q: how do you handle dynamic changes to profiles? A: either WSP resume with or HTTP get with new profile URI or profile diff
- Q: are these designed to convey user preferences or just profile diffs? A: can be done without profile diff, imagine two URI's, one with device capabilities and one with user preferences
- must be very precise about how to resolve the profile, initial oversights in the spec led to many debates
- uptake is slower than expected, but growing, e.g. this workshop, the
DIWG, some carriers are mandating UAProf, handset manufacturers are
including UAProf in devices
- Q&A
- Q: are there public repositories for profiles? A: yes
- Q: is the architecture tailored to carriers or enterprises? A: yes, profiles typically made available by manufacturer, must be publicly available
- Q: are there public repositories for profiles? A: yes
OPES
Abbie Barbir
Notes Taken by Luu Tran
- OPES uses some terminology that differs from web terminology
- OPES does not assume HTTP
- system model
- intermediary is a policy enforcement node
- admin server is the only system capable of downloading to the intermediary
- remote execution environment: when decisions are made externally
- main assumption of OPES: everything is done in a controlled environment (under SLA's)
- who can adapt what? surrogate or delegate authoritative
- OPES issues
- got hammered when trying to standardize, New York Times called it "evil" because it was intercepting requests without the users's knowledge
- need proper mechanism for error handling and enforcement at intermediary
- need verification to ensure that adaptation is allowed (consent) by the origin server and user agent (e.g. prevent ISP's from replacing ads)
- need encryption and privacy
- IETF WG status approved, but charter changed to not break the end-to-end data integrity of the internet
- Q&A
- Q: what is the role of intermediaries in adapting content? A: OPES assumes there is an agreement between intermediary and the origin server, but that's easier said than done
Group Discussion
What are the hot topics?
Notes Taken by Chaals McCathie Neville
Jacco: DI working draft defines a functional presentation. I don't see that concept coming up much except in Johan's presentation. What we want to convey is the intent of the author, whatever the access mechanism used. So how do you know what that intention is?
Roger: And how much does the author need to know about what adaptions might take place?
Tayeb? INRIA guy: We want to achieve a solution for limited devices - according to our implementation experience, we need to define a universal profiling description of required elements to use content? in a universally accessible solution.
Larry: If you got a colour version on a monochrome device, do you really get the colour version? Devices can compensate for limitations in ways we haven't explored, and delivering adaptable content is different from delivering adapted content that has lost information.
Roger: So you should be able to receive all aspects of the content
Larry: Or having some version that states what the difference between it and the "whole version" is.
(some discussion of this)
Tayeb: For example, the complete solution should not pass over the whole document, so the effort is wasted. But it must be done at the negotiation level - the client must declare what can be stripped (CMN's words) - a monochrome client can still ask for colour if it has an adaptation method that it can make use of.
Roger: Trying to impose a particular model of what adaptations should be done is wrong- you need to be flexible and allow adaptation to be done at different stages of delivery (on the server, on the client, after application of user preferences, ...)
Johan: extreme case is broadcast systems with no back-channel (e.g. TV). This sounds a lot like what the accessibility people are doing.
support for having open possibility of where to adapt...
Andreas ?? Need smarter measures for explaining how content could be sensibly broken up, to allow for useful adaptation
Johan: I think that is unavoidable - unless we have some AI program that can determine all of this, and that still needs the info as a starting point
Krishna: Application author needs to embed their logic. There isn't one catch-all answer...
MarkButler: Does anyone not think that delivery context is important to working out how to do adaptation
Martin: It is the second most important thing, aftger trying to get Device Independent content to be explicitly authored for transformability
Tantek: Device context is not well enough defined in the statement.
Larry: it is good to keep as much content as possible as far down the chain as possible, But we should keep the device context out of reach of the authors as far as possible - this does still show up - for example in media queries, or in Javascript vocabulary for evaluating environment.
Toshihiko: My company supports device independence. Device indep is desperately neede by content authors, despite intersting issue such as profiling, privacy, etc. Let's limit scope to presentation capabilities. For browser vendors, whether it is in any protocol doesn't metter - they just ened to be able to send their capabilities to the server - I can't see that it is difficult. There are a small number of browser vendors, and we know our competitiors very well.
Andreas ??: I think it is dangerous to leave the author to write for devices, and then leave it up to the infrastructure - your content is potentially rendered in an inappropriate way 0- the author needs the ability to give hints about how to render content
Roger: There are different kinds of authors...
Andreas ?? Maybe it should be optional - it should be available.
Roger - some authors want the control, others don' want to know
Johan: It isn't just about the presentation - there are adaptations of content itself - changing text and interacction structures.
Tantek: It is a blurred line
Larry: the further away from the device you are, the coarser a granularity you need in the context - it is not reasonable to expect authors to specifically author for different handsets and check in emulators, which is what they do at the moment. The harder it is to do this the better my company does, but it doesn't help users. With CSS media query it is clear that a pretty coarse granularity can be used, but if you are the last link to a device you may do something, but you are not fooling people into thinking they are getting the content.
Chaals: Tools are there to help people produce content - the idea is that they should do the work of sorting out as many options as possible
Scott: There are content authors who are doing animations, where they need to know what it looks like. Animators change a colour gradient to match particular bugs in one or two devices, to make sure that their stuff goes well.
Tayeb: In delivery context problem is simple. We need to provide a complete solution which is difficult. Today we have a lot of heterogeneous devices, so we need to provide content that can be understood by all devices. There is a need for content definition methods that are completely adaptable, and being able to cover the various sets of conditions that exist.
Notes Taken by Luu Tran
- Objectives
- (14) what are the benefits we want to achieve?
- (5) what needs to be generally adopted?
- (12) do static content and dynamic applications have different requirements?
- (5) what should be the role of intermediaries?
- what can be reused and what needs to be further developed (in collaboration)?
- Protocols and Vocabularies
- (20) how can vocabulary proliferation be avoided, is there a common core?
- (9) how does delivery context go beyond the web (e.g. SyncML, UPnP, SIP, wireless village initiatives, etc.)?
- (5) protocols
- CC/PP and UAProf
- (12) practical experience of CC/PP and UAProf implementation
- (12) how can adoption of CC/PP and content negotiation be improved?
- Authoring
- (20) what is device independent content?
- Negotiation
- (18) how should content be matched to device capabilities?
- (3) how can we avoid negotiation?
- Privacy
- (4) privacy, and is it needed for device capabilities?
- many more possible, but W3C is oriented toward the web, typically producing markups that drive the web experience, and we need to limit the scope to the DIWG
CC/PP and UAProf: Issues, Improvements and Future Directions
Mark Butler
Notes Taken by Luu Tran
- DELI: handles one task - profile resolution
- DELI handles ambiguity on overides based on lack of ordering in RDF by building an ordered data structure
- "transcoding" used here for lack of a better word, meaning is dynamic generation of adapted content based on context profile
Composite Profile Information
Andreas Schade
Notes Taken by Luu Tran
- motivation came from development with WAP Push, UAProf is optional in the WAP specification
- CPI library: server extension for origin servers
- provides caching for both merged and default profiles
- CC/PP processor uses an XML parser instead of a RDF parser
- Q&A
- Q: do the issues you identified need to be addressed before the CC/PP specification is a recommendation? A: definitely, RDF isn't yet finished, so building CC/PP & UAProf on top of it cannot be finished yet, e.g. resolution necessitates order, but RDF doesn't express order
Delivery Context in MPEG-21
Sylvain Devillers
Notes Taken by Luu Tran
- focusing on content adaptation for video/audio/images as opposed to content negotiation
- delivering multimedia content extends beyond the web, i.e. not bound to HTTP, not just HTML/XML, e.g. digital item adaptation to HDTV or PDA
- Q&A
- Q: what do you mean by structure of the content? bits? A: typically we describe the parts of the data, the syntax and not the semantics
Standard Vocabularies
Martin Jones
Notes Taken by Luu Tran
- Volantis: UK software company, primary product performs content adaptation
- not offering a proposal for a core vocabulary, just identifying the need for it
- Q&A
- Q: how do you define what the majority of needs are and who those needs address? A: agreed, it would be easier if it's more constrained, but the web is not that constrained
- Q: how do you define a core when there aren't several vocabularies (only UAProf) to look at and determine commonalities? A: look at current web devices instead of existing CC/PP vocabularies
Group Discussion - Parallel Sessions
Session 1 - Objectives of Device Independence/Delivery Context
Notes Taken by Luu Tran
Objectives
- who are the recipients for the benefits? (authors, device users, players in between - e.g. service providers, network equipment vendors, etc.)
- do we care only about web connected (HTTP & browser) devices only, or about a broader set of devices?
- need a compromise: too narrow to consider only HTTP, but at the same time we don't want to solve everyone's problems
- if we can deliver content that's already device independent - that's the ideal, but if we can't, then we need to find a solution to the issues that have been identified
- other areas will have the same problems and can have the same solutions
- content adaptation is useful not only for different devices, but also for different users in different roles (e.g. lecture notes read by a lecturer versus a student)
- is there an audience category whose needs, if addressed, would meet the critical mass required for wide adoption?
- don't adapt too much or else you'll run in to a scalability problem
- some content authors should be aware of the delivery context in which their content is used
- look at other technologies to see what they can offer to solve these issues
- DIWG should evangelize consistent use of device (delivery context) vocabularies across standards
- DIWG should review and be involved in DI efforts across standards efforts and use existing technologies as much as possible
- DIWG should consider the varying needs of content authors, some who need fine grained control and some who don't care what the delivery context is
Notes Taken by Roger Gimson
Audiences for benefits:
- authors
- users
- service providers
- software/hardware vendors
Education needed on business models and benefits
Web-oriented view: HTTP,
Broader view: metadata-driven contextual delivery suitable for many
environments - focus on content not carrier
W3C has formed WGs on Web Services, deliverable over HTTP, email and other
protocols. All these have some common problems e.g. Internationalisation
Some principles, such as delivery context, can apply across applications
other than Web content delivery
Ideal is for all content to be device independent, and to allow exceptions only when strictly necessary
Scalability problems grow with the number of axes of adaptation. Cannot avoid adaptation for language/culture needs. Therefore should minimise amount of variability for other reasons (e.g. device) . Content providers should pick a very few device variants, and preferably only one.
Is possible to make a judgement about the device classes that should be prime targets? Is there 1-3, or rather 10-15?
Some authors will be happy to author a single document, and have it adapted in any way. Others will want to create a tailored experience for each kind of device.
Top priorities for DIWG:
- Review proposals from other groups to achieve consistency of device independence across existing standards.
- e.g. consistency of device vocabulary across recommendations
Allow multiple levels of granularity of device descriptions, ranging from simple (e.g. CSS media types) to complex (e.g. access to specific device capabilities). Authors must be able to use the simplest techniques, which are probably suitable for the majority of cases.
Number one audience is content authors, and the developers of tools that would be used by them. Secondary audience are implementors of the delivery chain, for whom implementation must be cheap and simple.
DIWG should be a review group, and encourage convergence
Session 2 - Protocols/Vocabularies/Implementations
Notes Taken by Stuart Lewis
Protocols/Vocabularies, CC/PP & UAProf- Protocols
- Implementations
- Vocabularies
- Promoting Use
Protocols
Three protocols - HTTP-ex, WHTTP & WSP (& Multi MIME)
Kaz - CC/PP is not only for HTTP. We should think about it in a protocol independant way.
Larry - What happened to older thoughts on content negotiation? Why did they fail? Are we learning the lessons from these, or just re-implmenting them? Why do we think our new versions will be more successful?
Taka - Used HTTP-ex, but would be simple not to.
Larry - Media features seem more well developed in the conneg framework. Newer protocols have not overcome some of the problems of older technologies.
Tayeb -Most protocols do not give the same benefits as CC/PP. Can I use te same protocols to provide what we want. (Tayeb) I thnk not. Are the Accept-* headers expressive enough? No. The HTTP 1.0 / 1.1 negotiation parameters as a solution is not good as the clients have limited power so the responsibility should not be with the client.
Stephane - We have multiple candidates for a protocol to carry CC/PP. We have no official recommendations about which to use (and why). We need to recommend a protocol. This is one of the reasons why CC/PPhas not been taken up.
Implementations
Art - CC/PP implementors day.
Johan - About above, none since. A year ago the industry was different. There were 6 or 7 implementations. Some of these are not available now.
Stuart - Are there any reference implementations?
Kaz - Keio have 1 implementation.
Tayeb - Implementations have been targeted. We need a clear description of common parameters. We need a common schema.
Andreas - What is an implementation?
Johan - A database could do some adaption.
Tayeb - How can we match profiles for browsers and documents to choose delivery strategy.
Krishna - How do we extract attributes from profiles to use thm? Implementation guides about how to use the profiles. Where in the model?
Vocabularies
Mark - People want to define vocabularies. Should this be avioded, should be use a standard vocab? How should we decide a standard vocab.
Johan - If we try to define a standard vocab we are automatically limiting ourselves.
Larry - There are two kinds of vocabs. An authors vocab (e.g. high level catagories). And there is a last-mile category (e.g. minute differences between common browsers). If we force authors to be aware of the second kind, we will have little interoperability. We should realise they are different. They are different perspectives on the same thing.
Stephane - We only seem to look at device classes.
Mark - We have very detailed profiles. Authors only want high level parameters.
Johan - We would like to know which parameters are imporatant to different device classes.
Johan - (Why were the profiles so complicated) Because the vendors want to describe their devices in detail.
Martin - It shouldn't be assumed that fine granularity details are only important nearthe end of the adaption process.
[Larry - (Last minute, not last mile).]
Art - Asked who should decide on the vocab? Do we need a standard vocab?
Larry - The W3C has standard vocabs (e.g. media queries and SMIL has one). Should we have many like this or just one?
Promoting Use
Andreas & Larry - Chicken and egg - one will need to implement before the other.
Larry - most content is static, therefore sending profiles adds nothing.
Krishna - WAP gateways to perform this is expensive. Cheap solutions are required for content authors.
Mark - What systems are available are not interoperable.
Larry - The problem is in deployment, not implementation.
Johan - We have not been able to demonstrate a compelling use case for DI. Therefore people prefer to use device dependent rather than DI authoring. The problem is not in the technology, but promoting it to the authors. Authors like high levels of control. Extensibility must be incorporated into the standards.
Question to browser vendors -
Panasonic - browser with UAProf. It is easy.
Mark - Why do the major browsers not implement profile support?
Andreas - It is over-complicated.
Johan - It was taken up by the people who have a need for it. E.g. Nokia, Ericsson.
Mikael - No one has heard of it.
Stephane - No one knows why they should implement CC/PP. Ignorance of the architecture.
Krishna - Lots to learn (e.g. XML ,XSLT).
Larry - Make sure the solution solves the problem before trying to sell it. Possibly CC/PP may be too complicated, on the other hand it might not be detailed enough (e.g. what fonts are available). Thats a puzzle!
Device Independence within the W3C
Kaz Kitagawa and Charles McCathie-Neville
Notes taken by Philipp Hoschka
??? (INRIA): have you defined principle of single authoring in DI
principles ?
Roger: yes
Stephane: if you succeed DI, WAI is just part of it - if you can adapt to
device capabilities and preferences, accessibility is part of that - what you
said is that you don't get user preferences and DI capabilities (from system
?) - DI framework requires information about the user, that's what this
workshop is about - there seems to be a mismatch with WAI experience
Charles: not true that you can't get info, but installed systems don't make
use of that info
Tayeb (?), INRIA: agree that you need information
Charles: agree that DI and WAI mean the same thing technically
Tantek: if you don't say that you're using Mozilla, you don't get a lot of
stuff - could you elaborate ?
Charles: first version of Sydney Olympics cite - Boston transport - various
other sites cannot be accessed if you don't use Netscape or IE?
Tantek: is that discrimination ?
Charles: just bad design - assumption is usually that those are only browsers
that do Javascript
Art (to Kaz): find it comical that Xforms is named as example for device
independence - lot of dependencies, brings in Schemas etc. - cannot be done
on small? devices
Kaz: agree that a lot of our specifications are too large for small devices -
lot of spec's now defince "basic" versions, e.g. SVG ... in personal opinion,
think we need more of this - also try to make spec smaller
Daniel: Web content guidelines ... want content to be richest possible so
that content can be adapted on the client - CC/PP wants to do adaption on
server - risk that if you base content on client, there will only be one
version left - risk in model when you take as input user data
Charles: Web content guidelines is about authoring content - current
discussion is about serving content,? when it makes sense to adapt it - how
do people find way to version that suits them if adapted version does not fit
their needs
??: ...
Larry: local adaptation in client should be discussed
Johan: charter of DI WG says that it should review? documents - Xforms should
be reviewed - has that been done ?
Kaz: Roland Merrik gave personal comments
Larry: last call is over
Using CSS to achieve Device Independence
Bert Bos
Notes taken by Philipp Hoschka
Larry: there is overlap between CSS media queries and CC/PP - larger
overlap to conneg - both have syntax for media queries - vocabularies are
overlapping, but slightly different - understand there has been justification
- strong to say that it is orthogonal
Bert: found very little overlap to conneg and UAPROF - their vocabularies are
different from what we need - syntax needed to fit into CSS, can't use less
than or greater than
Larry: understand they're different, but they're not orthogonal
Stephane: why did you do this work ? we have CC/PP, which overlaps with CSS
media queries - was there a problem with CC/PP that you try to fix ?
Bert: CSS media queries has advantages - easy for authors, lightweight,
extends something that was already in HTML - also easy on the server, no?
extra roundtrip, no URL to dereference, no profile to search - many useful
things with very little overhead - not intended to replace full device
capabilities
Roger: could imagine that this will be stretched
??, INRIA: CSS suitable for adaptinng presentations to users, but not do
adapt to devices
Mark: mechanisms you're defining very similar to how server could match
between CC/PP and ...? would like to see transparance so that we could use
same constraints in CSS and server based matching ... way CSS would query
should use? CC/PP profile - don't need to implement same profile twice -
techniques should be complementary
Bert: interesting idea
Device Independent User Interfaces
Walter Dees
Notes taken by Philipp Hoschka
Philipp: what is advantage of hierarchical stylesheets ?
A: ...
Tantek: CSS model is very similar to what was presented in this talk -
hierarchy of stylesheets allows to load? only the one for correct media - can
import different stylesheets depending on device characteriscs, save
bandwidth
Andrew (?), IBM: what is application domain that you targetted ? Home
appliances ?
A: yes, main area
??, IBM: is approach vulnerable to unforeseen effects if you change order of
stylesheets ? if you have? decision trees, ordering is important
A: you're right
Martin: is order of levels fixed ?
A: you can override lower levels ... structure might not even be a tree
sometimes
Mark: problem with hierarchiacal approach: fine if you're dealing with one
modality, but difficult if you deal with more than one
A: if you go down graphical path, you may also have to go down audio - you
may have both
Mark: you may also have different input modalities
...
A: if client has small screen with audio input, should look if there are any
stylesheets for it ...
Design Once and Render Anyway
Krishna Vedati
Notes taken by Philipp Hoschka
Sun: are you familiar with portlet specification in JSR 168 ??
standardizes layout - are you proposing W3C should do this ?
A: no, just something to think about
Style Sheets for Context Adaptation
Michael Kraus
Notes taken by Philipp Hoschka
??, INRIA: XSLT problem is that actual content is not valid, so XSLT won't work - need to educate authors to write better HTML
Towards Semantic Web Document Engineering, CWI
Jacco van Ossenbrugen
Group Discussion
Adaptation and Authoring
Notes taken by Johan Hjelm
Tantek Celic: Question about techniques. Saw presentation this morning, Philips hierarchy style sheets, multimedia, common threads. Explore what the common threads were. How can we use that to apply common descriptions?
Jacco van Ossebruggen: Amount of differences between devices is too big to
design a stylesheet for each. Do something that can adapt. Select or adapt.
Assume one stylesheet per device is naive. Need something preferably standard
that can generate stylesheet.
Larry Masinter: None used the system model presented on the first day. Had
client doing some (smaller, larger) processing. Not server adaptation, more
localized.
Krishna Vedati: Not true, maybe did not come across. From author perspective,
embed hints so rendering server can do.?
Larry: Hints in content?
Krishna: Server uses hints, creates something sends across. One point. People
are looking at automatic rendering, design so that easier to do heuristic
algorithms, etc.
Roger Gimson: Is there a difference between requirements for static content,
where opportunity for client style is great, vs dynamic content where there
is a greater amount of interaction client-server. Could have as part of
session, it understands device connected to session. Are there sufficiently
different requirements?
Chaals McCathie-Neville: Static content is subset of interactive content.
Take requirements for dynamic, multimedia content, have different static
pieces. Meeting requirements for adapting to interaction models are
automatic. Static content presented any given phase presentation, same as for
static content presented in only that phase. We are all fairly textbased,
understand how to do in text. Harder to do in e.g. animations.
Martin Duerst: Having content prepared on server side, adapt to devices,
different mechanisms eg style sheets. Adapting content, good fit. Use one
technology, extended technology. Keep context, session. On other hand, if set
up these things, do detail work, with every dimension you add, the complexity
of the code explodes exponentially, if you are not careful. More difficult
for dynamic content.
Roger: Depends on value of specific job, work to do the job. Voice seems to
me, pinpoint issue interaction, interacts different way. Not necessary
linear. Utter things that may fill in fields in a form in user preferred
order, not system preferred. Recognition grammar, etc. That modality got its
own set of concerns. Few of which overlap other modalities. Authors do
something special.?
Michael Kraus: Focus of workshop, provide framework for context adaptation.
Voice, multimedia, delegated to appropriate Working Group. Regardless of
content, have profile, rules in stylesheet to adapt actual adaptation rules
for specific media not work of this group.?
Tantek: Comment on Chaals comment. Disagree. Lots of static content, has lots
of text. Most dynamic content, very little text. Same requirements incorrect.
Large static content needs to summarize reduce paragraphs, etc. Provide more
progressively. Not occur with static text in dynamic content.?
Larry: Doubt that thought common theme expanded thinking. Thought talking
producing alternate presentations varies presentation capabilities. Heard
talk about accessibility, etc. Not just alternate presentation, alternate
material. Image and alt-text. At least evoked that for other formats.
Correspondingly, choice more than presentation capabilities of device,
context. Choose one presentation for museum artifact as opposed to library
book. Conceivably use same framework for adaptation. Interesting idea for
me.?
Martin: About voice. Stating working about voicexml spec. Thinking things
mentioned, but other conclusion. Not know well enough to say what can be
merged or not. Choose order to fill forms, can not do in browser. Bit more
similarity looks like. Over time understand better, bring these things
together. Better speech technology get, built in. Not put pointers to
grammars, etc. The more see how put closer together. Its possible, see some
degree convergence.
Chaals: What Martin said. Take up Tanteks point. Think material presented
series of voice dialogs, in way suit interactive form. Have bunch content,
chop up.?
Walter Dees: One difference, techniques are similar, dynamic apps stricter
requirements lay out, latency. Close collaboration client-server, fast
response from the user. Push to enable.?
Jacob: Learn from metadata, keep all info from production in the final
document. We throw all away, then try to adapt. If we had it all, easier to
do adaptation.
Roger: Would it not be application-specific? Ideal, description not device-
or application-dependent. Ideal a long way from. Otherwise, n times n
problem.?
Rigo Wennig: When think CCPP, P3P, metadata framework, distinction static o
dynamic context leaves some doubt, see delivery context, does not end until
end of dynamic content. Start your film on mobile and see it to the end.
Overrrequire if want to have adaptive during session. Static page,
load-display-end.
Wieland Schwinger: Have transaction, select tourist info. Beforehand, select
what is really interesting, go through site. Have transaction, starts
desktop, and ends at PDA: All long-running transactions. Location info,
changes context all the time.?
Johan Hjelm: Statelessness, session concepts, and dynamic concepts not quite
the same thing. Text can be dynamic.?
Stephane Boyera: Describe document profile, have this requirement to be
usable. If generated, not quite the same thing, like media query describe in
document what are available options.?
Tantek: Need to make distinction timed and dynamic content. Dynamic content,
generated on the fly. Timed content, like SMIL. Different requirements.
Multimedia, static-already authored. Dynamic content, do not know before
authored.
Roger: Dynamically generated content, interesting. Needs to be away to
describe what it is. Or could be. Great example, RSS to capture news
articles. Summaries of. Well defined representation for capturing that
information, semantics. Define schema, dynamic. Once defined schema, do
adaptation, slot into news portal. That paradigm, define schema into which
content be fitted, define adaptation.?
Krishna: You still need to know the type to adapt it.?
Tayeb Lelouma: Getting information about document is important to adapt.
Single authoring, principle of this group, adaptation mechanism must exist,
since offer doc in XML, XHTML.
Roger: If you embed in it variations you want to allow, depends on delivery
context, step 1. Step 2, beyond that, do not know what content is but it will
follow this structure. Not embedding adaptation on document, in schema.
Krishna: Schema, render this way if it is like that.
Michael: Vocabulary, similar. Have vocabulary describe news article, adapt
according. Describe standards for different structures.?
Jacob: Need info about delivery context, but also source content.?
Roger: Document profile, something that sets out to describe what document
contains. Rather than delivery context. Created as part of HTML. Lain dormant
for 2 or 3 years.?
Jacob: Say things like "need plugin".
Luu Tran: Understand scope of WG. Called device independent, but discussion
is about applications, documents. Are we really talking about device
independence? Already extended, device=delivery context. Also role user,
beyond hardware, software? Now hear, concept document independent. Not
necessarily case, dealing particular doc in device, given a device, view
document. How to describe document so that all document can be viewed on
device. Ultimate goal, all content all devices. Attack one angle, here other
angle attack it from. Where to consider.?
Toshihiko Yamakami: Delivery context, device independence different. People
here talk delivery context. Interested device independence.
Stephane Boyera: If achieve device independence, need some delivery context.
All delivery context, bigger than what needed for device independence. Should
concentrate only on this part of the delivery context? or larger work/WG?
Part of question for WG.?
Martin: Language mentioned. Why I am here. Mechanisms, look into, see
screensize, language, capabilities, preferences, kind of same way. Difficult
do something only works for one device. Not something else. On other hand,
not necessarily expertise other areas, work together with the working group,
give feedback. Language very technical example, deliver everything in one doc
does not scale. SVG, SMIL, switch statement. Not done that way. Technical
example, some way, have to tell server which version you want. Automatically
or explicitly.?
Roger: Delivery context, not achieve presentation, other issues. How to
define what needs to be done for delivery context. Yesterday, talked
consistency vocabulary, core vocabulary. Address different aspects, delivery
context. Representing device capability, specially relevant pres. adapt. In
terms of earlier stages of creating context-specific applications, what are
the requirements on delivery context?
Rigo: Only heard device capability, location. Are there other delivery
context issues??? Class them, by requirements.?
Roger: CCPP create framework, many kinds of delivery context can be placed.
Not just presentation.?
Johan: Document profiles, already considered. CCPP, match against document
profiles.?
Krishna: Talk about device independence, 4 groups, this morning. Adaptation,
different subgroup. Various people looking at. How to extract content
information, implementations. How to use it.?
Roger: Kaz, device independence, simplify job for authors. Single authoring,
a question of degree. Enable what they create from many kinds of devices,
prime goal device independence. Delivery context, in order to achieve device
independence, author aspects have to match.?
Toshihiko: Talk about current presentation, presentation like to make long
make short. Make recommendations, Kaz presentation, all the things all
different. Make sure fits requirements, fit domain. Where to do work,
clarified. All different.?
Stephane: Totally may be a bit strong. Define precisely, overlap device
independence working group.?
Larry: Language, as a delivery context. Most of the focus in
internationalization work, underlying capabilities. Not a lot supporting
authoring of content different languages. Accept-lang, other mechanisms,
select different representations. Reasonable implementations, if not
widespread deployment. Understand problems, relate to other domain. Why hasnt
this been more active topic in internationalization group, mostly focused on
localization.?
Martin: Ask localizatiability, topic in workshop had a month ago. Careful in
designing technology, easy to adapt different languages. Comment XSLT,
externalize language strings, call in from file, e.g. english, french, etc.
WG presented mechanism, not use. Use more as review focus. Now that the
characters get translated as characters, and not garbage. Was original focus.
Accept-language, not much on spec side, as far as people want to use, it
works. Do more outreach, help sites realize, use. Sometimes, sites select
language, waste screen space, get user to right language. If they have
information, go directly foreign language, still have option select other
language.?
Roger: In media queries, can you make language preference accessible?
Bert: No
Tantek: It is in CSS2.
Martin: You can style different pieces in different languages
differently.?
Roger: Not choose between alternatives.
Bert: Yes you can. Make it invisible.?
Martin: Advanced CSS. How do you get information, does it come from user?
Bert: Have not specified how user encodes it. If user specifies in CSS
syntax. By hand, or other way.
Martin: If documents have several language variants, show only one language
part. Only works for some kinds of documents. SVG, SMIL, switch statements.
Give to translator, reintegrate?
Roger: Whole set of authoring questions. Focus back delivery context,
mechanism CSS. Make available.?
Martin: HTTP, go somewhere, start with one ver, go other ver. Follow links,
follow new language links, accept language not support. Organize site right
way.?
Tayeb: SMIL 2.0, inside document, in fact use switch. Specify element. Can be
done HTTP. User sent request header.?
Johan: Educational problem. Also, switch off for performance reasons.?
Stephane: Same problem, language, delivery context. Generally, document, not
the same value. Language selection, same trouble as complex delivery.?
Martin: On paper, in HTTP 1.1, certain implementation, support q-values. This
is one of many example, where setting things up on server side, all different
language negotiation, get default values right. If go to q-values,
complicated. Not sure that is really used.?
Scott Hayman: Use on server side, use on client side instead?
Martin: Browsers get delivered in specific version, configured so national
versions state what language they want. Not in that state.?
Luu: Although useful to draw analogies device independence, easier authors,
draw analogies language, lot of advantages devices, machines, languages are
already predefined. Not easy make machine translate one language to another.
Human translators, author multiple times, system do selection. Ask are there
specific advantages, in developing standards for how systems should work to
do all the work for us, not end up as in language selection, everything is
manual. Do we need to do more education content authors, use accept header.
Authors dont deal with. System admins, deal with protocols.?
Tantek: Authors vs system admin, right. Not always authors fault. Somewhere
else in the chain. In this instance, educate author help. Meta http-equiv.
Some web servers may use. General, agree.?
Roger: Question to all. In the moment, HTTP header fields. Some are used,
some not. Debate delivery context more general ways. What is going to be high
enough benefit, people will do something change what is already there. CCPP
adoption, etc. It is a significant cost. If you had to choose one extra piece
of info, in delivery context, not now in HTTP header, what would it be?
Tayeb: Accept-headers, using the HTTP with accept-headers, not sufficient.
CCPP good for this. Describe client.?
Roger: What is the one high value item??
Scott: Japan, use user agent to specify the phone. Need a description what to
go after, user agent database. Need description what the fields really mean.
No database says, what is a p503i phone.?
Larry: History user agent string, identity version browser. Netscape,
mozilla. People do content, send extra if browser is mozilla. Other browser
maker, get content, say am mozilla too (compatible). Not deployable, even if
define what it meant. Content providers use in a way as not deployable as
specified. If user agent popular handset, they may do the same thing.?
Martin: Proposal, CCPP changed in automatic transactions, encourage all
vendors publish CCPP profiles, make work people easier tools and content.?
Roger: Maybe missing link mapping CCPP and user agent.?
Toshihiko: Device capability should be published, but short user agent field,
since end user has to pay for every bit. Is delivery context for end user or
content developer.
Mark Butler: Would be great if the vendors published. Associate strings with
profiles.?
Larry: In practice, vocabularies have, not enough, capture what authors need
to know when to create presentation. Mismatch, authors really need to know,
and the device makers specify.?
Johan: Maybe annotated UAPROF?
Martin: Go out, look at sites, come back examples what they check for.
Sometimes, not know use tech better, sometimes have to do because not get
result want.
Mikael Nilsson: Need to go out and do education.?
Michael: Crucial. University, give content adapted to student background,
performance. Perhaps not in interest of others. Not one exact item.
Roger: What is fine enough value, get implemented.
Rigo: Why should not every device have unique ID. Sent to server, know who
is, deliver content to that person.?
Larry: Characterization, handset and ROM, can characterize, versions of
plugins etc become unmanageable.?
Mikael: Not doable, privacy perspective. Second, agree with Larry, not doable
to just look at ID of device, you can download new software, change its
characteristics.?
Roger: Also, disadvantage of server-side.
Rigo: What wanted to get at direction, see development of devices,
development of content. Producing devices, also look at content, what can be
adapted. Specify profiles, criteria, converge.?
Krishna: Random idea, "not-accept-headers". Say "I do not want to do this".
Accept-headers, positive.?
Larry: Q-values, reverse.?
Mark: Come back to issue raised before. What techniques are there for device
independence. Various kind of distinctions. Whether do at the device, or
different device. If latter, send info to that device, implicitly
(user-agent), or explicitly (ccpp). Other kind of access, linear and
non-linear presentation. Some devices, different way look at content. Order
forced on you on some devices. Content author must think carefully. PC,
non-linear browsing, user can scan. Single authoring, WAI has guidelines, do
both. Content specialization. Format, transformation (like XSLT - different
target languages), styling (CSS, XSLT). Other 2, selection of alternates, and
generation. Always need alternate selection, computers can not translate
between languages. In our framework, have to allow alternates. Generation,
can not tagmark but transform. Eg. video transcoding (higher -> lower
resolution).?
Andreas: Use CCPP on something that comes form origin server. Phone people
not like, selection task on client. Browser looks at meta document, find out
what to do with content (did not get all of this).
Roger: Pass to client, based on what has been delivered, make choice of what
is further delivered.
Andreas Schade: Hesitant to go into, single request, multiple roundtrips.
Roger: Might not need multiple roundtrips.
Andreas: CCPP return is metacontent. Client could select what pieces of
document.
Luu: Different from document profiles?
Andreas: Maybe not at all. CCPP describe device. Single authoring.?
Universal Profiling for Content Negotiation and Adaptation in Heterogeneous Environments
Tayeb Lemlouma
Notes taken by Tayeb Lemlouma
Question (Charles): What you mean by “profiles of the schema use a
'valid' namespace”?
Answer: I meant simply, that profiles use the URI of the corresponding
defined profile schema where the URI exists really.
Question (Sylvain): How can we integrate and use XSLT style sheet in the
global architecture that you have defined?
Answer: XSLT style sheets represent a kind of adaptation method and in order
to use an adaptation method in NAC, you have just to define the XSLT style
sheet (or the adaptation method) profile in terms of input requirements
(admitted document kind in the input, etc.) and output description (such as
the kind of the generated document, its DTD, etc.)
Question: Do you consider in the your schema that some structures or types
definitions like those defined in WAG UAPROF schema (such as Boolean, Number,
Dimension etc.)?
Answer: The schema that I have presented identifies the profiling definition
of some basic elements that are necessary to resolve the problem of content
negotiation. The definition are not dependent to a particular kind of device
(such as WAP devices etc.) and includes many profiles and consider other
elements that can't be found in the WAG UAPROF, such as the document profile
and adaptation method profiles.. etc. However, the defined schema still not
complete yet this is why additional structures will be defined.
Context classification for device-independent Web-Applications
Cedric Ulmer
Notes taken by Mark Butler
Johan: Is speed the only parameter?
SAP: No its just an example of a criteria by users.
Stephane: What is the relationship between this and content adaptation?
SAP: This is based on device classes and a few usability classes. Depending
on the class you want the content to be adapted to, the hints are used to
prune the content appropriately.
SB: But how does knowing they are in the same class help the programmers?
SAP: It's the 7+-2 problem. Fewer device classes are better.
Customising Web Applications Towards Ubiquity
Wieland Schwinger
Notes from Martin Duerst
RDF Schema in CR may be okay for research/experimental work, but not for big company or reference from standard.
For basic datatypes, you can use XML Schema Datatypes, which is a Recommendation already, and defines what lexical values are equivalent.
XML Schema WG has a common type library; new types that you need but that you think that may be of wider usability can be submitted there.
Contextual multi-device delivery
Venu Vasudevan
Notes taken by Mark Butler
Johan: How do you define clusters of devices? Do they change over time?
V: We've played with scenarios. Users may revisit scenarios (home, work,
car). The other way is proxies can federate.?
J: Do the proxies reside in the cluster itself?
V: It's one network hop away from the end devices.
PH: How does you work fit in with transcoding?
V: The steaming media situation is the harder one so we solved that first.
Secondly certain types of transcoding do not have information loss.
Group Discussion
Feedback to W3C
Notes taken by Mark Butler
Output of workshop
1. Classes of device capability
2. Reviews on other W3C s spec
2.1 WAI Content authoring
2.1.1 Do this early on
2.2 XML WAI guidelines
2.3 XForms
2.4 P3P
2.4.1 Privacy
2.5 SMIL
2.6 CSS
2.6.1 Media queries
2.7 Review problems with CC/PP, resolve issues
2.8 SVG
2.9 XLINK
3. How does natural language fit into delivery context
4. Look at what delivery context involves?
4.1 Versioning of profiles
4.2 Merging of profiles
4.3 Collateral damage - privacy
5. Clarify relationship with WAI group
6. Define a device independent framework
6.1 Where does CC/PP, WAI etc fit?
7. Delivery context for non-human user agents
8. Delivery context for multiple devices
9. Interaction of messaging: store&forward, real-time, and delivery
context
9.1 Instant messaging
10. Identify what is in document profile and how it relates to delivery
context
10.1 Document metadata, e.g. title, subject, author
10.2 Rich media
10.3 Delivery context
10.4 Static content vs dynamic content vs timed content
11. Delivery context for non-textual media types
12. Documents
12.1 Guidelines document for DI authoring
12.1.1 Authoring
- Single authoring
- Multimodal authoring
- Device independent authoring
- Device independent hyperlinks
- Visability of adaptation to users
12.2 Techniques document for DI authoring
12.3 Document describing system model
12.3.1 System model
- Content negotiation
- Strategies of matching different elements of content negotiation
- Transformation
- XSLT
- Styling
- CSS
- Transcoding
- Pushing UAProf to IETF
- Protocol
- Fault Analysis
12.3.2 Requirements document for delivery context in that framework
12.4 A document describing a core vocabulary OR why it is not possible to do
this
12.4.1 Vocabulary
- Merging vocabularies - UAProf, media queries, conneg
- Set up a core vocabulary for DI and WAI
- Define data types for core vocabulary
- Define operators for core vocabulary
- Is this a job for RDF / RDFS?
- Liasing with WebOnt - can it be used here?
- Specifically merging vocabularies
13. Adding location to delivery context
14. Application vocabularies versus device vocabularies
14.1 Application vocabularies are much abstract
14.2 Cascading multi-level profiles
15. Stylesheets for content adaptation
16. Statefulness vs statelessness of delivery context