CC/PP Re: A single URI

As I read the CC/PP draft it describes three actors in the chain. An
"end-user", a proxy, and a server (in reality these can be chained further).
In actual use scenarios, a browser should not assume (well, if I was writing
in specspeak I would say MUST not assume <grin/>) that it captures the
capabilities and preferences of the end user by defining its own
capabilities - in other words, it is really a proxy.

In most cases, the user will accept whatever the browser says it can do, so
there will be no need to further modify the preferences. But in a significant
minority of cases this won't happen - the user will need to modify what the
browser claims it can do. For example:

  A user may use a voice recognition system to control their browser,
  operating by replacing the keyboard, and without providing a mouse. This
  does not affect their ability to make use of a good browser, which can be
  controlled by the keyboard or by the mouse. But it does mena that they
  should ensure that a CC/PP statement sent on their behalf doesn't claim
  they can use a mouse.

another example:

  I use a common browser, but because the network I am on is extremely slow
  (being based on GSM), I turn off support for various kinds of multimedia.
  (In iCab I can filter out objects by type - eg gif image, move, etc - and
  by URI - eg. I don't get any images from half a dozen advrtising providers
  - and by size - eg. I won't accept any file bigger than 20KB). It is
  important that these preferences are part of the CC/PP profile that my
  browser provides.

another example:

  My cellphone browser implements CC/PP, but doesn't have a lot of spare
  memory and has to swap in and out various media players. I can choose, on
  the fly, which ones I prefere to have, or it will make the choices based on
  default information. It therefore has to adjust, dynamically, which kind of
  media it accepts in what circumstances - in other words the CC/PP profile.

and a final one:

  I am deaf, and use a web browser that implements CC/PP to get optimised
  content. I need a way to include in the CC/PP transaction chain that sound
  is not useful.

In actual fact I don't see that the interface for doing this needs to be in
the browser - it can be implemented in a proxy service. This is the approach
taken by IBM in their WEBI work. But I prefer to have things like this in my
browser and shorten the chain through which things pass.

Cheers

Chaals

On Thu, 20 Dec 2001, Jim Ley wrote:

  "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
  > At 10:49 AM +0000 12/19/01, Jim Ley wrote:
  > >CC/PP as described in all of the public drafts do nothing to solve any
  of
  > >the problems described above - it's still talking about browsers and
  > >platforms, rather than users, so you have the same problems.
  >
  > On the contrary, CC/PP, when used correctly, talks in terms of
  capabilities
  > and preferences, which are user-centric, rather than just sending a
  browser
  > or platform identifier.

  I'd asked this before, can you please show me where in the public drafts
  of the CC/PP protocols, examples implementations etc. there exists
  frameworks for describing users accessibiltity needs, I'm obviously
  missing everything, or the working group has published something quite
  different to what it's developing privately.  Either way please provide
  evidence that supports the above so developers can start preparing - some
  of us actually create User Agents and sites.

  >  This means that problems such as storing a
  > database of capabilities for future browsers are solved.  CC/PP,
  correctly
  > applied, should also solve the problem of non-identifcation of assistive
  > technology (e.g. JAWS), since JAWS' capabilities _should_ be identified
  > within a CC/PP framework.

  So that doesn't solve the need to have a database of what jaws means in
  Accessibiltiy terms and all others UAs and ATs - and how do I provide site
  developers with the functionality of Snufkin (my own browser, based on my
  own needs.)

  Jim.



-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Thursday, 20 December 2001 07:06:48 UTC