DIAL Part 0: Primer

1.1 What is DIAL?

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

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

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

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

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 Reading the examples

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

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

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

2.2 The DIAL specification

DIAL documents must conform to the DIAL specification [DIAL]

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

2.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 [CSS3MQ] 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>				
			

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

2.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 [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.

2.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 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 &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.

2.8 Content metadata