Core Presentation Attributes:  Requirements and Use Cases

Informal public draft
17 January 2003

This version:
Latest version:
Previous version:
No previous public version.
Markus Lauff (SAP)
Amy Yu (SAP)
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 Attributes. The purpose of defining these Core Presentation Attributes is to provide a common set of 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 Attributes will simplify the task of adapting content to a specific presentation delivery content. The Requirements set out what is meant by 'core' and 'presentation', what is included in the definition of each attribute, as well as the way in which the attributes relate to existing standards and can be used in future vocabularies.

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 has no official standing. It is an informal draft made available for comment and early feedback. It may contain sections that are incomplete or inconsistent.

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.

Comments on this document may be sent to the public mailing list (archived at

A list of current W3C Recommendations and other technical reports can be found at

Table of contents

1 Introduction and Background

Information characterizing the delivery context of the end presentation device is a critical enabler for device independent authoring. 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 niche context of usage and implementation.  However, a standardized definition of key attributes is lacking, which would likely be used across applications universally specifically for the purposes of device  independent adaptation and rendering. The absence of a well-defined core set of attributes can lead to the proliferation of incompatible yet overlapping repositories of attributes that may conflict and detriment 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 attribute sets.

By defining a core set of presentation attributes, and showing their relationship to existing vocabularies, the Device Independence Working Group hopes that future vocabularies can reuse these common definitions. Authors of web applications will then have a sound basis for expressing the adaptation of their content to device presentation capabilities.

2 Purpose and Scope

The intended purpose of the Core Presentation Attributes recommendation will be to define Therefore, the scope of the Core Presentation Attributes 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 Attributes are those attributes that define some aspects of the way in which content may be presented to a user of an access mechanism.  Presentation attributes 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 in 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 in which the text can be rendered.

Core Presentation Attributes 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 Attributes recommendation. Specific information such as purpose and application of existing vocabulary sets are beyond the scope of this Requirements document. The proposed Core Presentation Attributes will be related to those of existing vocabularies as part of the future recommendation. However, the proposed core attributes will not be simply a union or intersection of existing vocabularies because of difficulties outlined in the next section.

Attributes related to a specific protocol, access rights, dynamic behaviour, or persistence are outside the scope of this document and are not addressed. The aim of this document is also not to provide information regarding the purpose of delivery context and various access mechanisms. These are discussed in earlier publications from this group [DIP, DCO].

Dublin Core [DC] defines a set of attributes that are relevant to document description and which have been reused in many context 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 attributes.

3 Challenges Introduced by Existing Vocabularies

The following examples illustrate difficulties in using existing vocabularies with regards to specific criteria of relevance 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 Conneg [Conneg] 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 Conneg [Conneg] 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 Conneg [Conneg], 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 Conneg [Conneg]?
For example, 'color' is represented by an enumerated selection in Conneg [Conneg], while 'color' is represented as a number of bits in CSS Media Queries [CSSMediaQueries], and 'ColorCapable' is defined as a boolean in UAProf [UAProf].

4 Requirements for Core Presentation Attributes

The following Requirements have been divided into two categories: Requirements that define the structures and properties of the attributes and the Requirements that define the attributes themselves.

4.1 Requirements defining the structure and properties of attributes

4.1.1 General

Each individual Core Presentation Attribute definition must include the following:

4.1.2 Uniqueness

Every attribute must have a name that uniquely identifies it.  Different attribute names will not be used to describe the same presentation capability.

4.2 Requirements defining the collection of Core Presentation Attributes

4.2.1 Reuse

The overall set of Core Presentation Attributes must be defined as:

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

4.2.2 Extensibility

It must be possible to add additional presentation attributes beyond the Core Presentation Attributes to make a presentation-specific vocabulary.

4.2.3 Modularity

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

4.2.4 Versioning

The CPA document should make proposals for how adding, removing or changing attributes in a vocabulary should be handled in order to:

4.2.5 Support for modalities

The Core Presentation Attributes should provide means to describe the modalities of a device.  Questions such as the following should be answered: Is the device able to process speech, ink, or only text?  Attributes that express such capabilities should be defined. 

4.2.6 Separation of input and output 

The Core Presentation Attributes should allow the author to specify whether an attribute is applicable to output, input, or both, as this is an essential part of the semantic description. 

4.2.7 Navigation capabilities 

The Core Presentation Attributes should provide a means to express the navigational capabilities of a device. This is not just a matter of physical properties (e.g. touch screen, knobs, or dials) but also of navigation widgets offered by the built-in browser. The navigational capabilities should thereby also contain semantic descriptions about the appearance (e.g. red/green button, wheel)

4.2.8 Conditional behaviour / union sets 

The vocabulary should allow to carry alternative sets of device attributes. 

Example / Purpose: some devices may be able to offer high resolution with low rendering speed or low resolution with high rendering speed. The CPA should allow to express this two alternative sets of attributes. The requirement dos NOT call for the ability to express sophisticated if-then-else constructs. 

4.2.9 Hierarchical Grouping

It must be possible to group attributes hierarchically. The grouping may be used to define META attributes or to qualify attributes in the hierarchy. META information for example could be used to express the lifetime of a value of an attribute or the relation of the attribute to the delivery context.

4.2.10 Compound Values

It should be possible for a Core Presentation Attribute to be represented as a set of values that may be ordered or unordered.

5 End-to-End Use Cases

The following use cases are intended to motivate the need for Core Presentation Attributes 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 show 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.

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 the ubiquitous 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. On the other hand, a web browser may already have 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 Attributes would therefore be relevant as part of making the request for the resource:


Though the user agent may suggest a target 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 size. Browsers themselves are often able to scale an image to the size they need. By suggesting a target size, however, the opportunity exists for the origin server, or some intermediate image transcoding proxy, to do a better job (where possible and permitted) of providing an appropriate version of the image.  Within the delivery context protocol, further controls over intermediate processing may be needed.

5.2 Request for a static formatted (HTML) resource


A user agent wishes to fetch a static formatted resource (represented as HTML) and include it as part of a presentation.


This is the ubiquitous 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, or when a user agent fetches a presentation for filling a complete display area such as a projected presentation.


The user agent requires the presentation to fit within a certain display area. The formatted resource may be available in different versions of HTML. The formatted 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 Attributes 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 target 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, an abbreviated and more simply formatted version of the resource may be sent to a small display, such as a PDA or phone or portlet, rather than a large display, such as a PC screen.

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 is the situation 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 static formatted resource, 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 to match the interactive parts of the presentation 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 Attributes would therefore be relevant as part of making the request for the 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.


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 Attributes would therefore be relevant as part of the document profile:


Some of these attributes can be extracted from the document markup itself (or its associated stylesheet), such as the markup language and version or the fonts it uses.


[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:
Feature Set Matching, sample software by Graham Klyne
A Syntax for Describing Media Feature Sets, IETF RFC-2533 March 1999
Media Queries, W3C Candidate Recommendation 8 July 2002
For latest version see:
Platform for Privacy Preferences Project, W3C Initiative
User Agent Profiling Specification, WAP Forum 20 October 2001
For latest version see:


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:

The full membership of the group at the time of publication is shown below. This document does not yet represent a consensus view.