suggestion: link to http://www.w3.org/StyleSheets/TR/W3C-NOTE.css instead of defining W3C Note styles inline

Core Presentation Attributes: Requirements and Use Cases

If renaming this document "Core Presentation Characteristics: Requirements and Use Cases", then all references to the future "Core Presentation Attributes" document needs to change to "Core Presentation Characteristics" too. However, I noticed several instances where the title of the CPA document is used to refer to the set of delivery context attributes that will be defined in the CPA document. This needs to be resolved. I don't expect that a simple search and replace through this document will suffice.

Informal public draft
17 January 2003

This version:
http://www.w3.org/2001/di/public/cpa-req/cpa-req-draft-20030117.html
Latest version:
http://www.w3.org/2001/di/public/cpa-req/
Previous version:
No previous public version.
Editors:
Markus Lauff (SAP) markus.lauff@sap.com
Amy Yu (SAP) amy.yu@sap.com
Authors:
Roger Gimson (HP)
Lalitha Suryanarayana (SBC Technology Resources)
Markus Lauff (SAP)
Contributors:
See Acknowledgments

Copyright 2003 W3C (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

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 typo?: "content" should be "context"?. The Requirements set suggestion: replace "The Requirements set" with "This document sets" 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 suggestion: change "as well as the way in which the attributes relate to existing standards and can be used in future vocabularies" to "the way in which the attributes relate to existing standards, and how the attributes 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 www-di@w3.org mailing list (archived at http://lists.w3.org/Archives/Public/www-di/).

A list of current W3C Recommendations and other technical reports can be found at http://www.w3.org/TR.

Table of contents

1 Introduction and Background

Information characterizing the delivery context of the end presentation device suggestion: replace "the end presentation device" with "a web access mechanism" to be consistent with DIP and DCO is a critical enabler for device independent authoring suggestion: since delivery context is also important for adaptation, replace "device independent authoring" with "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 niche suggestion: replace "niche" with "application specific" context of usage and implementation. However, a standardized definition of key attributes is lacking, which would likely be used across applications universally suggestion: insert "and" specifically for the purposes of device typo: extraneous   here 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 Breaking up a long sentence into a bulleted list is a little awkward to read.  Suggestion: replace with "...will be to define a common set of presentation attributes that:
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 suggestion: replace "in" with "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 in suggestion: replace "in" with "with" 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.  This paragraph seems like it should be moved to the beginning of this 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 typo: "context" should be "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 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. Within what namespace does this uniqueness apply? Globally unique? Unique within the CPA document? I imagine it would suffice to define the attribute names uniquely within the CPA document and also define a unique CPA namespace. The CPA namespace together with the attribute name as a local part would then be used as a qualified name for global uniqueness.

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 suggestion: expand "CPA" to "Core Presentation Attributes" 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 grammar: replace "to carry" with "the ability to express" alternative sets of device suggestion: replace "device" with "presentation" 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 suggestion: expand "CPA" to "Core Presentation Attributes document" should allow grammar: insert "the ability" to express this grammar: replace "this" with "these" 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.

I don't understand the necessity for this requirement. Grouping can be accomplished without the need for hierarchy. Also, how many levels of hierarchy are required? CC/PP only allows one level, i.e. components.

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

Summary

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

Context

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.

Variants

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.

Attributes

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

Discussion

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

Summary

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

Context

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.

Variants

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.

Attributes

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

Discussion

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

Summary

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

Context

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.

Variants

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.

Attributes

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

Discussion

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

Summary

A document has attributes that express its delivery expectations.

Context

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.

Variants

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.

Attributes

The following Core Presentation Attributes would therefore be relevant as part of the document profile:

Discussion

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.

References

[CC/PP]
http://www.w3.org/Mobile/CCPP/
[CC/PP: Structure and Vocabularies]
http://www.w3.org/TR/CCPP-struct-vocab/
[CC/PP Implementors Guide]
Harmonization with Existing Vocabularies and Content Transformation, W3C Note,
http://www.w3.org/TR/2001/NOTE-CCPP-COORDINATION-20011220/
[Conneg]
IETF Content Negotiation Working Group, concluded October 2000
http://www.ietf.org/html.charters/OLD/conneg-charter.html
[CSS Media Queries]
http://www.w3.org/TR/css3-mediaqueries
[DC]
Dublin Core Metadata Initiative
http://dublincore.org/
[DCO]
Delivery Context Overview for Device Independence
http://www.w3.org/2001/di/public/dco/
[DI-charter]
W3C Device Independence Working Group Charter
http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html
[DIP]
Device Independence Principles, W3C Working Draft 18 September 2001
For latest version see: http://www.w3.org/TR/di-princ/
[FSM]
Feature Set Matching, sample software by Graham Klyne
http://www.ninebynine.org/Software/Conneg-FSM/
[HTTP]
http://www.w3.org/Protocols/rfc2616/rfc2616.html
[MFS]
A Syntax for Describing Media Feature Sets, IETF RFC-2533 March 1999
http://www.ietf.org/rfc/rfc2533.txt
[MQ]
Media Queries, W3C Candidate Recommendation 8 July 2002
For latest version see: http://www.w3.org/TR/css3-mediaqueries/
[P3P]
Platform for Privacy Preferences Project, W3C Initiative
http://www.w3.org/P3P/
[SMIL]
http://www.w3.org/AudioVideo/
[SMIL1]
http://www.w3.org/TR/REC-smil
[SMIL2]
http://www.w3.org/TR/smil20
[UAProf]
User Agent Profiling Specification, WAP Forum 20 October 2001
For latest version see: http://www.wapforum.org/what/technical.htm

Glossary

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

attribute
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]
device
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]
proxy
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]
representation
An entity included with a response that is subject to content negotiation. There may exist multiple representations associated with a particular response status. [HTTP]
request
An HTTP request message [HTTP]
response
An HTTP response message [HTTP]
resource
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]
server
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]
variant
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]

Acknowledgements

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.