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.
767 lines
32 KiB
767 lines
32 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/strict.dtd">
|
|
<html xmlns="http://www.w3.org/TR/xhtml1/strict">
|
|
<head>
|
|
<title>XHTML Document Profile Requirements</title>
|
|
<link rel="stylesheet" href=
|
|
"http://www.w3.org/StyleSheets/TR/W3C-WD.css" type="text/css" />
|
|
<style type="text/css">
|
|
.comment { margin-left: 0.5 cm; margin-right: 0.5 cm; font-style: italic; color: #336600}
|
|
.note { margin-left: 0.5 cm; margin-right: 0.5 cm }
|
|
div.navbar { text-align: center }
|
|
div.contents {
|
|
background-color: rgb(204,204,255);
|
|
padding: 0.5em;
|
|
border: none;
|
|
margin-right: 5%;
|
|
}
|
|
.tocline { list-style: none; }
|
|
.center {text-align: center }
|
|
</style>
|
|
|
|
<style type="text/css">
|
|
dt.c2 {font-weight: bold}
|
|
a.c1 {font-weight: bold}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<div class="navbar"><a href="#toc">table of contents</a>
|
|
|
|
<hr />
|
|
</div>
|
|
|
|
<div class="head"><a href="http://www.w3.org/"><img class="head"
|
|
src="http://www.w3.org/Icons/WWW/w3c_home.gif" alt="W3C" /></a>
|
|
|
|
<h1 class="head"><a name="title" id="title">
|
|
</a>XHTML<sup>™</sup> Document Profile Requirements</h1>
|
|
|
|
<h2>Document profiles - a basis for interoperability
|
|
guarantees</h2>
|
|
|
|
<h3>W3C Working Draft 6th September 1999</h3>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/1999/WD-xhtml-prof-req-19990906">
|
|
http://www.w3.org/TR/1999/WD-xhtml-prof-req-19990906</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xhtml-prof-req">
|
|
http://www.w3.org/TR/xhtml-prof-req</a></dd>
|
|
|
|
|
|
<dt>Previous versions:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/MarkUp/Group/1999/xhtml-prof-reqs-19990730/">
|
|
http://www.w3.org/MarkUp/Group/1999/xhtml-prof-reqs-19990730/</a>
|
|
(W3C Members only)</dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>
|
|
<a href="http://www.w3.org/People/Raggett">Dave Raggett</a> <<a
|
|
href= "mailto:dsr@w3.org">dsr@w3.org</a>></dd>
|
|
|
|
<dd>
|
|
Peter Stark <<a href=
|
|
"mailto:stark@corp.phone.com">stark@corp.phone.com</a>></dd>
|
|
|
|
<dd>
|
|
Ted Wugofski <<a href=
|
|
"mailto:ted.wugofski@otmp.com">ted.wugofski@otmp.com</a>></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
|
|
Copyright</a> © 1999 <a href="http://www.w3.org/">W3C</a>
|
|
(<a href="http://www.lcs.mit.edu/">MIT</a>, <a href=
|
|
"http://www.inria.fr/">INRIA</a>, <a href=
|
|
"http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <abbr
|
|
title="World Wide Web Consortium">W3C</abbr> <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>
|
|
|
|
<h2 class="notoc">Abstract</h2>
|
|
|
|
<p>The increasing disparities between the capabilities of
|
|
different kinds of Web user agents present challenges to Web
|
|
content developers wishing to reach a wide audience. A promising
|
|
approach is to formally describe profiles for documents intended
|
|
for broad groups of user agents, for instance, separate document
|
|
profiles for user agents running on desktops, television,
|
|
handhelds, cellphones and voice user agents. Document profiles
|
|
provide a basis for interoperability guarantees. If an author
|
|
develops content for a given profile and a user agent supports
|
|
the profile then the author may be confident that the document
|
|
will be rendered as expected. The requirements for document
|
|
profiles are analyzed.</p>
|
|
|
|
<h2>Status of this document</h2>
|
|
|
|
<p>This 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 obsoleted 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 document has been produced as part of the <a
|
|
href="http://www.w3.org/MarkUp/">W3C HTML Activity</a>, but
|
|
should not be taken as evidence of consensus in the HTML Working
|
|
Group. The goals of the <a href=
|
|
"http://www.w3.org/MarkUp/Group/">HTML Working Group</a> <i>(<a
|
|
href="http://cgi.w3.org/MemberAccess/">members only</a>)</i> are
|
|
discussed in the <a href=
|
|
"http://www.w3.org/MarkUp/Group/HTMLcharter">HTML Working Group
|
|
charter</a> <i>(<a href="http://cgi.w3.org/MemberAccess/">members
|
|
only</a>)</i>.</p>
|
|
|
|
<p>Please send detailed comments on this document to <a href=
|
|
"mailto:www-html-editor@w3.org">www-html-editor@w3.org</a>. We
|
|
cannot guarantee a personal response, but we will try when it is
|
|
appropriate. Public discussion on HTML features takes place on the
|
|
mailing list <a href="mailto:www-html@w3.org">
|
|
www-html@w3.org</a>.</p>
|
|
|
|
<h1 class="notoc"><a name="toc" id="toc">Table of
|
|
Contents</a></h1>
|
|
|
|
<div class="contents">
|
|
<ul class="toc">
|
|
<li class="tocline">1. <a href="#intro">Introduction</a></li>
|
|
|
|
<li class="tocline">2. <a href="#framework">Framework for Content
|
|
Negotiation</a></li>
|
|
|
|
<li class="tocline">3. <a href="#reqs">Requirements for Document
|
|
Profiles</a></li>
|
|
|
|
<li class="tocline">4. <a href="#acks">Acknowledgements</a></li>
|
|
|
|
<li class="tocline">5. <a href="#refs">References</a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<!--OddPage-->
|
|
<h1><a name="intro">1. Introduction</a></h1>
|
|
|
|
<p>As vendors introduce new versions of user agents, content
|
|
developers have had to get to grips with a variety of differences
|
|
between user agents from the same vendor as well as the larger
|
|
differences between vendors. The World Wide Web Consortium plays
|
|
a stabilizing role through the development of standards, for
|
|
instance, HTML 3.2, HTML 4.0 and more recently XHTML 1.0.
|
|
Standards act as beacons for vendors, lighting the path towards
|
|
greater interoperability. Investment in existing code together
|
|
with the desire to innovate and differentiate act as pressures to
|
|
veer away from the light. The end result is that content
|
|
developers will be forced to continue to cope with
|
|
variations.</p>
|
|
|
|
<p>The range of user agent platforms is rapidly expanding to
|
|
include television sets, handheld organizers, cell phones, in-car
|
|
systems and regular phones. Each of these platforms presents
|
|
different capabilities. Viewing distances for television sets are
|
|
much greater than for desktop or notebook computers, reducing the
|
|
legibility of text. In addition saturated colors tend to bleed
|
|
and need to be avoided. Handheld devices have reduced resolution
|
|
and limited color capabilities. Cell phones are even more limited
|
|
with display resolutions of as little as 4 lines of 12
|
|
characters. Voice user agents substitute speech recognition for
|
|
keyboards, using synthetic or pre-recorded speech for output.</p>
|
|
|
|
<p>Users are likely to expect to be able to access Web services
|
|
from wherever they are and at any time - from home, on the move
|
|
or in the office. This will encourage content developers to reach
|
|
out to as wide an audience as possible, on as many kinds of user
|
|
agents as practical. One approach is to develop content
|
|
separately for each of the dominant platforms. Another is to
|
|
develop content in a way that lends itself to automatic
|
|
transformation to specific platforms. This approach emphasizes
|
|
the separation of content, structure and style. The
|
|
transformation can be done at authoring-time, by the originating
|
|
server, proxy server or in the user agent itself as
|
|
appropriate.</p>
|
|
|
|
<p>Document profiles offer a means to characterize the features
|
|
appropriate to given categories of user agents. For instance, one
|
|
profile might include support for style sheets, vector graphics
|
|
and scripting, while another might be restricted to the tags in
|
|
HTML 3.2. Document profiles can be used by servers to select
|
|
between document variants developed for different user agent
|
|
categories. They can be used to determine what transformations to
|
|
apply when such variants are not available. Content developers
|
|
can use document profiles to ensure that their web sites will be
|
|
rendered as intended.</p>
|
|
|
|
<!--OddPage-->
|
|
<h1><a name="framework">2. Framework for Content
|
|
Negotiation</a></h1>
|
|
|
|
<p>Web content developers can manage differences in user agent
|
|
capabilities by developing several variants of their content,
|
|
where each variant is tuned to the capabilities of a particular
|
|
class of user agents. If the server is able to obtain information
|
|
about the capabilities of a given user agent, then the server can
|
|
select the variant of the Web content most appropriate to that
|
|
user agent. If a suitable variant isn't available it may be
|
|
practical to apply a transformation to generate one.</p>
|
|
|
|
<p class="center"><img src="clientserver.gif" alt=
|
|
"diagram showing idea of how client capabilities are used by the server to select or transform content based upon document profiles"
|
|
width="384" height="181" /></p>
|
|
|
|
<p>In the figure above, the client is either a user agent or a
|
|
proxy server. The client's capabilities describe hardware and
|
|
software constraints, such as display size, multimedia support,
|
|
support for scripting and style sheets etc. The client's
|
|
preferences reflect user settings. The client transmits these to
|
|
the server. The <a href="#ref-cc-pp">W3C Note on CC/PP</a>
|
|
describes ways in which this can be realized. Additional
|
|
information is available from the IETF content negotiation
|
|
working group [<a href="#ref-conneg">CONNEG</a>].</p>
|
|
|
|
<p>The server has access to the content. The request from the
|
|
client includes a name that the server can use to identify one or
|
|
more documents. Each document is associated with a document
|
|
profile. The server compares the client capabilities to the
|
|
document profiles to find a good match or to identify which
|
|
document to use as a basis for transformation to meet the
|
|
client's request.</p>
|
|
|
|
<p class="center"><img src="doc-xform.gif" alt=
|
|
"diagram showing transformations" width="384" height="245" /></p>
|
|
|
|
<p>This framework is consistent with a broadcast scenario in
|
|
which there is a uni-directional link between the transmitter and
|
|
receiver.</p>
|
|
|
|
<p><img src="one-way.gif" width="428" height="88" alt=
|
|
"Diagram of flow in one-way devices" /></p>
|
|
|
|
<p>In a one-way scenario, a proxy server at the transmitter may
|
|
model the capabilities of the receivers and negotiate on the
|
|
receiver's behalf. In this scenario, the transmitter uses the
|
|
appropriate descriptions of the receiver capabilities in its
|
|
requests to the Web sites. As in the previous case, the
|
|
transmitter may transform the content to meet the capabilities of
|
|
the receiver or this may occur at the content server.</p>
|
|
|
|
<p>This capability is particularly useful in television and
|
|
mobile environments in which a return channel from the client is
|
|
either not available or desirable.</p>
|
|
|
|
<p>Further work is needed in four areas:</p>
|
|
|
|
<ul>
|
|
<li>Client capabilities and personal preferences</li>
|
|
|
|
<li>Content negotiation -- the details of how capabilities and
|
|
preferences are conveyed in the request</li>
|
|
|
|
<li>Document profiles -- describing groups of documents</li>
|
|
|
|
<li>Document instance profiles -- a document might declare that
|
|
it is a member of one profile, but it only uses a subset of the
|
|
profile, making it a valid variant for other profiles</li>
|
|
|
|
<li>Transformation of documents from one profile to another</li>
|
|
</ul>
|
|
|
|
<p class="note"><strong>Note</strong>: Preferences for modules
|
|
and attribute values etc. need to be treated as part of
|
|
formalization of client capabilities and personal preferences,
|
|
rather the document profiles which provide a declarative
|
|
description of a group of documents.</p>
|
|
|
|
<!--OddPage-->
|
|
<h1><a name="reqs">3. Requirements for Document Profiles</a></h1>
|
|
|
|
<p>This section identifies a <em>preliminary</em> list of
|
|
requirements for further work on document profiles as distinct
|
|
from client capabilities and personal preferences. Please note
|
|
that this is work in progress and should not be taken as evidence
|
|
of consensus in the HTML working group. No significance should be
|
|
attached to the order in which the requirements are listed.</p>
|
|
|
|
<p>The requirements are partitioned into two categories: (1)
|
|
functional requirements, and (2) design requirements. Functional
|
|
requirements represent the needs of the content authoring
|
|
community that will use the profiling solution. These needs are
|
|
fundamentally independent of how that solution is implemented.
|
|
Design requirements represent the needs of the tools community
|
|
that will implement the profiling solution (or parts thereof).
|
|
These needs are may drive requirements that go beyond the
|
|
solution at hand, including requirements related to how the
|
|
profiling solution integrates with other problems in this problem
|
|
space.</p>
|
|
|
|
<p class="note"><strong>Note:</strong> This document follows the
|
|
decision by the HTML working group to deliberately omit
|
|
consideration of how these requirements can be met. Proposed
|
|
solutions will be discussed in a separate draft.</p>
|
|
|
|
<h2>3.1. Functional Requirements</h2>
|
|
|
|
<p>Functional requirements correspond to the capabilities of
|
|
document profile system, and not how the solution is realized.
|
|
These requirements typically related to what features can be
|
|
found in the document profiles.</p>
|
|
|
|
<h3>3.1.1. Content developers shall have a simple means of
|
|
associating a document profile with a document</h3>
|
|
|
|
<p>There shall be a means for content developers to associate a
|
|
document with a document profile without having to specify the
|
|
features of that document profile.</p>
|
|
|
|
<p>A possible solution to this requirement is to allow content
|
|
developers to associate a name or location of the document
|
|
profile.</p>
|
|
|
|
<h3>3.1.2. Content developers shall have a simple means of
|
|
describing a document profile in terms of features found in that
|
|
profile</h3>
|
|
|
|
<p>Content developers may wish to provide more detail than a
|
|
simple document profile name. This is important if the name of
|
|
their document profile is not readily recognized (if it is new,
|
|
for example) or if their document profile is a variant of a
|
|
recognized document profile.</p>
|
|
|
|
<p>Document profile names must be unique.</p>
|
|
|
|
<p class="comment"><strong>Issue (what's a feature)</strong>: We
|
|
should provide a definition of a feature</p>
|
|
|
|
<p>The most obvious idea is to describe profiles as a list of
|
|
feature names, for instance, the names of modules, image formats,
|
|
scripting, and style sheet languages. Specific requirements for
|
|
some of these are spelled out below.</p>
|
|
|
|
<p>The semantics of features may be defined by binding them to
|
|
existing standards, or via additional information supplied as
|
|
part of an extended profile definition, or accessible via
|
|
registries.</p>
|
|
|
|
<p>In practice, in a flat name space, the number of names can get
|
|
out of hand. As a result, it is desirable to introduce a
|
|
hierarchical structure into feature names where each level in the
|
|
hierarchy scopes the name space for the next level of detail. One
|
|
possible approach for this is described in [<a href=
|
|
"#ref-rfc2506">RFC2506</a>].</p>
|
|
|
|
<h3>3.1.3. Content developers shall have a means of describing
|
|
exceptions to the general case (non-critical)</h3>
|
|
|
|
<p>If profile features are described in purely atomic terms it
|
|
may be necessary to decompose the features into a lot of
|
|
subsidiary features. The ability to specify exceptions makes it
|
|
practical to use a higher level description together with the
|
|
exceptions, leading to much shorter descriptions. These
|
|
exceptions may be additive or subtractive.</p>
|
|
|
|
<p>The draft modularization proposed for XHTML includes over 20
|
|
modules. If you wanted to define a profile omitting just one of
|
|
these modules, an additive description would involve some 20
|
|
modules, compared with 2 for the case where you can state
|
|
exceptions.</p>
|
|
|
|
<p>Exceptions can take several forms, for instance, the ability
|
|
to add a new element, or to add a new attribute to a given
|
|
element, or a new attribute value to a given attribute. When
|
|
exceptions act to override some property, that is to take away an
|
|
element, attribute or value, things become more complex.</p>
|
|
|
|
<p>One possible approach is to provide an algebra for adding and
|
|
subtracting modules as a basis for describing document profiles,
|
|
where the document syntax is defined by reference to a DTD or XML
|
|
schema specifying the combined effect of the modules. This
|
|
approach delegates the effort of combining the DTDs or schemas
|
|
for each module to the author of the profile.</p>
|
|
|
|
<p class="note"><strong>Note</strong>: The ability to deal with
|
|
inheritance and set subtraction could provide the basis for
|
|
formalizing the effects of module algebra on document syntax.
|
|
Dave Raggett has studied ways to achieve this using <em>assertion
|
|
grammars</em>.</p>
|
|
|
|
<h3>3.1.4. Content developers shall have a means of describing
|
|
alternative features in a document profile</h3>
|
|
|
|
<p>A document profile might specify that <code>image/gif</code>
|
|
or <code>image/png</code> support is required, but it is not
|
|
necessary for the client to support both features. There are
|
|
several features within the HTML, SMIL, and CSS that provide a
|
|
means for content developers to specify alternative content:
|
|
nesting <code>object</code> elements,the <code>switch</code>
|
|
element, and <code>@media</code> types. This means that a
|
|
document profile may indicate that it requires one feature or
|
|
another feature, but it is not necessary for the client to
|
|
support both features.</p>
|
|
|
|
<h3>3.1.5. Content developers shall have a means of expressing
|
|
constraints on linked data formats</h3>
|
|
|
|
<p>The need to say which image formats authors can rely on, e.g.
|
|
<code>image/gif</code>, <code>image/jpeg</code>, and <code>
|
|
image/png</code>. In addition, the profile may need to express
|
|
constraints on whether animated gifs are allowed, what optional
|
|
features of <code>image/png</code> are supported, and the maximum
|
|
file size permitted (e.g. < 20K).</p>
|
|
|
|
<h3>3.1.6. Content developers shall have a means of expressing
|
|
detailed interoperability constraints for scripts and style
|
|
sheets</h3>
|
|
|
|
<p>The variations in support for scripting and style sheets
|
|
across user agents and platforms cause real problems for content
|
|
developers. Document profiles need to be able to specify
|
|
constraints on the scripting language and interfaces, and on
|
|
which style properties and values are supported on what elements.
|
|
The capability to express these constraints would make it easier
|
|
to develop transformation tools. For instance, allowing content
|
|
developers to create content using a clean set of style
|
|
properties with automatic transformation into markup tuned to the
|
|
vagaries of particular user agents.</p>
|
|
|
|
<p class="note"><strong>Note:</strong> Work on the DOM and on
|
|
modularizing CSS will go some of the way to alleviate the problem
|
|
this requirement addresses, but the weak conformance requirements
|
|
for CSS and scripting (as a whole) means that this problem won't
|
|
go away altogether.</p>
|
|
|
|
<h3>3.1.7. Content developers shall have a means of expressing
|
|
expectations of user agent capabilities</h3>
|
|
|
|
<p>A document profile may make certain assumptions about user
|
|
agent capabilities. By expressing these in the profile, servers
|
|
can use information about user agent capabilities as a basis for
|
|
selecting content with matching assumptions.</p>
|
|
|
|
<p>Examples include assumptions about display resolution, and
|
|
multimedia support; support for Java and 3D graphics; support for
|
|
particular character sets, e.g. for Kanji, and support for
|
|
cookies. These requirements need to be expressed in the same
|
|
vocabulary used to describe user agent capabilities, e.g. see
|
|
W3C's work on Client Capabilities and Personal Preferences [<a
|
|
href="#ref-cc-pp">CC/PP</a>].</p>
|
|
|
|
<h3>3.1.8. Content authors shall have a means of defining
|
|
profiles for documents with controlled extensibility as will be
|
|
permitted by the XML Schema language</h3>
|
|
|
|
<p>Sometimes it is impractical to provide a closed definition for
|
|
a group of documents. For instance, where the set of elements
|
|
representing business procedures is evolving over time, it may be
|
|
impractical to specify a frozen set of elements. The document
|
|
schema needs to be able to indicate where the content model or
|
|
attributes are open-ended and in what way. This requirement is
|
|
needed to cater for situations where you have partial knowledge,
|
|
but can also be exploited as a mechanism for dealing with forward
|
|
compatibility.</p>
|
|
|
|
<p class="comment"><strong>Issue (Examples from Dave
|
|
H.):</strong> Dave Hollander (co-chair of the XML Schema working
|
|
group) has promised some real-world examples for this.</p>
|
|
|
|
<h3>3.1.9. Content authors shall have a means of expressing
|
|
distribution rights based on user agent support for features of
|
|
the profile</h3>
|
|
|
|
<p>A related point is the requirement to give authors control
|
|
over how user agents treat unknown elements and attributes. For
|
|
instance, should the user agent attempt to render the content of
|
|
an unknown element or not. This situation arises when a server
|
|
gets a request for a document from a user agent for which the
|
|
server can't provide a version of the document with a matching
|
|
profile.</p>
|
|
|
|
<p>The server can choose either to fail the request or to deliver
|
|
a document which the user agent may not be able to fully render.
|
|
The content author wishes to have some assurance in such cases
|
|
over how the user agent treats elements it doesn't understand.
|
|
Consistent treatment of this is essential to controlled evolution
|
|
of the Web. Without such a mechanism, content developers may feel
|
|
unable to deploy new features.</p>
|
|
|
|
<p class="note"><strong>Note:</strong> The HTML working group
|
|
spent considerable time on this issue at the Amsterdam meeting in
|
|
May. W3C's SMIL specification includes support for this
|
|
feature.</p>
|
|
|
|
<h3>3.1.10. Content developers shall have a means of expressing
|
|
how long the document profile may be cached</h3>
|
|
|
|
<p>If software agents have to download profiles each time they
|
|
get a request to for a document, the response time will suffer.
|
|
As as result, agents will want to cache profiles. The requirement
|
|
is for an ability to specify an expiry date/time after which the
|
|
cached copy must be refreshed. In HTML documents, authors can
|
|
specify this via the meta element. If profiles are specified in
|
|
other than HTML, then another mechanism is needed to meet this
|
|
requirement.</p>
|
|
|
|
<h3>3.1.11. Content developers shall have a means of expressing
|
|
attribution and copyright information</h3>
|
|
|
|
<p>Additional information about who has defined the profile and
|
|
when.</p>
|
|
|
|
<h3>3.1.12. Content developers shall have a means of expressing
|
|
required protocols</h3>
|
|
|
|
<p>Content developers need to be able to specify if using a
|
|
document (or executing a script or resource associated with the
|
|
document) requires the use of a particular protocol (such as an
|
|
SSL connection).</p>
|
|
|
|
<h2>3.2. Design Requirements</h2>
|
|
|
|
<p>Design requirements correspond to how the solution is
|
|
implemented and how it will be used, independent of the features
|
|
found within the document profile solution.</p>
|
|
|
|
<h3>3.2.1. The design shall support lightweight testing of two
|
|
profiles for equality</h3>
|
|
|
|
<p>This is needed to support efficient run-time selection of
|
|
documents belonging to a given profile.</p>
|
|
|
|
<h3>3.2.2. The design shall support lightweight testing of a
|
|
client's capabilities and preferences against a document's
|
|
profile.</h3>
|
|
|
|
<p>To provide support for matching a client's capabilities and
|
|
preferences with the profiles of variant documents.</p>
|
|
|
|
<h3>3.2.3. The design shall support machine readable
|
|
profiles</h3>
|
|
|
|
<p>This is needed so that servers can autonomously perform
|
|
content selection in response to a request. In addition, this is
|
|
needed to support transformation agents.</p>
|
|
|
|
<h3>3.2.4. The design shall specify document syntax by reference
|
|
to external definitions</h3>
|
|
|
|
<p>This requirement is needed to decouple work on profiles from
|
|
that on document syntax. This will allow W3C to develop a
|
|
specification for XHTML document profiles independently of work
|
|
on XML Schemas. It will enable profiles to use XML 1.0 Document
|
|
Type Definitions or XML Schemas. The expectation is that over
|
|
time XML Schemas will supplant DTDs.</p>
|
|
|
|
<h3>3.2.5. The design shall support formal verification that a
|
|
given document conforms to a profile</h3>
|
|
|
|
<p>This is needed when content developers are unsure of
|
|
themselves or their tools. It necessitates a formal definition of
|
|
the profile that can be used to automate the testing of whether
|
|
or not the document conforms to the profile. This can be reduced
|
|
to verifying that the document conforms to syntax and semantic
|
|
constraints defined by the profile.</p>
|
|
|
|
<h3>3.2.6. The design shall support multiple XML name spaces</h3>
|
|
|
|
<p>Document profiles need to be able to describe documents
|
|
including elements from more than one name space, and the means
|
|
to verify that such documents conform the the profile. It is
|
|
strongly desirable that any such solution does not prescribe the
|
|
prefixes used for each name space.</p>
|
|
|
|
<h3>3.2.7. The design shall support a human readable description
|
|
of the profile</h3>
|
|
|
|
<p>Which can be shown to content developers to aid their
|
|
understanding of the purpose of the profile and appropriate ways
|
|
to create content for it.</p>
|
|
|
|
<h3>3.2.8. The design shall support reference to specifications
|
|
and documentation defining a document type for the profiled
|
|
documents</h3>
|
|
|
|
<p>A common means to express the name and/or location of
|
|
available specifications or documentation about the document type
|
|
being profiled. This is similar to 'Human readable description of
|
|
the profile' but is called out as a separate requirement to
|
|
ensure that links to specs and documentation are treated in a
|
|
very consistent and predictable manner.</p>
|
|
|
|
<h3>3.2.9. The design shall use XML or RDF</h3>
|
|
|
|
<p>The idea here is to avoid creating radically new formats by
|
|
constraining profiles to be expressed in XML or RDF.</p>
|
|
|
|
<p>The work on client capabilities and personal preferences is
|
|
represented in RDF, making it attractive to consider use RDF for
|
|
document profiles [CC/PP].</p>
|
|
|
|
<p>The way profile information is structured in the profile
|
|
document should be such that the effort is minimized to map
|
|
between a profile document and a content negotiation session
|
|
using the same data. This applies to both the features in the
|
|
profile and the algebra combining/negotiating them [CONNEG].</p>
|
|
|
|
<h3>3.2.10. The design shall support a uniform way in which to
|
|
extend profiles</h3>
|
|
|
|
<p>It should be easy to extend profiles with new kinds of
|
|
constraints as the need for these emerges.</p>
|
|
|
|
<h3>3.2.11. The design shall support a means of specifying
|
|
document profile information inside the document.</h3>
|
|
|
|
<p>content developers should have a simple means of specifying a
|
|
document profile and keeping that profile information tightly
|
|
coupled to a specific document.</p>
|
|
|
|
<h3>3.2.12. The design shall support a means of specifying
|
|
document profiles external to the document</h3>
|
|
|
|
<p>content developers should be able to specify a document
|
|
profile external to a document so that it may be readily reused
|
|
by other documents. This is needed to simplify the management and
|
|
maintenance of profiles shared by large number of documents.
|
|
Furthermore, the size of profiles may make it impractical to
|
|
incorporate them directly in documents.</p>
|
|
|
|
<h3>3.2.13. The design shall support including document profile
|
|
information in a request to a server</h3>
|
|
|
|
<p>To enable servers to identify content appropriate to each
|
|
client, the request must be able to include information that can
|
|
be used to find matching document profiles. This requirement acts
|
|
as a constraint on the representations of client
|
|
capabilities/preferences and document profiles.</p>
|
|
|
|
<p>The Web is dependent on the TCP/IP network protocols. When
|
|
opening an HTTP connection (using TCP/IP) the size of the initial
|
|
request has a considerable effect on the number of round trip
|
|
times needed for the response to be received by the requestor.
|
|
For optimum performance the request should fit into a single
|
|
packet. This places a premium on reducing the size of the profile
|
|
description sent as part of an HTTP request.</p>
|
|
|
|
<p class="note"><strong>Note</strong>: This is an important
|
|
consideration when defining client-server protocols. If you want
|
|
to know more, Jim Gettys can explain this in great detail!</p>
|
|
|
|
<h3>3.2.14. The design shall support in-place or linked
|
|
assertions</h3>
|
|
|
|
<p>In much the same way as a file user agent allows folders to be
|
|
collapsed or expanded, the document profile should allow the
|
|
profile author to explicitly include a particular assertion, or
|
|
to include a link to it. In this way an otherwise identical
|
|
profile could be expressed explicitly, or as a list of titled
|
|
links, or some mix of both (the choice would depend upon
|
|
environmental or application considerations).</p>
|
|
|
|
<h3>3.2.15. Profiles that are embedded in the document shall be
|
|
accessible through the Document Object Model</h3>
|
|
|
|
<p>If the document profile information within the document, it
|
|
should be accessible through DOM interfaces.</p>
|
|
|
|
<h3>3.2.16. The design shall support referencing resources
|
|
indirectly</h3>
|
|
|
|
<p>The ability to express the name and/or location of a resource
|
|
resolution authority, such as a catalog file or name to resource
|
|
resolution server.</p>
|
|
|
|
<!--OddPage-->
|
|
<h1><a name="acks">4. Acknowledgements</a></h1>
|
|
|
|
<p>The editors wish to thank Murray Altheim and Håkon Wium
|
|
Lie for their feedback on earlier versions</p>
|
|
|
|
<!--OddPage-->
|
|
<h1><a name="refs">5. References</a></h1>
|
|
|
|
<dl>
|
|
<dt><a name="ref-cc-pp" id="ref-cc-pp" class="c1">
|
|
[CC/PP]</a></dt>
|
|
|
|
<dd>"Composite Capability/Preference Profiles (CC/PP): A user
|
|
side framework for content negotiation", F. Reynolds, J. Hjelm,
|
|
S. Dawkins, S. Singhal, 30 November 1998.<br />
|
|
<br />
|
|
This document describes a method for using the Resource
|
|
Description Format (RDF) to create a general, yet extensible
|
|
framework for describing user preferences and device
|
|
capabilities. Servers can exploit this to customize the service
|
|
or content provided.<br />
|
|
Available at: <a href="http://www.w3.org/TR/NOTE-CCPP">
|
|
http://www.w3.org/TR/NOTE-CCPP</a></dd>
|
|
|
|
<dt class="c2"><a name="ref-conneg" id="ref-conneg">
|
|
[CONNEG]</a></dt>
|
|
|
|
<dd>The <a href="http://www.imc.org/ietf-medfree/">IETF Content
|
|
Negotiation (conneg) Working Group</a> which has defined a number
|
|
of RFC's relevant to document profiles.</dd>
|
|
|
|
<dt><a name="ref-rfc2396" id="ref-rfc2396" class="c1">
|
|
[RFC2396]</a></dt>
|
|
|
|
<dd>"RFC2396: Uniform Resource Identifiers (URI): Generic
|
|
Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August
|
|
1998.<br />
|
|
This document updates RFC1738 and RFC1808.<br />
|
|
Available at: <a href="http://www.ietf.org/rfc/rfc2396.txt">
|
|
http://www.ietf.org/rfc/rfc2396.txt</a></dd>
|
|
|
|
<dt><a name="ref-rfc2506" id="ref-rfc2506" class="c1">
|
|
[RFC2506]</a></dt>
|
|
|
|
<dd>"RFC2506: Media Feature Tag Registration Procedure", K.
|
|
Holtman, A. Mutz, March 1999. This is in the IETF category of
|
|
"Best Current Practice"<br />
|
|
Available at: <a href="http://www.ietf.org/rfc/rfc2506.txt">
|
|
http://www.ietf.org/rfc/rfc2506.txt</a></dd>
|
|
|
|
<dt><a name="ref-xml" id="ref-xml" class="c1">[XML]</a></dt>
|
|
|
|
<dd>"Extensible Markup Language (XML) 1.0 Specification", T.
|
|
Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998.<br />
|
|
Available at: <a href="http://www.w3.org/TR/REC-xml">
|
|
http://www.w3.org/TR/REC-xml</a></dd>
|
|
|
|
<dt><a name="ref-xmlns" id="ref-xmlns" class="c1">
|
|
[XMLNAMES]</a></dt>
|
|
|
|
<dd>"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14
|
|
January 1999.<br />
|
|
XML namespaces provide a simple method for qualifying names used
|
|
in XML documents by associating them with namespaces identified
|
|
by URI.<br />
|
|
Available at: <a href="http://www.w3.org/TR/REC-xml-names">
|
|
http://www.w3.org/TR/REC-xml-names</a></dd>
|
|
</dl>
|
|
|
|
<p><a href="http://www.w3.org/WAI/WCAG1AAA-Conformance" title=
|
|
"Explanation of Level Triple-A Conformance"><img height="32"
|
|
width="88" src="http://www.w3.org/WAI/wcag1AAA.gif" alt=
|
|
"Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0" /></a></p>
|
|
|
|
<div class="navbar">
|
|
<hr />
|
|
<a href="#toc">table of contents</a></div>
|
|
</body>
|
|
</html>
|
|
|