Core Presentation Attributes: Requirements and Use Cases
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.
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.
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
- a common set of presentation attributes
- that can be reused in different delivery context vocabularies
- but share a common semantics
- in order to simplify the task of interpreting these attributes when
adapting content for presentation in different delivery contexts.
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.
The following examples illustrate difficulties in using existing vocabularies
with regards to specific criteria of relevance to authoring for Device Independence.
- Attributes cover a wide range of device capabilities - some of
which are implementation-specific and others are generic. For the sake of
device independence, we would like to emphasize attributes that are relevant
to presentation and independent of the details of the device-specific
implementation.
For example, an attribute defining the amount of memory available
in the device is effectively meaningless without detailed knowledge of the
device's implementation.
- Similar attributes have been given non-uniform names
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.'
- Syntax is different for different vocabularies. Some
of this syntax is easily translatable
to XML, but in some cases this translation is not as obvious.
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].
- Different approaches have been taken to defining the allowable values (type) of an attribute.
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].
- The semantics of the attributes are often unclear.
For example, what is the meaning of display size being defined
as a signed integer in Conneg [Conneg]?
- Attributes with similar names may have very different semantics
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].
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:
- a URI to unambiguously identify the attribute
- a unique alphanumeric string for its attribute name
- an XML Schema Datatype definition for its allowable attribute values
- at least one literal syntactic representation for each attribute value
- a natural language semantic definition (as unambiguous as feasible
without formalism)
- an illustration of how the attribute could be used in adapting content
for presentation
- a unit of measurement associated
with the attribute in a non-ambiguous
way
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:
- one or more XML schema (with URI)
- and/or one or more RDF schema (with URI)
- and/or one or more CC/PP schema (with URI)
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:
- clearly identify the applicable attribute definition in any instance
- maximize the backward and forward compatibility with existing and future
applications.
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.
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:
- acceptable image formats and versions: e.g. GIF89a, JPEG-2000
- target image size: e.g. 400 x 300 pixels
- target image colors: e.g. 24-bit rgb color per pixel
- acceptable alternative formats: e.g. text/plain, text/html
- target textual alternative length: e.g. caption (c.f. alt in HTML),
description (c.f. longdesc in HTML)
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:
- acceptable content formats and versions: e.g. HTML 4.0, XHTML 1.0
- acceptable content modules: e.g. XHTML Frames
- acceptable styling formats and versions: e.g. CSS 1.0, CSS 2.0 Mobile
Profile
- acceptable font families: e.g. sans-serif, serif
- acceptable fonts: e.g. Arial, Times New Roman
- acceptable languages: e.g. en, fr, de
- target presentation size: e.g. 300 x 150 pixels
- target presentation colors: e.g. 8-bit color per pixel from a palette
of 64K colors
- target text viewing distance: e.g. 40cm
- preferred minimum text size: e.g.10 point
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:
- acceptable interaction formats: e.g. HTML 4.0 form elements, XForms
1.0
- acceptable input modalities: e.g. text, pointer, tabbing, voice
- acceptable text input languages: e.g. en, fr
- acceptable speech recognition grammar size: e.g. 100 words
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:
- markup format and version: e.g. HTML 4.0, XHTML Transitional
- modules used in document: e.g. XHTML Frames
- text languages used in document: e.g. en, de
- font families used in document style: e.g. sans-serif
- fonts used in document style: e.g. Arial
- minimum target presentation size: e.g. 640 x 480 pixels
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.
- [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
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]
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:
- Michael Wasmund, IBM
- Shlomit Ritz Finkelstein
- Rotan Hanrahan, MobileAware
- Mark Butler, HP
- Roland Merrick, IBM
The full membership of the group at the time of publication is shown below.
This document does not yet represent a consensus view.
- Roger Gimson, HP (Chair, Co-Author)
- Markus Lauff, SAP (Co-Editor, Co-Author)
- Amy Yu, SAP (Co-Editor)
- Lalitha Suryanarayana, SBC Technology Resources (Co-Author)
- Mark Butler, HP
- Guido Grassel, Nokia
- Rhys Lewis, Volantis Systems
- Mark Watson, Volantis Systems
- Rotan Hanrahan, MobileAware
- Eamonn Howe, MobileAware
- Luu Tran, Sun Microsystems
- Greg Ziebold, Sun Microsystems
- Candy Wong, NTT DoCoMo
- Masashi Morioka, NTT DoCoMo
- Yoshihisa Gonno, Sony
- Steve Farowich, Boeing
- Roland Merrick, IBM
- Michael Wasmund, IBM
- Dennis Bushmitch, Panasonic
- Ryuji Tamagawa, Sky Think System
- Abbie Barbir, Nortel Networks
- Shlomit Ritz Finkelstein
- Jason White, University of Melbourne
- Kazuhiro Kitagawa, (W3C Activity Lead)
- Stephane Boyera, (W3C Staff Contact)
- Wendy Chisholm, (W3C WAI)
- Philipp Hoschka, (W3C Domain Lead)