index.html 43.8 KB

Raw Blame History Permalink

<!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:&nbsp;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:&nbsp;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. &nbsp;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.&nbsp; 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,&nbsp; 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&nbsp;&nbsp; </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.&nbsp; 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.&nbsp; 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&nbsp; 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.&nbsp; </p>
<ul>
  <li>Existing properties and attributes cover a wide range of device
    capabilities&nbsp; - 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.'&nbsp;</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.&nbsp;&nbsp; </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>] .&nbsp;
  '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.&nbsp;</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&nbsp; 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.&nbsp;&nbsp;</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.&nbsp; 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.&nbsp; 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.&nbsp;&nbsp; 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>].&nbsp; 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>&nbsp;</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.&nbsp;</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>