W3C

Compound Document by Reference Framework 1.0

W3C Working Draft 19 December 2005

This version:
http://www.w3.org/TR/2005/WD-CDR-20051219/
Latest version:
http://www.w3.org/TR/CDR/
Previous version:
http://www.w3.org/TR/2005/WD-CDR-20051121/
Editors:
Timur Mehrvarz, Vodafone Group Services Limited
Daniel Appelquist, Vodafone Group Services Limited
Lasse Pajunen, Nokia

Abstract

This document specifies the Compound Document Framework by Reference 1.0.

When combining separate markup languages, specific problems have to be resolved that are not addressed by their individual language specifications, such as the propagation of events across namespaces, the combination of rendering or the user interaction model.

Compound Document is the W3C term for a document that combines multiple formats.

Status of this Document

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 19 December 2005 Last Call Working Draft of the Compound Documents by Reference Framework. The Compound Document Formats Working Group explicitly requests comments on this specification. Please send them to public-cdf@w3.org. 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.

The deadline for Last Call comments is 27 January 2006.

This document has been produced by the Compound Document Formats Working Group as part of the Rich Web Clients 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.

Table of Contents

1 Compound Document Framework 1.0
    1.1 Scope
    1.2 Related Documents
    1.3 Reference and Inclusion
    1.4 Identification and Versioning
2 Compound Document by Reference (CDR) Framework 1.0
    2.1 Document Object Model
        2.1.1 Specialized DOM access
        2.1.2 Child to Parent DOM Access
        2.1.3 Parent to Child DOM Access
        2.1.4 SecurityException
    2.2 Events
        2.2.1 Event Propagation in a Compound Document
        2.2.2 Security Event
        2.2.3 Event-Related Legacy Markup
    2.3 Link Activation
        2.3.1 Child Documents
        2.3.2 Parent Documents
    2.4 Referencing Child Objects
        2.4.1 Referencing Elements
        2.4.2 Declarative Child Object Parameters
    2.5 Security Considerations
        2.5.1 Phishing
        2.5.2 Firewall Attack
        2.5.3 How this is handled today?

Appendices

A Definitions
B Conformance
C References
D IDL Definitions
E Java Language Binding
F ECMAScript Language Binding
G Authoring Guidelines (Non-Normative)
H Acknowledgements (Non-Normative)


1 Compound Document Framework 1.0

1.1 Scope

(This section is informative)

Combining content delivery formats can often be desirable in order to provide a seamless experience to the user.

For example, XHTML-formatted content can be augmented by SVG objects, to create a more dynamic, interactive and self adjusting 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:

  • XHTML + SVG + MathML
  • XHTML + SMIL
  • XHTML + XForms
  • XHTML + VoiceML

This document defines a generic Compound Document Framework that defines a language-independent processing model for combining arbitrary document formats.

NOTE: The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., CSS, MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats.

1.2 Related Documents

(This section is informative)

WICD Core

WICD Core is the foundation of rich multimedia content and describes rules for combining Hypertext Markup Language (XHTML) and scalable child objects, such as Scalable Vector Graphics (SVG) in a non device specific manner.

WICD Core builds upon CDF.

1.3 Reference and Inclusion

(This section is informative)

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.

  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.

  2. MathML Namespace declaration. The namespace for MathML 2.0 is declared. Each MathML element in the example below is qualified with the mathml: prefix.

A compound document example:

<?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

A Compound Document

Figure 1 (above): 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.

An XHTML document referencing an SVG document with 3 overlapping 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.

1.4 Identification and Versioning

(This section is informative)

A distinct identification of the supported Compound Document capabilities is often not possible by the advertisement of a list of supported content types. Such a list is not able to sufficiently describe the supported capabilities between compound languages. A unique profile identifier is often better suited to describe such characteristics. CDF profiles may define their identification and versioning criteria, which should utilize the mechanisms readily available from the root language. For example, if the root language is XHTML, then the content type of "application/xhtml+xml" can be used. It can then be used with the optional parameter of "profile", with a value of a URI that both identifies the profile and its version.

