W3C

Compound Document by Inclusion (CDI) Framework

Editor's draft October 2006

This Version:
NONE
Latest Version:
NONE
Editors:
Anne van Kesteren (Opera Software ASA) <annevk@opera.com>
Steve Speicher, IBM Corporation

Abstract

The Compound Document by Inclusion Framework defines how user agents and specification authors should deal with combining multiple namespaces in a single document in terms of DOM and rendering for example.

Status of this Document

Need to sort this out.

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 a Working Draft of the Compound Documents by Inclusion Framework. Public comments to this Working Draft can be made 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.

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

Need some text for an introduction.

1.1. Scope

Does this section really describe the scope?

This section is non-normative.

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:

This document defines a generic language-independent processing model for combining arbitrary document formats.

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.

CSS?

1.2. Conformance

Everying in this specification is normative except for diagrams, examples, notes and sections marked non-normative.

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 [RFC2119].

This specification defines the following classes of products:

conforming implementation
A user agent that implements all interfaces described in this specification and follows all must-, required- and shall-level of critera in this specification.
conforming document
A document that follows all must-, required- and shall-level of critera in this specification that apply to document authors.
conforming authoring tool
One that produces conforming documents.

1.3. Reference and Inclusion

Rename this section to definitions? It's about defining the various scenario's you have after all.

(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

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

2. Document Object Model (DOM)

Need some text here. This specification will hopefully be mostly defined in terms of DOM although I don't think it should require support for it per se.

2.1. DOM Interfaces implemented by Document objects

This section is in need of rewording and references...

Some specifications define DOM interfaces to be implemented by document objects for documents in particular languages, such as HTMLDocument for HTML documents and SVGDocument for SVG documents. If an implementation implements such an interface for any document objects, then it MUST implement that interface for any documents to which an element in the vocabulary corresponding to that interface could be added. For example, in an HTML+SVG implementation in which the document object in HTML-only documents implements HTMLDocument (among other interfaces), the document object in compound HTML and SVG documents (no matter what the root element is) and even in SVG-only documents must also implement the HTMLDocument interface, since DOM interfaces could be used to add HTML elements to that document.

2.2. Maintaining node state across namespaces

Need text. ACTION-524 on Steve...

2.3. Events

Doesn't DOM Level 3 Events just define this? Shouldn't be anything specific I'd say. ACTION-435 covers this anyway...

3. Rendering

Ensure styling changes, whether it be with new <cdf:style> markup, needs to be coordinated with CSS (default rules, conditional styling rules)

Styling affects all namespaces, unless qualified

May need to control local/inheritance of styling (disable a subtree from inheriting styling)

4. Scripting

statement about scripts all run in the same script context

What if different languages use different scripting contexts?

5. Identification and Versioning

Notes ...

6. Component Language Requirements

6.1. Namespaced well-formed XML

Component languages, both parent and child, must namespaced XML documents each with their own unique namespace.

Perhaps it's better to define things based on a DOM tree?

7. Internationalization

Waiting on Chris...

8. Accessibility

Julien...

9. Handling of unknown content

On Steve...

10. Guidelines for XML language designers

We need normative requirements on people making languages...

10.1. Importing elements into various namespaces

Specifications should not import an existing vocabulary into a new namespace (often known as chameleon namespaces), whether it is to use one technology within another or to import elements from a previous version of a specification into a new version. This creates problems for both authors and implementors when multiple namespaces import the same vocabulary:

  1. When authors or implementors building on W3C technologies want to search for, select, or match a certain type of element, having that same element appear in multiple namespaces makes the necessary code more complicated. For example, use of DOM's document.getElementsByTagNameNS [DOM3Core], [Selectors] or XPath's name test [XPath] all become more complicated when searching for the same element name within a set of namespaces, such as searching for an XForms input element [XForms] within the XForms an XHTML2 namespaces.
  2. Implementors are likely to face the same cost within their implementations: when they support multiple imports of the same vocabulary, the question of determining whether an element is a certain element type in that vocabulary becomes more complex to write. Furthermore, because it is more complex to write, it will be done incorrectly more often, leading to bugs that appear only when the vocabulary is used within some of the namespaces into which it is imported.
  3. Implementations are likely to face extra complexity and users of W3C technologies are likely to deal with extra confusion because of ambiguity over what DOM interfaces are implemented by imported elements. Implementing SMIL Animation elements such that they implement the SVGElement interface only some of the time can be hard for implementors; authors likewise might come to expect that SMIL Animation elements implement SVGElement when this is only true when those elements are imported into the SVG vocabulary [SVG11]. (This issue is slightly less general than the others; it only applies when specialized DOM APIs are involved, and it only applies for importing of another technology rather than importing as a versioning mechanism.)

XMLSpec chameleon guideline section

Acknowledgements

This section is non-normative.

The editors would like to thank the following contributors: