This document provides an introduction to, and the benefits of, DIAL (the Device Independent Authoring Language). It summarizes the concept of device independence, the scenarios in which it could be used, and the considerations in order to achieve that goal. It then describes the role of DIAL in ensuring the delivery of content suitable for the user, device and inherent circumstances in which it was requested.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This is the First Public Working Draft of a possible future W3C Recommendation.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1.1 What is DIAL?
1.2 How does DIAL work?
1.3 When would I use DIAL?
1.4 DIAL specification
1.5 How is DIAL different to existing approaches?
1.5.1 Alternatives to DIAL
1.5.2 Content selection
1.5.3 Declarative syntax
1.5.4 Convenience of flexible authoring
1.5.5 Distributed processing
1.5.6 Grammar validation
2 Examples of DIAL usage
2.1 Reading the examples
2.2 The DIAL specification
2.3 Level of text discourse
2.5 Object fallback
2.8 Content metadata
3 Further reading
The Device Independent Authoring Language [DIAL] is an XML language profile of XHTML version 2 [XHTML2], XForms [XForms] and Content Selection for Device Independence (DISelect) [DISelect], created by the W3C Device Independence Working Group [DIWG].
The goal of DIAL is to overcome the authoring challenges inherent in creating a web page which delivers a harmonized user experience across multiple delivery contexts. As such, DIAL forms a key part of the Device Independence activity "'to assist authors in creating sites and applications that can support device independence in ways that allow it to be widely employed'".
In other words, DIAL facilitates writing a Web page that can be presented by a range of devices, with differing capabilities and states; and consumed by users with differing preferences and entitlements (such varying conditions are illustrated in 'Delivery context characteristics'). This is achieved by allowing authors to declare authorial intent as to the conditions under which content should be chosen or filtered. In this simple example, the author intends that users subscribing to a service receive a premium representation of a content item, and other users receive a regular representation.
... <sel:select> <!-- check if the requesting user is a subscriber--> <sel:when expr="dcn:search('userSubscriptionStatus') = premium"> <!-- if so select this movie --> <object sel:selid="HelloWorldMovie" src="HW_movie_portrait.mov"/> </sel:when> <sel:otherwise> <!-- if not send an image instead --> <object sel:selid="HelloWorldMovie" src="HW_image.jpg"/> </sel:otherwise> </sel:select> ...
Following DIAL processing, the Hello World Movie XHTML markup
<object src="HW_movie_portrait.mov"/> is selected for delivery to the subscriber, and the Hello World image markup (
<object src="HW_movie_portrait.mov"/>) to others
In the examples, the
sel prefix is assumed to be bound to the DISelect namespace, and the
dcn prefix to the Delivery Context namespace. More complex examples of DIAL usage are detailed in 2 Examples of DIAL usage, showing a wider range of context-based selections)
A case for a facility such as DIAL is made in the Introduction to Device Independence [DIINTRO]: "the range of capabilities for input and output, and the range of markup languages and networks supported greatly complicate the task of authoring web sites and applications that can be accessed by users whatever device they choose to use."
In addition, since DIAL implements XHTML 2.0 metadata extensions, it allows other metadata standards to be plugged in to allow content to be selected or excluded for rendering based on variable business rules. These could include flagging the nature of the content (such as erotic or violent), or by indicating that it should only be shown in a certain location or time of day.
The reader is expected to be familiar with the concepts of XHTML 2.0 [XHTML2].
When a request is made for a DIAL document, it MUST pass through at least one DIAL processor before being presented to the requesting user. DIAL processors may exist at any of the server, optional intermediary adaptation, or client layers. Their role is to determine whether to select or filter out blocks of content marked up with DISelect expressions. The evaluation of these expressions requires the processor to query the Delivery Context [DCO], so that the decision to select or filter content involves the specific conditions under which the request was made. After all DIAL processing is complete, all content selections will have been resolved.
Note that the DIAL processors are responsible for evaluating the DISelect expressions, with the aim of producing an XHTML 2.0 representation of the content for that delivery context. The author is at liberty to initiate any subsequent transformation to another markup dialect (such as WML, XHTML 1.1, etc.) as necessary.
Delivery Context Interfaces [DCI] details how the delivery context is represented and how it may be queried by the DIAL processor.
To enable the full potential of DIAL to author should be aware of the potential Delivery Contexts [DCO] available to their system and the subsequent constraints.
DIAL should be considered when it is important to select Web page content that is specific to different users' delivery contexts. For example,
across a range of access devices (computers, mobile phones, PDAs, WebTV etc.) with different capabilities
when the Web page may be accessed via different connections (broadband, modems, UMTS or GPRS mobile bearers, etc.) and interaction modalities (keypad, voice, touch, audio presentation, video display.)
when user state (preferences and entitlements) and business policies can determine which content is presented (such as user age, location, credit balance etc.)
These factors are represented by the following graphic:
The combination of these factors at the time of content request or provisioning represents the delivery context relevant to that request. A change to any of the factors will result in a different delivery context instance: for example, consider the following example of a delivery context changing based on a different interaction mode:
A user drives to a nature reserve. Whilst driving, his device is set to operate via voice and audio interaction, since he is unable to look at the screen.
When he arrives at the nature reserve, he switches the device to a silent, visual interaction mode so as not to startle the wildlife with ringtones or voice interaction.
Declarations in the DIAL document capture the original intent of the author. By evaluating the statements against the current Delivery Context, it is possible to produce of a tailored representation of content for a wide range of situations.
There are numerous existing approaches which attempt to overcome various device independence authoring challenges. In many cases DIAL can supplement these approaches (as outlined below) through a declarative syntax for content selection.
The graphic above shows how existing device independent approaches allow content to be styled and structured according to a subset of delivery context, such as by applying XSLT transformations, server-side page templates, and CSS styles to an XHTML Web page. However there is typically little control over which content should be delivered to the user. Although it is feasible to do this through CSS styles that hide a given
div depending on the evaluation of various device capabilities, this has certain caveats:
it requires the user's device browser to support CSS3 Media Queries [CSS3MQ]
the evaluation is restricted to various presentation feature, not the full Delivery Context [DCO] which includes dynamic properties such as the connection speed, user location, or user preferences.
it results in an inefficient payload: redundant (unused) CSS and markup will be delivered to and discarded by the browser.
However DIAL supplements this approach by allowing content authors to write a single Web page, and declare within it which content or structures are relevant to which delivery contexts, and are subsequently delivered.
|Details regarding layout and its abstraction/representation will be added here as DIWG work progresses. Core Presentation characteristics as defined by other W3C groups (such as the Mobile Web Initiative Device Descriptions group) will be added as work from such groups becomes available.|
Existing techniques such as XSLT or server-side page templates can easily strip or choose blocks of content from a Web page prior to delivery, what DIAL adds is the ability for the author to declare under which circumstances that content should be selected or discarded.
The advantage of declarative selection syntax is that it allows a selection to be made without predicating the processor technology to do so. It also facilitates the swapping of processor implementations: since the selection logic is declared in the markup, there is no need to migrate those declarations between two programming languages.
Having a single document represent the content selections for a range of delivery contexts is arguably more efficient and convenient than the technique of Multiple Authoring: in which a different variant of each content resource is created for use in the user experience for each delivery context without adaptation (see graphic above).
Processors can be present at any, or all, of the server, client, or an optional intermediary layers. This allows a particular content selection decision to be made at the most relevant point: for example, static device capabilities (such as device width) and user state (age) may be known at the server layer, and the appropriate content selected. However it may make sense for a selection based on a volatile property (such as battery life, current screen orientation or bandwidth) to be deferred to the client. This decision of when to process is facilitated by DIAL's declarative syntax, which does not predicate the same programming language to evaluate the declarations in each layer.
|The discussion of how to negotiate the responsibility for processing a particular statement between processors is ongoing|
Since DIAL is an XML [XML] dialect, it may be validated to check that its grammar and structure corresponds to the DIAL specification. This is not the case with server-side templates (such as PHP, JSP, ASP, etc.) since they typically mix programming code with markup.
|The DIAL XML schema is currently under development.|
See Delivery Context Interfaces [DCI] for details on how the delivery context is represented and queried by the DIAL processor(s).
Elements and attributes with the
sel: prefix are bound to the DISelect namespace URI
Function names starting with
di-cssmq are the DISelect starter set XPATH functions for delivery context access derived from facilities in CSS 3 media queries [CSS3MQ]
Attribute values with the
dcn: prefix are bound to the Delivery Context [DCO] namespace,
|The examples will be illustrate schema and namespace declarations once the DIAL schema is available|
DIAL documents must conform to the DIAL specification [DIAL]
|The XML schema for DIAL is pending, awaiting on a XML schema implementation of XHTML 2.0|
Under a given delivery context it may be appropriate to deliver a teaser, summary, or full article representing the same textual content. In this example, the speed of connection (bandwidth) is the deciding factor as to what will be selected:
<!-- query the current bandwidth and store in a convenience variable--> <sel:variable name="bandwidth" value="dcn:search('bandwidth')" <sel:select> <!-- in this delivery context example the bandwidth may be low, medium, or high --> <sel:when expr="$bandwidth = 'slow'"> <p>Hatton wins big fight</p> </sel:when> <sel:when expr="$bandwidth = 'medium'"> <p>Ricky Hatton wins by 9th round knockout to claim world championship belt</p> </sel:when> <sel:when expr="$bandwidth = 'high'"> <p>...(full article text here, including hi-res image)...</p> </sel:when> </sel:select>
Although mechanisms exist to automatically adapt a single image at request time, so that it best suits the requesting device, DIAL allows graphic designers to ensure suitable pre-built images may be selected. Typically these will be of a higher quality than an adapted image.
<!-- query the requesting device's browser resolution in dpi and store in a convenience variable--> <sel:variable name="res" value="di-cssmq-resolution('dpi')"/> <sel:select> <sel:when expr="$res > 500> <object sel:selid="Cornish Yarg" src="yarg_hi.jpg"/> </sel:when> <sel:when expr="$res > 200> <object sel:selid="Cornish Yarg" src="yarg_mid.jpg"/> </sel:when> <sel:otherwise> <object sel:selid="Cornish Yarg" src="yarg_low.gif"/> </sel:otherwise> </sel:select>
Here follows a more complex example involving multiple selection criteria, and nested expressions. The author's intent is to deliver a full movie to premium subscribers with devices connected on a fast bandwidth. If these criteria are not met, or if the subscriber's device does not support movies, or the battery level is low, then an image will be sent instead. In addition the author wishes to deliver a movie (where relevant) tailored for the current screen orientation, taking into account that the user may have a swivel-screen device.
<!-- all sel: elements are from the DISelect namespace, all dcn: elements are from the Delivery Context Interfaces namespace--> <!-- acquire contextual information. The dcn: queries here have example search arguments--> <sel:variable name="power" value="dcn:search('battery')"/> <sel:variable name="bandwidth" value="dcn:search('bandwidth')"/> <sel:variable name="playMovies" value="dcn:search('movieSupport')"/> <sel:variable name="isSubscriber" value="dcn:search('userSubscriptionStatus')"/> <!-- orientation here includes devices where the user has manually changed orientation via a swivel-screen--> <sel:variable name="orientation" value="dcn:search('currentScreenOrientation')"/> <!-- ensure that the user receives content suitable for their delivery context...--> <sel:select> <!-- first check if the user is a subscriber and are entitled to premium content--> <sel:when expr="$isSubscriber = true"> <sel:select> <!-- note we can nest declarations... --> <!-- if this next statement is true, we know we can deliver a movie:--> <sel:when expr="$power > 20 and $playMovies= true and $bandwidth='fast'"> <sel:select> <sel:when expr="$orientation='portrait'"> <object sel:selid="HelloWorldMovie" src="HW_movie_portrait.mov"/> </sel:when> <sel:when expr="$orientation='landscape'"> <object sel:selid="HelloWorldMovie" src="HW_movie_landscape.mov"/> </sel:when> <sel:otherwise><!--connection and battery prevent movie being sent--> <object sel:selid="HelloWorld" src="HW.jpg"/> <p>Your battery or bandwidth are not sufficient for the full content - please try later</p> </sel:otherwise> </sel:select> <sel:otherwise><!-- not a subscriber--> <object sel:selid="HelloWorld" src="HW.jpg"/> <p>Subscribe to see the full content!</p> </sel:otherwise> </sel:select> </sel:select>
DIAL includes the XFORMS modules available to XHTML 2.0 . "XForms 1.0 defines a device-neutral, platform-independent set of form controls suitable for general-purpose use.". XFORMS brings the following specific benefits to a device independent system:
Multiple device support: "The high-level nature of the user interface controls, and the consequent intent-based authoring of the user interface makes it possible to re-target the user interaction to different devices." (from the Introduction to XForms [XForms]).
An example of this is the use of the
'Select one only' code example
<select1 ref="my:flavor"> <label>Flavor</label> <item> <label>Vanilla</label> <value>v</value> </item> <item> <label>Strawberry</label> <value>s</value> </item> <item> <label>Chocolate</label> <value>c</value> </item> </select1>
'Select one or many' code example
<select ref="my:flavors"> <label>Flavors</label> <choices> <item> <label>Vanilla</label> <value>v</value> </item> <item> <label>Strawberry</label> <value>s</value> </item> <item> <label>Chocolate</label> <value>c</value> </item> </choices> </select>
These imply author intent (the ability for the user to 'select multiple' or 'choose one' respectively). As such it is left up to the device browser to present the selection in the most suitable manner, as regards ease of navigation, screen width etc.
Separation of concern
XFORMS improves on HTML forms by separating structure and purpose from presentation, in order to meet the goal of device independence. This allows the content author to provide separate style directives for the current device context to provide a functional user experience.
Client side validation
An authoring challenge for tables is that there is a limit to the number of columns which can be provided across all delivery contexts. For example, a small-screen device will be unable to display all columns without making the cell contents so small as to be illegible.
DIAL provides the ability to selectively include a column, depending on the delivery context. This ensures that the less semantically important columns can be excluded, leaving a less rich, but still functional, user experience.
This selection is achieved by use of the
expr attribute on the XHTML 2.0
col element. If the
expr attribute is not present, that column is considered to be critical and will appear in all delivery contexts (assuming that the ancestor elements of the col are not excluded via evaluation of their own DI Select statements)..
The DIAL processor will evaluate the XPATH expression in the
expr attribute, based on the delivery context. If
true, then the
col will be included; if
false, it will not be included as the output of DIAL processing.
In the following example, we have a table representing the status of three teams in a local five-a-side football league.
<!-- store the usable display width in a variable for convenience and performance--> <sel:variable name="dispWidth" value="dcn:cssmq-width('px')"/> <table> <colgroup id="league-table"> <!-- for each column, declare when it should be selected. Absence of sel:expr means it must be selected in all delivery contexts--> <col id="position"/> <col id="logo" /> <col id="name" sel:expr="$dispWidth > 400"/> <col id="played" sel:expr="$dispWidth > 400"/> <col id="won" sel:expr="$dispWidth > 150" /> <col id="drawn" sel:expr="$dispWidth > 150" /> <col id="lost" sel:expr="$dispWidth > 150" /> <col id="goals-for" sel:expr="$dispWidth > 600" /> <col id="goals-against" sel:expr="$dispWidth > 600"/> <col id="goal-difference" sel:expr="$dispWidth > 150" /> <col id="points" /> </colgroup> <tbody> <tr> <th>Position</th> <th>Team</th> <th>Name</th> <th>P</th> <th>W</th> <th>D</th> <th>L</th> <th>F</th> <th>A</th> <th>GD</th> <th>Pts.</th> </tr> <!-- ...instance data for the table here.--> </tbody> </table>
The columns provide some information crucial to understanding the league table (position, team identifier, points) and supplementary information that provides further detail (played, won, drawn, lost, goals for and against). Since we are expecting to deliver the table to delivery contexts that cannot display all the data, we can inform the DIAL processor to exclude the less important columns. In this case we have included the
sel:expr attribute from DISelect [DISelect] to evaluate whether the usable device width is above certain thresholds. The useable device width is determined via the
dcn:cssmq-width function from Delivery Context: XPath Access Functions 1.0 [DCXPath].
The following diagrams show the result of requesting and rendering the example table with various delivery contexts.
The first table instance (above) contains all available information and would be rendered on a device with a wider display (greater than 600 pixels in this case), such as a desktop computer or Web TV. In these contexts, all the
sel:expr statements have evaluated to
true, and so all columns are included.
The second instance has been requested by a device with a usable width of 405 pixels. As such all
sel:expr statements evaluate to
true, except for:
<col id="played" sel:expr="$dispWidth > 500"/> <col id="goals-for" sel:expr="$dispWidth > 600" /> <col id="goals-against" sel:expr="$dispWidth > 600"/>
...and hence these are excluded.
The final instance shows the result of a request from a device with narrow usable width (less than 150 pixels). As such all the
sel:expr statements evaluate to
false, and only those critical columns without selection statements are included.
For the example above where display is conditional on the device width, it is possible to achieve the same result using CSS3 Media Queries [CSS3MQ] directly. However the caveat is that technique will only work on devices compliant with that specification.
|Needs further discussion. Is the DIAL processor only responsible for evaluating |
The reader is directed to the References section below, and is recommended to start with the DISelect and Delivery Context overview [DCO] documents.
At the time of publication, the participants of the Device Independence Working Group are:
The Device Independence Working Group has benefited in its work from the participation and contributions of a number of people not currently members of the Working Group, including in particular those named below. Affiliations given are those current at the time of their work with the WG.