W3C

Content Selection for Device Independence (DISelect) 1.0

W3C Working Draft 11 June 2004

This version:
http://www.w3.org/TR/2004/WD-cselection-20040611/
Latest version:
http://www.w3.org/TR/cselection/
Previous version:
This is the first public working draft
Editors:
Rhys Lewis, Volantis Systems Ltd. <rhys@volantis.com>
Roland Merrick, IBM <roland_merrick@uk.ibm.com>

Abstract

This document specifies a syntax and processing model general purpose selection. Selection involves conditional processing of various parts of an XML information set according to the results of the evaluation of expressions. Using this mechanism some parts of the information set can be selected for further processing and others can be suppressed. The specification of the parts of the infoset affected and the expressions that govern processing is by means of XML-friendly syntax. This includes elements, attributes and XPath expressions. This document specifies how these components work together to provide general purpose selection.

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 under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure.

Patent disclosures relevant to this document may be found on the WG patent disclosure page.

Table of Contents

1 Introduction
    1.1 Reading the Specification
    1.2 How the Specification is Organized
    1.3 Documentation Conventions
2 Overview
    2.1 Towards a Device Independent Profile
    2.2 The Selection Module
3 Processing Model
    3.1 Processing Overview
    3.2 Events
    3.3 Error Indications
        3.3.1 diselect-redeclaration-error Event
4 Attributes for Conditional Processing
    4.1 Overview
    4.2 The sel:expr Attribute
    4.3 The sel:selid Attribute
    4.4 Examples
5 Elements for Conditional Processing
    5.1 Overview
    5.2 The sel:if Element
        5.2.1 Attributes
    5.3 The sel:select Element
        5.3.1 Attributes
        5.3.2 Processing
    5.4 The sel:when Element
        5.4.1 Attributes
    5.5 The sel:otherwise Element
    5.6 Examples
6 Variables
    6.1 The sel:variable Element
        6.1.1 Attributes
        6.1.2 Declaring a Variable
        6.1.3 Referencing an existing Variable
        6.1.4 Scope of Variables and Nesting
        6.1.5 Type
    6.2 Examples
7 Expressions in DISelect
8 Starter Set XPath Functions for Delivery Context Access
    8.1 The dc:cssmq-width function
    8.2 The dc:cssmq-height function
    8.3 The dc:cssmq-device-width function
    8.4 The dc:cssmq-device-height function
    8.5 The dc:cssmq-device-aspect-ratio function
    8.6 The dc:cssmq-device-aspect-ratio-width function
    8.7 The dc:cssmq-device-aspect-ratio-height function
    8.8 The dc:cssmq-color function
    8.9 The dc:cssmq-color-index function
    8.10 The dc:cssmq-monochrome function
    8.11 The dc:cssmq-resolution function
    8.12 The dc:cssmq-scan function
    8.13 The dc:cssmq-grid function
    8.14 Units
        8.14.1 Length Units
        8.14.2 Resolution Units
9 Formal Definitions
    9.1 The Content Selection Namespace
    9.2 Schema

Appendices

A References
    A.1 Normative References
    A.2 Informative References
B Editor's Notes
    B.1 Changes in This Version
        B.1.1 Changes in the Version Dated 30 April 2004
        B.1.2 Changes in the Version Dated 1 March 2004
        B.1.3 Changes in the Version Dated 21 January 2004
        B.1.4 Changes in the Version Dated 14 December 2003
        B.1.5 Changes in the Version Dated 31 November 2003
    B.2 Open Issues


1 Introduction

1.1 Reading the Specification

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [IETF RFC 2119].

Expressions in the examples used in this document are based on [XPath 1.0]. This syntax requires that specific characters be escaped appropriately for use within XML processors. This quoting is used explicitly throughout the document.

1.2 How the Specification is Organized

1.3 Documentation Conventions

Throughout this document, the following namespace prefixes and corresponding namespace identifiers are used:

sel:

