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.
1046 lines
97 KiB
1046 lines
97 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Compound Document by Reference Use Cases and Requirements Version 1.0</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
.scrap td { background-color: #d5dee3;}
|
|
table.scrap {margin-bottom: 1em }
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
|
|
<h1><a name="title" id="title"></a>Compound Document by Reference Use Cases and Requirements Version 1.0</h1>
|
|
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 19 December 2005</h2><dl><dt>This version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2005/NOTE-CDRReqs-20051219/">http://www.w3.org/TR/2005/NOTE-CDRReqs-20051219/</a>
|
|
|
|
</dd><dt>Latest version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/CDRReqs/">http://www.w3.org/TR/CDRReqs/</a>
|
|
</dd><dt>Previous version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2005/WD-CDRReqs-20050809/">http://www.w3.org/TR/2005/WD-CDRReqs-20050809/</a>
|
|
</dd><dt>Editors:</dt><dd>Daniel Appelquist, Vodafone Group Services Limited</dd><dd>Timur Mehrvarz, Vodafone Group Services Limited</dd><dd>Antoine Quint, Fuchsia Design (Invited Expert)</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.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> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
|
|
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
|
|
This document describes the use cases for a framework
|
|
that combines documents by reference and the set of requirements for
|
|
such a framework.
|
|
</p></div><div>
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2><p>
|
|
<em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this
|
|
document. A list of current W3C publications and the latest
|
|
revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em>
|
|
</p><p>This is the fourth publication of the Compound Document by Reference Use Cases and Requirements 1.0
|
|
document.
|
|
It
|
|
has been produced by the <a href="http://www.w3.org/2004/CDF/">Compound
|
|
Document Formats Working Group</a>, which is part of the <a href="http://www.w3.org/2006/rwc/Activity">Rich Web Clients Activity</a>.</p>
|
|
<p>The CDF Working Group have declared this document to be stable and
|
|
have published it as a W3C Note. Meanwhile, work continues on
|
|
requirements for <a href="http://www.w3.org/TR/CDFReqs/">Compound Documents Use Cases and Requirements Version 2.0</a> which includes
|
|
Compound Documents by Inclusion.</p>
|
|
|
|
<p>
|
|
Comments and discussion on this document should be sent to
|
|
<a href="mailto:public-cdf@w3.org">public-cdf@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-cdf/">public archives</a>).
|
|
</p>
|
|
<p>
|
|
Publication as a Working Group Note does not imply endorsement by the W3C
|
|
Membership. This is a draft document and may be updated, replaced or
|
|
obsoleted by other documents at any time. It is inappropriate to cite
|
|
this document as other than work in progress.
|
|
</p>
|
|
</div><div class="toc">
|
|
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
|
|
1.1 <a href="#approach">Approach</a><br />
|
|
1.1.1 <a href="#phases-of-work">Phases of Work</a><br />
|
|
1.1.2 <a href="#intro-by-reference">By Reference</a><br />
|
|
1.1.3 <a href="#intro-by-inclusion">By Inclusion</a><br />
|
|
1.2 <a href="#rich_multimedia_content_definition">Definition of Rich Multimedia Content</a><br />
|
|
1.3 <a href="#relationships-with-other">Relationships With Other Technologies</a><br />
|
|
1.3.1 <a href="#relationships-html-xhtml">HTML and XHTML</a><br />
|
|
1.3.2 <a href="#relationships-svg">SVG</a><br />
|
|
1.3.3 <a href="#relationships-smil">SMIL</a><br />
|
|
1.3.4 <a href="#relationships-xlink">XLink</a><br />
|
|
1.3.5 <a href="#relationships-xinclude">XInclude</a><br />
|
|
1.3.6 <a href="#relationships-soap-attachments">SOAP Attachments and Optimization Technologies</a><br />
|
|
1.3.7 <a href="#relationships-open-document">OASIS's Open Document Format</a><br />
|
|
1.3.8 <a href="#relationships-forms">XForms</a><br />
|
|
1.3.9 <a href="#relationship-xhtml-voice">XHTML + Voice</a><br />
|
|
1.4 <a href="#terms">Definition of Terms</a><br />
|
|
1.5 <a href="#who_what_will_implement_the_specification">Who/what will implement the specification</a><br />
|
|
1.5.1 <a href="#authoringtools">Authoring tools and content production systems</a><br />
|
|
1.5.2 <a href="#useragents">User agents, such as browsers and plug-ins</a><br />
|
|
1.5.3 <a href="#intermediaryprocessors">Intermediary Processors, content renderers</a><br />
|
|
2 <a href="#use-cases">Use Cases</a><br />
|
|
2.1 <a href="#web_publishing_broadcasting">Web Publishing and Broadcasting</a><br />
|
|
2.1.1 <a href="#usecase-news-service">Interactive News Service</a><br />
|
|
2.1.2 <a href="#usecase-web-portal">Web Portal</a><br />
|
|
2.1.3 <a href="#usecase-ticker">News or stock ticker</a><br />
|
|
2.1.4 <a href="#usecase-document-viewing">Document viewing</a><br />
|
|
2.1.5 <a href="#usecase-infotainment">Infotainment</a><br />
|
|
2.2 <a href="#usecase-web-applications">Web Applications</a><br />
|
|
2.2.1 <a href="#usecase-reservation-system">Reservation system</a><br />
|
|
2.2.2 <a href="#usecase-order-entry">Order entry system</a><br />
|
|
2.2.3 <a href="#usecase-online-shopping">On-line shopping</a><br />
|
|
2.2.4 <a href="#usecase-survey">Survey</a><br />
|
|
2.2.5 <a href="#usecase-web-games">Games</a><br />
|
|
2.2.6 <a href="#usecase-interactive-maps">Interactive maps</a><br />
|
|
2.3 <a href="#usecase-resident-applications">Resident Applications</a><br />
|
|
2.3.1 <a href="#usecase-pim">Personal Information Management</a><br />
|
|
2.3.2 <a href="#usecase-communication">Communication</a><br />
|
|
2.3.3 <a href="#usecase-idle-screen">Dynamic graphics as background or screen saver in mobile phone</a><br />
|
|
2.3.4 <a href="#usecase-document-viewing2">Document viewing</a><br />
|
|
2.3.5 <a href="#usecase-icon-bar">Interactive Icon bar</a><br />
|
|
2.3.6 <a href="#usecase-interactive-maps2">Interactive Maps</a><br />
|
|
2.4 <a href="#content_authoring_aggregation_deployment">Content Authoring, Aggregation and Deployment</a><br />
|
|
2.4.1 <a href="#personal-content-creation">Personal content creation</a><br />
|
|
2.4.2 <a href="#personal-content-management">Personal content management</a><br />
|
|
2.4.3 <a href="#web-logs">Web logs</a><br />
|
|
2.4.4 <a href="#content-aggregation">Content aggregation</a><br />
|
|
2.4.5 <a href="#professional-content-management">Professional content management</a><br />
|
|
2.5 <a href="#usecase-navigation">Navigation</a><br />
|
|
2.5.1 <a href="#svg-logo-ad">SVG used as logo or advertisement (no links in SVG).</a><br />
|
|
2.5.2 <a href="#svg-embedded-map">SVG embedded interactive map (links in SVG). </a><br />
|
|
2.5.3 <a href="#svg-images-animate-when-focused">Menu with SVG images that animate and expand when focused (no links in SVG)</a><br />
|
|
2.5.4 <a href="#embedded-svg-interactive">SVG image is embedded interactive part of the Web page (SVG has
|
|
links)</a><br />
|
|
2.6 <a href="#specific-use-cases">Specific Use Cases</a><br />
|
|
2.6.1 <a href="#usecase-sync-of-html-content">Synchronization of HTML content with audio visual content:</a><br />
|
|
2.6.2 <a href="#usecase-animated-svg-icons">Animated SVG icons in HTML menu</a><br />
|
|
2.6.3 <a href="#usecase-poll-results">Visualization of poling results in HTML page</a><br />
|
|
3 <a href="#requirements">Requirements</a><br />
|
|
3.1 <a href="#requirements_cdr">High-Level Requirements</a><br />
|
|
3.1.1 <a href="#reqmt-exploitexisting">CDR MUST exploit existing specifications, favoring W3C
|
|
specifications wherever possible and limit the definition of new
|
|
markup unless absolutely required for integration purposes</a><br />
|
|
3.1.2 <a href="#reqmt-richmultimedia">CDR MUST provide the ability for content developers to describe
|
|
or author rich media content define Rich Multimedia Content</a><br />
|
|
3.1.3 <a href="#reqmt-baseset">CDR MUST specify a base set of formats, corresponding
|
|
profiles and versions</a><br />
|
|
3.1.4 <a href="#reqmt-otherformats">Each CDR profile and version MUST specify, which formats can be referenced</a><br />
|
|
3.1.5 <a href="#reqmt-elementused">CDR MUST specify, for each format, the element used to
|
|
reference other formats, if any.</a><br />
|
|
3.1.6 <a href="#reqmt-genericintegrationtechniques">CDR MUST specify generic integration techniques</a><br />
|
|
3.1.7 <a href="#reqmt-temporalsync">
|
|
CDR MUST support temporal synchronization of dynamic content
|
|
coming from multiple references, possibly with multiple
|
|
references to the same source.</a><br />
|
|
3.1.8 <a href="#reqmt-eventscrossnamespace">CDR MUST support event mechanisms that cross namespace boundaries</a><br />
|
|
3.1.9 <a href="#reqmt-scriptability">CDR MUST support scriptability</a><br />
|
|
3.1.10 <a href="#reqmt-nestinglevel">CDR MUST say the allowed nesting level of referencing</a><br />
|
|
3.1.11 <a href="#reqmt-scriptingbetweencomponents">CDR MUST explain how scripting interacts between components and the parent document</a><br />
|
|
3.1.12 <a href="#reqmt-crossnamespace-focus">CDR profiles MUST specify how event propagation works
|
|
across namespace boundaries.</a><br />
|
|
3.1.13 <a href="#reqmt-crossnamespace-links">CDR profiles MUST specify how focus traversal works with
|
|
referenced documents.</a><br />
|
|
3.1.14 <a href="#reqmt-link-activation">CDR profiles MUST specify how link activation work with
|
|
referenced document.</a><br />
|
|
3.1.15 <a href="#reqmt-crossnamespace-animations">CDR profiles MUST specify triggering of animations across namespaces.</a><br />
|
|
3.1.16 <a href="#reqmt-crossnamespace-fragmentIDs">CDR MUST support fragment identifiers in cross-namespace
|
|
interaction</a><br />
|
|
3.1.17 <a href="#reqmt-addingeventhandlers">CDR profiles SHOULD provide a method for adding event
|
|
handlers using declarative markup for the formats it uses</a><br />
|
|
3.1.18 <a href="#reqmt-accessibility">CDR documents MUST cater for accessibility requirements</a><br />
|
|
3.1.19 <a href="#reqmt-dynamicupdating">CDR documents MUST support dynamic updating</a><br />
|
|
3.1.20 <a href="#reqmt-transport">CDR must define its integration into the Web
|
|
Architecture. It must include delivery over HTTP and should also
|
|
strive to be transport independent</a><br />
|
|
3.1.21 <a href="#reqmt-compression">CDR MUST NOT prevent compression of the data</a><br />
|
|
3.1.22 <a href="#reqmt-unified-key-handling-across-CD">CDR MUST define the way soft-keys and accesskeys are handled across document components</a><br />
|
|
3.1.23 <a href="#reqmt-fonts">CDR User Agents MUST provide a default font for use by all components</a><br />
|
|
3.1.24 <a href="#reqmt-serversideadaptation">CDR MUST NOT prevent server-side adaptation</a><br />
|
|
3.1.25 <a href="#reqmt-limitedbandwidth">CDR MUST support limited bandwidth networks and limited
|
|
capability devices</a><br />
|
|
3.1.26 <a href="#reqmt-document-confirmance-criteria">CDR Profiles MUST define clear document conformance criteria</a><br />
|
|
3.1.27 <a href="#reqmt-useragent-conformance-criteria">CDR Profiles MUST define clear user agent conformance criteria</a><br />
|
|
3.1.28 <a href="#reqmt-currentLoadingStatus">CDR Profiles SHOULD provide a way to know the current loading status of a
|
|
referenced component</a><br />
|
|
3.1.29 <a href="#reqmt-packaging-static">CDR MUST provide a solution for packaging of self-contained, static content</a><br />
|
|
3.1.30 <a href="#reqmt-packaging-streamed">CDR MAY provide a solution for packaging of streamed content</a><br />
|
|
3.2 <a href="#rich_multimedia_content_requirements">CDR Profile 1 Requirements (Rich Multimedia Content)</a><br />
|
|
3.2.1 <a href="#reqmt-userinteractionmodel">CDR Profile 1 MUST specify a user interaction model</a><br />
|
|
3.2.2 <a href="#reqmt-useragentidentifies">CDR Profile 1 MUST explain how a User Agent is able to identify a CDR Profile 1 document</a><br />
|
|
3.2.3 <a href="#reqmt-scalablegraphics">CDR Profile 1 MUST support 2D scalable vector graphics</a><br />
|
|
3.2.4 <a href="#reqmt-audio">CDR Profile 1 MUST support audio</a><br />
|
|
3.2.5 <a href="#reqmt-video">CDR Profile 1 SHOULD support video</a><br />
|
|
3.2.6 <a href="#reqmt-layouts">CDR Profile 1 MUST support grid, flow, overlapping layouts</a><br />
|
|
3.2.7 <a href="#reqmt-transparency">CDR Profile 1 MUST support SVG backgrounds</a><br />
|
|
3.2.8 <a href="#reqmt-transparency2">CDR Profile 1 MAY support XHTML backgrounds</a><br />
|
|
3.2.9 <a href="#reqmt-identificationofmarkup">CDR Profile 1 MUST support identification of markup and versions in CDF documents</a><br />
|
|
3.2.10 <a href="#reqmt-scalablediagrams">CDR Profile 1 MUST support scalable diagrams that can be animated
|
|
and can cause link traversal</a><br />
|
|
3.2.11 <a href="#reqmt-xhtmlplussvg">CDR Profile 1 MUST define how to reference SVGT graphics and resources
|
|
from an XHTML document</a><br />
|
|
3.2.12 <a href="#reqmt-advertisingsvg">CDR Profile 1 MUST support advertising the specific supported versions
|
|
of formats and capabilities in headers</a><br />
|
|
3.2.13 <a href="#reqmt-XHTMLasroot">CDR Profile 1 MUST support XHTML as a root/host language</a><br />
|
|
3.2.14 <a href="#reqmt-XHTMLobjectelement">The XHTML <object> element MUST be used for referring to
|
|
other formats from XHTML</a><br />
|
|
3.2.15 <a href="#reqmt-xhtmlsvginteractionmodel">CDR Profile 1 MUST define the interaction model for an SVG
|
|
document referenced by an XHTML document</a><br />
|
|
3.2.16 <a href="#reqmt-animatedSVGicons">CDR Profile 1 MUST define for animated SVG icons to act like HTML
|
|
images (no need for interactivity, links, zoom and pan)</a><br />
|
|
3.2.17 <a href="#reqmt-focusevents">CDR Profile 1 MUST define a way for events to trigger SVG
|
|
animation</a><br />
|
|
3.2.18 <a href="#reqmt-realestatenegotiation">CDR Profile 1 MUST define the process for real-estate negotiation
|
|
between an XHTML document and a referenced SVG document</a><br />
|
|
3.2.19 <a href="#reqmt-leftovers">CDR Profile 1 MUST define handling of leftover SVG area</a><br />
|
|
3.2.20 <a href="#reqmt-systemfontsupport">CDR Profile 1 MUST define system font support in SVG</a><br />
|
|
3.2.21 <a href="#reqmt-temportal-start-and-stop">CDR Profile 1 SHOULD provide temporal synchronization with dynamic media</a><br />
|
|
3.2.22 <a href="#reqmt-stop-and-start-media">CDR Profile 1 MAY provide functionality to stop and start media objects</a><br />
|
|
3.2.23 <a href="#reqmt-unifiedrendering">CDR Profile 1 MUST support a unified rendering and processing model</a><br />
|
|
3.2.24 <a href="#reqmt-animationOnLoad">CDR Profile 1 SHOULD provide a way to play an animation while some
|
|
referenced components of the Combined Document are loading</a><br />
|
|
3.2.25 <a href="#reqmt-audiomixing">CDR Profile 1 MUST specify the behavior of audio mixing</a><br />
|
|
</p>
|
|
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#references">References</a> (Non-Normative)<br />
|
|
B <a href="#acknowledgements">Acknowledgements</a> (Non-Normative)<br />
|
|
C <a href="#changes-log">Changes Log</a> (Non-Normative)<br />
|
|
</p></div><hr /><div class="body"><div class="div1">
|
|
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><div class="div2">
|
|
<h3><a name="approach" id="approach"></a>1.1 Approach</h3><p>The Compound Document Formats Working Group is producing
|
|
recommendations on combining separate component languages
|
|
(e.g. XML-based languages, elements and attributes from
|
|
separate vocabularies), like XHTML, SVG, XForms, MathML, and
|
|
SMIL, with a focus on user interface markups. When combining
|
|
user interface markups, specific problems have to be resolved
|
|
that are not addressed by the individual markups
|
|
specifications, such as the propagation of events across
|
|
markups, the combination of rendering or the user interaction
|
|
model with a combined document. The Compound Document Formats
|
|
working group will address this type of problems. This work
|
|
is divided in phases and two technical solutions: combining
|
|
by reference and by inclusion.</p><p>The group is addressing the semantics of combining markups,
|
|
which goes beyond the mechanics and syntactical elements used
|
|
to combine markups. The semantic of combining markup is, to a
|
|
large extent, specific to any two markups being combined. For
|
|
example, including SVG markup in an XHTML document can be done
|
|
in various ways and there is a need to define how the
|
|
combination is done and what it means, especially with regards
|
|
to issues mentioned above (such as event propagation, user
|
|
interactions or rendering). Because defining the combined
|
|
semantics is complex, because the group needs to deliver a
|
|
test suite and specific conformance requirements (see <a href="http://www.w3.org/2004/CDF/admin/charter">charter</a>)
|
|
and because there is a growing request to support specific
|
|
versions of specific markups, the group will initially produce
|
|
a specification that mandates specific versions of specific
|
|
markup profiles. However, as explained in the following
|
|
section, the group will structure its specification work such
|
|
that generic combination concepts and techniques are part of a
|
|
framework specification so that they can be easily referenced
|
|
and reused in other contexts, or in future specifications this
|
|
group produces.</p><div class="div3">
|
|
<h4><a name="phases-of-work" id="phases-of-work"></a>1.1.1 Phases of Work</h4><p>The phases of work lists a set of languages (with their
|
|
profiles) that are combined. As the languages differ by
|
|
their features and properties, different issues come up when
|
|
combining together different languages. Therefore, the phase
|
|
constrains the issues that are currently solved.</p><p>The standardization starts with a limited set of
|
|
languages. Once issues on these languages are solved, a next
|
|
larger package is started. The following phases contain more
|
|
languages and therefore, the corresponding recommendations
|
|
solve a wider variety of combination issues. </p><p>Each phase results in:</p><ul><li><p>a new version of the Compound Document Framework
|
|
specification</p></li><li><p>(at least) one specific Profile specification
|
|
that uses the corresponding Compound Document
|
|
Framework. Each Profile specification will include a list
|
|
of specific supported languages (and profiles thereof) and
|
|
also include any supplemental integration notes as
|
|
necessary beyond what is described in the
|
|
Framework.</p></li></ul></div><div class="div3">
|
|
<h4><a name="intro-by-reference" id="intro-by-reference"></a>1.1.2 By Reference</h4><p>The first technical solution for combining document
|
|
formats is combination by reference. This means that
|
|
documents using different languages (XML vocabularies) are linked
|
|
by a reference such as XLink references, XHTML <img>, <object>
|
|
and XForms instance src attributes.
|
|
This allows separate languages to work together,
|
|
but it allows implementations of the languages be
|
|
separated. </p><p>The standardized issues are for example, how events flow
|
|
in multi-document environment, how different documents are
|
|
accessed by the scripts, and how different languages should
|
|
cooperate in drawing to the screen (or other media).</p></div><div class="div3">
|
|
<h4><a name="intro-by-inclusion" id="intro-by-inclusion"></a>1.1.3 By Inclusion</h4><p>
|
|
A subsequent phase will address compound documents by inclusion, which is
|
|
combining more than one namespace vocabulary within the same document. For
|
|
example, a compound document with XHTML as the enclosing root schema which
|
|
contains nested XForms namespace elements, and SVG namespace elements,
|
|
and XML Events elements all in the same document. A compound document by
|
|
inclusion, may also contain reference to other separate documents, and
|
|
therefore may be a combination of inclusion and reference.
|
|
</p><p>
|
|
The standardization issues that will be addressed in the Compound
|
|
Documents by Inclusion Recommendation are how different namespace
|
|
vocabulary implementations will interact within the same document, and how
|
|
compound documents by inclusion should be loaded and processed by browser
|
|
user agents.
|
|
</p></div></div><div class="div2">
|
|
<h3><a name="rich_multimedia_content_definition" id="rich_multimedia_content_definition"></a>1.2 Definition of Rich Multimedia Content</h3><p>
|
|
This specification addresses UI languages in order to
|
|
facilitate <b>rich multimedia content</b>, which can
|
|
include the following characteristics.
|
|
</p><ul><li><p>
|
|
Graphically rich content, possibly including animated
|
|
background image.</p></li><li><p>
|
|
|
|
Content author/provider has exact control of the
|
|
presentation, including fonts, layout, color, etc.
|
|
|
|
</p></li><li><p>
|
|
|
|
Layout adaptation: layout can be based upon device
|
|
characteristics - screen size, color depth, resolution,
|
|
orientation.</p></li><li><p>
|
|
|
|
Navigation (forward/backwards tab, up/down/left/right,
|
|
accesskey, pointer, voice), graphical menus,
|
|
interactivity and animations.
|
|
|
|
</p></li><li><p>
|
|
|
|
Graphical menu systems where items have an animated
|
|
action when focused on.
|
|
</p></li><li><p>
|
|
|
|
Portable user interface.
|
|
|
|
</p></li><li><p>
|
|
|
|
Presentation can be customized to reflect a brand or
|
|
user's personality.
|
|
</p></li><li><p>
|
|
|
|
Skinnable user interface: the ability to use animations
|
|
and interactivity as a user interface "skin" or template
|
|
around other content.
|
|
|
|
</p></li><li><p>
|
|
|
|
Rich content for different contexts.
|
|
</p></li><li><p>
|
|
|
|
Dynamic content: documents that are generated on the fly or
|
|
which change over time
|
|
</p></li><li><p>
|
|
Interaction with mixed content, for example interacting with all the
|
|
parts (graphics, text, images, audio, video, voice and multimodal
|
|
interaction) of the mixed document.
|
|
</p></li><li><p>
|
|
|
|
Content adaptation, such as when a portal delivers a mixed
|
|
document with varying capabilities (textual content and
|
|
interactive animated content, for example) to a user which
|
|
has been aggregated from multiple rich content sources.
|
|
|
|
</p></li></ul><p>The following table shows existing W3C formats which are relevant to rich multimedia content. Each combination for which there is a requirement is
|
|
annotated with comments. This is here to
|
|
show the relationship between current W3C recommendations and
|
|
the definition of rich multimedia content: <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p><table rules="all" frame="box"><thead><tr><th></th><th>XHTML + CSS</th><th>SVG</th><th>SMIL</th><th>XForms</th><th>VoiceXML</th><th>XBL</th><th>DOM/Scripting</th></tr></thead><tbody><tr><th align="left">Graphically rich content, possibly including animated
|
|
background image</th><td>Need CSS's 'background-*' properties</td><td>Need animated graphics facility of SVG</td><td>SMIL supports z-order. Hence, animated or non-animated background image are easy to make in SMIL.</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Content author/provider has exact control of the presentation, including fonts, layout, color, etc...</th><td>For when author/provider requires exact control in flowable scenarios</td><td>For when author/provider requires exact control in fixed canvas scenarios</td><td>SMIL provides an exact control of the main document layout and it uses other media types such as XHTML or PNG for the content.</td><td>(not directly applicable)</td><td>Author exact control of audio presentation when media=aural or for multimodal presentation</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Layout adaptation: layout can be based upon device characteristics - screen size, color depth, resolution, orientation</th><td>For some scenarios, CSS box model layout and @media will be part of solution</td><td>For some scenarios, scalable graphics will be part of the solution</td><td>SMIL BasicContentControl (including <smil:switch>) is the module that provides this functionality.</td><td>In XForms, the content is separated from the presentation, and
|
|
thus it support layout adaptation of forms.</td><td>Allows author to provide an aural presentation when media=aural.</td><td>(not directly applicable)</td><td>(not directly applicable)</td></tr><tr><th align="left">Navigation (forward/backwards tab, up/down/left/right, accesskey, pointer, voice), graphical menus, interactivity and animations</th><td>Need XHTML <form> elements to define navigation points</td><td>For graphical menus, rich interactivity and animations</td><td>SMIL Linking module provides this functionality</td><td>For device-independent representation of human-computer interaction</td><td>For voice</td><td>(not directly applicable)</td><td>For when the author requires advanced behavior</td></tr><tr><th align="left">Menu system e.g., items get animated when focused</th><td>For some scenarios, XHTML+CSS is sufficient for menus</td><td>For rich UI and animation</td><td>Menus can be done in SMIL, but it can be cumbersome because each menu item needs to be in a separate file. Scripting could also be used in conjunction with referenced XHTML content.</td><td>Menus could be presented as forms with help of XBL</td><td>(not directly applicable)</td><td>Allows menus to be abstracted as reusable components</td><td>Often, menus require scripting facilities</td></tr><tr><th align="left">Portable user interface</th><td>For some scenarios, XHTML+CSS is sufficient for portable UIs</td><td>For rich UI and animation</td><td>Menus can be done in SMIL, but it can be cumbersome because each menu item needs to be in a separate file. Scripting could also be used in conjunction with referenced XHTML content.</td><td>For device-independent representation of human-computer interaction</td><td>For voice-based user interfaces</td><td>Allows menus to be abstracted and reskinned to adapt to different
|
|
platforms</td><td>Often, XBL components require client-side scripting</td></tr><tr><th align="left">Presentation can be customized to reflect brand or user's personality</th><td>For some scenarios, XHTML+bitmaps is sufficient</td><td>For some scenarios, SVG's richness is a requirement</td><td>SMIL CustomTestAttributes module provides this functionality.</td><td>(not directly applicable)</td><td>(not directly applicable)</td><td>Allows presentation elements to be abstracted and reskinned</td><td>Client-side scripting is often used for presentation customization</td></tr><tr><th align="left">Skinnable user interface e.g., ability to skin a document with animations and interactivity. </th><td>XHTML+CSS alone are not sufficient for skinnable UI</td><td>For rich graphics, animations and rich interactivity</td><td>SMIL controls the main document layout and all content is customizable. Test module provides ability to select appropriate content.</td><td>XForms provides the definition of the abstract UI components before skinning is applied</td><td>If you want to skin for voice</td><td>Allows UI elements to be abstracted and reskinned</td><td>Often, XBL components require client-side scripting</td></tr></tbody></table></div><div class="div2">
|
|
<h3><a name="relationships-with-other" id="relationships-with-other"></a>1.3 Relationships With Other Technologies</h3><p>There are many technologies that allow combining different
|
|
languages. Most extensible languages provide this
|
|
feature. The combining technologies and issues can be divided
|
|
in two categories. The first category is how the combining
|
|
is described. The second category is how the semantics of
|
|
combining is understood. Each language specifies the first
|
|
category. The combining recommendations try to solve the
|
|
second ones.</p><div class="div3">
|
|
<h4><a name="relationships-html-xhtml" id="relationships-html-xhtml"></a>1.3.1 HTML and XHTML</h4><p>HTML has an <object> element. This element can be used to
|
|
combine by reference. The <object> element provides a way to
|
|
link to external documents.</p></div><div class="div3">
|
|
<h4><a name="relationships-svg" id="relationships-svg"></a>1.3.2 SVG</h4><p>SVG has a <foreignObject> element. This element can be used
|
|
to combine by reference. The <foreignObject> element
|
|
provides a way to link to external documents.</p></div><div class="div3">
|
|
<h4><a name="relationships-smil" id="relationships-smil"></a>1.3.3 SMIL</h4><p>SMIL technologies are closely related to combining by
|
|
reference. SMIL provides mechanisms (e.g., <animation>, <audio>
|
|
and <video> elements) to combine content and synchronize them in time.</p></div><div class="div3">
|
|
<h4><a name="relationships-xlink" id="relationships-xlink"></a>1.3.4 XLink</h4><p>Xlink specifies a generic reusable vocabulary for links
|
|
in XML documents. An XLink may be specified on an arbitrary
|
|
element in such a way that an XLink enabled processor will
|
|
be able to understand the linking semantics of said element. A variety of
|
|
linking behaviors (embedding, hyperlinking, etc.) may be further
|
|
described using additional linking metadata.</p></div><div class="div3">
|
|
<h4><a name="relationships-xinclude" id="relationships-xinclude"></a>1.3.5 XInclude</h4><p>XInclude specifies how to combine different infosets
|
|
together. This approach may be used for combination by
|
|
inclusion.</p><p>After the XInclude markup is processed, the WG's produced
|
|
recommendations will specify the semantics on how the application
|
|
should understand the compound document.</p></div><div class="div3">
|
|
<h4><a name="relationships-soap-attachments" id="relationships-soap-attachments"></a>1.3.6 SOAP Attachments and Optimization Technologies</h4><p>SOAP Attachments provide a way to divide documents into
|
|
several pieces for more efficient serialization and subsequent
|
|
recombination. For the WG's produced recommendations,
|
|
SOAP Attachments are similar in scope to the XInclude technology,
|
|
the combining technology operates and provides semantic
|
|
information on top of these serialization issues.</p></div><div class="div3">
|
|
<h4><a name="relationships-open-document" id="relationships-open-document"></a>1.3.7 OASIS's Open Document Format</h4><p>The OASIS effort is targeted at office productivity
|
|
applications, such as word processors, spreadsheets or
|
|
presentation authoring tools. The work is focused on
|
|
representing the full information contained in documents
|
|
that are created and edited with such tools in an
|
|
interoperable manner. On the other hand, the CDF effort is
|
|
focused on combining formats for web publication and has a
|
|
lot of focus on user agent environment, and runtime
|
|
behavior. For example, the CDF Working Group efforts will focus on issues
|
|
such as the runtime interaction model for documents
|
|
including components from different XML formats. This is not
|
|
addressed by the Open Document Format specification. The
|
|
Open Document Format, on the other hand, specifies an office
|
|
application compatible style model, page layouts, index
|
|
generations, text fields, table formulas which the CDF
|
|
specifications will not address.</p></div><div class="div3">
|
|
<h4><a name="relationships-forms" id="relationships-forms"></a>1.3.8 XForms</h4><p>XForms is a schema designed to split documents into three
|
|
parts: the XForms model, the instance data, and the user
|
|
interface. It provides a mechanism for expressing the data
|
|
and intent of a form and allowing browser/renderers the
|
|
flexibility to present the information most suitable for the
|
|
device currently rendering the form. XForms supports
|
|
compound document by inclusion by design since it is not a
|
|
free-standing document type, and was always meant to be
|
|
enclosed by a root document.</p></div><div class="div3">
|
|
<h4><a name="relationship-xhtml-voice" id="relationship-xhtml-voice"></a>1.3.9 XHTML + Voice</h4><p>The XHTML+Voice profile is designed for Web clients that
|
|
support visual and spoken interaction. The XHTML+Voice
|
|
profile brings spoken interaction to standard web content by
|
|
integrating a set of mature web technologies such as XHTML
|
|
and XML Events with XML vocabularies developed as part of
|
|
the W3C Speech Interface Framework. The profile includes
|
|
voice modules that support speech synthesis, speech dialogs,
|
|
command and control, speech grammars, and the ability to
|
|
attach Voice handlers for responding to specific DOM events,
|
|
thereby re-using the event model familiar to web
|
|
developers. Voice interaction features are integrated
|
|
directly with XHTML and CSS, and can consequently be used
|
|
directly within XHTML content. The definition of the
|
|
XHMTL+Voice profile is a compound document profile.</p></div></div><div class="div2">
|
|
<h3><a name="terms" id="terms"></a>1.4 Definition of Terms</h3><p>The working group has decided to use following terms in the
|
|
work and this document.</p><dl><dt class="label">Compound document</dt><dd><p>
|
|
The compound document is a
|
|
document that combines separate component languages either
|
|
by reference or by inclusion.</p></dd><dt class="label">Root document</dt><dd><p>In the case of combining by reference, one compound
|
|
document may be a collection of several separate
|
|
documents.</p><p>The top-most (e.g. document not having any references
|
|
to it) compound document is called Root document.</p></dd><dt class="label">Parent document</dt><dd><p>In the case of combining by reference, one compound
|
|
document may be a collection of several separate
|
|
documents.</p><p>The document that references another document is called
|
|
Parent document. The top-most parent document is also called
|
|
Root document.</p></dd><dt class="label">Child document</dt><dd><p>In the case of combining by reference, one compound
|
|
document may be a collection of several separate
|
|
documents.</p><p>The document that is referenced is called Child
|
|
document. If the Child document references other documents,
|
|
it is also called Parent document.</p></dd><dt class="label">User Agent</dt><dd><p>
|
|
See <a href="http://www.w3.org/TR/di-gloss/#def-user-agent">definition</a> in Device Independence Glossary document.</p></dd><dt class="label">Component Language</dt><dd><p>Component language refers to an XML-based language (like XHTML and SVG) with its own elements and attributes.</p></dd></dl></div><div class="div2">
|
|
<h3><a name="who_what_will_implement_the_specification" id="who_what_will_implement_the_specification"></a>1.5 Who/what will implement the specification</h3><div class="div3">
|
|
<h4><a name="authoringtools" id="authoringtools"></a>1.5.1 Authoring tools and content production systems</h4><p>Compound documents can be authored by a variety of means including:</p><ul><li><p>Hand editing with a text editor</p></li><li><p>Dynamic generation via a Web servers or other back end systems</p></li><li><p>Via authoring tools which focus on the component languages (an
|
|
XHTML authoring tool)</p></li><li><p>Via authoring tools which focus on compound documents (a "CDF
|
|
authoring tool")</p></li></ul><p>It is expected that there will be multiple categories of CDF authoring
|
|
tools. Here are some examples:</p><ul><li><p>Document-centric authoring tools to create content which mixes static
|
|
text and graphics for the purpose of publishing on the Web</p></li><li><p>Multimedia-centric authoring tools for creating time-based, interactive
|
|
content (a movie or game, for example)</p></li><li><p>Application-centric authoring tools to create user interfaces</p></li><li><p>Forms-centric authoring tools to create data templates</p></li><li><p>Device-independent authoring tools for creating content that can be
|
|
adapted to different user requirements and across different media</p></li></ul></div><div class="div3">
|
|
<h4><a name="useragents" id="useragents"></a>1.5.2 User agents, such as browsers and plug-ins</h4><p>Depending on the system, CDF content will be viewed in a variety of ways:</p><ul><li><p>Via native support within a browser which is
|
|
conformant with CDF specification(s)</p></li><li><p>Via a browser plug-in which registers itself as a
|
|
handler for CDF content</p></li><li><p>Via a dedicated CDF viewing application</p></li><li><p>Via browser fallback compatibility (e.g., the
|
|
browser treats CDF files as XHTML content)</p></li><li><p>Via accessibility tools such as screen
|
|
readers</p></li></ul></div><div class="div3">
|
|
<h4><a name="intermediaryprocessors" id="intermediaryprocessors"></a>1.5.3 Intermediary Processors, content renderers</h4><p>Systems that process, combine, re-order, re-format or
|
|
otherwise render content based on context. An example
|
|
is a content rendering engine which takes content in a
|
|
device neutral form and renders it appropriately
|
|
according to particular device or bearer characteristics
|
|
(such as screen size or bandwidth).</p></div></div></div><div class="div1">
|
|
<h2><a name="use-cases" id="use-cases"></a>2 Use Cases</h2><p>The W3C and other bodies have created multiple XML syntaxes
|
|
for various purposes, such as XHTML for on-line document
|
|
viewing, SVG for 2D vector graphics or SMIL for multi-media
|
|
synchronization. While there has been a lot of interest for
|
|
these individual solutions, there has been a growing demand for
|
|
a solution that would let end-users use them together to define
|
|
a single piece of content. The individual markups as those just
|
|
mentioned have great features, but these features become even
|
|
more compelling when combined. For example, being able to
|
|
display scalable 2D images in XHTML pages provides the ability
|
|
to define pages which can be printed with high
|
|
quality. Similarly, using SVG images in an XHTML table provides
|
|
an easy way to layout SVG images in a table.</p><p>There is a demand for letting content creators combine
|
|
markups so as to create richer documents, containing multi-media
|
|
information: text, graphics, audio and video. For that reason,
|
|
the main use case for the CDF activity is the definition of rich
|
|
multimedia content, as defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p><div class="div2">
|
|
<h3><a name="web_publishing_broadcasting" id="web_publishing_broadcasting"></a>2.1 Web Publishing and Broadcasting</h3><p>
|
|
Services that mix text, audio, video and interactive elements to deliver information.
|
|
</p><div class="div3">
|
|
<h4><a name="usecase-news-service" id="usecase-news-service"></a>2.1.1 Interactive News Service</h4><p>
|
|
An interactive news service may provide the user with
|
|
multimedia news content comprising traditional text and
|
|
images, but also audio and video reports as well as
|
|
diagrams which react to user behavior.
|
|
</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: newspaper Web sites that offer interactive features which go beyond textual content offered in a print edition.</p></div></div><div class="div3">
|
|
<h4><a name="usecase-web-portal" id="usecase-web-portal"></a>2.1.2 Web Portal</h4><p>A "portal" application combines content and services from
|
|
multiple back-end sources across multiple integration
|
|
paths to create a cohesive user experience. Portals often
|
|
are customizable to user preferences and other factors and
|
|
therefore often produce dynamic content that is specific to
|
|
a particular user-request.</p></div><div class="div3">
|
|
<h4><a name="usecase-ticker" id="usecase-ticker"></a>2.1.3 News or stock ticker</h4><p>An animated "ticker" which displays dynamic data, such as
|
|
stock prices or current news headlines, can be displayed as
|
|
part of a larger page of more static information, such as a
|
|
news article.</p></div><div class="div3">
|
|
<h4><a name="usecase-document-viewing" id="usecase-document-viewing"></a>2.1.4 Document viewing</h4><p>The capability to view documents with preserved
|
|
formatting, layout, images and graphics and interactive
|
|
features such as zooming in and out and multi-page
|
|
handling.</p></div><div class="div3">
|
|
<h4><a name="usecase-infotainment" id="usecase-infotainment"></a>2.1.5 Infotainment</h4><p>Infotainment services
|
|
combine information and entertainment from different sources
|
|
into a single interactive service with compelling
|
|
presentation. The user experience for such services is often
|
|
a single "page" which displays multiple pieces of
|
|
content, each potentially of a different kind. These
|
|
services often require dynamic user interfaces that use
|
|
animation and other graphic effects to produce a pleasing
|
|
user interface.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: mobile portals deployed by mobile network operators.</p></div></div></div><div class="div2">
|
|
<h3><a name="usecase-web-applications" id="usecase-web-applications"></a>2.2 Web Applications</h3><p>
|
|
Web applications typically have some form of programmatic
|
|
control, either on the client, on the server or a
|
|
combination of both. This document addresses client-side Web
|
|
applications only. They may run within the user agent, or
|
|
within another host application. A Web application is
|
|
typically downloaded on demand each time it is "executed",
|
|
allowing a developer to update the application for all users
|
|
when needed. Web applications are usually smaller than
|
|
regular desktop applications, and can have rich graphical
|
|
interactive interfaces.
|
|
</p><div class="div3">
|
|
<h4><a name="usecase-reservation-system" id="usecase-reservation-system"></a>2.2.1 Reservation system</h4><p>Interactive services which allow a user to book travel or
|
|
make other kinds of reservations by using graphically-rich
|
|
user interface. For instance, a user may use a calendar to
|
|
pick a departure or check-in date and a map to locate a
|
|
destination, with results represented as textual data for
|
|
confirmation.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Example: online travel sites or airline
|
|
sites.</p></div></div><div class="div3">
|
|
<h4><a name="usecase-order-entry" id="usecase-order-entry"></a>2.2.2 Order entry system</h4><p>An application which might be used in the field to
|
|
process orders for goods or services.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Examples: Parcel tracking application used by
|
|
delivery agents; order entry system used by a mobile sales
|
|
force.</p></div></div><div class="div3">
|
|
<h4><a name="usecase-online-shopping" id="usecase-online-shopping"></a>2.2.3 On-line shopping</h4><p>E-Commerce services which use interactive elements to
|
|
display goods and enable a shopping experience.</p></div><div class="div3">
|
|
<h4><a name="usecase-survey" id="usecase-survey"></a>2.2.4 Survey</h4><p>A survey application which provides a multi-part form
|
|
which can be stepped forward or backward and submitted in
|
|
one action.</p></div><div class="div3">
|
|
<h4><a name="usecase-web-games" id="usecase-web-games"></a>2.2.5 Games</h4><p>Interactive games that use animated content embedded
|
|
within a page and using elements within the page to actuate
|
|
functions within the game. For example, a simple painting
|
|
game where the painting occurs in the animated area but a
|
|
palate of colors are set outside of this area in the
|
|
non-animated area.
|
|
</p></div><div class="div3">
|
|
<h4><a name="usecase-interactive-maps" id="usecase-interactive-maps"></a>2.2.6 Interactive maps</h4><p>In a mapping application, the map itself may appear in an
|
|
animated inset, while controls that show or hide various
|
|
aspects of the map or zoom the view in or out may be located
|
|
outside the animated area.</p></div></div><div class="div2">
|
|
<h3><a name="usecase-resident-applications" id="usecase-resident-applications"></a>2.3 Resident Applications</h3><p>
|
|
These are applications which are resident or partially resident on
|
|
a device.
|
|
</p><div class="div3">
|
|
<h4><a name="usecase-pim" id="usecase-pim"></a>2.3.1 Personal Information Management</h4><p>To-do list, calendar entries and Calculator user interfaces.</p></div><div class="div3">
|
|
<h4><a name="usecase-communication" id="usecase-communication"></a>2.3.2 Communication</h4><p>Email, MMS, instant messaging, access to phone functions,
|
|
such as dialing a number, sending a text message, or
|
|
manipulation of the built-in address book (subject to
|
|
security and privacy considerations).</p></div><div class="div3">
|
|
<h4><a name="usecase-idle-screen" id="usecase-idle-screen"></a>2.3.3 Dynamic graphics as background or screen saver in mobile phone</h4><p>In a mobile phone, a Web application is set as background or screen
|
|
saver, and is dynamically updated depending on, for example, data from
|
|
the network or the time of day. This allows the user to have immediate
|
|
access to 'glancable' information, such as current weather conditions,
|
|
stock quotes, or more application-oriented information such as flight
|
|
departure data.</p></div><div class="div3">
|
|
<h4><a name="usecase-document-viewing2" id="usecase-document-viewing2"></a>2.3.4 Document viewing</h4><p>The capability to view documents with preserved
|
|
formatting, layout, images and graphics and interactive
|
|
features such as zooming in and out and multi-page
|
|
handling.</p></div><div class="div3">
|
|
<h4><a name="usecase-icon-bar" id="usecase-icon-bar"></a>2.3.5 Interactive Icon bar</h4><p>A set of icons,
|
|
representing destinations in a
|
|
portal or applications, which
|
|
animate when focused on.</p></div><div class="div3">
|
|
<h4><a name="usecase-interactive-maps2" id="usecase-interactive-maps2"></a>2.3.6 Interactive Maps</h4><p>Display of a map with interactive features such as
|
|
panning, zooming, level of detail, points of interest.</p></div></div><div class="div2">
|
|
<h3><a name="content_authoring_aggregation_deployment" id="content_authoring_aggregation_deployment"></a>2.4 Content Authoring, Aggregation and Deployment</h3><p>This class includes tools and applications for both personal
|
|
and professional content creation, management, and
|
|
distribution.</p><div class="div3">
|
|
<h4><a name="personal-content-creation" id="personal-content-creation"></a>2.4.1 Personal content creation</h4><p>Personal content is created by users themselves and, often, shared
|
|
with other users. In many cases, users want to combine different
|
|
content formats. A typical example is that use take a picture with
|
|
mobile phone, write short message about the excellent meal that he/she
|
|
had in the restaurant, and attach a map which shows the location of
|
|
the restaurant.</p></div><div class="div3">
|
|
<h4><a name="personal-content-management" id="personal-content-management"></a>2.4.2 Personal content management</h4><p>
|
|
Personal content management refers to storing your
|
|
personal media content including images, audio, video,
|
|
graphics, text, etc. It should be possible to link
|
|
different content items to each other, view them
|
|
simultaneously. In addition, the content management system
|
|
should support adaptation of the content for different
|
|
kinds of devices and sharing the content online with other
|
|
users. </p></div><div class="div3">
|
|
<h4><a name="web-logs" id="web-logs"></a>2.4.3 Web logs</h4><p>
|
|
Blogs are personal diaries that are published online. Many
|
|
bloggers try to create visually attractive content by
|
|
combining different content formats. </p></div><div class="div3">
|
|
<h4><a name="content-aggregation" id="content-aggregation"></a>2.4.4 Content aggregation</h4><p>
|
|
In content aggregation, content coming from different
|
|
sources is combined together. Web portals are typical
|
|
examples. Often, content aggregators have different
|
|
versions of the content offering for different delivery
|
|
channels and user groups. Therefore, content filtering and
|
|
transforming is often required. In addition, the content
|
|
aggregators want to maintain certain look and feel of
|
|
service across different devices and versions. Also, there
|
|
might be need for Digital Rights Management (DRM).
|
|
</p></div><div class="div3">
|
|
<h4><a name="professional-content-management" id="professional-content-management"></a>2.4.5 Professional content management</h4><p>
|
|
Most professional web sites use content management
|
|
systems, which provide means for version management,
|
|
access control, content versioning, etc. The content
|
|
itself is usually in several different formats.
|
|
</p></div></div><div class="div2">
|
|
<h3><a name="usecase-navigation" id="usecase-navigation"></a>2.5 Navigation</h3><div class="div3">
|
|
<h4><a name="svg-logo-ad" id="svg-logo-ad"></a>2.5.1 SVG used as logo or advertisement (no links in SVG).</h4><p>SVG images are used as embedded logos or advertisements (with
|
|
animations) in an XHTML document.
|
|
There are no links in the SVG images.
|
|
The user cannot focus the images, they are like bitmaps embedded by
|
|
<img>. </p></div><div class="div3">
|
|
<h4><a name="svg-embedded-map" id="svg-embedded-map"></a>2.5.2 SVG embedded interactive map (links in SVG). </h4><p>An SVG image, which is an interactive city map, is embedded inside an
|
|
XHTML page.
|
|
There are links inside the SVG image.
|
|
The user can navigate to the SVG map, which then gets focus.
|
|
When the map has focus the user can either navigate further into the
|
|
first link inside the map or skip the map and navigate further to the
|
|
next link in the XHTML document.</p></div><div class="div3">
|
|
<h4><a name="svg-images-animate-when-focused" id="svg-images-animate-when-focused"></a>2.5.3 Menu with SVG images that animate and expand when focused (no links in SVG)</h4><p>SVG images are used as menu icons, wrapped inside <a> elements, in an
|
|
XHTML document.
|
|
There are no links inside the SVG images.
|
|
When the user focuses a menu item, the icon expands and starts to
|
|
animate.
|
|
When the user moves to the next item, the animating icon returns to the
|
|
state it had before it had focus, and the next icon, which now gets
|
|
focus and starts to animate.</p></div><div class="div3">
|
|
<h4><a name="embedded-svg-interactive" id="embedded-svg-interactive"></a>2.5.4 SVG image is embedded interactive part of the Web page (SVG has
|
|
links)</h4><p>An SVG image is used as 2D-graphics in a Web page. The SVG image has
|
|
links.
|
|
The user can navigate directly from an XHTML link into the first link in
|
|
the SVG image; the SVG image is seamlessly integrated with the XHTML
|
|
page.
|
|
The user navigates directly from the last link inside the SVG image to
|
|
the next link, after the SVG image, in XHTML. </p><p>This is an alternative scenario in <a href="#svg-embedded-map"><b>2.5.2 SVG embedded interactive map (links in SVG). </b></a>.</p></div></div><div class="div2">
|
|
<h3><a name="specific-use-cases" id="specific-use-cases"></a>2.6 Specific Use Cases</h3><p>Whereas the use cases outlined above are general in nature, the following use cases go into more detail and specifically describe some of the implementation issues that require the use of compound document technology.</p><div class="div3">
|
|
<h4><a name="usecase-sync-of-html-content" id="usecase-sync-of-html-content"></a>2.6.1 Synchronization of HTML content with audio visual content:</h4><p>The description of an auction item on an auction service (a Web page)
|
|
includes a short video clip that describes the item. Lets
|
|
assume the user needs to watch the video clip in-full for
|
|
legal reasons before he is allowed to place a bid for this
|
|
item by typing the amount in an entry field and pressing the
|
|
"Place Bid" button on the same Web page.</p><p>User starts play-back of the video by selecting a button
|
|
on the page. This raises an event that starts playback of
|
|
the embedded video object. Once the video has ended the
|
|
embedded video object raises another event. This event
|
|
causes the "Place Bid" to become selectable in the HTML
|
|
page.</p><p>This use case includes several functionalities which are
|
|
not possible in HTML and the <object> element today: </p><ul><li><p>starting and stopping playback of an embedded video (or audio) in response to interaction with another HTML element</p></li><li><p>an embedded object generating an event that causes an update to the including HTML page (possibly with the help of JavaScript) without reloading this page</p></li></ul></div><div class="div3">
|
|
<h4><a name="usecase-animated-svg-icons" id="usecase-animated-svg-icons"></a>2.6.2 Animated SVG icons in HTML menu</h4><p>An HTML page includes a menu for the user to select
|
|
between different Web applications. Each menu item is a
|
|
single <a> element. Each anchor value consists of an SVG
|
|
graphics and a rich text label. Each SVG graphics must
|
|
scale to fit the same size rectangular bounding box
|
|
(position and size defined by the containing HTML+CSS
|
|
document), aspect ratio must be maintained when
|
|
scaling. Example:</p>
|
|
<h5><a name="scrap-usecase-animated-svg-icons" id="scrap-usecase-animated-svg-icons"></a>Animated SVG Icons Example</h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre><a href="Web-application-1.html">
|
|
<object width="100%" data="menu-item-1.svg" />
|
|
Web Application Choice<em>1</em>
|
|
</a></pre></td></tr></tbody></table><p>The background image of the page (defined by background-image CSS property) must be visible through the 'holes' in the SVG graphics.</p><p>While the user designates an anchor without selecting it (see :hover pseudo class in HTML) the rendering of the anchor value should change as follows:</p><ul><li><p>background of the text part of the anchor changes to yellow</p></li><li><p>the SVG graphics plays an animation</p></li></ul><p>While the user activates an anchor (see active pseudo class in CSS) the rendering of the anchor value should change as follows: </p><ul><li><p>background of the text and SVG parts of the anchor changes to blue</p></li><li><p>the SVG graphics does not animate. Any running animation stops</p></li></ul><p>The following features can not be done with HTML + CSS alone, or cause significant overhead in the content:</p><ul><li><p>background image visible through the 'holes' of content rendered by a typical browser plug-in (or at least this is implementation dependent).</p></li><li><p>SVG content animate for the exact duration of an anchor being designated</p></li><li><p>reliable definition of dimension and aspect ratio of SVG content</p></li></ul></div><div class="div3">
|
|
<h4><a name="usecase-poll-results" id="usecase-poll-results"></a>2.6.3 Visualization of poling results in HTML page</h4><p>An HTML page allows to enter poling results for the three candidates of an election. As soon as (partial) results of the pole have been entered a pie chart on the same HTML page should be updated to visualize the entered data.</p><p>The HTML page consists of three entry fields to enter number of votes for each candidate. A JavaScript calculates the percentage of votes for each candidate and updates a pie chart in SVG immediately. </p><p>The key functionality that can not be done with the current integration of HTML and SVG via the <object> element is access from JavaScript to both documents.</p></div></div></div><div class="div1">
|
|
<h2><a name="requirements" id="requirements"></a>3 Requirements</h2><p>
|
|
All the requirements collected by this WG
|
|
are listed in the following sections.
|
|
</p><div class="div2">
|
|
<h3><a name="requirements_cdr" id="requirements_cdr"></a>3.1 High-Level Requirements</h3><p>
|
|
These are general requirements for the Compound Documents by
|
|
Reference (CDR) specification.
|
|
</p><div class="div3">
|
|
<h4><a name="reqmt-exploitexisting" id="reqmt-exploitexisting"></a>3.1.1 CDR MUST exploit existing specifications, favoring W3C
|
|
specifications wherever possible and limit the definition of new
|
|
markup unless absolutely required for integration purposes</h4><p>It is not the role of the Working Group to invent new
|
|
markup, but rather to specify rules by which existing markup
|
|
formats are combined.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-richmultimedia" id="reqmt-richmultimedia"></a>3.1.2 CDR MUST provide the ability for content developers to describe
|
|
or author rich media content define Rich Multimedia Content</h4><p>Rich Multimedia Content is defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>.</p></div><div class="div3">
|
|
<h4><a name="reqmt-baseset" id="reqmt-baseset"></a>3.1.3 CDR MUST specify a base set of formats, corresponding
|
|
profiles and versions</h4><p>Conformant implementations MUST support this base set.</p></div><div class="div3">
|
|
<h4><a name="reqmt-otherformats" id="reqmt-otherformats"></a>3.1.4 Each CDR profile and version MUST specify, which formats can be referenced</h4><p>Each CDR profile has a root document and one or more
|
|
child documents. The CDR profile has to specify both the
|
|
root document and the possible child documents.</p></div><div class="div3">
|
|
<h4><a name="reqmt-elementused" id="reqmt-elementused"></a>3.1.5 CDR MUST specify, for each format, the element used to
|
|
reference other formats, if any.</h4><p>For example, the CDR
|
|
specification will specify that the XHTML <object> element is to
|
|
be used for formats included in XHTML, and will specify the
|
|
usage of this element to include other formats.</p><p>It may be necessary to transfer some parameters declaratively
|
|
to a child document. Each CDR profile MAY specify a list of pre-defined
|
|
parameters/values for the <object> element. For instance, for CDR WP1,
|
|
there could be these kind of parameters/values:</p>
|
|
<h5><a name="scrap-usecase-object-parameters" id="scrap-usecase-object-parameters"></a></h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre>
|
|
<param name="Volume" value="50" />
|
|
<param name="Mute" value="false" />
|
|
<param name="amination" value="onfocusevent" />
|
|
</pre></td></tr></tbody></table></div><div class="div3">
|
|
<h4><a name="reqmt-genericintegrationtechniques" id="reqmt-genericintegrationtechniques"></a>3.1.6 CDR MUST specify generic integration techniques</h4><p>These are techniques that will be applicable
|
|
beyond the set of formats, versions and profiles required by the
|
|
CDR spec.</p></div><div class="div3">
|
|
<h4><a name="reqmt-temporalsync" id="reqmt-temporalsync"></a>3.1.7
|
|
CDR MUST support temporal synchronization of dynamic content
|
|
coming from multiple references, possibly with multiple
|
|
references to the same source.</h4><p>Support the synchronization of multiple instances of
|
|
dynamic content, such as animations, audio and video, within a
|
|
single compound document.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-eventscrossnamespace" id="reqmt-eventscrossnamespace"></a>3.1.8 CDR MUST support event mechanisms that cross namespace boundaries</h4><p>Define consistent rules that specify how events pass to
|
|
components. In particular, provide rules that define the behavior
|
|
when events are passed across namespace boundaries.</p></div><div class="div3">
|
|
<h4><a name="reqmt-scriptability" id="reqmt-scriptability"></a>3.1.9 CDR MUST support scriptability</h4><p>Compound documents have to support scripting languages. The scripts
|
|
have to be able to access and modify the elements of both root and child
|
|
documents.</p></div><div class="div3">
|
|
<h4><a name="reqmt-nestinglevel" id="reqmt-nestinglevel"></a>3.1.10 CDR MUST say the allowed nesting level of referencing</h4><p>Each CDR profile must define, whether there are restrictions to
|
|
number of nesting levels. For example, whether a referenced SVG can
|
|
itself reference another XHTML content.</p></div><div class="div3">
|
|
<h4><a name="reqmt-scriptingbetweencomponents" id="reqmt-scriptingbetweencomponents"></a>3.1.11 CDR MUST explain how scripting interacts between components and the parent document</h4><p>CDR profile documents must explain what kind of access, if any,
|
|
scripts have between the parent and child documents and
|
|
vice-versa. Can a script in a child document access its parent's
|
|
DOM, and if so, how? Can a script in a parent document access a
|
|
child's DOM? If there is access, the mechanism must be described.</p></div><div class="div3">
|
|
<h4><a name="reqmt-crossnamespace-focus" id="reqmt-crossnamespace-focus"></a>3.1.12 CDR profiles MUST specify how event propagation works
|
|
across namespace boundaries.</h4><p>CDF profile documents must explain how, if at all, events get
|
|
propagated from parent to child documents and vice-versa. Do
|
|
events from a parent document get propagated to the children
|
|
documents? Do events from a child document get propagated to the
|
|
parent document?</p><p>For example, if an XHTML document references an SVG document,
|
|
what is the event propagation model when the user activates an SVG
|
|
element? Do events bubble from a child document to the referencing
|
|
parent document? Does event capture happen from the root of the
|
|
referenced document or does it happen from the root of the
|
|
referencing document? This event propagation model MUST be
|
|
consistent with the <a href="http://www.w3.org/TR/DOM-Level-3-Events">DOM Level 3 event
|
|
model</a>.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-crossnamespace-links" id="reqmt-crossnamespace-links"></a>3.1.13 CDR profiles MUST specify how focus traversal works with
|
|
referenced documents.</h4><p>For example, when an XHTML document references an SVG document,
|
|
what is the relation between the XHTML document's focus traversal
|
|
and the SVG document's focus traversal. How does the SVG document
|
|
get focus and how does the focus traversal starts in the SVG
|
|
document? How does it end?
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-link-activation" id="reqmt-link-activation"></a>3.1.14 CDR profiles MUST specify how link activation work with
|
|
referenced document.</h4><p>A referenced object may be wrapped with a XHTML anchor.
|
|
A referenced object may contain it's own embedded links.
|
|
A referenced object may be wrapped with a XHTML anchor and
|
|
contain it's own embedded links.</p><p>In addition, a referenced object may draw it's own visual
|
|
feedback for focus activation and/or mouse-over.</p><p>CDR must specify all these cases, since they may require different
|
|
handling, depending on the type of user interaction: pointing device
|
|
or joystick operation.</p></div><div class="div3">
|
|
<h4><a name="reqmt-crossnamespace-animations" id="reqmt-crossnamespace-animations"></a>3.1.15 CDR profiles MUST specify triggering of animations across namespaces.</h4><p>For example, if an XHTML document references an SVG document,
|
|
the profile MUST specify how an SVG animation can be triggered by
|
|
an XHTML event target.</p></div><div class="div3">
|
|
<h4><a name="reqmt-crossnamespace-fragmentIDs" id="reqmt-crossnamespace-fragmentIDs"></a>3.1.16 CDR MUST support fragment identifiers in cross-namespace
|
|
interaction</h4><p>In CDR, child documents within a parent document are referenced
|
|
with URI references. This URI reference must support also
|
|
so-called <a href="http://www.w3.org/TR/webarch/#fragid">fragment
|
|
identifiers</a>. Each fragment identifier is passed to the
|
|
component or plug-in that displays the child document, when the
|
|
documents are loaded. The handling of the fragment identifiers
|
|
depends on the MIME type of the child document.</p></div><div class="div3">
|
|
<h4><a name="reqmt-addingeventhandlers" id="reqmt-addingeventhandlers"></a>3.1.17 CDR profiles SHOULD provide a method for adding event
|
|
handlers using declarative markup for the formats it uses</h4><p>Event handlers contain instructions on how to react to certain
|
|
event. These can be written either using a scripting language or a
|
|
declarative (i.e., markup) language. The CDR specification should
|
|
provide a method to add event handlers both to parent and child
|
|
documents. If a CDR profile contains a markup language that
|
|
supports declarative event handlers then the CDR profile should
|
|
also support event handlers defined using markup.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-accessibility" id="reqmt-accessibility"></a>3.1.18 CDR documents MUST cater for accessibility requirements</h4><p>All CDR profiles must take accessibility requirements in
|
|
consideration. The <a href="http://www.w3.org/WAI/">Web
|
|
Accessibility Initiative</a> has defined Web Accessibility
|
|
Guidelines, which must be used when CDR profiles are developed. In
|
|
addition, markup language specific accessibility guidelines have
|
|
been defined in Techniques for Web Content Accessibility
|
|
Guidelines document. A CDR profile must support all the techniques
|
|
that are supported by the markup language modules included in
|
|
it. The same applies for the authoring tool accessibility
|
|
guidelines and the user agent accessibility guidelines.</p></div><div class="div3">
|
|
<h4><a name="reqmt-dynamicupdating" id="reqmt-dynamicupdating"></a>3.1.19 CDR documents MUST support dynamic updating</h4><p>Dynamic documents can be manipulated by scripts, etc. The user
|
|
interaction can fire events, which are caught by event
|
|
handlers. The event handlers can then manipulate the elements via
|
|
the DOM interface. These changes are then displayed to the
|
|
user. CDR documents must support dynamic updating across different
|
|
parent and child documents.</p></div><div class="div3">
|
|
<h4><a name="reqmt-transport" id="reqmt-transport"></a>3.1.20 CDR must define its integration into the Web
|
|
Architecture. It must include delivery over HTTP and should also
|
|
strive to be transport independent</h4><p>CDR profile documents must describe how they integrate into the
|
|
Web Architecture, particularly in the areas of media types and
|
|
transfer/transport protocols. It must be described how this works
|
|
with HTTP as well as other protocols typically used to transfer
|
|
Web content (e.g., RTP).</p></div><div class="div3">
|
|
<h4><a name="reqmt-compression" id="reqmt-compression"></a>3.1.21 CDR MUST NOT prevent compression of the data</h4><p>For efficiency, user agents and other renderers must support
|
|
served content that is compressed in whole or part.</p></div><div class="div3">
|
|
<h4><a name="reqmt-unified-key-handling-across-CD" id="reqmt-unified-key-handling-across-CD"></a>3.1.22 CDR MUST define the way soft-keys and accesskeys are handled across document components</h4><p>
|
|
For instance, what happens when there is a conflict between 2 accesskeys
|
|
which have the same value but are supposed to trigger different actions
|
|
in the parent and in the child documents.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-fonts" id="reqmt-fonts"></a>3.1.23 CDR User Agents MUST provide a default font for use by all components</h4><p>Standalone components or renderers, such as SVGT engines, do not
|
|
always provide a default system font.</p><p>A CDR User Agent, however, must at least provide one default system
|
|
font to all components, such as browsers, SVG engines and other renderers.</p><p>The CDR specification cannot mandate any particular font, nor font
|
|
technology. But it mandates the availability of 'a' default font, so
|
|
that content providers can print text in any component or render as
|
|
simply as this can be done in XHTML.</p><p>The default system font may be bitmap based, antialiased or a
|
|
vector font. Ideally, the same default system font should be used for
|
|
all components.</p>
|
|
<h5><a name="code-reqmt-fonts" id="code-reqmt-fonts"></a>The following SVG sample markup MUST generate visible text.</h5><table class="scrap" summary="Scrap"><tbody><tr><td><pre><svg ...>
|
|
<text x="20" y="20" font-size="normal" fill="#000">Sample Text</text>
|
|
</svg></pre></td></tr></tbody></table></div><div class="div3">
|
|
<h4><a name="reqmt-serversideadaptation" id="reqmt-serversideadaptation"></a>3.1.24 CDR MUST NOT prevent server-side adaptation</h4><p>Some animations could be too heavy for some terminals - or
|
|
could be too 'unsophisticated' for others.</p><p>Server side adaptation must therefore be possible in order to
|
|
support less capable devices. For example, it should be possible
|
|
for a server to determine the SVG capabilities of the device (such
|
|
as the rendering and animation capabilities.</p></div><div class="div3">
|
|
<h4><a name="reqmt-limitedbandwidth" id="reqmt-limitedbandwidth"></a>3.1.25 CDR MUST support limited bandwidth networks and limited
|
|
capability devices</h4><p>Small footprint and mobile devices often are connected to
|
|
mobile networks, characterized by comparatively low bandwidth
|
|
and/or high connection latency. Additionally, mobile networks may
|
|
charge users for data downloaded. It is therefore desirable to
|
|
ensure that this bandwidth is used optimally.</p><p>Authoring tools and/or systems serving CDR documents must be
|
|
able to use techniques to reduce size of materials transmitted and
|
|
the latency involved.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-document-confirmance-criteria" id="reqmt-document-confirmance-criteria"></a>3.1.26 CDR Profiles MUST define clear document conformance criteria</h4><p>CDR Profile specifications must define what kinds of documents are conformant and non-conformant.</p></div><div class="div3">
|
|
<h4><a name="reqmt-useragent-conformance-criteria" id="reqmt-useragent-conformance-criteria"></a>3.1.27 CDR Profiles MUST define clear user agent conformance criteria</h4><p>CDR Profile specifications must define conformance rules for user agents.</p></div><div class="div3">
|
|
<h4><a name="reqmt-currentLoadingStatus" id="reqmt-currentLoadingStatus"></a>3.1.28 CDR Profiles SHOULD provide a way to know the current loading status of a
|
|
referenced component</h4><p>Sometimes, one or several medias are needed before the end-user can
|
|
interact with a RichMedia application : for instance, a list of small
|
|
audio clips must be downloaded in an interactive game before the
|
|
end-user can start playing. Or some small audio clips must be downloaded
|
|
before the application can provide speech instructions in a navigation
|
|
system ("turn left", "turn right", ...). As a result, CDR should explain
|
|
a way to know whether a referenced component is currently loading, has
|
|
successfully been loaded or failed to be loaded and launch appropriate
|
|
actions accordingly.</p></div><div class="div3">
|
|
<h4><a name="reqmt-packaging-static" id="reqmt-packaging-static"></a>3.1.29 CDR MUST provide a solution for packaging of self-contained, static content</h4><p>Packaging is needed in order to support optimization of the
|
|
number of individual fetch operations that are required to
|
|
construct the final user experience on the device.</p></div><div class="div3">
|
|
<h4><a name="reqmt-packaging-streamed" id="reqmt-packaging-streamed"></a>3.1.30 CDR MAY provide a solution for packaging of streamed content</h4><p>In addition to <a href="#reqmt-packaging-static"><b>3.1.29 CDR MUST provide a solution for packaging of self-contained, static content</b></a>,
|
|
packaging of streams may be studied in order to accomodate audio
|
|
and video content.</p></div></div><div class="div2">
|
|
<h3><a name="rich_multimedia_content_requirements" id="rich_multimedia_content_requirements"></a>3.2 CDR Profile 1 Requirements (Rich Multimedia Content)</h3><p>The language profile combining XHTML, CSS and SVG according to the
|
|
CDR rules is referred to in this document as CDR Profile 1. This
|
|
section identifies the requirements specific for the use of XHTML as
|
|
the parent CDR Profile 1 document and SVG Tiny as the child
|
|
document. This profile supports presentation of rich multimedia
|
|
content, as defined in <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a>, and many of the
|
|
requirements herein are related to this definition. XHTML and SVG
|
|
have been chosen as the first profile for CDR according to analysis
|
|
of existing specifications and their applicability to rich
|
|
multimedia content: <a href="#relationships-with-other"><b>1.3 Relationships With Other Technologies</b></a></p><p>These requirements should be considered as additional
|
|
requirements to the applicable requirements specified in other
|
|
sections of the document.</p><div class="div3">
|
|
<h4><a name="reqmt-userinteractionmodel" id="reqmt-userinteractionmodel"></a>3.2.1 CDR Profile 1 MUST specify a user interaction model</h4><p>CDR Profile 1 must support a clear user interaction model between
|
|
components (event/focus management). Interactivity between
|
|
components will help to provide a seamless and compelling user
|
|
experience of documents which combine XHTML and media
|
|
elements.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-useragentidentifies" id="reqmt-useragentidentifies"></a>3.2.2 CDR Profile 1 MUST explain how a User Agent is able to identify a CDR Profile 1 document</h4><p>CDR Profile 1 content (that is, content which confirms to a language
|
|
profile built using the CDR Profile 1 specification) will be unambiguously
|
|
identified as conforming to that language profile.</p><p>Content creators and viewer implementations will both better be
|
|
able to meet the conformance requirements of the CDR
|
|
specifications if such content can be unambiguously identified.
|
|
Use of a specific mime type will furthermore (through the use of
|
|
accept headers) allow servers to perform a simple check on whether
|
|
a suitable client is available.</p></div><div class="div3">
|
|
<h4><a name="reqmt-scalablegraphics" id="reqmt-scalablegraphics"></a>3.2.3 CDR Profile 1 MUST support 2D scalable vector graphics</h4><p>
|
|
2D Scalable vector graphics are required in order to easily deploy the
|
|
same user interface onto multiple devices with different screen
|
|
sizes / shapes and resolutions.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-audio" id="reqmt-audio"></a>3.2.4 CDR Profile 1 MUST support audio</h4><p>User agents must support the ability to play audio while rendering content. For example, a rendered document may choose to play music while the document is displayed.</p></div><div class="div3">
|
|
<h4><a name="reqmt-video" id="reqmt-video"></a>3.2.5 CDR Profile 1 SHOULD support video</h4><p>User agents should support the ability to play video while rendering content. For example, a rendered document may choose to play a video clip while the document is displayed.</p></div><div class="div3">
|
|
<h4><a name="reqmt-layouts" id="reqmt-layouts"></a>3.2.6 CDR Profile 1 MUST support grid, flow, overlapping layouts</h4><p>In order to create rich content document, content authors need the
|
|
ability to position and layout information items or user interface
|
|
components. This is crucial authoring feature which also allows content
|
|
to adapt to different screen sizes and aspect ratio. Layout is a
|
|
complement to the scalable nature to formats such as SVG. In CDR Profile
|
|
1, grid and flow layouts MUST be supported. Overlapping layout, i.e.,
|
|
the ability to layout component that overlap completely or partially,
|
|
MUST also be supported.</p></div><div class="div3">
|
|
<h4><a name="reqmt-transparency" id="reqmt-transparency"></a>3.2.7 CDR Profile 1 MUST support SVG backgrounds</h4><p>A CDR user agent MUST support static SVG background images and
|
|
MAY support animated or scripted SVG background images. Authors
|
|
however should not assume that the latter functionality will be
|
|
available.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-transparency2" id="reqmt-transparency2"></a>3.2.8 CDR Profile 1 MAY support XHTML backgrounds</h4><p>A CDR user agent MAY support compositing above an XHTML document defined as a background image.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-identificationofmarkup" id="reqmt-identificationofmarkup"></a>3.2.9 CDR Profile 1 MUST support identification of markup and versions in CDF documents</h4><p>CDR Profile 1 must provide a mechanism for uniquely identifying the
|
|
markups and versions used in a particular CDF documents. Ensure
|
|
that this information can be used in content negotiation.
|
|
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-scalablediagrams" id="reqmt-scalablediagrams"></a>3.2.10 CDR Profile 1 MUST support scalable diagrams that can be animated
|
|
and can cause link traversal</h4><p>An example of usage is the implementation of buttons which render
|
|
their own visual feedback (animated buttons for
|
|
navigation). These will provide a scalable alternative to the
|
|
use of images as the source of links that can be
|
|
traversed. These should be allowed to contain animation, but
|
|
not rich interaction.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-xhtmlplussvg" id="reqmt-xhtmlplussvg"></a>3.2.11 CDR Profile 1 MUST define how to reference SVGT graphics and resources
|
|
from an XHTML document</h4><p>A compound document by reference is defined as one root or
|
|
parent document that makes a reference to separate child
|
|
documents. Compound Document profiles that include SVG Tiny as
|
|
referenced documents from XHTML must define how to reference the
|
|
separate SVG Tiny graphics and resources.</p></div><div class="div3">
|
|
<h4><a name="reqmt-advertisingsvg" id="reqmt-advertisingsvg"></a>3.2.12 CDR Profile 1 MUST support advertising the specific supported versions
|
|
of formats and capabilities in headers</h4><p>When a user agent makes a request for content, it must identify
|
|
the content types it can support. This is done by specifying the
|
|
mime-type, version, and profile information, for each supported
|
|
type of content, in the request. Using HTTP, this can be done by
|
|
either using the HTTP ACCEPTS header or the UAProf.</p></div><div class="div3">
|
|
<h4><a name="reqmt-XHTMLasroot" id="reqmt-XHTMLasroot"></a>3.2.13 CDR Profile 1 MUST support XHTML as a root/host language</h4><p>However it is not necessarily the only root hosting language.</p></div><div class="div3">
|
|
<h4><a name="reqmt-XHTMLobjectelement" id="reqmt-XHTMLobjectelement"></a>3.2.14 The XHTML <object> element MUST be used for referring to
|
|
other formats from XHTML</h4><p>It is desirable to achieve the goal of embedding media and
|
|
other objects into XHTML documents by using the existing
|
|
<object> element rather than extending XHTML. The XHTML
|
|
<object> element will be the method by which XML document types
|
|
will be referenced from XHTML documents.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-xhtmlsvginteractionmodel" id="reqmt-xhtmlsvginteractionmodel"></a>3.2.15 CDR Profile 1 MUST define the interaction model for an SVG
|
|
document referenced by an XHTML document</h4><p>To ensure interoperability, it is important that the CDR Profile 1
|
|
specification defines the interaction model for SVG documents referenced
|
|
by XHTML documents. For example, the interaction model must define if
|
|
and how interaction with an SVG document requires activation, or if
|
|
activation is optional, how activation is controlled. By the same token,
|
|
the interaction model should define the precedence rules between the SVG
|
|
content and the referencing XHTML document, for example regarding
|
|
hyperlinking: if an XHTML <object> is enclosed in an <a> element and the
|
|
<object> references an SVG document which itself displays anchors, what
|
|
is the behavior when clicking over one of the anchors in the SVG element?</p></div><div class="div3">
|
|
<h4><a name="reqmt-animatedSVGicons" id="reqmt-animatedSVGicons"></a>3.2.16 CDR Profile 1 MUST define for animated SVG icons to act like HTML
|
|
images (no need for interactivity, links, zoom and pan)</h4><p>
|
|
When used as background images, it is complex and most often irrelevant to
|
|
provide interaction, such as zooming, panning, linking and mouse events
|
|
processing, with the SVG graphics. However, animation makes senses in that
|
|
it can provide decorative value.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-focusevents" id="reqmt-focusevents"></a>3.2.17 CDR Profile 1 MUST define a way for events to trigger SVG
|
|
animation</h4><p>This is required in order to support pleasing
|
|
button animation on select and activate events, such as focus
|
|
events, beyond the current "on/off" capability in
|
|
CSS</p></div><div class="div3">
|
|
<h4><a name="reqmt-realestatenegotiation" id="reqmt-realestatenegotiation"></a>3.2.18 CDR Profile 1 MUST define the process for real-estate negotiation
|
|
between an XHTML document and a referenced SVG document</h4><p>CDR Profile 1 will provide comprehensive, mandatory rules that
|
|
specify how document components from different XML vocabularies are
|
|
scaled when they occur within other components
|
|
(right-sizing). Support the ability for relative size measures
|
|
to be used by authors. Ensure that rules define the behavior
|
|
when fixed and relative sized components are used together
|
|
within a single document. Ensure that the rules define the
|
|
behavior associated with areas of the containing component
|
|
not filled by the contained component. Thus, it will be
|
|
possible to create truly screen size-independent content.
|
|
</p></div><div class="div3">
|
|
<h4><a name="reqmt-leftovers" id="reqmt-leftovers"></a>3.2.19 CDR Profile 1 MUST define handling of leftover SVG area</h4><p>Rendering SVG content in a fixed-sized area often
|
|
results in visible areas outside of the SVG viewbox. How these areas
|
|
are filled must be defined.</p></div><div class="div3">
|
|
<h4><a name="reqmt-systemfontsupport" id="reqmt-systemfontsupport"></a>3.2.20 CDR Profile 1 MUST define system font support in SVG</h4><p>SVGT does not mandate system fonts, but in the context of a
|
|
user agent, highly optimized system fonts are available. On many
|
|
devices (when executed in the context of a user agent), highly
|
|
optimized fonts are available. </p><p>It is therefore necessary to make highly optimized terminal
|
|
fonts (used by the user agent) available to SVG as system fonts and
|
|
to support the ability for common font sets to be used
|
|
throughout the combined document. In particular, platform fonts
|
|
should be able to be used if supported, with support font fall-back
|
|
mechanisms to provide defaults in the event that chosen fonts
|
|
are unavailable. The SVG <text> element should always display
|
|
something as long as it is within the viewport.</p><p>Related to CDR requirement: <a href="#reqmt-fonts"><b>3.1.23 CDR User Agents MUST provide a default font for use by all components</b></a>.</p></div><div class="div3">
|
|
<h4><a name="reqmt-temportal-start-and-stop" id="reqmt-temportal-start-and-stop"></a>3.2.21 CDR Profile 1 SHOULD provide temporal synchronization with dynamic media</h4><p>The Profile should be able to synchronize events with the start and end of playback of dynamic media objects, such as a video or audio stream.</p></div><div class="div3">
|
|
<h4><a name="reqmt-stop-and-start-media" id="reqmt-stop-and-start-media"></a>3.2.22 CDR Profile 1 MAY provide functionality to stop and start media objects</h4><p>The profile may include mechanisms to start playback of dynamic content (from the start of a stream) and to stop playback (with automatic rewind).</p></div><div class="div3">
|
|
<h4><a name="reqmt-unifiedrendering" id="reqmt-unifiedrendering"></a>3.2.23 CDR Profile 1 MUST support a unified rendering and processing model</h4><p>Ensure that rendering is consistent across all components of a
|
|
CDR Profile 1 document. In particular, ensure that there are suitable
|
|
rules that define how z-ordering applies between different
|
|
components which may overlay one another. Also ensure that there
|
|
are rules that define how transparency is handled when components
|
|
overlay one another. CSS z-ordering may provide a mechanism for
|
|
controlling this.</p></div><div class="div3">
|
|
<h4><a name="reqmt-animationOnLoad" id="reqmt-animationOnLoad"></a>3.2.24 CDR Profile 1 SHOULD provide a way to play an animation while some
|
|
referenced components of the Combined Document are loading</h4><p>The profile should define mechanisms allowing to play an animation while
|
|
one or several parts of the combined document are loading. For instance,
|
|
this can be a progress bar informing the end-user about the loading
|
|
progress or an advertising which plays while some audio/video content is
|
|
being fetched.</p></div><div class="div3">
|
|
<h4><a name="reqmt-audiomixing" id="reqmt-audiomixing"></a>3.2.25 CDR Profile 1 MUST specify the behavior of audio mixing</h4><p>CDR Profile 1 must specify how user agents behave when multiple
|
|
audio streams are played simultaneously within a compound
|
|
document.</p></div></div></div></div><div class="back"><div class="div1">
|
|
<h2><a name="references" id="references"></a>A References (Non-Normative)</h2></div><div class="div1">
|
|
<h2><a name="acknowledgements" id="acknowledgements"></a>B Acknowledgements (Non-Normative)</h2><p>The editors would like to thank the contributors:</p><blockquote><p>Jon Ferraiolo, Adobe<br />Vincent Hardy (Working Group Chair), Sun Microsystems Inc.
|
|
<br />Scott Hayman, RIM<br />Dean Jackson (Working Group Team Contact), W3C<br />Kevin Kelly, IBM<br />Lasse Pajunen, Nokia<br />Peter Stark, Sony Ericsson<br />Petri Vuorimaa, Helsinki University of Technology</p></blockquote></div><div class="div1">
|
|
<h2><a name="changes-log" id="changes-log"></a>C Changes Log (Non-Normative)</h2><ul><li><p>20050630</p><ul><li><p>Removed the now conflicting 'reqmt-packaging' (TM)</p></li><li><p>Added (in place, so that numbering does not change) <a href="#reqmt-unified-key-handling-across-CD"><b>3.1.22 CDR MUST define the way soft-keys and accesskeys are handled across document components</b></a> (TM)</p></li></ul></li><li><p>20050518</p><ul><li><p>Added <a href="#reqmt-packaging-static"><b>3.1.29 CDR MUST provide a solution for packaging of self-contained, static content</b></a> and <a href="#reqmt-packaging-streamed"><b>3.1.30 CDR MAY provide a solution for packaging of streamed content</b></a> (DKA)</p></li></ul></li><li><p>20050517</p><ul><li><p>Added <a href="#reqmt-audiomixing"><b>3.2.25 CDR Profile 1 MUST specify the behavior of audio mixing</b></a> requirement on audio mixing (DKA)</p></li></ul></li><li><p>20050504:</p><ul><li><p>Added <a href="#reqmt-currentLoadingStatus"><b>3.1.28 CDR Profiles SHOULD provide a way to know the current loading status of a
|
|
referenced component</b></a> based on comments from Vincent Mahe (TM)</p></li><li><p>Added <a href="#reqmt-animationOnLoad"><b>3.2.24 CDR Profile 1 SHOULD provide a way to play an animation while some
|
|
referenced components of the Combined Document are loading</b></a> based on comments from Vincent Mahe (TM)</p></li></ul></li><li><p>20050403:</p><ul><li><p>Fixed two wording bugs based on comments from Vincent Mahe (TM)</p></li><li><p>Added comment about pre-defined object parameters/values to <a href="#reqmt-elementused"><b>3.1.5 CDR MUST specify, for each format, the element used to
|
|
reference other formats, if any.</b></a> based on comments from Vincent Mahe (TM)</p></li><li><p>Fixed example <a href="#usecase-animated-svg-icons"><b>2.6.2 Animated SVG icons in HTML menu</b></a> to use object instead of img element to embed SVG (TM)</p></li></ul></li><li><p>20050401:</p><ul><li><p>Changed examples to use <scrap> element (DKA)</p></li><li><p>Integrated Vincent's comments (DKA)</p></li><li><p>Fixed up table with input from Vincent, Jon and Petri (DKA)</p></li></ul></li><li><p>20050327:</p><ul><li><p>Moved table to <a href="#rich_multimedia_content_definition"><b>1.2 Definition of Rich Multimedia Content</b></a> (DKA)</p></li><li><p>Added <a href="#reqmt-video"><b>3.2.5 CDR Profile 1 SHOULD support video</b></a> (DKA)</p></li></ul></li><li><p>20050327:</p><ul><li><p>20050326:</p><ul><li><p>Rephrased 3 items based on feedback from Lasse, Brad and Vincent (TM)</p></li><li><p>Changed <a href="#reqmt-link-activation"><b>3.1.14 CDR profiles MUST specify how link activation work with
|
|
referenced document.</b></a> to list 3 cases</p></li><li><p>Changed <a href="#reqmt-fonts"><b>3.1.23 CDR User Agents MUST provide a default font for use by all components</b></a> to prevent the word 'sharing' - making clear that no change to HTML/CSS rendering is required</p></li><li><p>Changed <a href="#reqmt-exploitexisting"><b>3.1.1 CDR MUST exploit existing specifications, favoring W3C
|
|
specifications wherever possible and limit the definition of new
|
|
markup unless absolutely required for integration purposes</b></a>.</p></li></ul></li><li><p>20050325:</p><ul><li><p>Removed many references to "namespace" / normalized usage. (DKA)</p></li><li><p>Added use cases from Lasse (LP/DKA)</p></li><li><p>Changed <a href="#reqmt-genericintegrationtechniques"><b>3.1.6 CDR MUST specify generic integration techniques</b></a> to a must. (DKA)</p></li><li><p>Changed <a href="#reqmt-compression"><b>3.1.21 CDR MUST NOT prevent compression of the data</b></a> and 'reqmt-packaging'/> to "MUST NOT prevent"</p></li><li><p>Changed <a href="#reqmt-serversideadaptation"><b>3.1.24 CDR MUST NOT prevent server-side adaptation</b></a> to a MUST NOT prevent</p></li><li><p>Moved <a href="#reqmt-unifiedrendering"><b>3.2.23 CDR Profile 1 MUST support a unified rendering and processing model</b></a> to the Profile 1 section</p></li></ul></li><li><p>20050321:</p><ul><li><p>Added new intro text from Vincent. (VH/DKA)</p></li></ul></li><li><p>20050304:</p><ul><li><p>Removed references to trademarked names. (DKA)</p></li><li><p>Added text to "who will implement" section (JF/DKA)</p></li><li><p>Added navigation use cases (PS/DKA)</p></li></ul></li><li><p>20050303:</p><ul><li><p>Changed browser to user agent throughout (DKA)</p></li><li><p>Added many contributions (VH/LP/SH/KK/DKA)</p></li><li><p>Moved table, rewrote intros, etc... (DKA)</p></li></ul></li><li><p>20050301:</p><ul><li><p>Added terms to terms section. (LP/DKA)</p></li></ul></li><li><p>20050228:</p><ul><li><p>Added "terms" seciton to intro. (DKA)</p></li><li><p>Changed WP1 to CDR Profile 1. (DKA)</p></li><li><p>Moved "who will implement" subsection to intro. (DKA)</p></li><li><p>Removed "intelligent documents" use case. (DKA)</p></li><li><p>Added intro text to use case section. (VH/DKA)</p></li><li><p>Simplified requirements into two flat sections (DKA)</p></li><li><p>Added definitions of terms from Lasse (DKA/LP)</p></li></ul></li><li><p>20050221:</p><ul><li><p>Made many changes based on JCD's suggestions on the list (and resolution of issue 4) (DKA)</p></li><li><p>Added necessary text as per Issue 27.</p></li></ul></li><li><p>20050218:</p><ul><li><p>Added intermediary type to <a href="#who_what_will_implement_the_specification">discussion of possible implementors</a></p></li><li><p>Added text for <a href="#reqmt-dynamicupdating">reqmt-crossnamespace-mimetypes</a>,
|
|
<a href="#reqmt-dynamicupdating">reqmt-crossnamespace-fragmentIDs</a>,
|
|
<a href="#reqmt-dynamicupdating">reqmt-addingeventhandlers</a>, <a href="#reqmt-dynamicupdating">reqmt-accessibility</a>,
|
|
<a href="#reqmt-dynamicupdating">reqmt-dynamicupdating</a>
|
|
(DKA, PV)</p></li><li><p>Added text to and re-ordered <a href="#reqmt-eventscrossnamespace"><b>3.1.8 CDR MUST support event mechanisms that cross namespace boundaries</b></a>(DKA, VH)</p></li><li><p>Added text to <a href="#reqmt-crossnamespace-animations">animations
|
|
crossing namespaces requirement</a>. (DKA, VH)</p></li></ul></li><li><p>20050217:</p><ul><li><p>Changes relating to resolution of issue-5 (making
|
|
HTML background images a "may") (DKA)</p></li><li><p>Minor reformatting and text changes (DKA)</p></li><li><p>Added text for 3.3.3 - 3.4.1.1 (DKA, SH)</p></li><li><p>Changed CDR references to WP1 in section describing WP1 (DKA)</p></li></ul></li><li><p>20050215:</p><ul><li><p>Checked spelling</p></li><li><p>Moved some explanatory text from requirement names into
|
|
descriptions</p></li><li><p>Reformated many items to remove [description],
|
|
etc... structure and make requirements into freeform
|
|
paragraphs. In the process, tightened up a lot of
|
|
descriptions. (DKA)</p></li><li><p>Reformated a lot of white space (DKA).</p></li></ul></li><li><p>
|
|
20050204 (2nd pass):
|
|
</p><ul><li><p>Removed spurious attributes in table (DKA)</p></li></ul></li><li><p>
|
|
20050204:
|
|
</p><ul><li><p>Changed status (DKA)</p></li><li><p>Rewrote some intro text for clarity (DKA)</p></li><li><p>Fixed up syntax and adherence to xmlspec schema (DKA)</p></li></ul></li><li><p>
|
|
20050127 (3rd pass):
|
|
</p><ul><li><p>Added text to requirements (DKA)</p></li></ul></li><li><p>
|
|
20050127 (2nd pass):
|
|
</p><ul><li><p>Added IDs to use cases (DKA)</p></li><li><p>Added IDs to requirements (DKA)</p></li><li><p>Added text to "Idle screen" use case (DKA)</p></li><li><p>Removed constraining structure of use cases (AQ)</p></li><li><p>Enhanced "Interactive News Service" use case (AQ)</p></li><li><p>Added description to "Document viewing" use case (AQ)</p></li><li><p>Added description to "Reservation system" use cases (AQ)</p></li><li><p>Added examples to "Web Publishing and Broadcasting" use cases (AQ)</p></li></ul></li><li><p>
|
|
20050127:
|
|
</p><ul><li><p>Added introduction from Lasse (DKA)</p></li></ul></li><li><p>
|
|
20050126 (2nd pass):
|
|
</p><ul><li><p>Updated verbiage to "CDR MUST support limited bandwidth networks and limited capability devices" (DKA)</p></li><li><p>Updated verbiage to "The XHTML <object> tag MUST be used for combining formats" (DKA)</p></li><li><p>Updated verbiage to "CDR MUST support user interaction model" (DKA)</p></li><li><p>Updated verbiage to "CDR MUST specify how User Agent is able to identify a CDR document" (DKA)</p></li><li><p>Rephrased requirement from "CDR MUST leverage existing W3C Specifications" to "CDR MUST exploit existing specifications, favoring W3C specifications wherever possible" and added verbiage (DKA)</p></li></ul></li><li><p>
|
|
|
|
20041214:
|
|
</p><ul><li><p>Added XSLT PI so that source file can be seen as transformed XHTML within the browser (AQ)</p></li></ul></li><li><p>
|
|
20041130:
|
|
</p><ul><li><p>Set up new document structure (3.2 High-Level Requirements, 3.3 Rich Multimedia Content Requirements, 3.4 Formats Requirements, 3.5 Specific Combinations Requirements, 3.6 Authoring, delivery and deployment Requirements) (TM)</p></li></ul></li><li><p>
|
|
|
|
20041122:
|
|
</p><ul><li><p>Set up basic document (TM+AQ)</p></li><li><p>First draft of use cases and requirments based on Sophia F2F minutes (TM+AQ)</p></li></ul></li></ul></li></ul></div></div></body></html>
|