Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification describes a means to support distributed XML Document Object Models via an XML serialization of DOM events. This enables events raised on one DOM tree to be replicated on a remote copy of that tree. One application of this is to support remote user interfaces. This specification includes a serialization for DOM3 events, and is designed to be extended for use with others kinds of events. An informative treatment is given for mapping IDL interfaces into XML, as a basis for serializing such events.
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/.
All sections of this document are normative unless noted as informative. 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 document contains the editor's draft for Distributed DOM 1.0.
Publication as an Editor's 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.
This document has been produced by the W3C Ubiquitous Web Applications Working Group as part of the W3C Ubiquitous Web Applications (UWA) Activity. The goals of the UWA Working Group are discussed in the UWA Working Group charter.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please send feedback on this document to public-uwa@w3.org (archive).
This section is informative.
This specification defines a means for synchronising copies of an XML Document Object Model (DOM) via an XML serialization of DOM events. This enables events raised on one DOM tree to be replicated on a duplicate of that tree. This can be applied to support remote user interfaces, where users interact with a remote application through a user interface driven from a representation as an XML DOM tree.
A transport agnostic XML syntax is defined for the transmission of XML DOM events, and assumes that the transport provides for reliable, timely and in sequence delivery. This specification does not cover the process of session initiation and termination which are presumed to be handled by other means.
For an XML based user interface, the DOM describes user interface components that the user can interact with, for example, buttons that the user can activate, and text entry fields the user can type into. User interaction results in DOM events being raised. The application can respond to these events by raising further events, or through making changes to the DOM that update the user interface.
If the user interface resides on a different device from the application, then user interface events can be serialised and transmitted from the device hosting the user interface to the device hosting the application. Event listeners set by the application will then be invoked as if the listener had been set on the device hosting the user interface. User interface components may also respond to events raised by the application and transmitted to the device hosting the user interface.
When the application makes modifications to the DOM, these result in DOM mutation events that can be serialised and transmitted to the device hosting the user interface. The serialization is sufficient to replicate the changes to the DOM and the resulting DOM mutation events. This specification describes the serialisation for DOM3 events and associated processing semantics. The specification is deliberately extensible to cover additional events, and an informative set of rules is provided for mapping event IDL interfaces into XML.
The following examples illustrate a variety of ways in which the serialization of DOM events can be applied. The examples assume a hypothetical markup language for user interfaces. For instance, here is the markup for a simple confirmation dialog:
Hypothetical Confirmation Dialog
<?xml version="1.0" encoding="utf-8"?> <panel xmlns="http://example.com/2007/ns/ui" xml:lang="en"> <caption>Confirm order?</caption> <button>Okay</button> <button>Cancel</button> </panel>
The application and user interface are assumed to run on different devices, with a distributed DOM that allows the application to set event listeners, and to respond to user interface events by updating the DOM.
The application could add an event listener for activation events on the first button as follows:
Example: Adding an event listener
<ddom xmlns='http://www.w3.org/2007/ddom' xmlns:ui='http://example.com/2007/ns/ui'> <event target='/ui:panel/ui:button[1]' name='DOMEventListenerAdded' event='DOMActivate'/> </ddom>
DOMEventListenerAdded and DOMEventListenerRemoved aren't part of the DOM3 event specification and are instead defined as part of this specification to allow for adding and removing event listeners in coupled DOMs.
The above example illustrates the duality between signalling that an event has occurred and reflecting the associated effect across coupled DOM's. The application adds the event listener to the DOM on one device, and this in turn results in the above message being sent to the coupled DOM on the device hosting the user interface to add the event listener to the coupled DOM.
The target attribute defines the target of the event via an XPath expression. By changing the way the XML namespaces are declared, you can simplify the XPath expression at the expense of adding namespace prefixes to the ddom and event elements, for instance:
Example: Adding an event listener
<d:ddom xmlns:d='http://www.w3.org/2007/ddom' xmlns='http://example.com/2007/ns/ui'> <d:event target='/panel/button[1]' name='DOMEventListenerAdded' event='DOMActivate'/> </d:ddom>
When the user activates the button, the event could be transmitted from the user interface to the application via the following message:
Example: An activation event
<d:ddom xmlns:d='http://www.w3.org/2007/ddom' xmlns='http://example.com/2007/ns/ui'> <d:event target='/panel/button[1]' name='DOMActivate'/> </d:ddom>
The event listener set by the application would then be activated as if the event had occurred locally. The application could then respond by updating the user interface. The following examples illustrate various ways in which that could occur.
To replace the user interface in its entirety, the DOMNodeRemoved event is targetted at the document root with the new DOM as the content of the event element.
Example: Replacing the UI as a whole
<d:ddom xmlns:d='http://www.w3.org/2007/ddom'
xmlns='http://example.com/2007/ns/ui'>
<d:event target='/' name='DOMNodeRemoved'>
<panel>
<caption>Your order has been placed and you
should receive an email confirmation shortly</caption>
</panel>
</d:event>
</d:ddom>
By changing the target, it is possible to remove or replace individual elements.
The following message illustrates how to set an attribute with a given value. In this case the class attribute on the caption element is set to the text 'important'.
Example: Setting an attribute
<d:ddom xmlns:d='http://www.w3.org/2007/ddom' xmlns='http://example.com/2007/ns/ui'> <d:event target='/panel/caption/@class' name='DOMAttrModified' newValue='important'/> </d:ddom>
In principle, the new value could have been given as the content of the event element, but doing so introduces the issue of how to convert element content into a DOM string. Using an attribute (newValue) avoids that problem. DOMNodeInserted and DOMNodeRemoved could likewise be used for adding and removing attributes, but doing so would introduce additional challenges for ensuring interoperability.
The next example shows how you could introduce a new element, in this case a button:
Example: Adding a new element
<d:ddom xmlns:d='http://www.w3.org/2007/ddom'
xmlns='http://example.com/2007/ns/ui'>
<d:event target='/panel/'
name='DOMNodeInserted'>
<button>Done</button>
</d:event>
</d:ddom>
How do you use XPath to indicate the beginning or end of an element's content?
I also plan to add an example showing how to copy a subtree using the XSLT copy-of element as part of the payload for insert and remove operations.
The DOMCharacterDataModified event can be used for messages indicating changes to character data. This makes use of the same newValue attribute as used with the DOMAttrModified event.
Example: Updating character data directly
<d:ddom xmlns:d='http://www.w3.org/2007/ddom' xmlns='http://example.com/2007/ns/ui'> <d:event target='/panel/caption/text()' name='DOMCharacterDataModified' newValue='Thank you, your business is important to us!'/> </d:ddom>
to be continued
application/ddom+xmlNone.
The encoding of a Distributed DOM 1.0 document MUST be determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in RFC 3023 [RFC3023] sections 8.9, 8.10 and 8.11.
As with other XML types and as noted in RFC 3023 [RFC3023] section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in some environments to fail.
Distributed DOM 1.0 documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Encoding header; for systems which do not, such as direct file system access, this is indicated by the file name extension or file metadata. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in RFC 1952 [RFC1952] section 2.3.1.
It must be noted that Distributed DOM 1.0 events MAY be used to modify the document that they target, and in fact that is the primary functionality that they expose in version 1.0. Such modifications may cause security issues with the processor of the target document, but those issues are outside the scope of this registration document.
In addition, because of the extensibility features for
Distributed DOM 1.0 and
of XML in
general, it is possible that "application/dd+xml"
may describe content that has security implications beyond
those described here. However, if the processor follows only
the normative semantics of this specification, this content
will be outside the Distributed DOM 1.0 namespace and
MUST
be ignored. Only in the case where the processor recognises and
processes the additional content, or where further processing
of that content is dispatched to other processors, would security
issues potentially arise. And in that case, they would fall
outside the domain of this registration document.
This specification describes processing semantics that dictate behaviour that must be followed when dealing with, among other things, unrecognised elements, events, and attributes, both in the Distributed DOM 1.0 and XML Events namespaces and in other namespaces.
Because Distributed DOM 1.0 is extensible, conformant
"application/ddom+xml" processors MUST
expect that content received is well-formed XML, but it
cannot be guaranteed that the content is valid to a particular
grammar, or that the processor will recognise all of the
elements and attributes in the document — in fact it will
likely not recognise the payload. Rules are defined so that
such extended documents are guaranteed to be processed
in an interoperable manner.
Distributed DOM 1.0 has a published Test Suite and associated implementation report showing which implementations passed which tests at the time of the report. This information is periodically updated as new tests are added or as implementations improve.
This media type registration is extracted from Appendix A of the Distributed DOM 1.0 specification.
None—since this is the first draft.
The editors of this specification are indebted to Robin Berjon for his work on REX 1.0.