RE: Rendering DIAL

In theory, DIAL could be rendered anywhere from the origin server to the final client. However, we believe that much of the processing of DIAL will take place before the final stages of delivery. In other words, the processing is likely to take place in the server, a proxy or other intermediate, rather than on the device. Many use cases we considered (and have experience of in our respective companies) involve the selection of material provided by the author, and this means that the unselected material is not necessary for the particular client to which the resource representation is being delivered. For example, the page may contain several main titles (a long one for big devices, a smaller version for PDA, a two-word eye-catcher for tiny devices, a very colourful one for fancy devices, and maybe even versions in alternative languages), but only one of those is appropriate in the delivery context. So why would we deliver *all* of that material when most of it will be deleted? Instead, we think this would happen in pre-processing.
 
You could use an XSLT stylesheet for each aspect of the context, and dynamically merge these into pipeline for server-side processing. You could generate a complete stylesheet programatically (even in XSLT itself!) to add to the flexibility. I wouldn't like to speculate at this point how efficient this would be, and my own company prefers alternative processes, but a functional multi-device adaptation in XSLT is possible.
 
The light in living room of my father's house is connected to his security system, which in turn forms part of an intranet wherein such components are seen as resources with URLs, and in the case of the light it has read and write capability. The light is also a dimmer, with (I believe) 16 levels of intensity. In theory, I can communicate many messages to him via the light bulb. Messages demanding that he pay attention to the house entry points can be represented as a flashing light, but if I wished I could associate the "mood" of a message with a certain bulb brightness. Of course, in reality, communication via the telephone is his preferred medium, but we in the DIWG hope that our imagination is not too limited when it comes to thinking about devices that may be part of the Web. :)
 
As for the author not envisaging future devices, that is one of the reasons we look towards metadata abstractions. For example, rather than saying that content item 1 must be followed by content item 2 for certain devices, we would prefer to say that "where the device supports the concept of perceptual proximity, item 1 and item 2 should be proximate". I think that DIWG could be a long way from getting to that level of abstraction (and figuring out how such concepts get mapped to real devices) but we've taken the first step by suggesting a way for authors to indicate how they would like their content to be adapted for contexts they can understand today.
 
---Rotan Hanrahan.

________________________________

From: www-di-request@w3.org on behalf of Ben Francis
Sent: Fri 26/05/2006 21:17
To: www-di@w3.org
Subject: Rendering DIAL




Dear Device Independence Working Group,

I am an undergraduate reading for BEng/MEng Computer Interactive Systems
at the University of Birmingham in the UK and I am very interested in
the activities of the Device Independence Working Group. I am also
currently completing a paper for a competition entry which touches on
these issues.

Please tell me if there is a more appropriate place to ask these questions.

I am interested to know whether members of the working group envisage
Device Independent Authoring Language documents being rendered natively
(say, in a web browser) or transformed (with either client or
server-side adaptation) into another format first. Or perhaps both uses
are intended?

I understand that it would be possible to transform a DIAL document into
another format using XSLT, but for server-side adaptation that would
require an XSL stylesheet for every conceivable format, even those which
the author of a document may not envisage.

Also, how far does "device independence" stretch exactly? For example,
do you think a certain resource could be represented by a device as
simplistic as a light switch? A URI could be used to point at a resource
http://house/lounge/lamp which could be rendered by a light switch in
the room or on a control panel somewhere else in the building. Is this
stretching the language too far?

Thank you for your time

Ben Francis

Received on Saturday, 27 May 2006 20:31:41 UTC