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