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
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 SHOULD NOT define 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.4 CDR MUST specify a base set of formats, corresponding
profiles and versions
Comformant implementations MUST support this base set.
3.1.5 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.6 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.
3.1.7 CDR MAY 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.8
CDR MUST support temporal synchronisation of dynamic content
coming from multiple references, possibly with multiple
references to the same source.
Support the synchronisation of multiple instances of
dynamic content, such as animations, audio and video, within a
single compound document.
3.1.9 CDR MUST ensure that user agent controls work consistently
regardless of the component that has focus
Support every namespace in the compound document as a
first class component.
3.1.10 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 behaviour
when events are passed across namespace boundaries.
3.1.11 CDR MUST support scriptability
CDR 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.12 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.13 CDR MUST explain how scripting interacts between components and the host document
CDF 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.14 CDR MUST explain which events get dispatched to the referenced document
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?
3.1.15 CDR profiles MUST define how eventing (such as events, focus
or links) work across namespaces
With CDR profiles, documents in different namespaces can
reference each other. The CDR profiles MUST specify multiple
issues related to event propagation and handling.
3.1.16 CDR profiles MUST specify how event propagation works
across namespace boundaries.
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.17 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.18 CDR profiles MUST specify how link activation work with
referenced document.
For example, if an XHTML anchor contains an reference to an SVG
document which, itself, contains anchors, CDR profiles must
specify which anchor takes precedence when the SVG document is
moused-over (assuming a pointer interaction) or equivalently
activated.
3.1.19 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.20 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.21 CDR MUST support a unified rendering model
Ensure that rendering is consistent across all components of a
compound 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.1.22 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.23 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.24 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.25 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.26 CDR MUST allow compression of the data
For efficiency, user agents and other renderers must support
served content that is compressed in whole or part.
3.1.27 CDR MUST allow packaging of the data
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 (this is about
multipart/mixed).
3.1.28 CDR MUST define the sharing of fonts among all components of a document
Every platform and device user agent, browser, or renderer
behaves differently with respect to client provided fonts. Some
have bitmap fonts and others have font engines that can produce
vector fonts. Some provide access to these fonts, and others do
not.
User agents, browsers and renderers must provide the possibility to
use system fonts by components within documents if available and
accessible. Since a resident system font cannot always be guaranteed,
user agents must include a default font for use by components within
the document when a font is required.
3.1.29 CDR MUST support 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. In particular provide a means by
which the SVG capabilities of the device can be communicated to
the server. (for instance the rendering and animation capabilities
in form of an index).
3.1.30 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.2 CDR Profile 1 Requirements (Rich Multimedia Content)
The language profile combining XHTML 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 support 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 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 scalable graphics
Scalable 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 music play while the document is displayed.
3.2.5 CDR Profile 1 MUST support grid, flow, overlapping layouts
In order to create rich content document, content authors need to
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.6 CDR Profile 1 MUST define transparency support for 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.7 CDR Profile 1 MAY define transparency support for XHTML backgrounds
XHTML background images may be supported.
3.2.8 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.9 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.10 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 another separate child
document(s). 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.11 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.12 CDR Profile 1 MUST support XHTML as a root/host language
However it is not necessarily the only root hosting language.
3.2.13 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.14 CDR Profile 1 MUST support Non-interactive Background SVG
This allows for scalable (one size fits all) background images.
3.2.15 CDR Profile 1 MUST define for animated SVG icons to act like HTML
images (no need for interactivity, links, zoom and pan)
Zooming into a scalable image makes sense only if it was
enlarged to the full screen-view before. Enable SVG to be used as
an alternative to images. Icon mode so not interactive. Gives
animation. Gives scalability. Icon mode includes any fixed diagram
- no animation, but can be the subject of a link. (zoom and pan is
not required for icon-mode SVG's, but for full view SVG's.)
3.2.16 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.17 CDR Profile 1 MUST define how an XHTML document can reference an SVG Tiny document
CDR Profile 1 must specify how an XHTML document can refer to an SVG Tiny document such that the SVG Tiny document is rendered as a child document of the parent XHTML document.
3.2.18 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.19 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 namespaces 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 behaviour
when fixed and relative sized components are used together
within a single document. Ensure that the rules define the
behaviour 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.20 CDR Profile 1 MUST define handling of leftover SVG area
Rendering SVG in a destination box that is fixed will usually
end up in areas outside the SVG viewbox to become visible. These
areas may be filled by the SVG (child) object.
3.2.21 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.28 CDR MUST define the sharing of fonts among all components of a document.