Content Selection for Device Independence (DISelect) 1.0

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

Content Selection for Device Independence (DISelect) 1.0

W3C Working Draft 11 June 2004

Abstract

Status of this Document

Table of Contents

Appendices

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

8.1.2 Function

8.1.3 Examples

8.2 The dc:cssmq-height function

8.2.1 Prototype

8.2.2 Function

8.2.3 Examples

8.3 The dc:cssmq-device-width function

8.3.1 Prototype

8.3.2 Function

8.3.3 Examples

8.4 The dc:cssmq-device-height function

8.4.1 Prototype

8.4.2 Function

8.4.3 Examples

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

8.5.1 Prototype

8.5.2 Function

8.5.3 Examples

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

8.6.1 Prototype

8.6.2 Function

8.6.3 Examples

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

8.7.1 Prototype

8.7.2 Function

8.7.3 Examples

8.8 The dc:cssmq-color function

8.8.1 Prototype

8.8.2 Function

8.8.3 Examples

8.9 The dc:cssmq-color-index function

8.9.1 Prototype

8.9.2 Function

8.9.3 Examples