Core Presentation Characteristics: Requirements and Use Cases

W3C Working Draft
10 May 2003

This version:
Latest version:
Previous version:
First public working draft
Markus Lauff (SAP) markus.lauff@sap.com
Amy Yu (SAP) amy.yu@sap.com
Roger Gimson (HP)
Lalitha Suryanarayana (SBC Technology Resources)
Markus Lauff (SAP)
See Acknowledgments


This document sets out the Requirements for defining a set of Core Presentation Characteristics. The purpose of defining these Core Presentation Characteristics is to provide a common set of property or attribute definitions that can be reused in many contexts in which the presentation capabilities of a presentation device need to be considered. The use of well-defined Core Presentation Characteristics will simplify the task of adapting content to a specific presentation delivery context. The document sets out what is meant by 'core' and 'presentation,' what should be included in the definition of each characteristic, what should be defined when grouped characteristics into collections, and what kind of characteristics should be included in the core. It also suggests some use cases.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.

This is a working draft of a possible future W3C Note.

This document is published as part of the W3C Device Independence Activity by the Device Independence Working Group. It is a deliverable as defined in the charter of that group. An earlier version was made available as an informal public draft by the working 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/).

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

Table of contents

1 Introduction and Background

Information characterizing the delivery context of a web access mechanism is a critical enabler for device independence. To that end, the Delivery Context Overview for Device Independence document [DCO] summarizes the various techniques currently used within the industry for representing, conveying and processing delivery context information. Most of these approaches like OMA UAProf [UAProf] and CSS Media Queries [CSSMediaQ] have also specified partial or complete sets of capabilities related to their application specific context of usage and implementation.  However, a standardized definition of key presentation characteristics is lacking, which would likely be used across applications universally and specifically for the purposes of device independent adaptation and rendering. The absence of a well-defined core set of characteristics can lead to the proliferation of incompatible yet overlapping repositories of properties or attributes that may conflict and detriment from the selection of an appropriate presentation. Consequently, there is a need to harmonize existing semantics, syntax and definitions for describing delivery context information while also providing opportunities for extensibility and forward compatibility with new capabilities and features that have not yet been conceived.

An attempt to address these issues was first initiated in the context of CC/PP. In fact, the CC/PP specification [CC/PP] provides a sample non-normative "core" vocabulary for CC/PP aware devices. While the CC/PP Implementer's Guide [CC/PP-Guide] identified and listed existing vocabularies that could conform to the CC/PP structure and schema and provided illustrations to that effect, it did not specifically attempt to coalesce and unify the definition and semantics of the various attributes within each vocabulary into a common core. The burden of such harmonization was left to individual groups themselves with the expectation that they, as good citizens of the Web, would ensure that the future evolution of the vocabularies would converge to a common core.  In the interim, the impact is being felt by the developer community that strives to build device independent applications in spite of the difficulty of interoperation between these vocabularies.

In light of these issues, this document proposes and outlines a core set of presentation characteristics that refer to the presentation capabilities of a device or its user agent and which are a subset of the full delivery context. By showing their relationship to existing vocabularies, the Device Independence Working Group hopes that future vocabularies can reuse these definitions. Authors of web applications will then have a sound basis for expressing the adaptation of their content to device presentation capabilities. This version of the core presentation characteristics specification will concentrate on the most essential presentation characteristics, while enabling more characteristics to be added later.

To further the foreseen evolution of the document,  the W3C Device Independence Working Group will liaise with representatives from groups that define UAProf, CSS Media Queries, and IETF Media Feature Sets. The goal of this cooperation will be to work towards establishing a consensus on a set of characteristics that will benefit and be compatible to future vocabulary definitions.

2 Purpose and Scope

The intended purpose of the Core Presentation Characteristics recommendation will be to define a common set of presentation properties or attributes that:

Therefore, the scope of the Core Presentation Characteristics definitions is restricted to attributes that are 'core' for the 'presentation' of web content.  A more thorough explanation of the meaning of these two terms is presented below.

Presentation characteristics are those properties that define some aspects of the way in which content may be presented to a user of an access mechanism.  Presentation characteristics are directly related to the presentation model being used. For example, when rendering some HTML with CSS visual styling, CSS defines a presentation model which includes, for example, the visual area within which the presentation is to be made, and the fonts with which text can be rendered. Similarly, when requesting an image to be rendered as part of a presentation, there is a presentation model which includes the image size and resolution at which it is to be displayed. For an audio presentation of some text using a text-to-speech model, the presentation model may include the available voices with which the text can be rendered.

