Remote Events for XML (REX) Requirements

W3C Working Group Note02 February 2006

This version:

http://www.w3.org/TR/2006/NOTE-rex-reqs-20060202

Latest version:

http://www.w3.org/TR/rex-reqs

Editor:

Robin Berjon (Expway) <robin.berjon@expway.fr>

Copyright ©2006W3C^® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark anddocument use rules apply.

This document lists the requirements for anXML grammar intended for representing events as they are defined inDOM 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 aDOM representation by sending itDOM Events as if they had occurred directly at the same location.

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 currentW3C publications and the latest revision of this technical report can be found in theW3C technical reports index at http://www.w3.org/TR/.

This document is produced by a joint task force of theSVGWG (part of theGraphics Activity) and theWeb APIWG (part of theRich Web Clients Activity). Please send comments topublic-webapi@w3.org (Archive), the public email list for issues related to Web APIs.

The patent policy for this document is the5 February 2004W3C Patent Policy. Patent disclosures relevant to this specification may be found on theSVG Working Group's patent disclosure page andWeb 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 withsection 6 of theW3C Patent Policy.

This document does not necessarily represent the full and complete consensus of the REX Task Force, the Web API Working Group, or theSVG 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 theW3C 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. Functional Requirements
• 2. Format Requirements
• 3. Ecosystem Requirements

1. Functional Requirements

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 theDOM 3 Core API. This does not entail that all of theDOM 3 Core API needs be exposed, simply that it must be possible to perform modifications corresponding to the followingDOM 3 Events events: DOMNodeInserted, DOMNodeRemoved, DOMAttrModified, and DOMCharacterDataModified.

MUST rely on an event-based processing model

The chosen method of providing orthogonality acrossW3C specifications covering interaction languages is to communicate both across and within language boundaries using events. This ensure 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 isDOM 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,SVGDOM 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 theXML stack is to rely on XPath. The support for XPath required in REX may be a subset of XPath 1.0.

2. Format Requirements

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 anXML syntax

In order to better integrate into theXML 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 inXML.

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.

3. Ecosystem Requirements

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 anyXML language

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

SHOULD be implementable on top ofSVG Tiny 1.2 uDOM

TheSVG Tiny 1.2 uDOM provides a convenient measure of aDOM 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 theXML ecosystem and reuseXML technology

TheXML stack is now so vast that checking a new specification for applicability to others is at best impractical. This requirement is to support theIntegratable intoXML Stack property as defined in theXBC Properties document:XML as a data format is surrounded by a large body of specifications that provide additional features considered to form theXML Stack. A format is said to integrate well into theXML Stack if it can easily find its place into the large body ofXML-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 theTransport Independence property as defined in theXBC 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 theArchitecture of the World Wide Web: Volume One.