Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Compound document is the W3C term for a document that combines multiple formats, such as XHTML, SVG, SMIL and XForms. When combining separate 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. This document specifies integration of existing markup formats in preference to inventing new markup.
This document specifies the first two Compound Document profiles - WICD Mobile and WICD Desktop - and consists of four main sections:
This section describes generic rules and behaviour for combining sets of standalone XML formats.
WICD stands for Web Integration Compound Document. WICD Core describes rules for combining Hypertext Markup Language (XHTML) and scalable child objects, such as Scalable Vector Graphics (SVG). WICD Core is designed to address the needs of rich multimedia content in non device specific manner. WICD Core builds upon CDF.
WICD Mobile is based on XHTML Mobile Profile and SVG Tiny 1.2 and is designed to enable rich multimedia content on mobile handset devices. It may also be appropriate for other handheld devices. However, WICD Mobile is aimed at mass marked, one hand operation devices, and is supposed to enables publishers to target these type of devices without having to do user agent ID evaluation. In this profile, child objects are embedded by reference (CDR = Compound Document by Reference). WICD Mobile builds upon WICD Core.
WICD Desktop is designed to enable rich multimedia content on desktop type agents. It may also be appropriate for high capability handheld devices. This profile is based on XHTML and SVG 1.2 (full). In this profile, child objects are embedded by reference (CDR). WICD Desktop builds upon WICD Core.
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 W3C technical reports index at http://www.w3.org/TR/.
This is the 9 August 2005 W3C Working Draft of the Compound Document Framework specification, the first public Working Draft of this document. Many sections are incomplete and marked as requiring more work. It is intended to provide the reader with an understanding of the approach that will be taken in future drafts. We expect a new draft to replace this Working Draft in September 2005.
The Compound Document Formats Working Group explicitly requests comments on this specification. Please send them to public-cdf@w3.org, the public email list for issues related to compound documents on the Web. This list is archived and acceptance of this archiving policy is requested automatically upon first post. To subscribe to this list send an email to public-cdf-request@w3.org with the word subscribe in the subject line.
This document has been produced by the Compound Document Formats Working Group as part of the Compound Document Formats Activity within the W3C Interaction Domain.
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
Per section 4 of the W3C Patent Policy, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.
Publication as a Working Draft 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.
1 Compound Document Framework 1.0
1.1 Introduction
1.2 Techniques for Combining Documents
1.2.1 Reference and Inclusion
1.2.2 Layout
1.2.3 Events
1.2.4 Document Object Model
1.2.5 Link Activation
1.2.6 Referencing child objects
1.3 Security Considerations
2 WICD Core 1.0
2.1 Introduction
2.2 Child Object Use Cases
2.2.1 Scalable Foreground Icon Object
2.2.2 Scalable Background Image
2.2.3 Scalable Overlay Object (Sprite)
2.3 Child Object Formats
2.3.1 SVG
2.3.2 Audio
2.3.3 Video
2.4 Child Object Layout
2.4.1 Rightsizing
2.4.2 Leftover Margins
2.4.3 Transparency
2.5 Focus Support
2.5.1 Focus Navigation (linear 2-way, tab/shiftTab)
2.5.2 Focus Navigation (graphical 4-way/8-way)
2.5.3 Focus Event triggered Child Object Animations
2.6 Font Support
2.6.1 System Fonts
2.6.2 Font Naming
2.6.3 Font Sharing
2.7 Packaging and Encoding
2.7.1 Content Encoding
2.7.2 Content Packaging
2.8 Other User Agent Behavior
2.8.1 Temporal Synchronisation of Media
2.8.2 Play Animations while Document is loading
2.8.3 Caching Directives
2.9 Events
2.9.1 XHTML legacy event attributes
2.9.2 Attaching Events to Compound Documents
3 WICD Mobile 1.0
3.1 Introduction
3.2 Document Formats
3.2.1 Root document: XHTML [?]
3.2.2 ECMAScript 3rd Edition Compact Profile
3.2.3 DOM
3.2.4 CSS Mobile Profile 1.0 / Wireless
3.2.5 SVG Tiny 1.2
3.2.6 Bitmap formats
3.2.7 Audio formats
3.2.8 Video formats
3.3 Document Identification
3.3.1 MIME Type
3.3.2 User Agent Identification
3.3.3 Filename extension
4 WICD Desktop 1.0
4.1 Introduction
4.2 Document Formats
4.2.1 Root document: XHTML
4.2.2 ECMAScript 3rd Edition
4.2.3 DOM
4.2.4 CSS 2.1
4.2.5 SVG 1.2 Full
4.2.6 Bitmap formats
4.2.7 Audio formats
4.2.8 Video formats
4.2.9 Other formats
4.3 Document Identification
4.3.1 MIME Type
4.3.2 User Agent Identification
4.3.3 Filename extension
A Definitions
B Conformance
C References
D Media Type Options (Non-Normative)
Combining content delivery formats can often be desirable in order to provide a seamless experience to the user.
For example, XHTML-formatted presentation of content can be augmented by SVG animated objects to provide a dynamic, interactive presentation that is more compelling, more usable, more scalable and maintainable than a static HTML-based presentation. A set of standard rules is required in order to provide this capability across a range of user agents and devices.
These are examples of compound documents:
All Compound Documents have a XML based root document.
Editorial note | |
The group arrived at a resolution that the root document must be XML based on 13 January 2005. Since then, two members of the group have raised objections. |
With the release of multiple Compound Document profiles, the Framework specification (this section of the document) may become a standalone document, containing only generic rules and behaviour for all CD profiles.
(Non-Normative)
A namespace uniquely identifies a set of names so that there is no ambiguity when objects having different origins but the same names are mixed together. An XML namespace is a collection of element type and attribute names. These element types and attribute names are uniquely identified by the name of the unique XML namespace of which they are a part. In an XML document, any element type or attribute name can thus have a two-part name consisting of the namespace name and the element or attribute name.
A compound document by inclusion combines XML markup from several namespaces into a single physical document. A number of standards exist, and continue to be developed, that are descriptions of XML markup within a single namespace. XHTML, XForms, VoiceXML, and MathML are some of the prominent examples of such standards, each having its own namespace. Each of these specifications focuses on one aspect of rich-content development. For example, XForms focuses on data collection and submission, VoiceXML on speech, and MathML on the display of mathematical notations.
To authors of content, each of these many standards is useful and important. However, it is the combination of elements of any number of these standards that lends true flexibility and power to rich document creation. A document may exist to be displayed within a web browser, to display an input form, with a scalable graphic and a bit of mathematical notation, all on the same page. XHTML, XForms, SVG, and MathML, respectively, serve these needs, and could therefore be combined into a single multi-namespace document.
Consider this simple example, a compound document combining XHTML and MathML. The namespace declarations are marked by an appended comment to match the numbered namespaces listed below in the XML source in Example 1.
XHTML Namespace declaration. The namespace for XHTML 1.0 is declared. Each XHTML element in the example below is qualified with the xhtml: namespace prefix.
MathML Namespace declaration. The namespace for MathML 2.0 is declared. Each MathML element in the example below is qualified with the mathml: prefix.
<?xml version="1.0" encoding="iso-8859-1"?> <xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml"> <!-- 1 --> <xhtml:body> <xhtml:h1>A Compound document</xhtml:h1> <xhtml:p>A simple formula using MathML in XHTML.</xhtml:p> <mathml:math xmlns:mathml="http://www.w3.org/1998/Math/MathML"> <!-- 2 --> <mathml:mrow> <mathml:msqrt> <mathml:mn>49</mathml:mn> </mathml:msqrt> <mathml:mo>=</mathml:mo> <mathml:mn>7</mathml:mn> </mathml:mrow> </mathml:math> </xhtml:body> </xhtml:html>
Example 1: A Simple Compound Document
Figure 1: Rendered Simple Compound Document - This is a rendered version of the simple compound document in Example 1 which combines XHTML and MathML for rich content.
Compound documents may be composed of a single document that contains multiple namespaces, as seen in Example 1. This is a Compound Document “by Inclusion” (CDI). However, a compound document may also be composed over several documents in which one document of a particular namespace references another separate document of a different namespace.
For example, a root or top-most document might contain XHTML content for defining and formatting a page. This parent XHTML document can reference another document, , of another namespace, through the use of the XHTML <object> tag. This can be repeated for as many documents as needed. The root document plus this collection of separate, referenced documents is considered a Compound Document “by Reference” (CDR). See Figure 2 for a simple CDR document in which an XHTML root document contains a reference to a separate SVG child document having markup for three colored circles.
Figure 2 (above): Compound Document by Reference - A simple compound document by reference where a XHTML document references a separate SVG document. Below you see the two markup fragments.
XHTML:
<?xml version="1.0"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>circles</title> </head> <body> <object height="350" width="600" type="image/svg+xml" data="circles.svg"/> </body> </html>
SVG:
<?xml version="1.0" encoding="UTF-8"?> <svg xmlns="http://www.w3.org/2000/svg"> <g fill-opacity="0.7" stroke="black" stroke-width="0.2cm"> <circle fill="red" cx="6cm" cy="2cm" transform="translate(0,50)" r="100"/> <circle fill="blue" cx="6cm" cy="2cm" transform="translate(70,150)" r="100"/> <circle fill="green" cx="6cm" cy="2cm" transform="translate(-70,150)" r="100"/> </g> </svg>
And of course, a compound document may be a hybrid of both compound document by inclusion and compound document by reference.
Rendering scalable, but fixed aspect-ratio content into a fixed-sized destination area will often result in non filled margins. In case of SVG child objects: When the viewbox and the viewport do not have the same aspect ratio, and preserveAspectRatio is not set to 'none' (the default being 'xMidyMid') some space is left in between the borders of the viewbox and that of the viewport.
The following illustration shows, how a square, scalable object cannot be used to completely fill a rectangular, non-square destination box.
The child object must render any leftover areas.
Compound document profiles which leverage the Compound Document Framework and which support events and interactivity must have event interfaces and an event processing model that are compatible with the DOM Level 3 Events Specification.
Compound document profiles may subset DOM Level 3 Events, but any DOM Events subsetting should be coordinated with other related DOM subsetting standards efforts. For example, mobile subset efforts for W3C languages such as XHTML, SVG, SMIL and XForms should be coordinated with each other because of the high likelihood that compound document profiles will be defined which combine these languages together.
Propagation of events from a child component up to its parent.
There are four different cases how event flow through references can happen.
Each case should behave in a same way. There should not be any behavioural differences on how the content is referenced.
In order to claim conformance to this Compound Documents Framework, a compound document profile must define how all of its event-related language constructs and scripting constructs map to corresponding DOM3 event facilities, unless DOM3 events has already defined the mapping. In particular:
For each event construct within supported languages, the profile must define the event's namespace and local name, what phases it supports (capture, target, bubble), whether it is cancellable, and the name of the DOM interface for its event structure (e.g., events.dom.w3c.org::UIEvent).
Any events that are defined to be equivalent to a corresponding event from DOM3 Events must have compatible behavior, such as the phases supported, cancellability and propagation across parent/child compound document boundaries. For example, for a "click" event from language A to be equivalenced to the DOM3 "click" event, it also must be cancellable since DOM3 "click" is cancellable.
The profile must define how to map language features for event listeners, event handlers, and event targets into corresponding DOM3 Events facilities.
Compound document profiles which leverage the Compound Document Framework and which support scripting must have scripting interfaces that are compatible with the DOM Level 3 Core Specification.
Compound document profiles may subset DOM Level 3 Core, but any DOM Core subsetting should be coordinated with other related DOM subsetting standards efforts. For example, mobile subset efforts for W3C languages such as XHTML, SVG, SMIL and XForms should be coordinated with each other because of the high likelihood that compound document profiles will be defined which combine these languages together.
Many languages define specialized DOM APIs. The W3C has defined an HTML DOM which extends the Core DOM and provides various convenience APIs for interacting with HTML documents. Similarly, the SVG language defines an SVG DOM which extends Core DOM.
Compound document profiles must specify whether the specialized DOM APIs that are defined within the component languages are supported.
Note: Although not required for compliance with the Compound Document Framework, it is strongly recommended that compound document profiles support all specialized DOM APIs that are supported in the component languages.
A compound document consists of a number of conceptually isolated documents whose interaction points are at specific DOM nodes.
For the purposes of scripting, CSS cascading and so forth each document may be considered to map to its own isolated DOM.
In the compound document case it may be desirable to provide a mechanism by which a parent document may gain access to a child document DOM. It may also be desirable to provide a mechanism by which the child document may gain access to the parent DOM.
One unknown is whether a child document may gain access to a sibling DOM as this may raise security issues.
Current DOM specifications do not support child to parent DOM access. Therefore, this specification introduces a new interface called ReferencedDocument. The ReferencedDocument interface contains an attribute called referencingElement. The referencingElement attribute provides an access to the referencing element in the parent's DOM.
The ReferencedDocument interface represents situation where current document is referenced from an element in another document. Therefore, typically it is the object providing Document interface that supports the ReferenceDocument interface.
IDL Definition:
Interface ReferencedDocument { readonly attribute Element referencedElement; };
Attributes:
referencedElement of type Element
This attribute provides an access to element in parent's DOM that references this node.
Specialized DOM implementations have specified ways how to access child DOM interfaces. Especially HTML has one. DOM Level 2 HTML has HTMLObjectElement interface (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-9893177) that has an attribute called contentDocument (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-38538621). contentDocument returns available Document interface or null if there is no document.
IDL Definition:
Interface ChildDocument { readonly attribute Document contentDocument; };
Attributes:
contentDocument of type Document
This attribute provides access to the child document.
Editorial note | |
This section depends on the ability of the compound document profile to provide a means of navigating to all focusable elements and raises the issue of nested links in html documents, as well as how this should be handled by the dom. |
Link activation behavior for hyperlinks within a child object is defined by the child object's relevant language specification. For example, if the parent document is XHTML and the child object is SVG, then the SVG specification defines the behavior for what happens when a hyperlink within the SVG object is activated.
Link activation behavior for hyperlinks within a parent object is defined by the parent object's relevant language specification
Link activation behavior for hyperlinks within a child object is defined by the child object's relevant language specification
Nested hyperlinks are more complicated. The following illustrates nested hyperlinks. Suppose the parent document is XHTML as follows:
parent.html
<html:a href="LargeMap.html"> <html:object type="image/svg+xml" data="child.svg"/> </html:a>
and the child SVG document contains the following:
child.svg
<svg:a xlink:href="DetailedCountyMap.html"> <svg:text>county map</svg:text> </svg:a>
The <svg:text> element is surrounded by two hyperlinks: a near one defined within the same SVG file and a farther one defined within the parent XHTML file. Nested hyperlinks for Compound Documents are processed in a manner consistent with the following model:
hyperlink-related event processing is compatible with the DOM3 Event model. Thus, an event such as a mouse click or a keyboard action which maps to DOMActivate will participate in capture, target and bubble phases according to the DOM3 Event specification.
elements which define hyperlinks (e.g., the <html:a> and <svg:a> elements) define implicit DOMActivate event listeners for the target and bubble phases (i.e., the useCapture parameter on the implicit addEventListenerNS() call is false), with a default action to execute a hyperlink to the identified resource
the target element for pointer device events is established by first determining the most deeply nested child document which has content that intersects with the geometric (x,y) location of the event. Within the child document, the target element is chosen following the rules defined within the child document's language specification. (For example, the SVG specification says that the target element for pointer events generally is the topmost element on the canvas.)
The implication is that the behavior of nested hyperlinks depends on how the hyperlink is activated. Here are some examples which illustrate common possibilities:
Suppose the user gives focus to an <html:a> within the parent XHTML document above and then hits the "Enter" key to activate that link. In the example above, the <html:a> element is the event target. This would cause execution of the hyperlink to "LargeMap.html".
Suppose the user gives focus to an <svg:a> within the child SVG document and then hits the "Enter" key to activate that link. In the example above, the <svg:a> element is the event target. This would cause execution of the hyperlink to "DetailedCountyMap.html".
Suppose the user uses a mouse or other pointer device to click on the work "county map" in the above example. Because this pointing device event occurs over geometry controlled by both the parent XHTML and child SVG documents, and because the SVG document is the most deeply nested, then the target element will be chosen according to the rules in the SVG specification. In the example above, this will cause the <svg:text> element to be the event target. The <svg:a> element will receive the event after bubbling from the <svg:text> element, which will cause a hyperlink to "DetailedCountyMap.html".
(This section in informative)
Since the child document's language specification defines hyperlinking behavior, here are recommendations for language specifications for languages which might be used as child documents within the context of compound documents:
Relevant language specifications should include a mechanism for defining the possible targets for the hyperlink. For example, the HTML4 specification includes a 'target' attribute on the 'html:a' element which supports targets of _blank, _self, _parent, _top and <frametarget> (see http://www.w3.org/TR/html401/types.html#type-frame-target). The SVG Tiny 1.2 specification also supports a 'target' attribute on the 'svg:a' element with the same list of possible values, except with the addition of an "_replace" keyword (see http://www.w3.org/TR/SVGMobile12/linking.html#AElementTargetAttribute). The WebCGM specification also supports targets of _blank, _self, _parent, _top, _replace and <frametarget> (see http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2).
Relevant language specification should provide a clear definition of the behavior of the "_self" keyword. For SVG and WebCGM, when there is a parent HTML document which references an SVG or WebCGM graphic via html:object, the "_self" keyword causes the HTML document to be replaced by the linked content. However, when a parent HTML document references a child HTML document via html:object or html:iframe, some HTML browsers implement the "_self" keyword such that only the child HTML document is replaced. Because of this, relevant language specifications should be clear about UA behavior in response to the "_self" keyword. One strategy to consider: if the primary usage scenario falls under the category of "replaced element" (see http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element), as is the case with SVG, then defining "_self" to replace the parent document is appropriate.
For language specifications such as SVG which define "_self" to replace the parent document, it might be appropriate to support a "_replace" feature similar to what exists in SVG Tiny 1.2 and WebCGM. This feature causes a hyperlink to replace the child document only but leave parents and other ancestor documents unchanged. (For example, if an SVG document is referenced by a parent HTML document via an 'html:object' element, and if the SVG document has an 'svg:a' element with target="_replace", then when that hyperlink is activated, the SVG document gets replaced but only the 'html:object' element changes within the parent HTML document.)
Sometimes in industry practice a plugin user agent is used to handle certain types of child documents. For example, plugins might handle SVG or MathML child documents. In these scenarios the plugin may only be able to handle particular formats via the "_replace" keyword. (For example, a MathML plugin might be able to handle only MathML content.) Because of this, relevant language specification that support "_replace" (or alternative syntax for the same feature) should clearly specify requirements when "_replace" references content of the same type and content of other types. (For example, only content of the same type can be referenced with "_replace", or any type can be referenced with "_replace", but then error processing must be defined for unknown or unsupported content.)
(This section in informative)
One potential area of ambiguity in the context of compound document is the meaning of the "_self" and "_parent" keywords. (See HTML4's definition at http://www.w3.org/TR/html401/types.html#type-frame-target and SVG Tiny 1.2's definition at http://www.w3.org/TR/SVGMobile12/linking.html#AElementTargetAttribute). For example, suppose a parent XHTML document references a child SVG document via an 'html:object' element and support the SVG document has an 'svg:a' element with target="_self". The SVG Tiny 1.2 specification says that "_self" causes both the XHTML parent frame and the child SVG to be replaced when the hyperlink is activated.
However, there are potential ambiguities if the parent language format supports its own particular notions of nested regions (e.g., frames, panes or sub-documents). It is strongly recommended that relevant language specifications clearly define how its own nested region features relate to the hyperlinking keywords _self, _parent, and _top.
Each hosting language has its own methods to reference child objects. They provide different functionalities but following section describes common functionalities.
In Compound Document Framework 1.0, embedding media and other objects is done by using the existing elements in the host languages rather than by extending them with new markup. In XHTML documents, the <object> element will be used to reference XML document types. In SVG documents, the <foreignObject> element is used. In SMIL, the ref element should be used.
It may be necessary to transfer parameters declaratively to a referenced child object. Compound Document profiles may define specific parameters/values for this purpose. Two examples:
<object type="..." data="..."> <param name="param1" value="true" /><param name="param2" value="123" /> </object>
<svg xmlns="http://www.w3.org/2000/svg"> <foreignObject> <metadata> param=value; param=value </metadata> </foreignObject> </svg>
Child objects are by default not focusable.
For child objects to become focusable, one of the following must apply:
The child object is wrapped by an anchor element.
The child object advertises itself as being focusable. Either because it is activatable as a whole, or because it has embedded links.
In SVG, elements advertise that they are focussable using the focussable attribute.
In many cases referenced content can provide additional functionality. For example an embedded SVG graphic may provide the ability to zoom and pan within its viewport. In the compound document case it may be desirable to restrict child-specific functionality to preserve the authors intent.
Should object specific functionality be desired, the object may become a focus target by wrapping the object within an anchor element.
If a referenced object contains focus elements and the parent document wraps the referenced object with an anchor the result is that focus navigation behaviour needs definition. Should a pointing device be used, one possibility is that hit-testing on the content of the referenced object result in focus on targets in the child where the pointing device successfully intersects such a child object target, whilst applying focus to the entire child object should hit-testing fail to intersect targets in the child.
Focus activation in the case of referenced objects is discussed in detail in section 2.5 Focus Support.
There may be secuerity considerations to consider in allowing interaction between a document from one source and another from a different source. These will be investigated and described in this section.
Editorial note | |
Does this need to conform to RFC3552, or is that overkill? |
The WICD Core specifies a device independent foundation for Compound Document profiles based on XHTML, CSS and SVG.
Profiles based on WICD Core support presentation of rich multimedia content as having the following characteristics:
Graphically rich content, possibly including animated background image.
Content author/provider has exact control of the presentation, including fonts, layout, color, etc.
Layout adaptation: layout can be based upon device characteristics - screen size, color depth, resolution, orientation.
Navigation (forward/backwards tab, up/down/left/right, accesskey, pointer, voice), graphical menus, interactivity and animations.
Graphical menu systems where items have an animated action when focused on.
Portable user interface.
Presentation can be customized to reflect a brand or user's personality.
Skinnable user interface: the ability to use animations and interactivity as a user interface "skin" or template around other content.
Rich content for different contexts.
Dynamic content: documents that are generated on the fly or which change over time
Interaction with mixed content, for example interacting with all the parts (graphics, text, images, audio, video, voice and multimodal interaction) of the mixed document.
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.
Many of the requirements herein are related to this definition. XHTML and SVG have been chosen according to analysis of existing specifications and their applicability to rich multimedia content.
The root document of any profile, that is based on WICD Core must be a XHTML document.
Child objects (e.g. SVG, Video, Audio, SMIL?, others?) are embedded using the XHTML <object> element. Child objects may be embedded as icon objects, as background images or as overlays objects.
Scalable icon objects appear on the main XHTML layer, just like bitmap objects. The following example shows how a SVG object is displayed as part of the XHTML document:
SVG referenced from XHTML
<object data="icon.svg" type="image/svg+xml" width="100" height="100" />
User agents must support scalable icon objects, being animating, interactive and include embedded links.
Non-animating scalable images (SVG) must be supported for CSS background images. Conformant content must not include animated backround (SVG) images. A scalable background image will not provide support for interaction, such as zooming, panning, linking and user interaction events.
The relevant SVG conformance requirement http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers says: "If the user agent includes an XHTML or SMIL viewing capability, then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" wherever raster image external resources can be used, such as in the XHTML 'img' element.
The following example shows how a SVG object is placed on the XHTML background, using the CSS background-image attribute:
Use of background-image:
<html> <body style="background-image:url(noanim.svg);background-attachment:fixed"> <p>This in foreground</p> </body> </html>
The following example will set an svg image noanim.svg as a fixed, non-repeating (ie, not tiled) non-scrolling ('pinned') background, using the individual properties:
Pinned background
body { background-color: white; background-image: url(noanim.svg); background-repeat: no-repeat; background-attachment: fixed; background-position: center center }
or using the shorthand (the order is then significant):
Pinned background, shorthand
body { background: white url(noanim.svg) no-repeat fixed center center }
If noanim.svg has width and height in px, then this is well defined. If it is (the default) 100% 100% then it will display, as large as will fit, where the background area to cover is seen as a viewport.
CSS absolute positioning may be used to detach a child object from main XHTML layer in order to create a new transparent layer.
SVG using absolute positioning
#svg-sprite { position: absolute; left: 0; top: 0; width: 100%; border: 0px; } <body> <div> <object class="svg-sprite" data="sprite.svg" type="image/svg+xml" /> <p>Hello 1</p> <object data="foo.svg" type="image/svg+xml" width="100" height="50" /> <p>Hello 2</p> </div> </body>
User agents must support interactive overlay images.
User agents must support overlay images with embedded links.
The most obvious scalable child object format is SVG. Multiple SVG child objects may be referenced from the same XHTML document. Multiple SVG child objects may animate in parallel.
It may be necessary to transfer parameters declaratively to a SVG child document. The following is a list of possible parameters/values:
The child object may animate all the time. focusin/focusout/activate events will be handled at any time.
The child object will only render the first frame for time zero (0) and then suspend indefinitely. This may be used for SVG objects that are non-animating to allow the user agent for performance and memory optimizations.
Scalable child objects allow the creation of truly screen size independent content and layout in XHTML.
For this purpose, scalable child objetcs are referenced, by using width and/or height attributes with values relative to their destination box (which may be the full available rendering area (canvas) of the user agent or maybe a table cell). In case the scalable child object has it's own fixed aspect ratio, it is meaningful to provide only one size attribute value (width -or- height) of the XHTML object element, when referencing it. The child object will then get 'rightsized' proportionally.
Example:
<object data="icon.svg" type="image/svg+xml" width="100%" />
The final dimensions of the scalable child object are determined by the following rules:
a. If the object element has width and/or height attributes set (through CSS or directly in XHTML), these values will be used.
b. Else, if the child object has it's own (intrinsic) width and/or height values set, these values will be used.
c. Else, the child object will be rendered into the full available region (destination box), made available by the outer container.
By setting only one of the XHTML object-element size attributes (width or height), the intrinsic size of the child object will be overridden.
Child document transparency composite onto the parent document transparency.
In the absence of a background colour or image on the element that established the viewport (eg html:object or svg:svg) it's background is transparent. This is in order to maximize the visual quality of content the parent document should be visible through the leftovers (as well as through the child document itself where it is transparent).
A defined background applies to the entire viewport (including the leftovers) so that content that spills outside of the viewbox into the leftovers is still on the correct background.
Any UI event, such as a mouse click, that hits on the leftover areas, goes straight to the document that contains the element that established that viewport.
No additonal features (not currently available with SVG and CSS) are required. The current set of features is sufficient to cater to the use cases that we have.
The rendered results of a compound document may result in overlap of content originating from different namespaces, for example an SVG graphic on top of some XHTML.
Some user agents may provide monolithic implementations for all namespaces whilst others provide rendering for each namespace in a separate block of executable code such as for example by providing a so-called 'plug-in' interface for each renderer.
In the case where an existing XHTML implementation is to be extended via the addition of a namespace supporting transparency such as SVG it is possible to provide a combined output using alpha-compositing by allowing the SVG implementation access to the output of the XHTML rendering. This would assume the XHTML base layer is opaque and the SVG layer on top would be responsible for retrieving the rendered output pixel data from the XHTML renderer and combine it with the SVG to support SVG layering on top of the XHTML. Such an approach removes the need to add any transparency support to an existing XHTML implementation whilst adding support for transparency support when new namespaces are added.
Such an approach to supporting a foreground transparency layer can be easily implemented given access to the result of rendering output of an existing implementation. In order to support such a feature the XHTML implementation would need to notify a plugin that its rendering is complete.
If animation in the XHTML was supported, then it would also be required to notify the plugin every time a change in the rendered output occured. Such a change would most likely require an off-screen buffer to be used in order to 'double-buffer' so as to avoid flicker.
Given access to the rendered output of an XHTML implementation this combination using transparency on the foreground object must be supported.
Given that transparency information for the output of the background object may be unavailable, this combination requiring transparency on the background and foreground objects may be supported.
The following are topics that relate to focus navigation:
- Focusable Items.
In a CDF document, the focusable items, i.e., items which can form part of a focus traversal, are defined by the respective document types being combined. For example, focusable items in an SVG document are defined by the SVG 1.2 focusable attribute (http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/interact.html#focusable-prop).
- Focus Traversal Inside a Component with no references.
In a CDF document, focus traversal inside any component is defined by the corresponding document type specification. For example, the SVG 1.2 specification defines focus traversal inside an SVG document.
- Focus Traversal At Component Boundaries.
The question of focus traversal arises when focus traversal needs to go through an integration point, such as the <object> tag in XHTML.
XHTML and SVG have methods for linear 2-way focus traversal. XHTML provides a default traversal order, and allows it to be changed with the use of tabindex attribute within one XHTML document. SVG's provides the focusNext and focusPrev elements which may be used to provide similar functionality within an SVG document. However, neither of these methods can be used when XHTML and SVG are combined. Therefore in the case of a compound document by reference combining XHTML with SVG some alternate form of navigation is required.
When navigating an XHTML document it is possible to assign so-called access keys to links in order to provide a 'hot-key' navigation ability. It is unclear how such access keys work in the case of a referenced XHTML document containing access keys. Similarly if multiple parts of a compound document contained access keys, should the user agent provide access key navigation into the child document or restrict it to the parent document only.
Editorial note | |
The Working Group is currently investigating two approaches to two-dimensional focus navigation. The two alternatives are provided in the sections below. The intent of the group is to recommend all WICD UA's to implement the same navigation technique, so that content can be written in consistent and portable ways. |
Graphical focus navigation is based on current visualization of the presentation. When the device does not provide a pointing device (like mouse or touchpad/stylus), this navigation method is used.
Focus navigation is always based on current state within the document. For example, scripts and animations may change the document. The focus navigation is calculated at the time when user interacts with the user agent and the navigation result depends on that moment.
The main idea of the graphical focus navigation is the concept of a current focus point inside the page and inside the currently focused object. This current focus point can be visualized to indicate the position inside the currently focused object (using a UI component such as a pointer or some other type of icon). It can also be presented by highlighting visual objects around the current focus point. The current focus point is used as a starting location for calculating a distance function towards the other focusable objects when navigating.
When user navigates e.g. presses navigation input controls, the current focus point is moved and the focused object changed accordingly. The focus point movement depends on current movement direction and available focusable content in that direction.
The focus navigation algorithm consists of three phases: finding candidates for focus movements, calculating and adjusting movement based on a distance function, and moving the current focus point with possibly changing focusable object.
Phase 1. At first, focusable objects are searched from the direction of navigation. The search includes content that is currently visible in that direction and content that becomes visible if viewport changes.
Phase 2. At second, the current focus point is moved to the direction of navigation. This movement may keep the point within the current focusable object or it may move it out of the current focusable object. Then, the current focus point movement is adjusted by distance function. The distance function takes location of current focus point, and locations and shapes of available focusable content in the area, and calculates most suitable location for the point movement. The distance function enables selection of near focusable objects in cases where more unintuitive selection would otherwise be made.
Phase 3. Finally, there is a check that when focus point moves to another object, focused object is changed accordingly.
X-way navigation is not based on focus ring. Traversal order is NOT related to position of focusable object in the source document.
Mobile handset devices usually come with a 4- or 8-way joystick and with no pointing device. The resulting 2-dimensional focus traversal cannot be based on a focus ring, as 2-way focus traversal usually is. Instead, 4- or 8-way focus traversal should be based on the rendered location of focusable objects.
Hierarchical approach to the <object> tag referencing SVG on gaining focus
The <object> tag may get focus (and display a focus outline), if the referenced SVG's root element has its focusable attribute set to auto _and_ there is no specified focusnext on the root svg element _and_ there are focusable items in the document. In that situation, focus traversal of the child component is subject to an "Activation" mechanism (see below).
Example:
<html> <body> <a id="h_link1">...</a> <object id="obj1" href="svg.svg" /> <a id="h_link2">...</a> </body> </html>
svg.svg:
<svg focusable="auto"> <a id="s_link1">....</a> <a id="s_link2">...</a> <a id="s_link3">...</a> </svg>
Using forward navigation, the focus ring will be:
h_link1 -> obj1 -> h_link2
and, if activation is done when obj1 has focus:
h_link1 -> obj1 [activation] -> s_link1 -> s_link2 -> .... [deactivation] -> h_link2
Activation: a mechanism to initiate focus traversal of a child component.
When an <object> tag itself may get focus (as described below in "Situations where the <object> tag referencing SVG may gain focus"), focus traversal may either continue in the referencing parent document or may enter the child component if the user activates that component via a user agent specific mechanism (e.g., pressing an 'enter' key or double clicking on the component). Once a child component has been activated, focus traversal proceeds in the child component.
Moving focus from a child component to its referencing parent document.
The mechanism for moving focus from a child component to a parent component is defined by the child component's specification. In the case of SVG, there is no mechansim to specifically request exiting ending the focus ring and, for example, skip focusable elements (see focus-nav2 example below).
It has been proposed that we request the SVG Working Group to add the 'parent' keyword to the list of allowed values for the focusXYZ properties. The 'parent' value will mean that the focus has reached the end of the focus ring.
When focus leaves a child component then focus is moved to the first element of the child component's focus ring, as defined by the child component specification.
De-Activation: a mechanism to terminate focus traversal of a child component.
When activation is used to initiate focus traversal of a child component, there is a need to provide a mechanism to specifically exit the child focus traversal. The user agent must ofer a mechanism to de-activate the component (e.g., pressing an 'esc' key or clicking outside the component). Once the child component is de-activated, the referencing <object> tag re-gains focus.
A potential problem identified in regard to the activation/deactivation model is that many mobile devices provide directional navigation and selection, however lack any appropriate method for deactivation. For example a DVD player has 4-way directional navigation plus a 'select' key which may map to the activation command as well as a 'back' key which naturally maps to the deactivation mechanism. Such a 'back' key is lacking in many mobile devices today.
Editorial note | |
Switching off automatic UA-focus outline must be supported for focus-event triggered animation to really work. But this is not possible to do with CSS-MP. Therefor extensions to CSS-MP may be required. (Same thing with scalable child object rightsizing.) |
An example of focus event triggered animations is the implementation of scalable buttons which render their own visual feedback. Such buttons are allowed to contain animation, but no interaction. They will provide a scalable alternative to the use of images as the source of links that can be traversed.
Focus events are enabled for each child object by setting a specific object element parameter:
<object type="image/svg+xml" data="focus-button.svg"> <param name="animation" value="onfocusevent" /> </object>
With the "animation" parameter set to "onfocusevent",
The following SVG example applies to declarative animation:
<svg id="SVGRoot"> ... <rect ... > <animate begin="SVGRoot.focusin" ... /> <animate begin="SVGRoot.focusout" ... /> </rect> ... </svg>
The following XHTML markup makes use of focus events in order to implement SVG child object rendered focus animations on multiple anchor objects. The UA's default focus outline is disabled using CSS.
<style type="text/css"> a.svglink:focus { outline: none } </style> <object type="image/svg+xml" data="header.svg" /> <!-- defaults to 'play' --> <a href="foo1.html" class="svglink"> <object type="image/svg+xml" data="foo1.svg"> <param name="animation" value="onfocusevent" /> </object> </a> <a href="foo2.html" class="svglink"> <object type="image/svg+xml" data="foo2.svg"> <param name="animation" value="onfocusevent" /> </object> </a>
The 'focusin'-animation is not timewise limited and may loop any number of times.
The 'focusout'-animation should be limited to one second and must not loop.
Standalone components or renderers, such as SVG engines, do not always provide a default system font.
In the context of WICD Core however, UA's must at least provide one default system font (including a missing glyph) to all components, such as browsers, SVG engines and other renderers. If there isn't info in the font to display a particular character then the missing glyph is used. Whatever I18N support a CDF implementation provides should not be worse than that of the platform on which it is running.
WICD Core specification cannot mandate any particular font, nor a specific font technology.
But it mandates the availability of at least one default font, so that content providers can print text in any component or render, as simple, as in XHTML.
The default system font(s) may be bitmap or vector based. Ideally, the same default system font(s) are used for all components.
The following SVG sample markup must generate visible text:
<svg ...> <text x="20" y="20" font-size="medium" fill="#000">Fahrvergnuegen*</text> </svg>
In both XHTML (using CSS) and SVG, font selection is done by the font-family property, which takes a list of font family names. (This is combined with other properties such as font-weight to select a specific font face). The family names must match exactly - Times will not match Tymes or 'New Times'.
In desktop usage, authors frequently choose fonts that they know are installed by default on particular platforms. On mobile:
Conforming WICD Core 1.0 content should specify serif, sans-serif, or monospaced (three of the 'generic font families') as the last item in the list of font family names.
In SVG, named fonts, or subsets of fonts, can be supplied along with the content. This ensures that the desired look and feel is preserved regardless of the fonts available on a particular platform.
Content (XHTML, SVG, CSS, script, etc) may be compressed with gzip [RFC 1952] or deflate [RFC 1951]. Conforming CDF Viewers must correctly support gzip-encoded and deflate-encoded content. If they support HTTP/1.1, they must support these encodings according to the HTTP/1.1 specification [RFC2616]; in particular, the client must specify with an "Accept-Encoding:" request header [HTTP-ACCEPT-ENCODING] with those encodings that it accepts, including at minimum gzip and deflate, and then decompress any gzip-encoded and deflate-encoded data streams.
If the content is compressed with gzip or deflate, Conforming CDF Servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate.
Multipart/related packaging must be supported by all agents implementing any WICD Profile. These agents will advertise "multipart/related" capability with their HTTP request accept headers.
MIME implementations must in general treat unrecognized subtypes of "multipart" as being equivalent to Multipart/mixed. Agents supporting the WICD Profile are therefor expected to support both, related and mixed.
Implementations preceding this specification may support only Multipart/mixed. These agents advertise "multipart/mixed" with their HTTP request accept headers.
User Agents must allow synchronization of referenced media via events. Events that correspond to the following actions must be available in the containing document:
Similarly, the User Agent must allow the containing document to control the playback of referenced media using at least the following actions:
Note: This technique is not optimal. The more appropriate way to achieve temporal synchronization is using the SMIL synchronization attributes. However, these are not available in this profile. Another technique is to reference all the media elements from a single SVG file.
The behavior of playing animations while loading a document is dependent on the capabilities of the root namespace of the document.
For example, HTML starts processing the document immediately using a parse and process in parallel model. While XML can use a parse first then process model where the entire DOM is built and then handed to the application, or can also the parse and process in parallel model.
When loading more than one animation during document load synchronization of animations may be desirable. However, HTML and XHMTL have no inherent capability to provide this synchronization HTML and XHTML eventing cannot guarantee synchronization of animations while the document is loading.
SVG, SVGT, and SMIL have synchronization capabilities that can be used when these namespaces are the root or enclosing schema of a document.
In WICD Core, HTML's event attributes (e.g., onclick and onload) map to equivalent DOM3 Events features. Each event attribute represents the creation and registration of an EventListener. The corresponding element represents the EventTarget. For these event listeners, useCapture is set to false. If the attribute representing the event listener is changed, this corresponds to the removal of the previously registered EventListener and the registration of a new one. The relative order of event listeners due to HTML event attributes versus other event listeners is not defined.
The following defines the mapping from HTML event attributes to corresponding DOM3 events:
This section is informative
For compound documents where in one language the legacy focus
event in the http://www.w3.org/2001/xml-events
is used and in
the other the DOMFocusIn
in the same namespace authors have to
take note of the fact that the directly after the focus
event
is dispatched the DOMFocusIn
event is dispatched but not the
other way around. Equivalent for blur
and DOMFocusOut
.
Authors are thus advised to use the DOMFocusIn
and DOMFocusOut
events.
Authors are encouraged to attach event listeners either via the DOM addEventListenerNS method or XML Events. Note that User Agents are not currently required to support XML Events in all document formats.
The WICD Mobile profile is primarily designed to enable rich multimedia content on mobile handset devices. These are devices with...
The intended audience for this specification is user agent or browser implementers, authoring tool vendors and content developers. This profile targets a range of mobile handset devices from relatively low-end consumer handsets to so-called smart phones, and may also be appropriate for other handheld devices such as PDAs.
Agents conformant to the WICD Mobile must implement the 2 WICD Core 1.0.
The following is a WICD Mobile markup sample:
<?xml version="1.0"?> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Example WICD Mobile content</title> </head> <body> <h1>Example WICD Mobile content<h1> <object type="image/svg+xml" src="child.svg" width="50%" /> </body> </html>
Editorial note | |
We will look at both XHTML MP 1.2 and XHTML Basic and try to harmonize. |
[XHTMLMP12] “XHTML Mobile Profile 1.2” (PDF)
[XHTMLMP11] “XHTML Mobile Profile 1.1” (PDF)
[XHTMLBasic XHTML Basic. W3C Recommendation 19th December 2000
Conformant Multimedia Mobile Profile user agents must support ECMAScript 3rd Edition as a scripting language. The media type must be application/ecmascript.
Consider: V2_1-20040816-C/OMA-WAP-ESMP-V1_0-20040709-C (PDF)
ToDo: ...
Consider: V2_1-20040816-C/OMA-WAP-ESMP-V1_0-20040709-C (PDF)
Consider: Document Object Model (DOM) Level 3 Core Specification
Consider: Document Object Model (DOM) Level 3 Events Specification
CSS Mobile Profile 1.0 (W3C Candidate Recommendation 25 July 2002)
[Wireless Profile CSS 1.1] (PDF) OMA Candidate Version 1.1 – 09 Jun 2004
Note: Rightsizing is now specified in CSS 2.1 (?) - but not yet available in mobile/wireless CSS.
The viewer must support JPEG/JFIF [JPEG][JFIF] and PNG [PNG] raster image formats. Other image formats may be supported in addition. For JPEG, the subset defined in [SVG12] shall be supported. For PNG, all color types and bit depths shall be supported, gamma correction shall be supported, and any alpha or transparency information shall be used to composite the image onto the background.
Audio may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG audio element, or indirectly from an SVG video element where the video includes audio.
In XHTML, there are no timing elements. Thus, audio will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link). In conforming WICD 1.0 content, audio referenced from an XHTML object element must have width and height of zero.
In SVG, audio may be triggered by user interaction or by animations to start, stop, or change volume.
For accessibility, conforming WICD 1.0 user agents must profile the option of switching off audio. [UAAG].
No audio format is mandated in this profile. Any audio format supported by the device must also be supported to be used with the <audio> element in SVG and <object> element in XHTML.
Video may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG video element.
In XHTML, there are no timing elements. Thus, video will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link).
In SVG, video may be triggered by user interaction or by animations to start, pause, rewind, or stop.
For accessibility, conforming WICD 1.0 user agents must provide the option of pausing, rewinding, or stopping video.
No video format is mandated in this profile. Any video format supported by the device must also be supported to be used with the <video> element in SVG and <object> element in XHTML.
Documents authored for WICD Mobile should be associated with the "..." mime type.
Consider: D Media Type Options.
User agents supporting WICD content are supposed to send an HTTP accept header including the WICD MIME type.
Consider: D Media Type Options.
The prefered filename extension for WICD Mobile content is ".wicd".
Consider: D Media Type Options.
(This section is purposely incomplete at this time.)
The WICD Desktop profile is designed to enable rich multimedia content on desktop and high capability handheld agents. These are agents with...
Agents, conformant to WICD Desktop, must implement the 2 WICD Core 1.0.
Desktop type agents should also support the WICD Mobile profile. However, this might require emulating small screen devices and joystick events.
Conformant WICD Desktop user agents must support ECMAScript 3rd Edition as a scripting language. The media type must be application/ecmascript.
The viewer must support JPEG/JFIF [JPEG][JFIF] and PNG [PNG] raster image formats. Other image formats may be supported in addition. For JPEG, the subset defined in [SVG12] shall be supported. For PNG, all color types and bit depths shall be supported, gamma correction shall be supported, and any alpha or transparency information shall be used to composite the image onto the background.
Audio may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG audio element, or indirectly from an SVG video element where the video includes audio.
In XHTML, there are no timing elements. Thus, audio will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link). In conforming WICD 1.0 content, audio referenced from an XHTML object element must have width and height of zero.
In SVG, audio may be triggered by user interaction or by animations to start, stop, or change volume.
For accessibility, conforming WICD 1.0 user agents must profile the option of switching off audio. [UAAG].
Some audio formats may be mandated in this profile. Any audio format supported by the device must also be supported to be used with the <audio> element in SVG and <object> element in XHTML.
Video may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG video element.
In XHTML, there are no timing elements. Thus, video will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link).
In SVG, video may be triggered by user interaction or by animations to start, pause, rewind, or stop.
For accessibility, conforming WICD 1.0 user agents must provide the option of pausing, rewinding, or stopping video.
Some video formats may be mandated in this profile. Any video format supported by the device must also be supported to be used with the <video> element in SVG and <object> element in XHTML.
Documents authored for any of the WICD profiles should be associated with the "..." mime type.
Consider: D Media Type Options.
User agents supporting WICD content are supposed to send an HTTP accept header including the WICD MIME type.
Consider: D Media Type Options.
The prefered filename extension for WICD content is ".wicd".
Consider: D Media Type Options.
The working group has decided to use following terms in the work and this document.
The compound document is a document that combines separate component languages either by reference or by inclusion.
In the case of combining by reference, one compound document may be a collection of several separate documents.
The top-most (e.g. document not having any references to it) compound document is called Root document.
In the case of combining by reference, one compound document may be a collection of several separate documents.
The document that references another document is called Parent document. The top-most parent document is also called Root document.
In the case of combining by reference, one compound document may be a collection of several separate documents.
The document that is referenced is called Child document. If the Child document references other documents, it is also called Parent document.
See definition in Device Independence Glossary document.
Component language refers to an XML-based language (like XHTML and SVG) with its own elements and attributes.
This specification defines conformance for several classes of products:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (see ). However, for readability, these words do not appear in all uppercase letters in this specification.
At times, this specification recommends good practice for authors and user agents. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.
Document Conformance
A conforming WICD document must conform to the framework and the relevant profile(s).
All Compound Documents must have a XML based root document.
A WICD root document must be a XHTML document.
...
...
User Agent Conformance
A WICD Mobile conformant user agent must implement all three sections of this specification: Compound Document Framework, WICD Core and WICD Mobile.
A scalable background image will not provide support for interaction, such as zooming, panning, linking and mouse events.
...
...
[ECMA] European Computer Manufacturers Association, "ECMAScript Language Specification 3rd Edition", December 1999, http://www.ecma-international.org/publications/standards/Ecma-262.htm Also available as ISO/IEC 16262: 1999 [SMT] IETF, "Scripting Media Types", 06 June 2005 http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt
Issues relating to MIME/metadata tagging of CD content.
The CDF Working Group has discussed tagging and identification of compound documents by use of Internet Media Types (also known as MIME types). Such identification raises a number of different approaches and questions relating to the best approach.
We are actively seeking feedback from the user community regarding our proposals and options listed below.
One key aspect that has been discussed at length is whether the MIME type identification of a compound document should focus mainly on the framework or be more biased towards identifying combinations of different XML namespaces. Thus the MIME type could either identify the abstract framework itself (with no specific namespace identifiers) or it would identify specific profile descriptors that indicate the combinations of XML namespaces contained in the document or both.
This appendix attempts to paraphrase the discussions up to this point and give a perspective of our options.
Firstly; MIME Type identification requires us to make 5 decisions: 1) Do we propose a MIME (internet Media Type) type for CD content; and 2) What form of MIME type do we use; and 3) Do we provide a 'version' parameter; and 4) Do we provide a 'profile' parameter; and 5) If there is a single new MIME type, should it mean the content uses the generic CD framework (which might be some vertical industry CD) or uses the specific profile associated with a particular generation of specs from the CDF WG (e.g. XHTML-MP+SVG-t1.2+...)?
Decision 2 brings with it a number of sub-questions: 2.1) Do we combine a profiling mechanism with the MIME type (as a parameter, also see decision 4) 2.2) Do we propose a generic CD MIME type that covers all (see CDI vs. CDR below) CD content, or do we have multiple MIME types that identify the content of a CD content presumably for content negotiation purposes. 2.3) Do we like long descriptive or short summary names for the MIME type.
Closely related to all of this is the CDI vs. CDR issue which has related problems.
Decision 1 discussion:
This issue revolves around the question of whether we need to provide identifying metadata about the compound document.
Proposals include:
In general the group feedback indicates that some new MIME type would be desirable.
Proposal (i) requires a whole new set of processing at the XML level to effectively decode the sub-parts of a CD. This is equivalent to a multipart/related but with more processing overhead. Proposal (ii) whilst in some cases XHTML biased generates the issue of requiring a large number of MIME types to be registered. Also, it means that as new namespaces are introduced, each combination needs to be registered. It looks very much like we'd need n^2 MIME types where 'n' is the number of namespaces we support. Proposal (iii) seems favourable to many people but it has been pointed out any requirement for 'sniffing' will make it problematic. Proposal (iv) allows existing MIME types to be used for content if that content appears to be similar to existing content (e.g. XHTML with embedded SVG graphics), but the UA is required to support newly defined CD rules such as right-sizing, etc.
The Working Group is of the opinion that we do provide a new MIME type for CD. The reasoning is that of the options, (i)-(iii) all provide the ability to distinguish a CD compliant document from a legacy document and (iv) whilst nice in principle fails to address the issue of a UA with predictable legacy layout suddenly causing content to display incorrectly in a new CD compatible UA. Trying to serve CD documents without a new identifying MIME type forces 'sniffing' which is quite undesirable.
One of the major criticisms of placing identifying data in the MIME type is that the information is redundant (given that XML is self-describing) and also that due to the redundancy mismatches between the MIME descriptor and the content itself are not only inevitable they are common. Some believe that any sort of profile/content specific tagging should not occur on the base MIME type.
Given those points it seems that a safe option is defining a MIME type for CD content and omitting any form of content tagging in the base MIME type itself. The issue of eliminating 'sniffing' is a separate problem to that of defining a base MIME type for CD content.
Decision 2 discussion:
Some of the MIME type issues have been discussed above, but there are quite a few different points of view here. The Working Group has provided a large number of options and spent time discussing them. In attempting to paraphrase it breaks it into 3 main options:
Option (i) has the advantage that it will never need to be changed, but has the disadvantage that it provides no useful information for the UA to decide if it can handle the content. Option (ii) whilst more 'helpful' suffers from the content/metadata mismatch problem (no doubt familiar to programmers - i.e. keep the distinct information in one place). Also it requires a new MIME type for each profile produced. Option (iii) is related to option (i) and is described in detail below under decision 4.
Given the testing complexity of (ii) most of the Working Group feels that options (i) or (iii) are the only practical solutions.
Decision (2) sub-questions:
2.1 Do we combine a profiling mechanism with the MIME type (as a parameter, also discussed as a separate issue, see decision 4)
A number of people have expressed consistent views on this issue. Profiling and versioning on the MIME type has failed in the past and in the CD case, it is a separate issue to the identification of the CD framework requirement.
A compound document specifies how interaction of namespaces behave. Packaging a compound document in an email or served as a web-page requires identification of its need for following CD rules such as right-sizing, etc.
What profile of CD sub-content is in the delivered package is irrelevant. If SVG-Tiny 1.1 is referenced by XHTML Full then what use is the profile? If we have a profile descriptor (as a base MIME type) for every possible combination of parts of content then it may be helpful, but we fall into the testing of all combinations QA trap. Also if the content claims to be mobile profile XHTML and it references an external SVG file via a URI which then references XHTML Full in its foreignObject, what is the encoding? It's impossible to dynamically follow the reference URI(L)s to work it out and they can change anyway. The complexity of referencing and attempting to label a profile at the top level in some member's opinions makes this a futile exercise. Even if it works on some content it will fail on others, and thus the group feels that clear profile identifiers cover the known namespaces and that no such mixed referencing be compliant with a CD profile (unless it is specifically allowed in the profile itself).
Due to these considerations some people in the group are inclined to say we have no profile/version attached to the base MIME type for CD content.
2.2 Do we propose a generic CD MIME type that covers all CD content, or do we have multiple MIME types that identify the content of a CD document presumably for content negotiation purposes.
As the discusion of question 2 above goes it seems that there is a preference for a generic MIME type.
This also extends to the CDR vs. CDI issue. A very simplified generalization is presented below.
CDI vs. CDR.
Compound Documents by Inclusion as opposed to Compound Documents by Reference differ in one thing: packaging.
Whilst the legacy web we deal with provides explicit tags (e.g. embed, object, foreignObject) to distinguish boundaries of referenced content, one Working Group member believes that the behavior of referenced content should mirror inline content.
This is a point of discussion later, but the logic is that there is no distinction between:
<html> <img src="rect.svg"/> </html>
and
<html> <div> <svg> <rect x="0" y="0" width="10" height="10" fill="red"/> </svg> </div> </html>
The boundary is syntactic and we should treat it as such. Furthermore if we provide some distinction between CDR content and CDI content, then the following scenario becomes real:
Root level document - XHTML marked as CDR; Embedded SVG references XHTML Referenced XHTML from SVG is a CDI document with CDI semantics.
Such nested referencing means that the top-level MIME type label as 'CDR' is superfluous as the content overrides it. Unless we provide a tree-based classification to identify all the referenced parts in a top-level CDR document, the identifier is meaningless.
Also CDI is one document. All it needs is the MIME type.
A CDR is an aggregate of multiple parts. MIME packaging via multipart/related already deals with this issue and has well-known inclusion mechanisms via Content-ID and Content-Location - so we should not reinvent the wheel here.
A possible outcome of this is one CD content MIME type and the distinction (if any) between CDI and CDR be done by use of existing MIME multipart encoding and referencing mechanisms.
2.3 Do we like long descriptive or short summary names for the MIME type.
Some Working Group members expressed a desire for short names as opposed to long qualifiers. Other group members pointed out that the size of the http accept header may force a limitation on the size of the MIME type.
This issue is minor and once the other decisions are made any name is fine within reason. The Working Group has tentatively coined the MIME type WICD. WICD is an acronym for Web Integrated Compound Document. Whilst the final name is yet to be decided, the real decisions are: do we have a MIME type; how many MIME types; do we have a profile; do we distinguish CDI/CDR.
Decision 3 discussion:
Some of the proposals relating to MIME types relates to providing a 'version' parameter to distinguish different versions of WP1/WP2 etc. This suffers the same problems as 2.(ii) above although not quite as severe.
If we choose a single MIME type for all CD content, the version parameter is almost irrelevant given that the sub-content can contain a mixture of different namespaces all of varying versions.
As an aside, MIME itself defined version - 1.0 which has been unchanged for over a decade. It seems that version tagging at the packaging level (which is what MIME types are) fails to work in reality. Despite some hopes that large vendors may be able to 'force' the industry to follow versioning and profile information guidelines, it may be sensible to err on the side of caution and ignore this option. It may be prudent to to ignore 'version'.
Summary of Decisions 1-3:
1) Yes, have a new MIME type. 2) Make the MIME type generic. 3) No version or profile information in the base MIME type.
Decision (4) discussion:
The discussions relating to the provision of a profile parameter have identified a number of quite different points of view. The main options have been:
Option (i) has been heavily supported by some members of the group. The idea here is that the MIME type performs the role of identifying the fact that the content follows CDF rules as far as interaction of namespaces, events, scripting and so forth. It should convey no identification of the content mixture itself, that is left to the UA. This provides maximal flexibility for vendors to implement any mix of namespaces they see fit. Some Working Group members see this as a guarantee that the MIME type is of no use since interoperability of products from different vendors is compromised.
Option (ii) is similar to option (i) except that a strict set of namespaces is defined as being a CDF document. This is a great boost to interoperability since the set of namespaces is known in advance, however extensibility suffers from this approach.
Option (iii) is favoured by a number of working group members. This uses a generic CDF MIME type to identify that the document complies with CD semantics whilst the mix of namespaces is defined by the profile parameter. It has been suggested that a unique URI be provided in the profile parameter to identify different mixes of namespaces. Using this approach a known profile of a CDF document, such as for example XHTML+SVG+MathML would have a single well-known URI that all user agents can either understand or reject. This approach has the advantage that the MIME type itself is generic and thus only one is required whilst different 'flavours' of content may be tagged using a list of URIs kept in a well-known place. It also allows a vendor to add their own specific vendor URI to a mix of custom XML namespaces.
Option (iv) is essentially the same as option (iii) apart from the fact that existing MIME types may embellished by a CDF profile parameter that qualifies the document as conforming to CDF semantics. So for example, an SVG document conforming to CDF semantics could be identified by the MIME type:
image/svg+xml; cdf-profile="http://www.example.com/2005/svg+weirdml"
or an XHTML document conforming to CDF semantics could be identified by the MIME type:
application/xhtml+xml; profile="http://www.example.com/2005/xhtml+svg+random"
The first example adds a CDF defined parameter to the existing MIME type for SVG, whilst the second example reuses the xhtml MIME type parameter 'profile' rather than adding a specific CDF parameter. If a given MIME type doesn't have an existing profile parameter, CDF would define its own.
There are strong views on this issue from both points of view. One is that the profile parameter should not be used so that vendors have maximal flexibility and allow the UA to decide what to do with the content. The alternate point of view is that without some specific profile definition there will be no interoperability guarantees and so the MIME type itself conveys no useful information.
The Working Group as a whole is in favor of some form of profile being associated with the MIME type primarily to help interoperability of implementations from different vendors.
Decision (5) discussion:
Most of the points related to this point have been covered above. If there is a single MIME type, does it apply to one single defined set of namespaces. There are two basic options here:
There are some members of the working group that believe (i) is the only truly generic and orthogonal approach whilst others argue that (ii) is the only way to guarantee that different UAs will produce the same result.
The working group seems to lean towards making sure that the actual namespaces covered by the initial CDF specification (also known as WP1) are well defined and thus in the absence of a profile parameter (as discussed in decision 4) there must be a defined set of namespaces. Thus option (ii) is favored by most of the group.
If a profile parameter is used to define the content of the document this decision is unnecessary.
Final summary of CDF Working Group preferences (not unanimous at this time):
The Working Group is seeking feedback from the user community regarding these preferences. The Working Group has not reached consensus on these issues and would like opinions regarding the options listed above to be voiced.
Option |
Media Type |
Pros |
Cons | |
---|---|---|---|---|
1. |
1-mime-no-parms |
application/cdf+xml |
|
|
2. |
n-mimes-no-parms |
application/cdf-[profile]+xml |
|
|
3. |
1-mime-prof-parm |
application/cdf+xml;profile=[profile-ID] |
|
|
4. |
0-mime-prof-parm |
Reuse existing root media types [MIME];profile=[profile-ID] |
|
|
5. |
n-mimes-prof-parm |
application/cdf-[profile]+xml; profile=[profile-ID] |
N/A |
Invalid, to have to specify profile twice |
6. |
1-mime-vers-parm |
application/cdf+xml; version=[version] |
|
|
7. |
n-mimes-vers-parm |
application/cdf-[profile]+xml; version=[version] |
|
|
8. |
0-mime-prof-parm |
Reuse existing root media types; version=[version] |
N/A |
Invalid, adding just version doesn't identify framework or content |
9. |
0-mime-no-parms |
Reuse existing media types |
|
|
10. |
short-prof-parm |
N/A; profile=[profile-ID] |
|
|
11. |
cdf-vs-wicd |
application/cdf+xml application/wicd+xml |
|
|
12. |
new-root-doctype |
application/cdf+xml |
|
|
13. |
cdi-vs-cdr |
N/A |
|
|
Key areas to consider for media types: