W3C

DIAL Part 0: Primer

Device Independent Authoring Language

W3C Working Draft 10 October 2006

This version:
http://www.w3.org/TR/2006/WD-dial-primer-20061010/
Latest version:
http://www.w3.org/TR/dial-primer/
Previous version:
This is the first published Working Draft
Editor:
Kevin Smith, Vodafone Group

Abstract

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.

Status of this Document

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 is published as part of the W3C Device Independence Activity by the Device Independence Working Group (Member Only Link). It is a deliverable as defined in the Charter of that group.

Comments on this document may be sent to the public www-di@w3.org mailing list (archived at http://lists.w3.org/Archives/Public/www-di/).

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.

Table of Contents

1 Introduction
    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.4 Images
    2.5 Object fallback
    2.6 Forms
    2.7 Tables
    2.8 Content metadata
3 Further reading

Appendices

A References (Non-Normative)
    A.1 Device Independence Working Group
    A.2 Other references
B Acknowledgements (Non-Normative)


1 Introduction

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

Note:

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

1.2 How does DIAL work?

diagram showing the DIAL process

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 various factors which would encourage use of DIAL

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.1 Alternatives to DIAL

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.

1.5.2 Content selection

transformation and styling process

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.3 Declarative syntax

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.

1.5.4 Convenience of flexible authoring

each requesting delivery context requires specific Web page markup

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

1.5.5 Distributed processing

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.

Editorial note 
The discussion of how to negotiate the responsibility for processing a particular statement between processors is ongoing

1.5.6 Grammar validation

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.

Editorial note 
The DIAL XML schema is currently under development.

2 Examples of DIAL usage

Note:

See Delivery Context Interfaces [DCI] for details on how the delivery context is represented and queried by the DIAL processor(s).

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.

Editorial note 
The examples will be illustrate schema and namespace declarations once the DIAL schema is available

2.2 The DIAL specification

DIAL documents must conform to the DIAL specification [DIAL]

Editorial note 
The XML schema for DIAL is pending, awaiting on a XML schema implementation of XHTML 2.0

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.

    different types of forms

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

table rendered for a wide-display delivery context

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.

table rendered for a smaller display delivery context

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.

table rendered for a narrow-display delivery context

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.

Note:

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.

2.8 Content metadata

Editorial note 
Needs further discussion. Is the DIAL processor only responsible for evaluating sel statements, or for other content declarations? For example the ICRA tagging on a content item could be combined with evaluation of the delivery context to select or filter the content.

3 Further reading

The reader is directed to the References section below, and is recommended to start with the DISelect and Delivery Context overview [DCO] documents.

A References (Non-Normative)

A.1 Device Independence Working Group

DIWG
W3C Device Independence Working Group (See http://www.w3.org/2001/di/.)
DIINTRO
Introduction to Device Independence S.Boyera, R. Lewis, 2004 W3C Ubiquitous Web Domain (See http://www.w3.org/2001/di/IntroToDI.html.)
DIP
Device Independence Principles R.Gimson, 2003. W3C Working Note (See http://www.w3.org/TR/di-princ/.)
Glossary
Glossary of Terms for Device Independence R.Lewis, 2005. W3C Working Draft (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/.)
ACDI
Authoring Challenges for Device Independence R. Lewis, 2003. W3C Note (See http://www.w3.org/TR/acdi/.)
DCO
Delivery Context R. Gimson et al, 2006 W3C Working Note (See http://www.w3.org/TR/di-dco/.)
DCI
Delivery Context: Interfaces (DCI) K. Waters et al, 2005 W3C Working Draft (See http://www.w3.org/TR/DPF/.)
DCXPath
Delivery Context: XPath Access Functions 1.0 R.Lewis and R.Merrick, 2006. W3C Working Draft (See http://www.w3.org/TR/2006/WD-cselection-xaf-20061010/.)
DISelect
Content Selection for Device Independence (DISelect) R.Lewis and R.Merrick, 2006. W3C Working Draft (See http://www.w3.org/TR/cselection/.)
DIAL
Device Independent Authoring Language (DIAL) K Smith 2006. W3C Working Draft (See http://www.w3.org/TR/dial/.)

A.2 Other references

RFC2119
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels . Internet Engineering Task Force, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
CSS3MQ
CSS3 Media Queries Håkon Wium Lie et al., 2003. W3C Candidate Recommendation (See http://www.w3.org/TR/css3-mediaqueries/.)
XHTML2
XHTML TM 2 J. Axelsson et al., 2003. W3C Working Draft (See http://www.w3.org/TR/xhtml2/.)
CC/PP
Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0 G.Klyne, et al., 2004. W3C Recommendation (See http://www.w3.org/TR/CCPP-struct-vocab/.)
XForms
XForms 1.0 M. Dubinko et al., 2003 W3C Recommendation (See http://www.w3.org/TR/xforms/.)
CSS
Cascading Style Sheets, level 2 revision 1 B. Bos et al., 2004 W3C Candidate Recommendation (See http://www.w3.org/TR/CSS21/.)
XML
XML Extensible Markup Language (XML) 1.1 (Second Edition), T. Bray et al, W3C Recommendation August 2006 (See http://www.w3.org/TR/xml11/.)
XSLT
XSL Transformations (XSLT) Version 1.0 J. Clark, 1999 W3C Recommendation (See http://www.w3.org/TR/xslt.)

B Acknowledgements (Non-Normative)

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.