See Final Agenda for further links
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
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
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Notes Taken by Luu Tran
Objectives
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
Notes Taken by Stuart Lewis
Protocols/Vocabularies, CC/PP & UAProfProtocols
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!
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
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
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 ...
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
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
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.
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.
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.
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.
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.
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