Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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.
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
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
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.
Throughout this document, the following namespace prefixes and corresponding namespace identifiers are used:
The DISelect namespace (http://www.w3.org/2004/06/diselect) described in The Content Selection Namespace.
The Delivery Context namespace (http://www.w3.org/2004/06/dc)
The XML Schema namespace (http://www.w3.org/2001/XMLSchema) [XML Schema Part 1]
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]
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.
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.
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. |
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.
This section is normative.
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.
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.
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. |
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') > 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') > 200 & dc:cssmq-color() > 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.
This section is normative.
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.
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.
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.
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.
This mandatory attribute defines the basic rule applied to matching within the sel:select
element.
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.
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.
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.
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.
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.
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.
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') > 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') > 200"> <object sel:selid="pic42" src="image1"/> </sel:when> <sel:when sel:expr="dc:cssmq-color() > 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') > 200"> <object src="image1"/> </sel:when> <sel:when sel:expr="dc:cssmq-color() > 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') > 200 and "dc:cssmq-color() > 4> <object src="image1"/> </sel:when> <sel:when sel:expr="dc:cssmq-color() > 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.
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.
The sel:variable
element is used to declare variables and to set their value.
This attribute specifies the name of the variable. It is used when declaring a new variable.
This attribute specifies the name of the variable. It is used when referring to a variable that has already been declared.
This optional attribute specifies an XPath expression that provides the value to be assigned to the 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. |
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
.
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.
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.
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:when
clauses.
<sel:variable sel:name="width" sel:value="dc:cssmq-width('px')"/> <sel:select> <sel:when sel:expr="$width > 400"> <object src="image1"/> </sel:when> <sel:when sel:expr="$width > 200"> <object src="image2"/> </sel:when> <sel:when sel:expr="$width > 100"> <object src="image2"/> </sel:when> <sel:otherwise> <p>Many people had to be evacuated.</p> </sel:otherwise> </sel:select>
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.
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. |
This section is normative.
xsd:decimal dc:cssmq-width(xsd:string units, xsd:decimal default?)
The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.
An optional default value to be returned by the function if the usable display width cannot be determined from the delivery context.
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.
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.
This section is normative.
xsd:decimal dc:cssmq-height(xsd:string units, xsd:decimal default?)
The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.
An optional default value to be returned by the function if the usable display height cannot be determined from the delivery context.
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.
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.
This section is normative.
xsd:decimal dc:cssmq-device-width(xsd:string units, xsd:decimal default?)
The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.
An optional default value to be returned by the function if the physical display width cannot be determined from the delivery context.
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.
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.
This section is normative.
xsd:decimal dc:cssmq-device-height(xsd:string units, xsd:decimal default?)
The units in which the value is to be returned. The possible values of this argument are described in detail in Length Units.
An optional default value to be returned by the function if the physical display height cannot be determined from the delivery context.
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.
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.
This section is normative.
xsd:string dc:cssmq-device-aspect-ratio(xsd:string default?)
An optional default value to be returned by the function if the aspect ratio cannot be determined from the delivery context.
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.
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.
This section is normative.
xsd:integer dc:cssmq-device-aspect-ratio-width(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.
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.
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.
This section is normative.
xsd:integer dc:cssmq-device-aspect-ratio-height(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.
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.
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.
This section is normative.
xsd:integer dc:cssmq-color(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.
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.
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
.
This section is normative.
xsd:integer dc:cssmq-color(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.
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.
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
.
This section is normative.
xsd:integer dc:cssmq-monochrome(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.
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.
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
.
This section is normative.
xsd:decimal dc:cssmq-resolution(xsd:string units, xsd:decimal default?)
The units in which the value is to be returned. The possible values of this argument are described in detail in Resolution Units.
An optional default value to be returned by the function if the resolution cannot be determined from the delivery context.
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.
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
.
This section is normative.
xsd:string dc:cssmq-scan(xsd:string default?)
An optional default value to be returned by the function if the scan type cannot be determined from he delivery context.
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.
The display uses a progressive scanning scheme
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.
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.
This section is normative.
xsd:boolean dc:cssmq-grid(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.
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.
The starter set of XPath functions for accessing delivery context recognizes the following xsd:string
literal values that specify length units.
the length is specified in pixels
the length is specified in inches
the length is specified in centimeters
the length is specified in millimeters
the length is specified in font points
the length is specified in picas
The starter set of XPath functions for accessing delivery context recognizes the following xsd:string
literal values that specify resolution units.
the resolution is specified as a number dots or pixels per inch
the resolution is specified as a number dots or pixels per centimeter
the resolution is specified as a number dots or pixels per millimeter
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
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.
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.
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.
Added the xcs namespace prefix to the attributes and elements of the new markup
Replaced > with > 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
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.