2 Compound Document by Reference (CDR) Framework 1.0

2.1 Document Object Model

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.

A compound document using references consists of a number of child documents. Each child document contains elements and attributes from one or more namespaces. The corollary of this is that each child document generates its own DOM. The interaction points between parent and child documents of a compound document are at referencing DOM nodes in a parent document. The compound document framework provides means to access child and parent documents' DOM.

For the purposes of scripting and CSS cascading, these apply to the individual DOMs corresponding to each document in isolation. However, for events, CDR defines an event flow, where events can propagate from child to parent document.

2.1.1 Specialized DOM access

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.

2.1.2 Child to Parent DOM Access

User agent must provide access to parent document.

For a child document to access the parent document, this specification introduces the ReferencedDocument interface.

The ReferencedDocument interface only applies to objects implementing the Document interface defined in DOM Level 3 Core. [DOM3Core] profiles built upon this specification must specify on which exact document objects the interface must be implemented. User agents may implement this interface for each document object they consider to be viable.

Accessing the parent document through the DOM can be disabled for security reasons. In such cases user agents should throw a SecurityException as defined in section 2.1.4.

IDL Definition:

interface ReferencedDocument {
  readonly attribute Element referencingElement;
  // Raises SecurityException with code of SECURITY_ERR
  //   when access is disabled for security reasons.
};

The referencingElement attribute must represent the element node used for including the current document in the parent document. If access to the parent document is disabled or there is no parent document the attribute must be null.

2.1.3 Parent to Child DOM Access

User agents, which support a DOM, must provide access to child documents.

DOM Level 2 HTML defined a way for several elements to access the child document using the contentDocument attribute. [DOM2HTML] This specification defines a generic ReferencingElement interface.

The ReferencingElement only applies to objects implementing the Element interface defined in DOM Level 3 Core. [DOM3Core] Profiles build upon this specification must specify on which exact element objects the interface must be implemented. User agents may implement this interface for each element object they consider to be viable.

Accessing the child document through the DOM can be disabled for security reasons. In such cases user agents should throw a SecurityException as defined in section 2.1.4.

IDL Definition:

interface ReferencingElement {
  readonly attribute Document contentDocument;
  // Raises SecurityException with code of SECURITY_ERR
  //   when access is disabled for security reasons.
};

The contentDocument attribute must represent the child document. If access to the child document is disabled or there is no child document the attribute must be null.

2.1.4 SecurityException

Accessing parent or child documents through the DOM as described in sections 2.1.2 and 2.1.3 can be disabled for security reasons. In such cases user agents should throw a SecurityException.

IDL Definition:

exception SecurityException {
  unsigned short   code;
};
// SecurityExceptionCode
const unsigned short      SECURITY_ERR       = 83;

code represents an integer indicating the type of error generated. SECURITY_ERR is given back if an attempt was made to break through the security policy of the user agent.

2.2 Events

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.

2.2.1 Event Propagation in a Compound Document

Events targetted at child documents do not reach the parent document by default. The propagate attribute from the DocumentEventPropagation interface enables a way for events to reach a parent document.

The DocumentEventPropagation only applies to objects implementing the Document interface defined in DOM Level 3 Core. [DOM3Core] Profiles build upon this specification must specify on which exact document objects the interface must be implemented. User agents may implement this interface for each document object they consider to be viable.

IDL Definition:

interface DocumentEventPropagation {
  attribute boolean propagate; 
};

When propagate is set to true events targetted at the document shall propagate to the parent document, if any. When propagate is set to false events must not propagate. The default value of the attribute is false.

2.2.2 Security Event

When a document breaks through the user agent security policy, user agents are encouraged to dispatch a security event in the http://www.w3.org/2005/10/cdf namespace on the document object. The event is not cancelable and has no bubbling phase. It implements the Event interface defined in DOM Level 3 Events. [DOM3Events]

Security event is a mechanism for notifying non-scripting related security violations. On the other hand, security exception in 2.1.4 is used for notifying scripting related issues.

2.2.3 Event-Related Legacy Markup

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 equivalent 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.

2.3 Link Activation

(This section is informative)

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".

