DIAL Part 0: Primer

1.1 What is DIAL?

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

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].

1.2 How does DIAL work?

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.

1.3 When would I use DIAL?

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.

1.4 DIAL specification

See the DIAL specification [DIAL] for information on DIAL grammar and conformance.

1.5 How is DIAL different to existing approaches?

1.5.2 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 span or 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.

Editorial note
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.

1.5.4 Convenience of flexible authoring

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).

2.1 Device-specific UI 1

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 preferred and alternate stylesheet selection in XHTML2.0, and so when her Webpages are requested the user is able to choose which stylesheet they prefer.

2.2 Device-specific UI 2

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.

2.3 Delivery-context specific UI

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

2.4 Device-specific content

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.

2.5 User-specific content 1

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.

2.6 User-specific content 2

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.

2.7 Time-specific content

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 DISelect 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 page.

2.8 Location-specific content

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 DISelectsel: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 away.

2.9 Declarative content

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.

3.1 Reading the examples

The examples below are DIAL code snippets showing DISelect expressions within XHTML 2 [XHTML 2]

Elements and attributes with the sel: prefix are bound to the DISelect namespace URI http://www.w3.org/2004/06/diselect

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 Context] namespace, http://www.w3.org/2004/06/dc.

3.2 The DIAL specification

DIAL documents must conform to the DIAL specification [DIAL]

3.3 Level of text discourse

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> 

3.4 Images

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.

In this example, DISelect's representation of [CSS3 Media Queries] is used as a selection criterion.

<!-- 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 &gt; 500>
   <object sel:selid="Cornish Yarg" src="yarg_hi.jpg"/>
 </sel:when>
 <sel:when expr="$res &gt; 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> 

3.5 Object fallback

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 &gt; 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> 

3.6 Forms

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 and select1 elements.

  '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

  The author may validate (enforce syntactic rules) of the form prior to submission, for example ensuring that a certain field contains an entry or that the entry in a password field matches that in the 'repeat password' field. Although this is possible using scripting , the implementation of (for example) JavaScript on mobile devices varies. As such the declarative nature of XFORMS validation allows the device to implement the validation rules in the most appropriate way.

3.7 Tables

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 &gt; 400"/>
                <col id="played" sel:expr="$dispWidth &gt; 400"/>
                <col id="won" sel:expr="$dispWidth &gt; 150" />
                <col id="drawn" sel:expr="$dispWidth &gt; 150" />
                <col id="lost" sel:expr="$dispWidth &gt; 150" />
                <col id="goals-for" sel:expr="$dispWidth &gt; 600" />
                <col id="goals-against" sel:expr="$dispWidth &gt; 600"/>
                <col id="goal-difference" sel:expr="$dispWidth &gt; 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 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 &gt; 500"/>
                <col id="goals-for" sel:expr="$dispWidth &gt; 600" />
                <col id="goals-against" sel:expr="$dispWidth &gt; 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.

3.8 Content metadata