All the requirements collected by this WG
are listed in the following sections.
3.1 High-Level Requirements
These are general requirements for the Compound Documents by
Reference (CDR) specification.
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
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.
3.1.2 CDR MUST provide the ability for content developers to describe
or author rich media content define Rich Multimedia Content
Rich Multimedia Content is defined in 1.2 Definition of Rich Multimedia Content.
3.1.3 CDR MUST specify a base set of formats, corresponding
profiles and versions
Conformant implementations MUST support this base set.
3.1.4 Each CDR profile and version MUST specify, which formats can be referenced
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.
3.1.5 CDR MUST specify, for each format, the element used to
reference other formats, if any.
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.
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:
<param name="Volume" value="50" />
<param name="Mute" value="false" />
<param name="amination" value="onfocusevent" />
|
3.1.6 CDR MUST specify generic integration techniques
These are techniques that will be applicable
beyond the set of formats, versions and profiles required by the
CDR spec.
3.1.7
CDR MUST support temporal synchronization of dynamic content
coming from multiple references, possibly with multiple
references to the same source.
Support the synchronization of multiple instances of
dynamic content, such as animations, audio and video, within a
single compound document.
3.1.8 CDR MUST support event mechanisms that cross namespace boundaries
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.
3.1.9 CDR MUST support scriptability
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.
3.1.10 CDR MUST say the allowed nesting level of referencing
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.
3.1.11 CDR MUST explain how scripting interacts between components and the parent document
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.
3.1.12 CDR profiles MUST specify how event propagation works
across namespace boundaries.
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?
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 DOM Level 3 event
model.
3.1.13 CDR profiles MUST specify how focus traversal works with
referenced documents.
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?
3.1.14 CDR profiles MUST specify how link activation work with
referenced document.
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.
In addition, a referenced object may draw it's own visual
feedback for focus activation and/or mouse-over.
CDR must specify all these cases, since they may require different
handling, depending on the type of user interaction: pointing device
or joystick operation.
3.1.15 CDR profiles MUST specify triggering of animations across namespaces.
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.
3.1.16 CDR MUST support fragment identifiers in cross-namespace
interaction
In CDR, child documents within a parent document are referenced
with URI references. This URI reference must support also
so-called fragment
identifiers. 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.
3.1.17 CDR profiles SHOULD provide a method for adding event
handlers using declarative markup for the formats it uses
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.
3.1.18 CDR documents MUST cater for accessibility requirements
All CDR profiles must take accessibility requirements in
consideration. The Web
Accessibility Initiative 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.
3.1.19 CDR documents MUST support dynamic updating
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.
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
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).
3.1.21 CDR MUST NOT prevent compression of the data
For efficiency, user agents and other renderers must support
served content that is compressed in whole or part.
3.1.22 CDR MUST define the way soft-keys and accesskeys are handled across document components
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.
3.1.23 CDR User Agents MUST provide a default font for use by all components
Standalone components or renderers, such as SVGT engines, do not
always provide a default system font.
A CDR User Agent, however, must at least provide one default system
font to all components, such as browsers, SVG engines and other renderers.
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.
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.
The following SVG sample markup MUST generate visible text.
<svg ...>
<text x="20" y="20" font-size="normal" fill="#000">Sample Text</text>
</svg> |
3.1.24 CDR MUST NOT prevent server-side adaptation
Some animations could be too heavy for some terminals - or
could be too 'unsophisticated' for others.
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.
3.1.25 CDR MUST support limited bandwidth networks and limited
capability devices
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.
Authoring tools and/or systems serving CDR documents must be
able to use techniques to reduce size of materials transmitted and
the latency involved.
3.1.26 CDR Profiles MUST define clear document conformance criteria
CDR Profile specifications must define what kinds of documents are conformant and non-conformant.
3.1.27 CDR Profiles MUST define clear user agent conformance criteria
CDR Profile specifications must define conformance rules for user agents.
3.1.28 CDR Profiles SHOULD provide a way to know the current loading status of a
referenced component
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.
3.1.29 CDR MUST provide a solution for packaging of self-contained, static content
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.
3.2 CDR Profile 1 Requirements (Rich Multimedia Content)
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 1.2 Definition of Rich Multimedia Content, 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: 1.3 Relationships With Other Technologies
These requirements should be considered as additional
requirements to the applicable requirements specified in other
sections of the document.
3.2.1 CDR Profile 1 MUST specify a user interaction model
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.
3.2.2 CDR Profile 1 MUST explain how a User Agent is able to identify a CDR Profile 1 document
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.
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.
3.2.3 CDR Profile 1 MUST support 2D scalable vector graphics
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.
3.2.4 CDR Profile 1 MUST support audio
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.
3.2.5 CDR Profile 1 SHOULD support video
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.
3.2.6 CDR Profile 1 MUST support grid, flow, overlapping layouts
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.
3.2.7 CDR Profile 1 MUST support SVG backgrounds
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.
3.2.8 CDR Profile 1 MAY support XHTML backgrounds
A CDR user agent MAY support compositing above an XHTML document defined as a background image.
3.2.9 CDR Profile 1 MUST support identification of markup and versions in CDF documents
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.
3.2.10 CDR Profile 1 MUST support scalable diagrams that can be animated
and can cause link traversal
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.
3.2.11 CDR Profile 1 MUST define how to reference SVGT graphics and resources
from an XHTML document
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.
3.2.12 CDR Profile 1 MUST support advertising the specific supported versions
of formats and capabilities in headers
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.
3.2.13 CDR Profile 1 MUST support XHTML as a root/host language
However it is not necessarily the only root hosting language.
3.2.14 The XHTML <object> element MUST be used for referring to
other formats from XHTML
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.
3.2.15 CDR Profile 1 MUST define the interaction model for an SVG
document referenced by an XHTML document
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?
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)
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.
3.2.17 CDR Profile 1 MUST define a way for events to trigger SVG
animation
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
3.2.18 CDR Profile 1 MUST define the process for real-estate negotiation
between an XHTML document and a referenced SVG document
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.
3.2.19 CDR Profile 1 MUST define handling of leftover SVG area
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.
3.2.20 CDR Profile 1 MUST define system font support in SVG
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.
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.
Related to CDR requirement: 3.1.23 CDR User Agents MUST provide a default font for use by all components.
3.2.21 CDR Profile 1 SHOULD provide temporal synchronization with dynamic media
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.
3.2.22 CDR Profile 1 MAY provide functionality to stop and start media objects
The profile may include mechanisms to start playback of dynamic content (from the start of a stream) and to stop playback (with automatic rewind).
3.2.23 CDR Profile 1 MUST support a unified rendering and processing model
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.
3.2.24 CDR Profile 1 SHOULD provide a way to play an animation while some
referenced components of the Combined Document are loading
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.
3.2.25 CDR Profile 1 MUST specify the behavior of audio mixing
CDR Profile 1 must specify how user agents behave when multiple
audio streams are played simultaneously within a compound
document.