Abstract
This document lists the requirements for an
grammar intended for representing events as they are defined in
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 representation by sending it
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 publications and the
latest revision of this technical report can be found in the
technical reports index at http://www.w3.org/TR/.
This document is produced by a joint task force of the
(part of the
Graphics Activity) and the
Web API (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 Patent Policy.
Patent disclosures relevant to this specification may be found on the
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 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 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 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.
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 the 3 Core API. This does
not entail that all of the 3 Core API needs be exposed, simply that
it must be possible to perform modifications corresponding to the
following 3 Events events: DOMNodeInserted, DOMNodeRemoved,
DOMAttrModified, and DOMCharacterDataModified.
- MUST rely on an event-based processing model
-
The chosen method of providing orthogonality across 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 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.
3 Core, 2 HTML, 1.1, 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 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 syntax
-
In order to better integrate into the 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 .
- 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 any language
-
REX needs to be specified so that it is not a silo technology
that only operates on one language, or a subset of possible
languages, but rather a general technology that can be
reused across the board.
- SHOULD be implementable on top of Tiny 1.2 uDOM
-
The Tiny 1.2 uDOM provides a convenient measure of a
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 ecosystem and reuse technology
-
The 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 Stack
property as defined in the XBC Properties
document: as a data format is surrounded by a large body of
specifications that provide additional features considered to form the
Stack. A format is said to integrate well into the Stack if it
can easily find its place into the large body of -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.