Core presentation characteristics are those that are relevant to almost every device using a particular presentation model. This excludes from the core any attributes that are specific to only a small subset of devices using a given  presentation model.

The purpose of this document is to set out specific requirements to be satisfied in a future Core Presentation Characteristics Recommendation. Specific information such as defining the purpose and application of existing vocabulary sets are beyond the scope of this Requirements document. The proposed Core Presentation Characteristics will be related to those of existing vocabularies as part of the future recommendation. However, the proposed core characteristics will not be simply a union or intersection of existing vocabularies because of difficulties outlined in the next section.

Characteristics related to a specific protocol, access rights, dynamic behavior, or persistence are outside the scope of this document and are not addressed. The aim of this document is not to provide information regarding the purpose of delivery context and various access mechanisms. These are discussed in other publications from this group such as the Device Independence Principles document [DIP] and the Delivery Context Overview for Device Independence [DCO].

Dublin Core [DC] defines a set of attributes that are relevant to document description and which have been reused in many contexts that need to refer to common document metadata. In a similar way, we will define a set of attributes that can be reused in many contexts that need to refer to common presentation characteristics.

3 Challenges Introduced by Existing Vocabularies

The following examples illustrate difficulties in using existing vocabularies with regards to specific criteria that are relevant to authoring for device independence. 

For example, an attribute defining the amount of memory available in the device is effectively meaningless without detailed knowledge of the device's implementation.

For example, screen size has been designated in various ways in different vocabularies: in IETF Media Feature set [MFS] it has been named 'pix-x' and 'pix-y,' in SMIL 1.0 [SMIL1] 'system-screen-size,' in SMIL 2.0 [SMIL2] 'systemScreenSize,' and in CSS Media Queries [CSSMediaQueries] 'device-width' and 'device-height.' 

For example, screen size may be given as separate values for width and height, as in IETF Media Feature set [MFS] and CSS Media Queries [CSSMediaQueries], or as a compound value, such as 'heightxwidth' in SMIL [SMIL] or 'widthxheight' in UAProf [UAProf].

For example, a natural language description is used in IETF Media Feature set [MFS], SMIL [SMIL], and UAProf [UAProf], whereas an RDF schema is used in the CC/PP example vocabulary [CC/PP].

For example, what is the meaning of display size being defined as a signed integer in IETF Media Feature set [MFS]?

For example, the semantics of the attribute 'color' is represented in a variety of ways; 'color' is represented by an enumerated selection in IETF Media Feature set [MFS] but as a number of bits in CSS Media Queries [CSSMediaQueries] .  'ColorCapable' is defined as a boolean in UAProf [UAProf].

4 Requirements for Core Presentation Characteristics

The following requirements have been divided into three categories: requirements that define the structure and properties of the individual attributes, requirements that define the collection of characteristics, and requirements that indicate whether a characteristic is suitable for inclusion in the core set.

4.1 Requirements defining the structure and properties of individual attributes

Each individual core presentation characteristic definition of an attribute must include the following:

If an attribute is associated with a measurable numeric value:

An attribute may have a value that is not a simple value when:

Where the description is available in the official language of the W3C:

4.2 Requirements defining the collection of characteristics

CPCR09 - Reuse: The overall set of Core Presentation Characteristics must be defined as:

in order to allow unambiguous reuse of the core attributes in different application contexts.

CPCR10 - Extensibility: It must be possible to add additional presentation attributes beyond the Core Presentation Characteristics to make a presentation-specific vocabulary.

CPCR11 - Modularity: The core attributes must be grouped into related subsets to allow reuse of selected subsets in defining future vocabularies.

CPCR12 - Versioning: The Core Presentation Characteristics Recommendation should make proposals that address how adding, removing or changing attributes in a vocabulary should be handled in order to:

4.3 Requirements about what characteristics are in the core

CPCR13 - Related work: Related work of UAProf, CC/PP, CSS Media Queries, and IETF Media Feature sets must be taken into account. The Core Presentation Characteristics should use these specifications as a starting point for defining core presentation attributes.

CPCR14 - Common Adaptation: The Core Presentation Characteristics must be useful for common adaptation tasks.

