This document lists the requirements for an XML grammar intended for representing events as they are defined in DOM 3 Events, primarily but not exclusively for purposes of transmission or synchronisation of remote documents. Such a vocabulary would enable one endpoint to interact remotely with another endpoint holding a DOM representation by sending it DOM Events as if they had occurred directly at the same location.

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 document is produced by a joint task force of the SVG WG (part of the Graphics Activity) and the Web API WG (part of the Rich Web Clients Activity). Please send comments to public-webapi@w3.org (Archive), the public email list for issues related to Web APIs.

The patent policy for this document is the 5 February 2004 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the SVG Working Group's patent disclosure page and Web API Working Group's patent disclosure page. 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.

This document does not necessarily represent the full and complete consensus of the REX Task Force, the Web API Working Group, or the SVG Working Group at the time of its publication, some issues being still considered to some degree contentious. It is made available for public review in the hope that access from a wider audience early in the process will help increase the quality and timeliness of the specification.

Publication as a Working Group Note 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.

These requirements cover what pertains directly to the functionality desired in REX.

MUST permit a document tree to be modified, locally or remotely

It must be possible, through use of REX, to cause a remote document tree to be updated as if by manipulation through the DOM 3 Core API. This does not entail that all of the DOM 3 Core API needs be exposed, simply that it must be possible to perform modifications corresponding to the following DOM 3 Events events: DOMNodeInserted, DOMNodeRemoved, DOMAttrModified, and DOMCharacterDataModified.

MUST rely on an event-based processing model

The chosen method of providing orthogonality across W3C specifications covering interaction languages is to communicate both across and within language boundaries using events. This ensures the integrity of the processing model, and that minimal information be available between the various parts that may be integrated within a user-agent. This is of specific importance where REX is concerned, since it cannot be useful without a tree to target that is presumably in another language. The baseline event specification with which to conform is DOM 3 Events.

MUST support multiple Document Object Model variants

Multiple technologies on the Web support multiple Document Object Models, some of which are standard or being standardised (e.g. DOM 3 Core, DOM 2 HTML, SVG DOM 1.1, SVG Tiny 1.2 uDOM) while others are found "in the wild" and may be de facto variants specific to a domain or to an implementation. In as far as technically reasonable, REX must support targeting multiple such object models.

MUST specify a minimal timing model

In order to properly support the ability to be transmitted over streaming protocols, REX must support timing facilities (at least to differentiate between delivery time and activation time). However these facilities must be limited to the strict set that is required to achieve the ability to be streamed and must not overlap with existing protocols.

MUST support addressing nodes using XPath

The proven way of addressing nodes in the XML stack is to rely on XPath. The support for XPath required in REX may be a subset of XPath 1.0.

These requirements cover how the functionality available in REX is to be captured by a format, and what constraints this format is to follow.

MUST be specified in a declarative manner

REX must support functionality that is currently possible using scripting, but without introducing the level of complexity and functionality that a scripting language permits. A simpler, more limited declarative approach is easier to handle on constrained platforms and high-performance environments.

MUST be expressed in an XML syntax

In order to better integrate into the XML and Web stacks, and as a straightforward manner of specifying a declarative language compared to inventing a completely new syntax, REX needs to be expressed in XML.

MUST be extensible

It must be possible to create new versions of REX as well as proprietary extensions to it without interfering with the way in which an implementation of the current version that is unaware of extensions processes the parts of the content that are not extensions. Such extensions cover both the markup in which REX is expressed and the events that it captures.

MUST support be forwards and backwards compatibility

REX must be specified in such a way that new vocabulary items (e.g. elements, attributes) and new events can be easily added in version n+1 content without causing implementations of version n to abort processing, and so that implementations of versions n+1 can still process the entirety of version n content.

MUST precisely define error handling

Error handling must be defined in such a way that user-agents will interpret non-conformant content in an interoperable manner.

These requirements cover the way in which REX needs to integrate with the existing ecosystem of surrounding specifications.

MUST integrate into the QA framework

The REX specification must take into account all relevant QA requirements, in such a manner that these requirements can be easily verified.

MUST be applicable to any XML language

REX needs to be specified so that it is not a silo technology that only operates on one XML language, or a subset of possible XML languages, but rather a general technology that can be reused across the board.

SHOULD be implementable on top of SVG Tiny 1.2 uDOM

The SVG Tiny 1.2 uDOM provides a convenient measure of a DOM subset that corresponds to the requirements of constrained devices. Ensuring that this specification can be implemented on the uDOM is a practical way of assessing whether it can be supported on mobile devices.

MUST integrate into the XML ecosystem and reuse XML technology

The XML stack is now so vast that checking a new specification for applicability to others is at best impractical. This requirement is to support the Integratable into XML Stack property as defined in the XBC Properties document: XML as a data format is surrounded by a large body of specifications that provide additional features considered to form the XML Stack. A format is said to integrate well into the XML Stack if it can easily find its place into the large body of XML-related technologies, with minimal effort in defining new or modified specifications.

MUST be transport independent

In order to be reusable across a large set of varied networks, REX must not rely on excessive requirements from the transport layer that it is being delivered on top of. This requirement is to support the Transport Independence property as defined in the XBC Properties document: A format is transport independent if the only assumptions of transport service are error-free and ordered delivery of messages without any arbitrary restrictions on the message length.

MUST integrate in the Architecture of the WWW

REX needs to support the requirements set forth in the Architecture of the World Wide Web: Volume One.