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

Delivery Context in Network Protocols

Larry Masinter

Notes Taken by Luu Tran


Johan Hjelm

Notes Taken by Luu Tran


Mikael Nilsson

Notes Taken by Luu Tran


Abbie Barbir

Notes Taken by Luu Tran

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

CC/PP and UAProf: Issues, Improvements and Future Directions

Mark Butler

Notes Taken by Luu Tran

Composite Profile Information

Andreas Schade

Notes Taken by Luu Tran

Delivery Context in MPEG-21

Sylvain Devillers

Notes Taken by Luu Tran

Standard Vocabularies

Martin Jones

Notes Taken by Luu Tran

Group Discussion - Parallel Sessions

Session 1 - Objectives of Device Independence/Delivery Context

Notes Taken by Luu Tran


Notes Taken by Roger Gimson

Audiences for benefits:

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:

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


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.


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?


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

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
- Styling
- 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