- From: Al Gilman <asgilman@access.digex.net>
- Date: Thu, 10 Jul 1997 08:29:57 -0400 (EDT)
- To: jromanac@dial.eunet.es (Javier Romaņach)
- Cc: w3c-wai-wg@w3.org
[Back on the action item, I think.] Maybe it would help to separate the question into two steps: 1. What is the range of dialog modes that we need to support? - Can we combine equipment capabilities, user capabilities, and user preferences under one browse-mode description? - can we encode this as a virtual-terminal model with a display virtual-datatype, a control virtual-datatype, and a machine model connecting display flow and control events? 2. What are our options in terms of how we connect a common core of information with those varying dialog modes? - for the options that involve communicating client display [and control?] capabilities to a server, does the capability negotiation function of HTTP 1.1 fill the communication need? - maybe the server only ever needs to worry about the display capability of the virtual terminal? You see, I think that the allocation of the adaptation function between client and server will be a market decision. We can't decide that arbitrarily. We need to provide protocol capabilities to support all options in the competitive range. We need part 1. regardless of what we think is going to happen in part 2. The first part is about things like how partial color vision is an separate question compared to visual acuity. What are the dimensions of capability we need to be aware of? What scales can we use to characterize the capability in those dimensions? Can we select a finite set of capability clusters in this capability space to target with representation styles? Or do there need to be parametric adjustments built into the styles to match the user's ability and preference on a continuous basis? In part 2. there are a range of approaches to how to adapt the content to the diversity of browse modes. At one end of the spectrum the author of some content has multiple styles for the different browse modes and checks his document in all these styles until happy with it. On that condition, it makes sense for the client to communicate its browse mode description to the server and the server to select the most appropriate style to go with the document. At the other extreme is the [likely more common] case where the author only checks the document in one style. Adapted views are generated by transformations whose output the author hasn't checked. These could be alternate style sheets that come with the client software or from a third party. They could also be functions built into the client or a piped filter. I wasn't at Sofia, so I may have misunderstood the action item. Is this related? -- Al Gilman
Received on Thursday, 10 July 1997 08:30:02 UTC