You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
942 lines
44 KiB
942 lines
44 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<html lang="en">
|
|
<head>
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-us">
|
|
<title>Core Presentation Characteristics: Requirements and Use
|
|
Cases</title>
|
|
<link href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" rel="stylesheet"
|
|
type="text/css">
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
|
|
alt="W3C" border="0" height="48" width="72"></a>
|
|
|
|
<h1 id="cpctit">Core Presentation Characteristics: Requirements and Use
|
|
Cases</h1>
|
|
|
|
<h2><span lang="en-us">W3C Working Draft<br>
|
|
10 May 2003</span></h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2003/WD-cpc-req-20030510/">http://www.w3.org/TR/2003/WD-cpc-req-20030510/</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/cpc-req/">http://www.w3.org/TR/cpc-req/</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd style="margin-top: 0; margin-bottom: 0">First public working
|
|
draft</dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Markus Lauff (SAP) <a
|
|
href="mailto:markus.lauff@sap.com">markus.lauff@sap.com</a></dd>
|
|
<dd>Amy Yu (SAP) <a href="mailto:amy.yu.sap.com">amy.yu@sap.com</a></dd>
|
|
<dt>Authors:</dt>
|
|
<dd>Roger Gimson (HP)</dd>
|
|
<dd>Lalitha Suryanarayana (SBC Technology Resources)</dd>
|
|
<dd>Markus Lauff (SAP)</dd>
|
|
<dt>Contributors:</dt>
|
|
<dd>See <a href="#acknowledgements">Acknowledgments</a></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
©2003 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.org/"> <acronym
|
|
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
|
|
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p>
|
|
</div>
|
|
<hr title="Separator for header">
|
|
|
|
<h2><a id="abstract">Abstract</a></h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<h2><a id="status">Status of this document</a></h2>
|
|
|
|
<p><em>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.</em></p>
|
|
|
|
<p>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 <a href="http://www.w3.org/TR/">http://www.w3.org/TR</a>.</p>
|
|
|
|
<p>This is a working draft of a possible future W3C Note.</p>
|
|
|
|
<p>This document is published as part of the <a
|
|
href="http://www.w3.org/2001/di/Activity">W3C Device Independence Activity
|
|
</a>by the Device Independence Working Group. It is a deliverable as defined
|
|
in the <a
|
|
href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">charter</a>
|
|
of that group. An <a
|
|
href="http://www.w3.org/2001/di/public/cpa-req/cpa-req-draft-20030117.html">earlier
|
|
version</a> was made available as an informal public draft by the working
|
|
group.</p>
|
|
|
|
<p>Comments on this document may be sent to the public <a
|
|
href="mailto:www-di@w3.org">www-di@w3.org</a> mailing list (archived at <a
|
|
href="http://lists.w3.org/Archives/Public/www-di/">
|
|
http://lists.w3.org/Archives/Public/www-di/</a>).</p>
|
|
|
|
<p>Patent disclosures relevant to this document may be found on the <a
|
|
href="http://www.w3.org/2001/di/Disclosures.html">WG patent disclosure
|
|
page</a>.</p>
|
|
|
|
<h2><a id="contents">Table of contents</a></h2>
|
|
<ul class="toc">
|
|
<li><a href="#introduction">1. Introduction and Background</a></li>
|
|
<li><a href="#2_Purpose_and_Scope">2. Purpose and Scope</a></li>
|
|
<li><a href="#problemsexisting">3. Challenges Introduced by Existing
|
|
Vocabularies</a></li>
|
|
<li><a href="#requirements">4. Requirements for Core Presentation
|
|
Characteristics</a></li>
|
|
<li><a href="#5_End-to-End_Use_Cases">5. End to End Use Cases</a></li>
|
|
<li><a href="#references">References</a></li>
|
|
<li><a href="#glossary">Glossary</a></li>
|
|
<li><a href="#acknowledgements">Acknowledgments</a></li>
|
|
</ul>
|
|
<hr>
|
|
|
|
<h2><a name="introduction">1 Introduction and Background</a></h2>
|
|
|
|
<p>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 <a href="#DCO">[DCO]</a>
|
|
summarizes the various techniques currently used within the industry for
|
|
representing, conveying and processing delivery context information. Most of
|
|
these approaches like OMA UAProf <a href="#uaprof">[UAProf</a>] and CSS Media
|
|
Queries <a href="#CSS_Meda_Queries">[CSSMediaQ]</a> 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. </p>
|
|
|
|
<p>An attempt to address these issues was first initiated in the context of
|
|
CC/PP. In fact, the CC/PP specification <a href="#CCPP_spec">[CC/PP]</a>
|
|
provides a sample non-normative "core" vocabulary for CC/PP aware devices.
|
|
While the CC/PP Implementer's Guide <a
|
|
href="#CCPP_Implementors_Guide">[CC/PP-Guide]</a> 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.</p>
|
|
|
|
<p><span lang="en-us">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.</span></p>
|
|
|
|
<p><span lang="en-us">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.</span></p>
|
|
|
|
<h2><a name="2_Purpose_and_Scope"></a>2 Purpose and Scope</h2>
|
|
|
|
<p>The intended purpose of the Core Presentation Characteristics
|
|
recommendation will be to define a common set of presentation properties or
|
|
attributes that:</p>
|
|
<ul>
|
|
<li>can be reused in different delivery context vocabularies</li>
|
|
<li>share common semantics </li>
|
|
<li>simplify the task of interpreting these attributes when adapting or
|
|
authoring content for presentation in different delivery contexts</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><b>Presentation </b>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.</p>
|
|
|
|
<p><b>Core </b>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 [<a href="#DIP">DIP</a>] and the Delivery
|
|
Context Overview for Device Independence [<a href="#DCO">DCO</a>].</p>
|
|
|
|
<p>Dublin Core [<a href="#DC">DC</a>] 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.</p>
|
|
|
|
<h2><a name="problemsexisting">3 Challenges Introduced by Existing
|
|
Vocabularies</a></h2>
|
|
|
|
<p>The following examples illustrate difficulties in using existing
|
|
vocabularies with regards to specific criteria that are relevant to authoring
|
|
for device independence. </p>
|
|
<ul>
|
|
<li>Existing properties and attributes cover a wide range of device
|
|
capabilities - some of which are implementation-specific and others
|
|
are generic. For the sake of device independence, emphasis should be
|
|
placed on attributes that are relevant to presentation and independent of
|
|
the details of the device-specific implementation. </li>
|
|
</ul>
|
|
|
|
<div align="left">
|
|
|
|
<blockquote>
|
|
<p><i>For example, an attribute defining the amount of memory available in
|
|
the device is effectively meaningless without detailed knowledge of the
|
|
device's implementation.</i></p>
|
|
</blockquote>
|
|
</div>
|
|
<ul>
|
|
<li>Similar properties and attributes have been given non-uniform names</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p><i>For example, screen size has been designated in various ways in
|
|
different vocabularies: in IETF Media Feature set [<a
|
|
href="#Conneg">MFS</a>] it has been named 'pix-x' and 'pix-y,' in SMIL 1.0
|
|
[<a href="#smil">SMIL1</a>] 'system-screen-size,' in SMIL 2.0 [<a
|
|
href="#SMIL2">SMIL2</a>] 'systemScreenSize,' and in CSS Media Queries [<a
|
|
href="#CSS_Meda_Queries">CSSMediaQueries</a>] 'device-width' and
|
|
'device-height.' </i></p>
|
|
</blockquote>
|
|
<ul>
|
|
<li>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. </li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p><i>For example, screen size may be given as separate values for width
|
|
and height, as in IETF Media Feature set [<a href="#Conneg">MFS</a>] and
|
|
CSS Media Queries [<a href="#CSS_Meda_Queries">CSSMediaQueries</a>], or as
|
|
a compound value, such as 'heightxwidth' in SMIL [<a href="#smil">SMIL</a>]
|
|
or 'widthxheight' in UAProf [<a href="#uaprof">UAProf</a>].</i></p>
|
|
</blockquote>
|
|
<ul>
|
|
<li>Different approaches have been taken to defining the allowable values,
|
|
or type, of an attribute.</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
|
|
<div align="left">
|
|
<i>For example, a natural language description is used in IETF Media
|
|
Feature set [<a href="#mfs">MFS</a>], SMIL [<a href="#smil">SMIL</a>], and
|
|
UAProf [<a href="#uaprof">UAProf</a>], whereas an RDF schema is used in the
|
|
CC/PP example vocabulary [<a href="#CCPP_spec">CC/PP</a>].</i></div>
|
|
</blockquote>
|
|
<ul>
|
|
<li>The semantics of the attributes are often unclear.</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p><i>For example, what is the meaning of display size being defined as a
|
|
signed integer in IETF Media Feature set [<a href="#mfs">MFS</a>]?</i></p>
|
|
</blockquote>
|
|
<ul>
|
|
<li>Attributes with similar names may have very different semantics</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p><i>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 [<a href="#mfs">MFS</a>] but as a number of bits in
|
|
CSS Media Queries [<a href="#CSS_Meda_Queries">CSSMediaQueries</a>] .
|
|
'ColorCapable' is defined as a boolean in UAProf [<a
|
|
href="#uaprof">UAProf</a>].</i></p>
|
|
</blockquote>
|
|
|
|
<h2><a name="requirements">4 Requirements for Core Presentation
|
|
Characteristics</a></h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3 id="r41">4.1 Requirements defining the structure and properties of
|
|
individual attributes</h3>
|
|
|
|
<p><span lang="en-us">Each individual core presentation characteristic
|
|
definition of an attribute must include the following:</span></p>
|
|
<ul>
|
|
<li><span lang="en-us"><b>CPCR01</b> a universally unique
|
|
identifier</span></li>
|
|
<li><span lang="en-us"><b>CPCR02</b> an XML Schema Data type definition for
|
|
its allowable attribute values</span></li>
|
|
<li><span lang="en-us"><b>CPCR03</b> at least one literal syntactic
|
|
representation for each attribute value</span></li>
|
|
<li><span lang="en-us"><b>CPCR04</b> a natural language semantic definition
|
|
(that is as unambiguous as possible without formalism)</span></li>
|
|
<li><span lang="en-us"><b>CPCR05</b> an illustration of how the attribute
|
|
could be used in adapting content for presentation</span></li>
|
|
</ul>
|
|
|
|
<p>If an attribute is associated with a measurable numeric value:</p>
|
|
<ul>
|
|
<li><span lang="en-us"><b>CPCR06</b> the unit of measurement associated
|
|
with the attribute needs to be expressed in a non-ambiguous way, but only
|
|
if a unit of measurement can be associated with the attribute.</span></li>
|
|
</ul>
|
|
|
|
<p>An attribute may have a value that is not a simple value when:</p>
|
|
<ul>
|
|
<li><b>CPCR07</b> the option of expressing a compound value for an
|
|
attribute, such as a set or sequence, is theoretically possible.</li>
|
|
</ul>
|
|
|
|
<p>Where the description is available in the official language of the W3C:</p>
|
|
<ul>
|
|
<li><b>CPCR08 - Natural Language:</b>At least one version of natural
|
|
language definitions, explanations, and other textual descriptions should
|
|
be provided in American English.</li>
|
|
</ul>
|
|
|
|
<h3><span lang="en-us" id="r42">4.2 Requirements defining the collection of
|
|
characteristics</span></h3>
|
|
|
|
<p><span lang="en-us"><b>CPCR09 - Reuse: </b>The overall set of Core
|
|
Presentation Characteristics must be defined as:</span></p>
|
|
<ul>
|
|
<li><span lang="en-us">one or more XML schemas (with URI)</span></li>
|
|
<li><span lang="en-us">and/or one or more RDF schemas (with URI)</span></li>
|
|
<li><span lang="en-us">and/or one or more CC/PP schemas (with
|
|
URI)</span></li>
|
|
</ul>
|
|
|
|
<p><span lang="en-us">in order to allow unambiguous reuse of the core
|
|
attributes in different application contexts.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR10 - Extensibility: </b>It must be possible to
|
|
add additional presentation attributes beyond the Core Presentation
|
|
Characteristics to make a presentation-specific vocabulary.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR11 - Modularity: </b>The core attributes must be
|
|
grouped into related subsets to allow reuse of selected subsets in defining
|
|
future vocabularies.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR12 - Versioning:</b> 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:</span></p>
|
|
<ul>
|
|
<li><span lang="en-us">clearly identify the applicable attribute definition
|
|
in any instance</span></li>
|
|
<li><span lang="en-us">maximize the backward and forward compatibility with
|
|
existing and future applications</span></li>
|
|
</ul>
|
|
|
|
<h3><span lang="en-us" id="r43">4.3 Requirements about what characteristics
|
|
are in the core</span></h3>
|
|
|
|
<p><span lang="en-us"><b>CPCR13 </b></span><b><span lang="en-us">- Related
|
|
work</span></b><span lang="en-us"><b>:</b> 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.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR14 - Common Adaptation:</b> The Core
|
|
Presentation Characteristics must be useful for common adaptation
|
|
tasks.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR15 - Support for modalities:</b> The Core
|
|
Presentation Characteristics should provide means to describe the modalities
|
|
of a device.</span></p>
|
|
|
|
<p><b><span lang="en-us">CPCR16 - Separation of input and
|
|
output</span></b><span lang="en-us"><b>:</b> The Core Presentation
|
|
Characteristics should allow the author to specify whether an attribute is
|
|
applicable to output, input, or both. </span></p>
|
|
|
|
<p><b><span lang="en-us">CPCR17 - Navigation capabilities</span></b><span
|
|
lang="en-us"><b>:</b> The Core Presentation Characteristics should provide a
|
|
means to express the navigational capabilities of a device.</span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR18 - Interoperability: </b>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. </span></p>
|
|
|
|
<p><span lang="en-us"><b>CPCR19 - Minimal initial set:</b> The Core
|
|
Presentation Characteristics should</span> 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.</p>
|
|
|
|
<h2><a name="5_End-to-End_Use_Cases">5 End-to-End Use Cases</a></h2>
|
|
|
|
<p>The following use cases are intended to motivate the need for Core
|
|
Presentation Characteristics in a few well-defined situations. </p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3 id="r51">5.1 Request for a static image resource</h3>
|
|
|
|
<h4 id="sum">Summary</h4>
|
|
|
|
<p>A user agent wishes to fetch a static image resource and include it as
|
|
part of a presentation.</p>
|
|
|
|
<h4 id="cont">Context</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="varia">Variants</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="att">Attributes</h4>
|
|
|
|
<p>The following Core Presentation Characteristics could therefore be
|
|
relevant as part of making the request for the resource:</p>
|
|
<ul>
|
|
<li>acceptable image formats and versions: e.g. GIF89a, JPEG-2000</li>
|
|
<li>desired image size: e.g. 400 x 300 pixels</li>
|
|
<li>desired image colors: e.g. 24-bit rgb color per pixel</li>
|
|
<li>pixel geometry: e.g. 4 : 3</li>
|
|
<li>gamma: e.g. 0.45</li>
|
|
<li>acceptable alternative formats: e.g. text/plain, text/html</li>
|
|
</ul>
|
|
|
|
<h4 id="dis">Discussion</h4>
|
|
|
|
<p>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. </p>
|
|
|
|
<h3 id="r52">5.2 Request for an HTML resource</h3>
|
|
|
|
<h4 id="sum1">Summary</h4>
|
|
|
|
<p>A user agent wishes to fetch an HTML resource and render it within the
|
|
constraints of the delivery context.</p>
|
|
|
|
<h4 id="con">Context</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="var">Variants</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="att1">Attributes</h4>
|
|
|
|
<p>The following Core Presentation Characteristics would therefore be
|
|
relevant as part of making the request for the resource:</p>
|
|
<ul>
|
|
<li>acceptable content formats and versions: e.g. HTML 4.0, XHTML 1.0</li>
|
|
<li>acceptable content modules: e.g. XHTML Frames</li>
|
|
<li>acceptable styling formats and versions: e.g. CSS 1.0, CSS 2.0 Mobile
|
|
Profile</li>
|
|
<li>acceptable font families: e.g. sans-serif, serif</li>
|
|
<li>acceptable fonts: e.g. Arial, Times New Roman</li>
|
|
<li>acceptable languages: e.g. en, fr, de</li>
|
|
<li>desired presentation size: e.g. 300 x 150 pixels</li>
|
|
<li>desired presentation colors: e.g. 8-bit color per pixel from a palette
|
|
of 64K colors</li>
|
|
<li>desired text viewing distance: e.g. 40cm</li>
|
|
<li>preferred minimum text size: e.g.10 point</li>
|
|
</ul>
|
|
|
|
<h4 id="disc">Discussion</h4>
|
|
|
|
<p><span lang="en-us">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 </span> desired<span
|
|
lang="en-us"> 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.</span></p>
|
|
|
|
<p><span lang="en-us">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.</span></p>
|
|
|
|
<h3 id="r53">5.3 Request for an interactive resource</h3>
|
|
|
|
<h4 id="s3">Summary</h4>
|
|
|
|
<p>A user agent wishes to fetch an interactive resource and include it as
|
|
part of a presentation.</p>
|
|
|
|
<h4 id="c3">Context</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="v3">Variants</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4 id="a3">Attributes</h4>
|
|
|
|
<p>The following additional Core Presentation Characteristics would be
|
|
relevant to making the request for a resource:</p>
|
|
<ul>
|
|
<li>acceptable interaction formats: e.g. HTML 4.0 form elements, XForms
|
|
1.0</li>
|
|
<li>acceptable input modalities: e.g. text, pointer, tabbing, voice</li>
|
|
<li>acceptable text input languages: e.g. en, fr</li>
|
|
<li>acceptable speech recognition grammar size: e.g. 100 words</li>
|
|
</ul>
|
|
|
|
<h4 id="d3">Discussion</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3 id="r54">5.4 Profile of a document</h3>
|
|
|
|
<h4 id="s4">Summary</h4>
|
|
|
|
<p>A document has attributes that express its delivery expectations.</p>
|
|
|
|
<h4 id="c4">Context</h4>
|
|
|
|
<p>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 [<a
|
|
href="#Conneg">Conneg</a>] 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 [<a href="#CSS_Meda_Queries">CSSMediaQueries</a>] already provides a
|
|
mechanism for allowing an author to specify alternative styles appropriate to
|
|
different delivery contexts.</p>
|
|
|
|
<h4 id="v31">Variants</h4>
|
|
|
|
<p>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. </p>
|
|
|
|
<h4 id="a4">Attributes</h4>
|
|
|
|
<p>The following Core Presentation Characteristics could therefore be
|
|
relevant as part of the document profile:</p>
|
|
<ul>
|
|
<li>markup format and version: e.g. HTML 4.0, XHTML Transitional</li>
|
|
<li>modules used in document: e.g. XHTML Frames</li>
|
|
<li>text languages used in document: e.g. en, de</li>
|
|
<li>font families used in document style: e.g. sans-serif</li>
|
|
<li>fonts used in document style: e.g. Arial</li>
|
|
<li>minimum target presentation size: e.g. 640 x 480 pixels</li>
|
|
</ul>
|
|
|
|
<h4 id="d4">Discussion</h4>
|
|
|
|
<p>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 [<a href="#DocProfile">DocProfile</a>]. Further work in
|
|
this area is within the charter of the Device Independence Working Group [<a
|
|
href="#DI-charter">DI-charter</a>]. However, this use case should be
|
|
considered speculative at this stage.</p>
|
|
<hr>
|
|
|
|
<h2><a name="references">References</a></h2>
|
|
<dl>
|
|
<dt>[<a name="CCPP_WG">CC/PP</a>]</dt>
|
|
<dd><a
|
|
href="http://www.ietf.org/html.charters/OLD/conneg-charter.html">http://www.w3.org/Mobile/CCPP/</a></dd>
|
|
</dl>
|
|
<dl>
|
|
<dt>[<a name="CCPP_spec">CC/PP: Structure and Vocabularies</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/CCPP-struct-vocab/">http://www.w3.org/TR/CCPP-struct-vocab/</a></dd>
|
|
</dl>
|
|
<dl>
|
|
<dt>[<a name="CCPP_Implementors_Guide">CC/PP Implementors Guide</a>]</dt>
|
|
<dd>Harmonization with Existing Vocabularies and Content Transformation,
|
|
W3C Note,</dd>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/NOTE-CCPP-COORDINATION-20011220/">http://www.w3.org/TR/2001/NOTE-CCPP-COORDINATION-20011220/</a></dd>
|
|
<dt>[<a name="Conneg">Conneg</a>]</dt>
|
|
<dd><a
|
|
href="http://www.ietf.org/html.charters/OLD/conneg-charter.html">IETF
|
|
Content Negotiation Working Group</a>, concluded October 2000<br>
|
|
<a
|
|
href="http://www.ietf.org/html.charters/OLD/conneg-charter.html">http://www.ietf.org/html.charters/OLD/conneg-charter.html/</a></dd>
|
|
<dt>[<a name="CSS_Meda_Queries">CSS Media Queries</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/css3-mediaqueries/">http://www.w3.org/TR/css3-mediaqueries/</a></dd>
|
|
<dt>[<a name="DC">DC</a>]</dt>
|
|
<dd>Dublin Core Metadata Initiative<br>
|
|
<a href="http://dublincore.org/">http://dublincore.org/</a></dd>
|
|
<dt>[<a name="DCO">DCO</a>]</dt>
|
|
<dd>Delivery Context Overview for Device Independence<br>
|
|
<a
|
|
href="http://www.w3.org/2001/di/public/dco/">http://www.w3.org/2001/di/public/dco/</a></dd>
|
|
<dt>[<a name="DI-charter">DI-charter</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">W3C
|
|
Device Independence Working Group Charter</a><br>
|
|
<a
|
|
href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html</a></dd>
|
|
<dt>[<a name="DIP">DIP</a>]</dt>
|
|
<dd><a href="http://www.w3.org/TR/2001/WD-di-princ-20010918/">Device
|
|
Independence Principles</a>, W3C Working Draft 18 September 2001<br>
|
|
<i>For latest version see:</i> <a
|
|
href="http://www.w3.org/TR/di-princ/">http://www.w3.org/TR/di-princ/</a></dd>
|
|
<dt>[<a name="DocProfile">ocProfile</a>]</dt>
|
|
<dd><a href="http://www.w3.org/TR/xhtml-prof-req/">XHTML Document Profile
|
|
Requirements</a><br>
|
|
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">
|
|
http://www.w3.org/TR/xhtml-prof-req</a></dd>
|
|
<dt>[<a name="FSM">FSM</a>]</dt>
|
|
<dd><a href="http://www.ninebynine.org/Software/Conneg-FSM/">Feature Set
|
|
Matching</a>, sample software by Graham Klyne<br>
|
|
<a
|
|
href="http://www.ninebynine.org/Software/Conneg-FSM/">http://www.ninebynine.org/Software/Conneg-FSM/</a></dd>
|
|
<dt>[<a name="HTTP">HTTP</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">http://www.w3.org/Protocols/rfc2616/rfc2616.html</a></dd>
|
|
<dt>[<a name="mfs">MFS</a>]</dt>
|
|
<dd style="margin-top: 0; margin-bottom: 0"><a
|
|
href="http://www.ietf.org/rfc/rfc2533.txt">A Syntax for Describing
|
|
Media Feature Sets</a>, IETF RFC-2533 March 1999<br>
|
|
<a href="http://www.ietf.org/rfc/rfc2533.txt">
|
|
http://www.ietf.org/rfc/rfc2533.txt</a></dd>
|
|
<dd style="margin-top: 0; margin-bottom: 0"><a
|
|
href="http://www.ietf.org/rfc/rfc2534.txt">Media Features for Display,
|
|
Print and Fax</a>, IETF RFC-2534 March 1999<br>
|
|
<a href="http://www.ietf.org/rfc/rfc2534.txt">
|
|
http://www.ietf.org/rfc/rfc2534.txt</a></dd>
|
|
<dt>[<a name="MQ">MQ</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/">Media
|
|
Queries</a>, W3C Candidate Recommendation 8 July 2002<br>
|
|
<i>For latest version see:</i> <a
|
|
href="http://www.w3.org/TR/css3-mediaqueries/">http://www.w3.org/TR/css3-mediaqueries/</a></dd>
|
|
<dt>[<a name="P3P">P3P</a>]</dt>
|
|
<dd><a href="http://www.w3.org/P3P/">Platform for Privacy Preferences
|
|
Project</a>, W3C Initiative<br>
|
|
<a href="http://www.w3.org/P3P/">http://www.w3.org/P3P/</a></dd>
|
|
<dt>[<a name="smil">SMIL</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/AudioVideo/">http://www.w3.org/AudioVideo/</a></dd>
|
|
<dt>[<a name="SMIL1">SMIL1</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/REC-smil/">http://www.w3.org/TR/REC-smil/</a></dd>
|
|
<dt>[<a name="SMIL2">SMIL2</a>]</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/smil20/">http://www.w3.org/TR/smil20/</a></dd>
|
|
<dt>[<a name="uaprof">UAProf</a>]</dt>
|
|
<dd><a
|
|
href="http://www1.wapforum.org/tech/documents/WAP-248-UAProf-20011020-a.pdf">User
|
|
Agent Profiling Specification</a>, WAP Forum 20 October 2001<br>
|
|
<i>For latest version see:</i> <a
|
|
href="http://www.wapforum.org/what/technical.htm">http://www.wapforum.org/what/technical.htm</a></dd>
|
|
</dl>
|
|
|
|
<h3 id="or">Other References:</h3>
|
|
<ul>
|
|
<li>RFC2506 Media Feature Tag Registration Procedure (BCP)</li>
|
|
<li>RFC2703 Protocol-independent content negotiation framework
|
|
(Informational)</li>
|
|
<li>RFC2738 Corrections to 'A syntax for describing media feature sets'
|
|
(Proposed Standard)</li>
|
|
<li>RFC2912 Indicating media features for MIME content (Proposed Standard)
|
|
<p>RFC2913 MIME content types in media feature expressions (Proposed
|
|
Standard)</p>
|
|
</li>
|
|
<li>RFC2938 Identifying composite media features (Proposed Standard)</li>
|
|
<li>RFC 2530 Indicating Supported Media Features Using Extensions to DSN
|
|
and MDN</li>
|
|
<li>RFC 2879 Content Feature Schema for Internet Fax</li>
|
|
</ul>
|
|
<hr>
|
|
|
|
<h2><a name="glossary">Glossary</a></h2>
|
|
|
|
<p>The following definitions are taken from the HTTP/1.1 specification (RFC
|
|
2616) <span class="ref">[<a href="#HTTP">HTTP</a>]</span> and the Device
|
|
Independence Principles <span class="ref">[<a href="#DIP">DIP</a>]</span>.</p>
|
|
<dl class="definition" id="def-access-mechanism">
|
|
<dt><strong>attribute</strong></dt>
|
|
<dd>A data element described with a specific associated name-value pair.
|
|
<span class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
<dt> </dt>
|
|
<dt><strong>access mechanism</strong></dt>
|
|
<dd>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.). <span
|
|
class="ref">[<a href="#DIP">DIP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>device</strong></dt>
|
|
<dd>An apparatus through which a user can perceive and interact with the
|
|
Web. <span class="ref">[<a href="#DIP">DIP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition" id="def-delivery-context">
|
|
<dt><strong>delivery context</strong></dt>
|
|
<dd>A set of attributes that characterizes the capabilities of the access
|
|
mechanism and the preferences of the user. <span class="ref">[<a
|
|
href="#DIP">DIP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>origin server</strong></dt>
|
|
<dd>The server on which a given resource resides or is to be created.
|
|
<span class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>proxy</strong></dt>
|
|
<dd>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. <span class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>representation</strong></dt>
|
|
<dd>An entity included with a response that is subject to content
|
|
negotiation. There may exist multiple representations associated with a
|
|
particular response status. <span class="ref">[<a
|
|
href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>request</strong></dt>
|
|
<dd>An HTTP request message <span class="ref">[<a
|
|
href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>response</strong></dt>
|
|
<dd>An HTTP response message <span class="ref">[<a
|
|
href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>resource</strong></dt>
|
|
<dd>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.
|
|
<span class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>server</strong></dt>
|
|
<dd>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. <span
|
|
class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>variant</strong></dt>
|
|
<dd>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. <span
|
|
class="ref">[<a href="#HTTP">HTTP</a>]</span></dd>
|
|
</dl>
|
|
<dl class="definition">
|
|
<dt><strong>user agent</strong></dt>
|
|
<dd>The client which initiates a request. These are often browsers,
|
|
editors, spiders (web-traversing robots), or other end user tools.
|
|
<span class="ref">[<a href="#HTTP">HTTP</a>]</span><br>
|
|
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. <span class="ref">[<a href="#DIP">DIP</a>]</span></dd>
|
|
</dl>
|
|
<hr>
|
|
|
|
<h2><a name="acknowledgements">Acknowledgements</a></h2>
|
|
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>Michael Wasmund, IBM</li>
|
|
<li>Shlomit Ritz Finkelstein</li>
|
|
<li>Rotan Hanrahan, MobileAware</li>
|
|
<li>Mark Butler, HP</li>
|
|
<li>Roland Merrick, IBM</li>
|
|
<li>Guido Grassel, Nokia</li>
|
|
<li>Luu Tran, Sun Microsystems</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The full membership of the group at the time of publication is shown
|
|
below. </p>
|
|
<ul>
|
|
<li>Roger Gimson, HP (<i>Chair, Co-Author</i>)</li>
|
|
<li>Markus Lauff, SAP (<i>Co-Editor, Co-Author</i>)</li>
|
|
<li>Amy Yu, SAP (<i>Co-Editor</i>)</li>
|
|
<li>Lalitha Suryanarayana, SBC Technology Resources (<i>Co-Author</i>)</li>
|
|
<li>Mark Butler, HP</li>
|
|
<li>Guido Grassel, Nokia</li>
|
|
<li>Franklin Reynolds, Nokia</li>
|
|
<li>Rhys Lewis, Volantis Systems</li>
|
|
<li>Mark Watson, Volantis Systems</li>
|
|
<li>Rotan Hanrahan, MobileAware</li>
|
|
<li>Eamonn Howe, MobileAware</li>
|
|
<li>Luu Tran, Sun Microsystems</li>
|
|
<li>Greg Ziebold, Sun Microsystems</li>
|
|
<li>Candy Wong, NTT DoCoMo</li>
|
|
<li>Masashi Morioka, NTT DoCoMo</li>
|
|
<li>Yoshihisa Gonno, Sony</li>
|
|
<li>Steve Farowich, Boeing</li>
|
|
<li>Roland Merrick, IBM</li>
|
|
<li>Michael Wasmund, IBM</li>
|
|
<li>Andreas Schade, IBM</li>
|
|
<li>Dennis Bushmitch, Panasonic</li>
|
|
<li>Ryuji Tamagawa, Sky Think System</li>
|
|
<li>Abbie Barbir, Nortel Networks</li>
|
|
<li>Tayeb Lemlouma, INRIA</li>
|
|
<li>Shlomit Ritz Finkelstein</li>
|
|
<li>Jason White, University of Melbourne</li>
|
|
<li>Stan Wiechers, Merkwelt</li>
|
|
<li>Kazuhiro Kitagawa, (<i>W3C Activity Lead</i>)</li>
|
|
<li>Stephane Boyera, (<i>W3C Staff Contact</i>)</li>
|
|
</ul>
|
|
</body>
|
|
</html>
|