CPCR15 - Support for modalities: The Core Presentation Characteristics should provide means to describe the modalities of a device.

CPCR16 - Separation of input and output: The Core Presentation Characteristics should allow the author to specify whether an attribute is applicable to output, input, or both. 

CPCR17 - Navigation capabilities: The Core Presentation Characteristics should provide a means to express the navigational capabilities of a device.

CPCR18 - Interoperability: The Core Presentation Characteristics should only contain attributes that can be measured in a reliable and interoperable way. It must be possible to compare different instances of  an attribute.

CPCR19 - Minimal initial set: The Core Presentation Characteristics should focus on a minimal initial set of attributes that are agreed to be highly useful, and accept that further attributes could be added later as their need becomes obvious.

5 End-to-End Use Cases

The following use cases are intended to motivate the need for Core Presentation Characteristics in a few well-defined situations.  

Some use cases are shown as requests for particular resources. Not all the attributes may need to be sent with each request, depending on the protocol used in the request. For example, in CC/PP or UAProf, attributes can be included as part of an HTTP request either explicitly or by reference to a base profile. It is not the purpose of the proposed recommendation to specify which representation and protocol should be used for conveying attributes.

One use case is shown as the definition of a document profile. It is intended that the attributes associated with a document could be used as part of content negotiation to match the document to a request for a specific delivery context. Again, it is not the purpose of the proposed recommendation to specify a particular content negotiation mechanism. However, the value of using comparable attributes in a document request and in a document profile should be obvious.

The example attributes listed as part of the use cases are not intended to define the exact attribute names or the syntactic representations to be used in the final recommendation. These example attributes are also not intended to be the only attributes needed in these use cases. The proposed recommendation will need to consider which attributes should be defined as core. The assumption should not be made that the following examples will be included in the core.

5.1 Request for a static image resource


A user agent wishes to fetch a static image resource and include it as part of a presentation.


This is a common situation when a web browser fetches an image for inclusion in a web page. It could also apply when fetching an image for display on its own, such as in a photo album appliance. An alternative scenario would be a web browser that already has a reference to an image resource but wishes to present it in some alternative form, such as text or speech.


The user agent may require the presented image to fit within a certain display area. The image resource may be available in different formats and resolutions. The user agent may wish to fetch a textual summary of the image rather than the image itself.


The following Core Presentation Characteristics could therefore be relevant as part of making the request for the resource:


Although the user agent may suggest a desired image size, there is no guarantee (depending on the extent to which the delivery path supports content negotiation and adaptation) that the delivered image will be that particular size. Browsers themselves are often able to scale an image to the size they need. However, including a specific target size provides the origin server or intermediate image proxy with the opportunity to select an appropriate version of the image, provided this is possible and permitted.  Within the delivery context protocol, further controls over intermediate processing may be needed.

5.2 Request for an HTML resource


A user agent wishes to fetch an HTML resource and render it within the constraints of the delivery context.


This is a common situation when a web browser fetches an HTML web page for display in a browser window. It could also apply when a proxy fetches some HTML for display within a defined area within a portal presentation.


The user agent requires the presentation to fit within a certain viewing area such as a browser window, a pane of a portal, or a fixed-size display such as a projector.  When rendering the presentation, the user agent is still allowed to adapt the content to fit into this viewing area or to scroll within the viewing area as needed. The resource may be available in different versions of HTML. The resource may use different techniques for adding presentation styling. The user agent may support only a limited set of fonts. The presentation may be designed for viewing from a certain distance. The viewer may prefer the presentation not to include small text.


The following Core Presentation Characteristics would therefore be relevant as part of making the request for the resource:


The user agent is responsible for rendering the HTML in an appropriate way, including matching it to the available display area and available fonts. However, by suggesting acceptable and desired attributes, the opportunity exists for the origin server, or some intermediate proxy, to support this goal by providing the most appropriate version of the resource. For example, an abbreviated and more simply formatted version of of the resource may be sent to a small display such as those on a PDA or phone.

Remark: The scenario in this use case does not demand or assume that the server is able to deliver a preformatted HTML resource that fulfills all of the Core Presentation Characteristics. The only expectation is that the server sends the most appropriate version of the requested resource.

5.3 Request for an interactive resource


A user agent wishes to fetch an interactive resource and include it as part of a presentation.