The DISelect namespace (http://www.w3.org/2004/06/diselect) described in The Content Selection Namespace.

dc:

The Delivery Context namespace (http://www.w3.org/2004/06/dc)

xsd:

The XML Schema namespace (http://www.w3.org/2001/XMLSchema) [XML Schema Part 1]

no prefix

The XHTML 2 namespace (http://www.w3.org/2002/06/xhtml2) [XHTML 2] is used as the default namespace in this document.

The XML representations of various elements within DISelect are presented using the syntax for Abstract Modules in XHTML Modularization [XHTML Modularization]

2 Overview

2.1 Towards a Device Independent Profile

This specification represents one part of the approach being developed within DIWG for the provision of a markup language that supports creation of web sites that can be used from a wide variety of devices with a wide variety of characteristics.

The overall approach being taken by DIWG is based on the development of a device independent profile for XHTML. The profile will be based on XHTML Version 2[XHTML 2], XForms[XForms] and current and forthcoming versions of CSS[CSS]. DIWG is developing additional modules that can be added to this combination of specifications to complete the profile. This specification describes the module that provides selection between versions of materials.

2.2 The Selection Module

In its paper on Authoring Challenges[Authoring Challenges], DIWG identified a series of challenges faced by authors trying to create materials that could be used on a wide variety of devices with very different characteristics. One common theme emerging from this work was the need to support authors in the specification of variability in the materials they produce.

In its paper on Device Independence Principles [DI Principles], DIWG has pointed out that the process by which authored materials are adapted for use on particular devices may take place at any point between the source of the material and the device.

The combination of these two requirements argues for a capability by which authors can provide alternative versions of their materials, from which a particular version can be chosen during adaptation. It also argues that the mechanism by which such selection can be performed should not be excessive in its processing demands, since it may need to be performed on a device with limited capacity.

Some user agents provide programming capability that can be exploited by authors to achieve results similar to those described in this specification. For example, [ECMAScript] is available in some browsers. Such facilities are, of course, very powerful, and allow dynamic modification of and interaction with the page during the user interaction. However, they are not universally available. In addition, the intent of the author is embodied within the program code rather than being declared within markup. This may cause difficulties in interpretation for assistive technologies, for example.

This specification provides a simple mechanism for the selection of the content that is to be expressed when adaptation takes place. It does not attempt to provide the dynamic modification associated with browser programming, embodied in languages such as [ECMAScript], nor does it attempt to provide the comprehensive transformation capabilities of [XSLT]. Rather, it provides capabilities that could be implemented using those mechanisms, but in a way that can requires only modest capability from the processors involved.

3 Processing Model

Editorial note 
We need to add a definition of the processing model here. We'll follow the XInclude approach of positioning the document that contains DISelect items as the input to a step in which it is replaced by host markup based on processing of DISelect. Probably worth a diagram too. We also need to cover appropriate use here. Though syntactically the elements and attribute may be used anywhere within the host markup, not all such uses will lead to valid infosets. Whether they do or not is dependent on the host language syntax.

3.1 Processing Overview

TO BE COMPLETED

3.2 Events

TO BE COMPLETED

3.3 Error Indications

Error indications happen as a result of unusual conditions in the DISelect Processor. Some of these are fatal errors, which halt processing, and bear the suffix exception. Non-fatal errors are raised for notification. They do not cause the DISelect processor to halt. They bear the suffix error. It is permissible for the DISelect Processor to perform some kind of default handling for any of the events described in this section. For example, a DISelect processor might choose to log error messages to a file by default.

3.3.1 diselect-redeclaration-error Event

TO BE COMPLETED

4 Attributes for Conditional Processing

This section is normative.

4.1 Overview

DISelect provides two attributes that can be used with elements of the host language. This section describes those attributes. One attribute, sel:expr , simplifies the specification of selection under certain circumstances. The other attribute, sel:selid , provides a mechanism for avoiding problems associated with duplication of values of host language id attributes.

4.2 The sel:expr Attribute

The section Elements for Conditional Processing describes an element-based mechanism that is appropriate in specific circumstances. In particular, if the decision applies to a significant amount of content, it is more appropriate to use the element-based form. Similarly, if a single decision relates several different versions of a piece of content, the element-based form is also more appropriate. However, for decisions that affect small amounts of content, it can be more convenient to use an attribute-based form that affects individual elements of the host markup.

The sel:expr optional attribute can be used with elements of the host language. It defines a conditional expression used to determine whether or not the element is selected for processing. If the result of the expression is true, the element is selected for processing. If the result is false, it is omitted from processing.

The default value of this attribute is true. Consequently, if the attribute is omitted, a processor must treat the associated element as if the value were true and include it for processing.

4.3 The sel:selid Attribute

The notion of unique identifiers that can be associated with particular elements in markup languages is common if not universal. Using them allows particular instances to be selected, so that, for example, links can be created or particular styling can be specified.

The uniqueness of these identifiers usually forms part of the validity constraints associated with the host language. The presence of multiple elements with the same identifier violates the constraints and makes the associated document invalid. This is a potential issue when the host language is combined with a selection mechanism, such as the one detailed here. An author may wish to provide alternative versions of particular elements to be used under different circumstances. Both versions may need to carry the same identifier. Consequently, although the document resulting from processing the selection markup will be valid, the document containing the selection markup is not. The sel:selid attribute provides a solution for this problem.

The sel:selid optional attribute can be used with elements of the host language. It defines the identifier that will be associated with the host language element on which it is used. During processing, the DISelect processor replaces the sel:selid attribute with a host language id attribute with the same value as that of the sel:selid attribute.

Examples of the use of sel:selid can be found in the examples of the use of elements for selection.

Editorial note 
Do we need to provide additional control over the attribute generated when selid is processed? For example, do we need to allow the namespace prefix to be controlled? If so, where is this control exercised? Could it be, for example, an attribute on select? What about the name of the generated attribute? Currently we assume that it is called id, possibly with some namespace prefix. We might need to be able to allow it to be set somewhere.

4.4 Examples

This section is informative.

The following example illustrates suppression of the display of an image if the usable width of the display on a device is too small. The first and third paragraphs containing the text are always presented. However, the second paragraph containing the image is shown only if the dc:cssmq-width function indicates that the usable width of the device display is more than 200 pixels.

<p>The flooding was quite extensive.</p>
<p sel:expr="dc:cssmq-width('px') &gt; 200"><object src="image1"/></p>
<p>Many people were evacuated from their homes.</p>

The conditional expressions used within the select attribute can contain multiple terms that relate, for example, to different characteristics from the delivery context. So, for example, if the image should only be shown on devices with color displays wider than 200 pixels, the following markup might be used.

<p>The flooding was quite extensive.</p>
<p sel:expr="dc:cssmq-width('px') &gt; 200 &amp; dc:cssmq-color() &gt; 0"><object src="image1"/></p>
<p>Many people were evacuated from their homes.</p>

In this version of the example, the value of the sel:expr attribute is true only if the dc:cssmq-width function indicates that the usable width of the device is more than 200 pixels and that the dc:cssmq-color function indicates that the display supports color.

5 Elements for Conditional Processing

This section is normative.

5.1 Overview

5.2 The sel:if Element

This element defines a set of material that is to be selected for processing if the associated conditional expression has the appropriate value. This element provides an alternative to use of the sel:expr attribute alone when a particular condition applies to several elements of the host language. In particular, the sel:if element allows control to be applied to an arbitrary fragment of the host language that does not itself have a single root element.

Note that there is no sel:else element. Instead, the sel:select element and its children, provide the mechanism for choosing between alternative versions of material.

5.2.1 Attributes

sel:expr

This mandatory attribute determines defines an expression used in determining whether or not the body content of the element is selected for processing. If the expression evaluates to an xsd:boolean value of true, the body content of the sel:when element is selected for processing.

5.3 The sel:select Element

This element encloses material that is subject to conditional selection for processing. Its body content consists of one or more sel:when elements and an optional sel:otherwise element. Expressions associated with the sel:select and sel:when elements control the conditions under which particular parts of the content are processed.

5.3.1 Attributes

sel:expr

This optional attribute determines whether or not the entire sel:select element is itself selected for processing. Details of this attribute are given in The sel:expr Attribute.

sel:precept

This mandatory attribute defines the basic rule applied to matching within the sel:select element.

matchfirst

This is the default value.

When this value is specified, the body content of only the first sel:when element which is selected for processing is used. The body content of other sel:when elements is ignored. The body content of any sel:otherwise element is ignored if one of the sel:when elements is selected for processing.

matchevery

When this value is specified, the body content of every sel:when element which is selected for processing is used. The body content of any sel:otherwise element is ignored if at least one of the sel:when elements is selected for processing.

5.3.2 Processing

The sel:when elements within a select are processed in document order. This is significant in that the order can affect which sel:when element is chosen when the sel:precept is set to matchfirst. It also affects the order in which material is processed when the sel:precept attribute is set to matchevery and multiple sel:when elements are selected for processing.

5.4 The sel:when Element

This element defines a set of material that is to be selected for processing if the associated conditional expression has the appropriate value. A single sel:select element may contain multiple sel:when elements.

5.4.1 Attributes

sel:expr

This optional attribute determines defines an expression used in determining whether or not the body content of the element is selected for processing. If the expression evaluates to an xsd:boolean value of true, the body content of the sel:when element is selected for processing. Note, however, that the value of the sel:precept attribute of the containing sel:select element determines overall which sel:when elements are considered for possible selection.

5.5 The sel:otherwise Element

This element defines a set of material that is to be selected for processing if none of the sel:when elements within the containing sel:select element are selected for processing.

5.6 Examples

This section is informative.

In this first example, the sel:expr attribute on the sel:if element controls the selection. If the display on the device is more than 200 pixels wide, both the image and the paragraph are selected for inclusion. If the display is not more than 200 pixels wide, neither is shown.

<sel:if sel:expr="dc:cssmq-width('px') &gt; 200">
  <object src="image1"/>
  <p>Many people had to be evacuated.</p>
</sel:select>  

In this example, the sel:expr attributes on the sel:when elements control the selection.

<sel:select>
  <sel:when sel:expr="dc:cssmq-width('px') &gt; 200">
    <object sel:selid="pic42" src="image1"/>
  </sel:when>
  <sel:when sel:expr="dc:cssmq-color() &gt; 4">
    <object sel:selid="pic42" src="image2"/>
  </sel:when>
  <sel:otherwise>
    <p sel:selid="pic42">Many people had to be evacuated.</p>
  </sel:otherwise>
</sel:select>  

Each sel:when element carries a conditional expression in its sel:expr attribute. The select element does not have an sel:precept attribute. As a result, the precept defaults to matchfirst. The first sel:when element whose sel:expr attribute evaluates to true will be selected for processing. Based on the expressions in the example, if the usable width of the device, as reported by the dc:cssmq-width function, is greater than 200 pixels, image1 will be included. If it is not, but if the device supports more than 4 bits per color, as reported by the dc:cssmq-color function, image2 will be included. If neither sel:when element is selected for processing, the sel:otherwise element is used, resulting in the paragraph of text being included.

The example also illustrates use of the sel:selid attribute. The image elements and the paragraph element all carry the same value of pic42 for this attribute. After processing, whichever of the elements is selected for processing will carry an id attribute with this value.

<sel:select sel:precept="matchevery">
  <sel:when sel:expr="dc:cssmq-width('px') &gt; 200">
    <object src="image1"/>
  </sel:when>
  <sel:when sel:expr="dc:cssmq-color() &gt; 4">
    <object src="image2"/>
  </sel:when>
  <sel:otherwise>
    <p>Many people had to be evacuated.</p>
  </sel:otherwise>
</sel:select>  

In this slightly modified version of the previous example, the sel:select element carries a sel:precept attribute with a value of matchevery. This change means that all sel:when elements whose sel:expr attributes evaluate to true are selected for processing. In this version of the example, if the usable width of the device is greater than 200 pixels and the device supports more than 4 bits per color, both images will be included. With a precept of matchfirst, only image1 would be included. Only if neither of these is true will the paragraph be included instead of one or more images.

<sel:select sel:precept="matchfirst">
  <sel:when sel:expr="dc:cssmq-width('px') &gt; 200 and "dc:cssmq-color() &gt; 4>
    <object src="image1"/>
  </sel:when>
  <sel:when sel:expr="dc:cssmq-color() &gt; 4">
    <object src="image2"/>
  </sel:when>
  <sel:otherwise>
    <p>Many people had to be evacuated.</p>
  </sel:otherwise>
</sel:select>  

This example illustrates the use of slightly more complex expressions within the sel:expr attribute on the sel:when elements. In this case, the first when will be selected if the usable width of the device is greater than 200 pixels and the device supports more than 4 bits per color.

6 Variables

DISelect supports the use of variables to help reduce the complexity of expressions and markup. Variables are declared and initialized using markup. Their values can also be modified using markup. Variables can be referenced from expressions using the standard XPath mechanisms.

6.1 The sel:variable Element

The sel:variable element is used to declare variables and to set their value.

6.1.1 Attributes

sel:name

This attribute specifies the name of the variable. It is used when declaring a new variable.

sel:ref

This attribute specifies the name of the variable. It is used when referring to a variable that has already been declared.

sel:value

This optional attribute specifies an XPath expression that provides the value to be assigned to the variable.

6.1.2 Declaring a Variable

A variable is declared by using the sel:variable element with the sel:name attribute being set. Variables must be declared before they can be referenced. It is mandatory, to supply an initial value to a variable when declaring it. Initial values are supplied using a suitable expression in the sel:value attribute.

Editorial note 
The reason for requiring initialization is all to do with not wanting to mandate the version of XPath required. The issue is data typing. If we allow variables to be instantiated without an initial value, we have to have an explicit way to set the type. If we do this, we need to define which types are supported, and the answer is different for different versions of XPath. So, on balance, it is better to allow the processor to infer the datatype from the form of the initialization.

6.1.3 Referencing an existing Variable

References to existing variables can occur within markup or within the XPath expressions used in DISelect. References to existing variables from markup use the sel:variable element with the sel:ref attribute. The value of the variable can be altered using this form of reference.

References from XPath expressions use the normal notation. The name of the variable is prefixed with $. Consequently, a variable declared using an sel:variable element with an sel:name attribute of width is referenced from an XPath expression as $width.

6.1.4 Scope of Variables and Nesting

The declaration of a variable defines its scope. The scope of a variable is from the point at which it is declared to the end of the body content of the element that contains its declaration. Repeated declaration of a variable within the same scope is considered to be a non-terminating error. It causes a diselect-redeclaration-error event to be raised. This is a notification event. The DISelect processor continues but ignores the redeclaration.

A variable can be referenced only from within its scope. An element that references a variable must be within the scope of the variable. An expression that references a variable must be associated with an element that is within the scope of the variable.

If variables with the same name are declared in nested scopes, the inner declaration hides the outer declaration for the scope of the inner declaration. References to the variable from within the inner scope apply to the inner declaration.

6.1.5 Type

Variables in DISelect may take any of the types supported by XPath. The types supported depend on the version of XPath supported by the processor. The types are defined in [XPath 1.0] and [XPath 2.0]

The type of a variable is determined when its value is set. The type of the variable becomes the type of the result of the expression that provides its value.

The value of a variable may be set during its declaration. This is known as initialization. The value may also be set subsequently. As a consequence, the type of a variable may change during its lifetime.

6.2 Examples

This section is informative.

The first example illustrates the initialization of a variable and its subsequent modification, using markup. The height variable is declared and initialized to the usable height of the display. Later, the value is updated to a constant value using the sel:variable element with an sel:ref attribute.

<sel:variable sel:name="height" sel:value="dc:cssmq-height('px')"/>
...
...              
<sel:variable sel:ref="height" sel:value="352"/>
 

In the following example, a number of sel:when clauses refer to the same value. In this case, it is the usable width of the display in pixels. An sel:variable is defined and initialized with this value. The variable is then used in the expressions in the sel:expr attributes in each of the sel:whenclauses.

<sel:variable sel:name="width" sel:value="dc:cssmq-width('px')"/>
<sel:select>
  <sel:when sel:expr="$width &gt; 400">
    <object src="image1"/>
  </sel:when>
  <sel:when sel:expr="$width &gt; 200">
    <object src="image2"/>
  </sel:when>
  <sel:when sel:expr="$width &gt; 100">
    <object src="image2"/>
  </sel:when>
  <sel:otherwise>
    <p>Many people had to be evacuated.</p>
  </sel:otherwise>
</sel:select>  

7 Expressions in DISelect

Editorial note 
We have discussed whether or not we actually have a dependency on XPath 2 rather than XPath 1. The main issue is data types. We want to use the newer datatyping in XPath 2 that is based on XML Schema datatypes. These are specified explicitly for the starter set functions. In addition, later on we expect to need to use the abstractions for sets of data that are introduced in XPath 2. Ideally we'd like to avoid having to specify which version is used. For conditional results, both support boolean anyway. For other datatypes, implicit type conversions may be enough.

DISelect uses a subset of [XPath 1.0] to express the calculations and conditions involved when determining whether or not a particular piece of content is to be included for processing. This subset is sufficient to construct conditional expressions and expressions that return values. It also includes the ability to invoke XPath functions.

DISelect makes use of a number of specific XPath functions. These functions provide a means of abstraction that avoids direct coupling between the underlying data, on which conditional processing decisions are based, and the references used by authors. This is particularly useful in hiding the specific details of the representations used in delivery context from the markup that references it. A minimum set of such functions is described in Starter Set XPath Functions for Delivery Context Access.

It is anticipated that, in future,additional sets of functions that will be defined for more comprehensive access to the delivery context. The delivery context is essentially a set of metadata. Representations of delivery context, such as [CC/PP], use appropriate technologies such as RDF[RDF Primer]. Additional sets of functions developed in future for access to the delivery context are expected to provide interfaces that reflect its role as metadata while still hiding the details of the underlying representation.

8 Starter Set XPath Functions for Delivery Context Access

The starter set XPath functions for delivery context access are intended to provide convenient, short hand forms for use by authors. The functions are derived from the facilities defined in [Media Queries]. They have been chosen to implement features similar to those associated with Media Queries. No attempt as been made to change the Media Queries function, except for two additions in the case of aspect ratio and the addition of a defaulting mechanism. It should be stressed that these particular functions are regarded as a minimum starter set.

In future, it is anticipated that additional sets of functions will be developed to provide more comprehensive access to the delivery context. It is also anticipated that access mechanisms that make explicit use of the underlying structure of the metadata within the delivery context will also be developed in future. These might, for example, make use of future capabilities to query RDF[RDF Primer].

Editorial note 
We need to describe the defaulting mechanism here and also discuss the fact that other functions and function namspaces can be used.

8.1 The dc:cssmq-width function

This section is normative.

8.1.1 Prototype

xsd:decimal dc:cssmq-width(xsd:string units, xsd:decimal default?)

xsd:string units

The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.

xsd:decimal default

An optional default value to be returned by the function if the usable display width cannot be determined from the delivery context.

8.1.2 Function

This function returns the usable width of the display associated with the device as a decimal number. This value may be smaller than that returned by the dc:cssmq-device-width function. Some devices, for example, have fixed areas of their display that are unavailable to applications.

The function returns the value supplied in the default argument if the usable width cannot be determined from the delivery context. It returns 0 if the usable width cannot be determined from the delivery context and no default argument is provided.

8.1.3 Examples

This section is informative.

The expression

dc:cssmq-width("px", 500) &gt; 400

returns the xsd:boolean value true, if the display has a usable width of more than 400 pixels, and false otherwise. If the width cannot be determined from the delivery context, the function returns the default value 500, and consequently the expression evaluates to true.

Similarly the expression

dc:cssmq-width("cm") &lt; 2.54

returns the xsd:boolean value true, if the display has a usable width of less than 2.54 centimeters and false otherwise.

8.2 The dc:cssmq-height function

This section is normative.

8.2.1 Prototype

xsd:decimal dc:cssmq-height(xsd:string units, xsd:decimal default?)

xsd:string units

The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.

xsd:decimal default

An optional default value to be returned by the function if the usable display height cannot be determined from the delivery context.

8.2.2 Function

This function returns the usable height of the display associated with the device as a decimal number. This value may be smaller than that returned by the dc:cssmq-device-height function. Some devices, for example, have fixed areas of their display that are unavailable to applications.

The function returns the value supplied in the default argument if the usable height cannot be determined from the delivery context. It returns 0 if the usable height cannot be determined from the delivery context and no default argument is provided.

8.2.3 Examples

This section is informative.

The expression

dc:cssmq-height("px") &gt; 200

returns the xsd:boolean value true, if the display has a usable height of more than 200 pixels, and false otherwise.

The expression

dc:cssmq-height("cm", 2.54)

returns the usable height of the display in centimeters as an xs;decimal value or the value 2.54 if the height cannot be determined from the delivery context.

8.3 The dc:cssmq-device-width function

This section is normative.

8.3.1 Prototype

xsd:decimal dc:cssmq-device-width(xsd:string units, xsd:decimal default?)

xsd:string units

The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.

xsd:decimal default

An optional default value to be returned by the function if the physical display width cannot be determined from the delivery context.

8.3.2 Function

This function returns the physical width of the display associated with the device as a decimal number. This value may be larger than that returned by the dc:cssmq-width function. Some devices, for example, have fixed areas of their display that are unavailable to applications.

The function returns the value supplied in the default argument if the physical width cannot be determined from the delivery context. It returns 0 if the physical width cannot be determined from the delivery context and no default argument is provided.

8.3.3 Examples

This section is informative.

The expression

dc:cssmq-device-width("px") &lt; 640

returns the xsd:boolean value true, if the display has a physical width of less than 640 pixels, and false otherwise. Similarly the expression

dc:cssmq-device-width("in") &lt; 3.6

returns the xsd:boolean value true, if the display has a usable width of less than 3.6 inches and false otherwise.

8.4 The dc:cssmq-device-height function

This section is normative.

8.4.1 Prototype

xsd:decimal dc:cssmq-device-height(xsd:string units, xsd:decimal default?)

xsd:string units

The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.

xsd:decimal default

An optional default value to be returned by the function if the physical display height cannot be determined from the delivery context.

8.4.2 Function

This function returns the physical height of the display associated with the device as a decimal number. This value may be smaller than that returned by the dc:cssmq-device-height function. Some devices, for example, have fixed areas of their display that are unavailable to applications.

The function returns the value supplied in the default argument if the physical height cannot be determined from the delivery context. It returns 0 if the physical height cannot be determined from the delivery context and no default argument is provided.

8.4.3 Examples

This section is informative.

The expression

dc:cssmq-device-height("cm") &gt; 2.7

returns the xsd:boolean value true, if the display has a physical height of more than 2.7 centimeters, and false otherwise. If the physical height cannot be determined from the delivery context, the function returns the value 0 and hence the expression evaluates to false.

The expression

dc:cssmq-device-height("px", 250)

returns the physical height of the display in pixels as an xs;decimal value or the value 250 if the height cannot be determined from the delivery context.

8.5 The dc:cssmq-device-aspect-ratio function

This section is normative.

8.5.1 Prototype

xsd:string dc:cssmq-device-aspect-ratio(xsd:string default?)

xsd:string default

An optional default value to be returned by the function if the aspect ratio cannot be determined from the delivery context.

8.5.2 Function

This function returns a representation of the physical aspect ratio of the device in the form defined in [Media Queries]. The resulting xsd:string contains values such as 16/9, indicating an aspect ratio of 16:9, the ratio commonly associated with wide screen television, for example. The first value represents the width and the second value the height of the display. The complete value indicates the relative sizes of these dimensions. The values within the result are always the minimum integer values that can represent the aspect ratio.

The function returns the value supplied in the default argument if the aspect ratio cannot be determined from the delivery context. It returns an empty string if the aspect ratio cannot be determined from the delivery context and no default argument is provided.

8.5.3 Examples

This section is informative.

The expression

dc:cssmq-device-aspect-ratio() = "16/9"

returns the xsd:boolean value true, if the display has an aspect ratio of 16:9 and false otherwise.

The expression

dc:cssmq-device-aspect-ratio("4/3")

returns the xsd:string value representing the device aspect ratio. If the aspect ratio cannot be determined from the delivery context, the value "4/3" is returned.

8.6 The dc:cssmq-device-aspect-ratio-width function

This section is normative.

8.6.1 Prototype

xsd:integer dc:cssmq-device-aspect-ratio-width(xsd:integer default?)

xsd:integer default

An optional default value to be returned by the function if the width value of the aspect ratio cannot be determined from the delivery context.

8.6.2 Function

This function returns the width value of the aspect ratio of the display associated with the device. This value is the xsd:integer representation of the first value returned by the dc:cssmq-device-aspect-ratio function. For example, if the dc:cssmq-device-aspect-ratio were to return the xsd:string value "16/9", this function would return the xsd:integer value 16.

The function returns the value supplied in the default argument if the width value of the aspect ratio cannot be determined from the delivery context. It returns a value of 0 if the width value of the aspect ratio cannot be determined from the delivery context and no default argument is provided.

8.6.3 Examples

This section is informative.

The expression

dc:cssmq-device-aspect-ratio-width() = 16

returns the xsd:boolean value true, if the display has an aspect ratio width of 16 and false otherwise.

The expression

dc:cssmq-device-aspect-ratio-width(12)

returns the xsd:integer value representing the width value of the aspect ratio. If the width value of the aspect ratio cannot be determined from the delivery context, the value 12 is returned.

8.7 The dc:cssmq-device-aspect-ratio-height function

This section is normative.

8.7.1 Prototype

xsd:integer dc:cssmq-device-aspect-ratio-height(xsd:integer default?)

xsd:integer default

An optional default value to be returned by the function if the height value of the aspect ratio cannot be determined from the delivery context.

8.7.2 Function

This function returns the height value of the aspect ratio of the display associated with the device. This value is the xsd:integer representation of the second value returned by the dc:cssmq-device-aspect-ratio function. For example, if the dc:cssmq-device-aspect-ratio were to return the xsd:string value "16/9", this function would return the xsd:integer value 9.

The function returns the value supplied in the default argument if the height value of the aspect ratio cannot be determined from the delivery context. It returns a value of 0 if the height value of the aspect ratio cannot be determined from the delivery context and no default argument is provided.

8.7.3 Examples

This section is informative.

The expression

dc:cssmq-device-aspect-ratio-height() = 9

returns the xsd:boolean value true, if the display has an aspect ratio height of 9 and false otherwise.

The expression

dc:cssmq-device-aspect-ratio-width(6)

returns the xsd:integer value representing the height value of the aspect ratio. If the height value of the aspect ratio cannot be determined from the delivery context, the value 6 is returned.

8.8 The dc:cssmq-color function

This section is normative.

8.8.1 Prototype

xsd:integer dc:cssmq-color(xsd:integer default?)

xsd:integer default

An optional default value to be returned by the function if the number of bits per color cannot be determined from the delivery context.

8.8.2 Function

This function returns the number of bits per color supported by the display associated with the device. The result is expressed as a positive integer.

The function returns the value supplied in the default argument if the number of bits per color cannot be determined from the delivery context. It returns 0 if the number of bits per color cannot be determined from the delivery context and no default argument is provided. The function also returns 0 if the device does not support color.

8.8.3 Examples

This section is informative.

The expression

dc:cssmq-color() &gt; 4

returns the xsd:boolean value true, if the display supports more than 4 bits per color, and false otherwise. Similarly the expression

dc:cssmq-color(8) &gt; 6

returns the xsd:boolean value true, if the display supports more than 6 bits per color. It also returns true if the number of bits per color cannot be determined from the delivery context. In this case, the function returns the supplied default value of 8, which is greater than 6.

8.9 The dc:cssmq-color-index function

This section is normative.

8.9.1 Prototype

xsd:integer dc:cssmq-color(xsd:integer default?)

xsd:integer default

An optional default value to be returned by the function if the number of entries in the color look up table for the device cannot be determined from the delivery context.

8.9.2 Function

This function returns the number of entries in the color look up table of the display associated with the device. The result is expressed as a positive integer.

The function returns the value supplied in the default argument if the number of entries in the color look up table cannot be determined from the delivery context. It returns 0 if the number of entries in the color look up table cannot be determined from the delivery context and no default argument is provided. The function also returns 0 if the device does not support color or has no look up table.

8.9.3 Examples

This section is informative.

The expression

dc:cssmq-color-index() &gt; 16

returns the xsd:boolean value true, if the color look up table of the display has more than 16 entries, and false otherwise. Similarly the expression

dc:cssmq-color-index(256) &gt; 64

returns the xsd:boolean value true, if the the color look up table of the display has more than 64 entries. It also returns true if the number of entries in the color look up table cannot be determined from the delivery context. In this case, the function returns the supplied default value of 256, which is greater than 64.

8.10 The dc:cssmq-monochrome function

This section is normative.

8.10.1 Prototype

xsd:integer dc:cssmq-monochrome(xsd:integer default?)

xsd:integer default

An optional default value to be returned by the function if the number of bits used to represent monochrome output cannot be determined from the delivery context.

8.10.2 Function

This function returns the number of bits used to represent monochrome output by the display associated with the device. The result is expressed as a positive integer.

The function returns the value supplied in the default argument if the number of bits used to represent monochrome output cannot be determined from the delivery context. It returns 0 if the the number of bits used to represent monochrome output cannot be determined from the delivery context and no default argument is provided. The function also returns 0 if the device does not support color.

8.10.3 Examples

This section is informative.

The expression

dc:cssmq-monochrome() &gt; 4

returns the xsd:boolean value true, if the display uses more than 4 bits to represent monochrome output, and false otherwise. Similarly the expression

dc:cssmq-monochrome(8) &gt; 6

returns the xsd:boolean value true, if the display uses more than 6 bits to represent monochrome output. It also returns true if the number of bits used to represent monochrome cannot be determined from the delivery context. In this case, the function returns the supplied default value of 8, which is greater than 6.

8.11 The dc:cssmq-resolution function

This section is normative.

8.11.1 Prototype

xsd:decimal dc:cssmq-resolution(xsd:string units, xsd:decimal default?)

xsd:string units

The units in which the value is to be returned. The possible values of this argument are described in detail in Resolution Units.

xsd:decimal default

An optional default value to be returned by the function if the resolution cannot be determined from the delivery context.

8.11.2 Function

This function returns the resolution of the display associated with the device as a decimal number.

The function returns the value supplied in the default argument if the resolution cannot be determined from the delivery context. It returns 0 if the resolution cannot be determined from the delivery context and no default argument is provided.

8.11.3 Examples

This section is informative.

The expression

dc:cssmq-resolution("dpi", 100) &gt; 200

returns the xsd:boolean value true, if the display has a resolution of more than 200 pixels per inch, and false otherwise. If the resolution cannot be determined from the delivery context, the function returns the default value 100, and consequently the expression evaluates to false.

8.12 The dc:cssmq-scan function

This section is normative.

8.12.1 Prototype

xsd:string dc:cssmq-scan(xsd:string default?)

xsd:string default

An optional default value to be returned by the function if the scan type cannot be determined from he delivery context.

8.12.2 Function

This function returns a representation of the type of scan used by the display associated with the device. The resulting xsd:string contains one of the following values.

progressive

The display uses a progressive scanning scheme

interlace

The display uses an interlace scanning scheme

The function returns the value supplied in the default argument if the type of scan cannot be determined from the delivery context. It returns an empty string if the type of scan cannot be determined from the delivery context and no default argument is provided.

8.12.3 Examples

This section is informative.

The expression

dc:cssmq-scan() = "interlace"

returns the xsd:boolean value true, if the display uses interlace scanning and false otherwise.

The expression

dc:cssmq-scan("progressive")

returns the xsd:string value representing the type of scanning used. If the type of scan cannot be determined from the delivery context, the value "progressive" is returned.

8.13 The dc:cssmq-grid function

This section is normative.

8.13.1 Prototype

xsd:boolean dc:cssmq-grid(xsd:boolean default?)

xsd:boolean default

An optional default value to be returned by the function if it is not possible to determine whether the device is grid based or bitmap based from the delivery context.

8.13.2 Function

This function returns an xsd:boolean value of true if the device is grid based. Grid based devices support a regular character array rather than a bitmap display. Examples of grid based devices include teletype terminals and simple mobile phones with fixed width fonts.

The function returns the value supplied in the default argument if it is not possible to determine whether the device is grid based or bitmap based from the delivery context. It returns false if it is not possible to determine whether the device is grid based or bitmap based from the delivery context and no default argument is provided.

8.13.3 Examples

This section is informative.

The expression

dc:cssmq-grid()

returns the xsd:boolean value true, if the display is grid based.

8.14 Units

8.14.1 Length Units

The starter set of XPath functions for accessing delivery context recognizes the following xsd:string literal values that specify length units.

px

the length is specified in pixels

in

the length is specified in inches

cm

the length is specified in centimeters

mm

the length is specified in millimeters

pt

the length is specified in font points

pc

the length is specified in picas

8.14.2 Resolution Units

The starter set of XPath functions for accessing delivery context recognizes the following xsd:string literal values that specify resolution units.

dpi

the resolution is specified as a number dots or pixels per inch

dpcm

the resolution is specified as a number dots or pixels per centimeter

dpmm

the resolution is specified as a number dots or pixels per millimeter

9 Formal Definitions

9.1 The Content Selection Namespace

The DISelect namespace has the URI: http://www.w3.org/2004/06/diselect. XML Processors must use the XML namespaces mechanism [XML Names] to recognize elements and attributes from this namespace

9.2 Schema

Editorial note 
We need a section here to describe the schema for DISelect and how it works with the schema for host languages, such as XHTML 2 and XForms.

A References

A.1 Normative References

IETF RFC 2119
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.)
XHTML Modularization
Modularization of XHTML M. Altheim, et al., 2001. W3C Recommendation (See http://www.w3.org/TR/xhtml-modularization/.)
XML Names
Namespaces in XML (See http://www.w3.org/TR/REC-xml-names/.)
XPath 1.0
XML Path Language (XPath) Version 1.0 J. Clark et al., 1999. W3C Recommendation (See http://www.w3.org/TR/xpath.)
XPath 2.0
XML Path Language (XPath) 2.0 A. Berglund et al., 2003. W3C Working Draft (See http://www.w3.org/TR/2003/WD-xpath20-20031112/.)
XML Schema Part 1
XML Schema Part 1: Structures H. S. Thompson et al., 2001. W3C Recommendation (See http://www.w3.org/TR/xmlschema-1/.)
Media Queries
Media Queries Håkon Wium Lie et al., 2003. W3C Candidate Recommendation (See http://www.w3.org/TR/css3-mediaqueries/.)
XHTML 2
XHTMLTM 2 J. Axelsson et al., 2003 W3C Working Draft (See http://www.w3.org/TR/xhtml2/.)

A.2 Informative References

Authoring Challenges
Authoring Challenges for Device Independence R. Lewis, 2003. W3C Note (See http://www.w3.org/TR/acdi/.)
DI Principles
Device Independence Principles R. Gimson, 2003. W3C Note (See http://www.w3.org/TR/di-princ/.)
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. Boss et al., 2004 W3C Candidate Recommendation (See http://www.w3.org/TR/CSS21/.)
RDF Primer
RDF Primer F. Manola et al., 2004 W3C Candidate Recommendation (See http://www.w3.org/TR/rdf-primer/.)
ECMAScript
ECMAScript Language Specification ECMA (European Computer Manufacturers Association) (See http://www.ecma-international.org/publications/standards/Ecma-262.htm.)
XSLT
XSL Transformations (XSLT) Version 1.0 J. Clark, 1999 W3C Recommendation (See http://www.w3.org/TR/xslt.)

B Editor's Notes

B.1 Changes in This Version

B.1.1 Changes in the Version Dated 30 April 2004

  • Corrected the errors noted in Cedric's note (Member only link).

  • Added material covering ECMAScript and XSLT to the justification

  • Added material to the section on starter set functions describing them and the other functions we expect to develop

  • Added informative references for a number of specifications including RDF, CSS, XForms, and the DI Principles and Authoring Challenges

  • Added material to the Overview to describe the overall approach being taken by DIWG in the development of a device independence profile for XHTML etc.

  • Added material to the overview justifying the need for the selection markup in terms of the results of Authoring Challenges and Principles.

  • Replaced <img> with <object> in the examples to be consistent with XHTML Version 2.

  • Updated the namespaces for sel: and dc: to use 2004 rather than 2003.

  • Added a definition of the selid attribute. Added an example of its use to one of the existing examples of selection based on elements.

  • Added description of the new "if" element in response to discussions on the list in the thread on Content selection elements (Member Only Link)and subsequent discussion during the teleconference (Member Only Link).

  • Updated the section on variables based on the discussions from the March F2F meeting (Member Only Link). Actually, there were two discussions, one based on the notion that we should have variables and allow their values to change, and one based on the notion of defining something like 'immutables'. Reviewing the section on variables in the light of the discussion it seems that the issues of scope and the effect of variable value change on evaluation are actually not significant issues. They certainly are not in the same league as those faced by XSLT because of its underlying processing model. DISelect is much more like a standard procedural language in this respect. So for the time being I've left variables as variable simply because if we can define a rational processing model not having explicit constants and variables is actually simpler for authors to understand.

  • Added a new section on errors and events to the processing model. This is after discussion on conference calls and at the March F2F meeting (Member Only Link) and is based on the way that XForms processors report errors. The first error is associated with duplicate declaration. It is non-fatal. This section will be expanded as the need for additional events arises.

  • Reverted to the use of expr in as the name of the attribute used to control whether or not an element is selected for processing. This is as a result of the discussion at the March F2F meeting (Member Only Link). Changed all occurences of the use of activate and removed the editor's note on this topic.

B.1.2 Changes in the Version Dated 1 March 2004

  • Fixed the typos noted in Roger's note (Member Only Link) point 1), that caused the name XSelect to continue to remain in the document incorrectly.

  • Changed the prefix to sel:from xcs:, as suggested in Roger's note (Member Only Link) point 1).

  • Fixed the typo noted in Cedric's note (Member only Link)referring to the definition of the when element and the mandatory nature of the activate (now expr) attribute on sel:when. This was a throwback to a previous version of the markup when there were two ways of using sel:when.

  • Fixed the typo noted in Cedric's note (Member Only Link) referring to specific examples which resulted in the text for the first example being inappropriate. Removed the reference to precept.

B.1.3 Changes in the Version Dated 21 January 2004

  • Renamed XSelect to DISelect as we have not yet heard from the XML core WG.

  • Added definitions for variables to the specification as part of the simplification of the markup performed in response to Michael's comments (Member Only Link) point 4.

  • Expanded the editors notes about the use of sel:activate as the name for the attribute that controls selection for processing in response to Michael's comments (Member Only Link) point 1

  • Revised the wording about use of sel:select to remove implication that it may be applied appropriately to any host language element. This is in response to Michael's comments (Member Only Link) point 1. Discussion of appropriate use will be included in the section on processing.

  • Added an example showing a slightly more complex conditional expression to the examples for the sel:select element.

  • Removed the shorthand version of the sel:select element in response to to Michael's comments (Member Only Link) point 4.

B.1.4 Changes in the Version Dated 14 December 2003

  • Added the xcs namespace prefix to the attributes and elements of the new markup

  • Replaced > with &gt; in the examples and code snippets

  • Added a reference to XHTML 2 and to its namespace

  • Added the definition of the dc:cssmq-resolution function

  • Added a editor's note about the name of the sel:activate (now sel:expr) attribute in response to Michael's comments (Member Only Link) point 1

  • Added a note about escaping of operators in XPath expressions to the section on expressions in response to Michael's comments point 2

  • Added an example to the section on the sel:expr attribute illustrating use of multiple conditions in a single expression in response to Michael's comments point 3

B.1.5 Changes in the Version Dated 31 November 2003

  • This is the first version of this document

B.2 Open Issues

CSI001

It is possible that this work has more general application than just device independence. One alternative name for the item is XML Selection (XSelect) 1.0. We need to investigate feeling in other groups about this and about whether the current working title is itself appropriate.