2.3.1 Child Documents

(This section is 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:

If specifications provide a mechanism for hyperlinking they must also define a way to target specific frames. In addition it must be defined how the current document can be replaced (the document the link is defined in), the parent document and the root document.

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).

NOTE: The keyword _self means different things in SVG than it does in HTML. In HTML it replaces the current document and in SVG it replaces the parent document.

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 there are no 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.)

2.3.2 Parent Documents

(This section is 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 suppose 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.

2.4 Referencing Child Objects

(This section is informative)

Each hosting language has its own methods to reference child objects. They provide different functionalities but following section describes common functionalities.

2.4.1 Referencing Elements

In Compound Document by Reference 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. For example, in XHTML documents, the <object> element will be used to reference XML document types. Similarly, in SVG documents, the <foreignObject> element is used, and in SMIL, the ref element should be used.

2.4.2 Declarative Child Object Parameters

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>

2.5 Security Considerations

(This section is informative)

There may be security 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.

2.5.1 Phishing

A common security problem on the Web is known as "phishing". A web application that looks like one which is trusted by the user collects some data (for example credit card numbers, addresses, etc), and then posts that information to a potentially hostile third party.

Allowing access across document boundaries potentially allows an object to fetch the actual document which is trusted by the user, and read the user's data as it is entered. This approach could defeat many browser interface features which are designed to warn the user that a site is not the one they think.

2.5.2 Firewall Attack

Another common attack is to post a document to a user behind a firewall, and then use it to gain access to a server whose name is known but which is normally behind the firewall, and then post information from the retrieved resources to a hostile party.

2.5.3 How this is handled today?

Currently, the common approach used is to restrict access across documents or network interfaces to material which comes from the same source as the code which tries to make that access. This makes it difficult to re-use resources on the Web, by requiring a copy to be held in the domain of each application which uses that resource. This breaks cacheability, potentially reduces maintainability, and requires services to maintain the entire service rather than taking full advantage of specialised third-party providers.

A Definitions

The following terms and definitions are used within this document.

Compound document

The compound document is a document that combines separate component languages either by reference or by inclusion.

Parent document

In the case of combining by reference, one compound document may be a collection of several separate documents.

A parent document represents a document that has a DOM as defined by DOM Level 3 Core and reference another document. The DOM that is formed must be tree-based.

Root document

In the case of combining by reference, one compound document may be a collection of several separate documents.

The outermost parent document is called the root document.

Child 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.

Component Language

Component language refers to an XML-based language (like XHTML and SVG) with its own elements and attributes.

CDR

A document which logically includes other documents via a hypertext reference.

For example: XML 1.1 or HTML documents tied through hypertext reference producing as many DOM linked to one another.

CDI

A document which includes other documents by-value.

For example: A single XML 1.1 document making use of XML grammars defined independently, normally making use of multiple namespaces.

User Agent

See definition in Device Independence Glossary document.

B Conformance

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

  1. All Compound Documents must have a root document which has a DOM.

  2. Conformant content SHOULD not raise security exceptions or events.

User Agent Conformance

  1. Conformant user agent must implement DOM Level 3 Core interfaces.

  2. Conformant user agent must implement DOM Level 3 Event interfaces.

  3. Conformant user agent must support specialized DOM interfaces required by the profile.

  4. Conformant user agent must support ReferencedDocument interface.

  5. Conformant user agent must support ReferencingElement interface.

  6. Conformant user agent must support DocumentEventPropagation interface.

Profile Conformance

  1. Conformant profile must specify required specialized DOM interfaces.

  2. Conformant profile must specify event facility mappings to DOM Level 3 Event facilities.

C References

Extensible Markup Language (XML) 1.0 (Third Edition)
Extensible Markup Language (XML) 1.0 (Third Edition) , C. M. Sperberg-McQueen, Eve Maler, Tim Bray, et. al. , Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-20040204. The latest version is available at http://www.w3.org/TR/REC-xml.
Namespaces in XML
Namespaces in XML , Tim Bray, Dave Hollander, and Andrew Layman, Editors. World Wide Web Consortium, 14 Jan 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest version is available at http://www.w3.org/TR/REC-xml-names.
Extensible Markup Language (XML) 1.1
Extensible Markup Language (XML) 1.1 , Eve Maler, John Cowan, Jean Paoli, et. al. , Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml11-20040204/. The latest version is available at http://www.w3.org/TR/xml11/.
Namespaces in XML 1.1
Namespaces in XML 1.1 , Andrew Layman, Dave Hollander, Richard Tobin, and Tim Bray, Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-names11-20040204. The latest version is available at http://www.w3.org/TR/xml-names11/.
Document Object Model (DOM) Level 3 Core Specification
Document Object Model (DOM) Level 3 Core Specification , Jonathan Robie, Steve Byrne, Philippe Le Hégaret, et. al. , Editors. World Wide Web Consortium, 07 Apr 2004. This version is http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407. The latest version is available at http://www.w3.org/TR/DOM-Level-3-Core/.
Document Object Model (DOM) Level 3 Events Specification
Document Object Model (DOM) Level 3 Events Specification , Tom Pixley and Philippe Le Hégaret, Editors. World Wide Web Consortium, 07 Nov 2003. This version is http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107. The latest version is available at http://www.w3.org/TR/DOM-Level-3-Events/.
Document Object Model (DOM) Level 2 HTML Specification
Document Object Model (DOM) Level 2 HTML Specification , Johnny Stenback, Philippe Le Hégaret, and Arnaud Le Hors, Editors. World Wide Web Consortium, 09 Jan 2003. This version is http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030107. The latest version is available at http://www.w3.org/TR/DOM-Level-2-HTML/.
Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification
Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification , Håkon Wium Lie, Tantek Çelik, Bert Bos, and Ian Hickson, Editors. World Wide Web Consortium, 13 Jun 2005. This version is http://www.w3.org/TR/2005/WD-CSS21-20050613. The latest version is available at http://www.w3.org/TR/CSS21.
Media Queries
Media Queries , Håkon Wium Lie, Tantek Çelik, and Daniel Glazman, Editors. World Wide Web Consortium, 08 Jul 2002. This version is http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708. The latest version is available at http://www.w3.org/TR/css3-mediaqueries/.
HTML 4.01 Specification
HTML 4.01 Specification , David Raggett, Arnaud Le Hors, and Ian Jacobs, Editors. World Wide Web Consortium, 24 Dec 1999. This version is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version is available at http://www.w3.org/TR/html401.
XHTML™ 1.1 - Module-based XHTML
XHTML™ 1.1 - Module-based XHTML , Murray Altheim and Shane McCarron, Editors. World Wide Web Consortium, 31 May 2001. This version is http://www.w3.org/TR/2001/REC-xhtml11-20010531. The latest version is available at http://www.w3.org/TR/xhtml11/.
WebCGM 1.0 Second Release
WebCGM 1.0 Second Release , Lofton Henderson, Roy Platon, Dieter Weidenbrueck, et. al. , Editors. World Wide Web Consortium, 17 Dec 2001. This version is http://www.w3.org/TR/2001/REC-WebCGM-20011217/. The latest version is available at http://www.w3.org/TR/REC-WebCGM.
Mathematical Markup Language (MathML) Version 2.0 (Second Edition)
Mathematical Markup Language (MathML) Version 2.0 (Second Edition) , David Carlisle, Patrick Ion, Robert Miner, and Nico Poppelier, Editors. World Wide Web Consortium, 21 Oct 2003. This version is http://www.w3.org/TR/2003/REC-MathML2-20031021/. The latest version is available at http://www.w3.org/TR/MathML2/.
Portable Network Graphics (PNG) Specification (Second Edition)
Portable Network Graphics (PNG) Specification (Second Edition) , David Duce, Editor. World Wide Web Consortium, 10 Nov 2003. This version is http://www.w3.org/TR/2003/REC-PNG-20031110. The latest version is available at http://www.w3.org/TR/PNG.
XML Events
XML Events , T. V. Raman, Steven Pemberton, and Shane McCarron, Editors. World Wide Web Consortium, 14 Oct 2003. This version is http://www.w3.org/TR/2003/REC-xml-events-20031014. The latest version is available at http://www.w3.org/TR/xml-events.
Voice Extensible Markup Language (VoiceXML) Version 2.0
Voice Extensible Markup Language (VoiceXML) Version 2.0 , Jim Ferrans, Bruce Lucas, Ken Rehor, et. al. , Editors. World Wide Web Consortium, 16 Mar 2004. This version is http://www.w3.org/TR/2004/REC-voicexml20-20040316/. The latest version is available at http://www.w3.org/TR/voicexml20.
Architecture of the World Wide Web, Volume One
Architecture of the World Wide Web, Volume One , Norman Walsh and Ian Jacobs, Editors. World Wide Web Consortium, 15 Dec 2004. This version is http://www.w3.org/TR/2004/REC-webarch-20041215/. The latest version is available at http://www.w3.org/TR/webarch/.
Synchronized Multimedia Integration Language (SMIL 2.1)
Synchronized Multimedia Integration Language (SMIL 2.1) , Dick Bulterman, Editor. World Wide Web Consortium, 27 Sep 2005. This version is http://www.w3.org/TR/2005/PR-SMIL2-20050927/. The latest version is available at http://www.w3.org/TR/SMIL2/.
Scalable Vector Graphics (SVG) Tiny 1.2 Specification
Scalable Vector Graphics (SVG) Tiny 1.2 Specification , , , , et. al. , Editors. World Wide Web Consortium, 07 Dec 2005. This version is http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/. The latest version is available at http://www.w3.org/TR/SVGMobile12/.
Compound Document by Reference Use Cases and Requirements Version 1.0
Compound Document by Reference Use Cases and Requirements Version 1.0 , Daniel Appelquist, Timur Mehrvarz, and Antoine Quint, Editors. World Wide Web Consortium, 09 Aug 2005. This version is http://www.w3.org/TR/2005/WD-CDRReqs-20050809/. The latest version is available at http://www.w3.org/TR/CDRReqs/.
Compound Document by Reference Framework 1.0
Compound Document by Reference Framework 1.0 , Timur Mehrvarz, Daniel Appelquist, and Lasse Pajunen, Editors. World Wide Web Consortium, 21 Nov 2005. This version is http://www.w3.org/TR/2005/WD-CDR-20051121/. The latest version is available at http://www.w3.org/TR/CDR/.
WICD Core 1.0
WICD Core 1.0 , Timur Mehrvarz, Daniel Appelquist, and Lasse Pajunen, Editors. World Wide Web Consortium, 21 Nov 2005. This version is http://www.w3.org/TR/2005/WD-WICD-20051121/. The latest version is available at http://www.w3.org/TR/WICD/.
WICD Full 1.0
WICD Full 1.0 , Timur Mehrvarz, Daniel Appelquist, and Lasse Pajunen, Editors. World Wide Web Consortium, 21 Nov 2005. This version is http://www.w3.org/TR/2005/WD-WICDFull-20051121/. The latest version is available at http://www.w3.org/TR/WICDFull/.
WICD Mobile 1.0
WICD Mobile 1.0 , Timur Mehrvarz, Daniel Appelquist, and Lasse Pajunen, Editors. World Wide Web Consortium, 21 Nov 2005. This version is http://www.w3.org/TR/2005/WD-WICDMobile-20051121/. The latest version is available at http://www.w3.org/TR/WICDMobile/.
Web Content Accessibility Guidelines 1.0
Web Content Accessibility Guidelines 1.0 , Wendy Chisholm, Gregg Vanderheiden, and Ian Jacobs, Editors. World Wide Web Consortium, 05 May 1999. This version is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/. The latest version is available at http://www.w3.org/TR/WAI-WEBCONTENT.
Authoring Tool Accessibility Guidelines 1.0
Authoring Tool Accessibility Guidelines 1.0 , Ian Jacobs, Jutta Treviranus, Charles McCathieNevile, and Jan Richards, Editors. World Wide Web Consortium, 03 Feb 2000. This version is http://www.w3.org/TR/2000/REC-ATAG10-20000203. The latest version is available at http://www.w3.org/TR/ATAG10.
User Agent Accessibility Guidelines 1.0
User Agent Accessibility Guidelines 1.0 , Jon Gunderson, Eric Hansen, and Ian Jacobs, Editors. World Wide Web Consortium, 17 Dec 2002. This version is http://www.w3.org/TR/2002/REC-UAAG10-20021217/. The latest version is available at http://www.w3.org/TR/UAAG10/.
Mobile Web Best Practices 1.0
Mobile Web Best Practices 1.0 , Charles McCathieNevile and Jo Rabin, Editors. World Wide Web Consortium, 17 Oct 2005. This version is http://www.w3.org/TR/2005/WD-mobile-bp-20051017/. The latest version is available at http://www.w3.org/TR/mobile-bp/.
ECMAScript Language Specification 3rd Edition
ECMAScript Language Specification 3rd Edition , European Computer Manufacturers Association, December 1999. Also available as ISO/IEC 16262: 199
Scripting Media Types
Scripting Media Types , IETF, 06 June 2005
OMG IDL Syntax and Semantics
OMG IDL Syntax and Semantics , defined in The Common Object Request Broker: Architecture and Specification, version 2, Object Management Group.

D IDL Definitions

This appendix contains the complete OMG IDL [OMGIDL] for the Compound Document by Reference Framework 1.0 definitions.

cdf.idl:

#ifndef _CDF_IDL_
#define _CDF_IDL_

#pragma prefix "w3c.org"
module cdf
{
  exception SecurityException {
    unsigned short   code;
  };

  // SecurityExceptionCode
  const unsigned short      SECURITY_ERR       = 83;

  interface ReferencedDocument {
    readonly attribute Element 	referencingElement;
    // Raises SecurityException with code of SECURITY_ERR
    //   when access is disabled for security reasons.
  };

  interface ReferencingElement {
    readonly attribute Document 	contentDocument;
    // Raises SecurityException with code of SECURITY_ERR
    //   when access is disabled for security reasons.
  };

  interface DocumentEventPropagation {
    attribute boolean propagate;
  };

};

#endif // _CDF_IDL_

E Java Language Binding

This appendix contains the complete Java Language [Java] binding for the Compound Document by Reference Framework 1.0.

org/w3c/cdf/SecurityException.java:

package org.w3c.cdf;

public class SecurityException extends org.w3c.dom.DOMException {
  static short SECURITY_ERR = 83;
}

org/w3c/cdf/ReferencedDocument.java:

package org.w3c.cdf;

public interface ReferencedDocument {
  public Element getReferencingElement() throws SecurityException;
}

org/w3c/cdf/ReferencingElement.java:

package org.w3c.cdf;

public interface ReferencingElement {
  public Document getContentDocument() throws SecurityException;
}

org/w3c/cdf/DocumentEventPropagation.java:

package org.w3c.cdf;

public interface DocumentEventPropagation {
  public bool getPropagate();
  public void setPropagate(bool);
}

F ECMAScript Language Binding

This appendix contains the complete ECMAScript [ECMA] binding for the Compount Document by Reference Framework 1.0 definitions.

Object SecurityException
  The SecurityException object has the following property:
    SecurityException.SECURITY_ERR
      The value of the constant is 83.

Object ReferencedDocument 
  The ReferencedDocument object has the following property:
    referencingElement
      This read-only property is of type Element.
      
Object ReferencingElement 
  The ReferencingElement object has the following property:
    contentDocument
      This read-only property is of type Document.
      
Object DocumentEventPropagation
  The DocumentEventPropagation object has the following property:
    propagate
      This property is a Boolean.

G Authoring Guidelines (Non-Normative)

Compound Document by Reference Framework 1.0 provides means for using multiple documents and combining presentation from parts. Authors are encouraged to use this method to enable reuse of the content.

Dividing content to reusable parts allow efficiency in content transfers. User agents may cache often used content that improves user experience and reduces need for transfering same content many times.

H Acknowledgements (Non-Normative)

The editors would like to thank the contributors: