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/.
This is a Working Draft of a possible future W3C Recommendation.
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 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 Use cases for DIAL
2.1 Device-specific UI 1
2.2 Device-specific UI 2
2.3 Delivery-context specific UI
2.4 Device-specific content
2.5 User-specific content 1
2.6 User-specific content 2
2.7 Time-specific content
2.8 Location-specific content
2.9 Declarative content
3 DIAL code examples
3.1 Reading the examples
3.2 The DIAL specification
3.3 Level of text discourse
3.5 Object fallback
3.8 Content metadata
4 Further reading
The Device Independent Authoring Language [DIAL] is an XML language profile of XHTML version 2 [XHTML 2], 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"/>e </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
(The declarations are bound to the
sel namespace of DISelect
http://www.w3.org/2005/sel ; and the XPATH expressions
dcn: values of the
expr attribute values) are
bound to the Delivery Context [Delivery Context] namespace,
http://www.w3.org/2004/06/dc. More complex examples of DIAL usage are detailed below, showing a
wider range of context-based selections)
A case for a facility such as DIAL is made in the Introduction to Device Independence Overview [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 [XHTML 2].
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 [DISelect] expressions. The evaluation of these expressions requires the processor to query the Delivery Context [Delivery Context], 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 [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 [Delivery Context Interfaces] 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 [Delivery Context]s 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 these 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[CSS3 Media Queries]
the evaluation is restricted to various presentation feature, not the full Delivery Context [Delivery Context] 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 [DIAL] is an XML [XML] dialect, it may be validated to check that its grammar and structure corresponds to the DIAL specification [DIAL]. This is not the case with server-side templates (such as PHP, JSP, ASP, etc.) since they typically mix programming code with markup.
|The discussion of how to negotiate the responsibility for processing a particular statement between processors is ongoing|
The following are illustrative, non-exhaustive use cases for DIAL
Susan is a content author who wishes her Website to be rendered
sympathetically depending on the device that has accessed it. She also wishes
to make use of rich user interface (UI) features where available, and simple
UI for less sophisticated devices; however she does not wish to spend a lot
of time differentiating between a large number of devices. She creates a DIAL
document which makes use of the CSS
selection in XHTML2.0, and so when her Webpages are requested the user is
able to choose which stylesheet they prefer.
Angela is a professional content author who wishes for the UI of her Website to be tailored according to the nature of the device requesting it. She therefore produces DIAL document with a CSS2 stylesheet which makes extensive use of media queries which declare the conditions under which the stylesheet instructions are executed.
Hwang runs a mobile-friendly Website which receives many hits from high-end devices with sophisticated browsers. However he is aware that the bandwidth of such devices varies greatly over time and location. Wishing to provide a good UI but without using too much bandwidth, Hwang creates a DIAL document which provides links to multiple CSS stylesheets, wrapped in DISelect statements. These statements contain expressions which determine if the bandwidth is sufficient to provide access to a rich, medium, or basic stylesheet. At request time the DISelect expressions are resolved, and the device browser requests the selected CSS stylesheet
Sid runs a mobile download site with a range of games. These are specific to particular devices, so if a game is selected he wants the user to be presented by a link to the game that will work on his or her device. As such his DIAL homepage contains multiple links to the 'games' section, each of which are wrapped in a DISelect construct. The DISelect expressions determine which link is appropriate to which device. At request time, the irrelevant links are stripped out of the DIAL document, and the user receives a Web page with a link to games only suitable to their device.
Nupur's magazine website offers a range of articles for all users. As a responsible webmaster, she ensures that her site fully complies with Web Content Accessibility Guidelines. In order to Ensure Graceful Transformation of content, she uses DIAL to provide full text equivalents for all images so that visibility-impaired users may receive a rich description of their content. At request time, the DISelect expressions which ask whether the user has a preference for text-only content are resolved: the DIAL processor calls a server-side preferences database with the user's identity to determine this. As such, when James, who is blind, requests the content, the image tags are filtered out of the page leaving the rich text equivalent.
Sven's gambling Website offers a service which is only suitable for users who are over 18. He also has some universal free content available to all. He creates a DIAL page which wraps these two links in DISelect statements. At request time these expressions are resolved by the DIAL processor, which determines from a trusted source whether the user is over 18. When 16 year old Barry accesses the site the link to the adult-only site is filtered out accordingly.
Horatio runs a news site and is aware that throughout the week his readers
are more, or less, interested in particular topics. These topics are laid-out
on his homepage as blocks of content, with a title, lead article and links in
each. He creates this homepage using DIAL, wrapping the blocks of content in
DISelect expressions which query the time at which the page has been
requested. Between 3pm to 6pm on a Saturday, the statements resolve to allow
the football content to appear at the top of the screen, for the rest of the
day world news is allocated the top spot. This layout is achieved through
sel:whenstatements to allocate an appropriate XHTML
div/@id based on the time of request - the CSS stylesheet will
then place the block with
div/@id='top' at the top of the
Pierre's restaurant review site allows users to determine the best places
to eat, all over Europe. When users are on the move, Pierre wants to present
them a mobile-friendly version of the site, which will make use of location
data to present the user with links and maps to the restaurants closest to
him or her. He previously used an HTML homepage with a form which asked the
user to manually enter their location, and hence link to the appropriate city
pages. Using DIAL, however, he can wrap multiple links in a
sel:select construct, which resolve the user's location
via the DCCI API. At request time,
the correct location is established and irrelevant links are stripped
Hannah oversees the deployment of a portal to a number of countries within her organisation. Among these countries the server-side technology used to produce their dynamic portal differs, however the business logic is the same. Hannah's development team code the portal using DIAL, which allows each country to create their own DIAL processor in their favoured programming language to resolve the DISelect statements in the portal. This reduces the burden on Hannah's developers to realise the poral code in multiple programming languages each time the portal is released.
See Delivery Context Interfaces [Delivery Context Interfaces] 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
Attribute values starting with
di-cssmq are the DISelect starter set XPATH
functions for delivery context access derived from facilities in CSS 3
media queries [CSS3 Media Queries]
Attribute values with the
dcn: prefix are bound to the
Delivery Context [Delivery
|The examples will be illustrate schema and namespace declarations once the DIAL schema is available|
|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 big fight and becomes pound-for-pound king</p> </sel:when> <sel:when expr="$bandwidth = 'high'"> <p>...(full article text here, including hi-res image of the knockout punch)...</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).
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
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 to evaluate whether the usable device width is above certain thresholds. The useable device width is determined via the Delivery Context: XPath Access Functions 1.0 [DCXPATH] dcn:cssmq-width function.
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
sel:expr statements have evaluated to
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
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 [CSS3 Media Queries] 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
This document was produced with the participation of the Device Independence Working Group participants:
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.