This situation occurs when a web browser fetches an HTML web page which includes some interactive elements, such as a form. It builds on the previous example of a simple HTML page, and therefore could be used in similar situations and require similar attributes for the display aspects of the presentation. The additional burden on the user agent is how the interactive parts of the presentation can be matched in the best way to the input capabilities of the presentation device.


Interaction may relate to navigation and selection, such as the ability to choose from a menu or to select by pointing or tabbing and click on a link. It may also relate to the ability to enter arbitrary text in specific alphabets.


The following additional Core Presentation Characteristics would be relevant to making the request for a resource:


By suggesting acceptable interaction attributes, the opportunity exists for the origin server, or some intermediate proxy, to do a better job of providing an appropriate version of the resource. For example, a version of the resource with simpler navigation requirements may be sent to a device with no pointing input such as a phone or a speech browser.

5.4 Profile of a document


A document has attributes that express its delivery expectations.


The author of an HTML document or the authoring tool which created it may express the conditions under which this document should be considered suitable for a particular delivery context. Content negotiation [Conneg] suggests there is a need to match the attributes of the resources available for delivery (which could be expressed in a document profile) with the attributes of the delivery context. CSS Media Queries [CSSMediaQueries] already provides a mechanism for allowing an author to specify alternative styles appropriate to different delivery contexts.


Some aspects of a document are intrinsic to the document itself, such as the markup language and version, or the fonts used.   Other aspects may be constraints imposed by the author, such as the minimum presentation size for which the document has been designed.


The following Core Presentation Characteristics could therefore be relevant as part of the document profile:


Some of these attributes can be extracted from the document markup itself (or its associated style sheet), such as the markup language and version or the fonts it uses. Some early ideas on document profiles were produced by the HTML working group [DocProfile]. Further work in this area is within the charter of the Device Independence Working Group [DI-charter].  However, this use case should be considered speculative at this stage.


[CC/PP: Structure and Vocabularies]
[CC/PP Implementors Guide]
Harmonization with Existing Vocabularies and Content Transformation, W3C Note,
IETF Content Negotiation Working Group, concluded October 2000
[CSS Media Queries]
Dublin Core Metadata Initiative
Delivery Context Overview for Device Independence
W3C Device Independence Working Group Charter
Device Independence Principles, W3C Working Draft 18 September 2001
For latest version see: http://www.w3.org/TR/di-princ/
XHTML Document Profile Requirements
Feature Set Matching, sample software by Graham Klyne
A Syntax for Describing Media Feature Sets, IETF RFC-2533 March 1999
Media Features for Display, Print and Fax, IETF RFC-2534 March 1999
Media Queries, W3C Candidate Recommendation 8 July 2002
For latest version see: http://www.w3.org/TR/css3-mediaqueries/
Platform for Privacy Preferences Project, W3C Initiative
User Agent Profiling Specification, WAP Forum 20 October 2001
For latest version see: http://www.wapforum.org/what/technical.htm

Other References:


The following definitions are taken from the HTTP/1.1 specification (RFC 2616) [HTTP] and the Device Independence Principles [DIP].

A data element described with a specific associated name-value pair. [HTTP]
access mechanism
A combination of hardware (including one or more devices and network connections) and software (including one or more user agents) that allows a user to perceive and interact with the Web using one or more interaction modalities (sight, sound, keyboard, voice etc.). [DIP]
An apparatus through which a user can perceive and interact with the Web. [DIP]
delivery context
A set of attributes that characterizes the capabilities of the access mechanism and the preferences of the user. [DIP]
origin server
The server on which a given resource resides or is to be created. [HTTP]
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy must implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. [HTTP]
An entity included with a response that is subject to content negotiation. There may exist multiple representations associated with a particular response status. [HTTP]
An HTTP request message [HTTP]
An HTTP response message [HTTP]
A network data object or service that can be identified by a URI. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. [HTTP]
An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. [HTTP]
A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `variant.' Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. [HTTP]
user agent
The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. [HTTP]
A process within a device that renders the presentation data for a web page into physical effects that can be perceived and interacted with by the user. [DIP]


This document was produced by members of the W3C Device Independent Working Group. Special thanks for their contributions, suggestions and discussions in the preparation of this document are due to the following:

We also thank Graham Klyne, Larry Masinter, Martin Jones and Håkon Wium Lie for their comments on the earlier informal draft, and have made several changes in response. However, there may still be aspects with which they disagree.

The full membership of the group at the time of publication is shown below.