Remote Events for XML (REX) 1.0

W3C Working Draft 02 February 2006

This version:
Latest version:
Robin Berjon (Expway) <robin.berjon@expway.fr>


This specification defines an XML [XML] grammar intended for representing events as they are defined in DOM 3 Events [DOM3EV], primarily but not exclusively for purposes of transmission. It enables 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 is a First Public Working Draft 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.

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

Table of Contents

1. Overview

This section is informative.

The Remote Events for XML (REX) specification defines a transport agnostic XML syntax for the transmission of DOM events as specified in the DOM 3 Events specification [DOM3EV] in such a way as to be compatible with streaming protocols.

The first version of this specification deliberately restricts itself to the transmission of mutation events so as to remain limited in scope and allow for progressive enhancements to implementations over time rather than require a large specification to be deployed at once. The framework specified here is however compatible with the transmission of any other event type, and great care has been taken to ensure its extensibility and evolvability.

1.1. Examples of usage

A variety of usage situations in for which REX can be used are exemplified below, also showing some specific features available when using REX.

1.1.1. Setting an attribute

The following REX message sets the fetch attribute to "ball" on an element that has an ID of spot.

Example: Setting an attribute

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='id("spot")/@fetch' name='DOMAttrModified' newValue='ball'/>

Note that we do not specify the 'attrChange' attribute since the default handles both modification and addition. The event that will be dispatched will automatically reflect whether an attribute had to be created or if it already existed and simply had its value changed.

1.1.2. Inserting an element

The following REX message adds a row at the seventh position (that is, after the current sixth and before the current seventh, which becomes the eight) in the second table contained in the document's body.

Example: Inserting an element

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='/html/body/table[2]' name='DOMNodeInserted' position='7'>
    <tr xmlns='http://www.w3.org/1999/xhtml'>
      <td>Alpine Labrador</td>
      <td class='food'>bone</td>

1.1.3. Removing an element

The following REX message removes all circle elements inside the root element that have a class attribute being poodle-stylist-location.

Example: Removing several elements

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='/svg/circle[@class="poodle-stylist-location"]' name='DOMNodeRemoved'/>

This shows how REX capitalises on the expressivity of XPath to perform multiple operations with a single command that is concise and network efficient. This capability is not limited to node removal, the processing model allows any event to be dispatched to multiple nodes.

1.1.4. Replacing an element

The following REX message replaces an element with ID femur with the new one provided in the payload.

Example: Replacing an element

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='id("femur")' name='DOMNodeRemoved'>
    <bone xmlns='http://example.org/BoneML' xml:id='tibia'>

Replacement is expressed as a removal with a payload. The processing model is exactly the same as if an event had been transmitted indicating removal, followed by another indicating insertion (internally, a REX user-agent processes both in the exact same manner — which also matches the manner in which a DOM implementation would perform this task) but this shorthand simplifies content generation and is more efficient both in bandwidth and in processing time (since the target only needs to be resolved once).

1.1.5. Replacing the entire document

The following REX message replaces an entire SVG document with a new one.

Example: Replacing an entire document

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='/' name='DOMNodeRemoved'>
    <svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 300 400'>
        <!-- ... --->
        <rect x='42' y='27' width='100' height='200' fill='orange'/>
        <!-- ... --->

Again, XPath's simple modelling of a document hierarchy is used to address the node we want to replace, in this case the document node captured simply as "/".

1.1.6. Updating text

All nodes, including text, can be updated directly. However character data has specific events in the DOM that are more straightforward and can be more lightweight to use. REX supports encapsulating such updates as well. The following example updates the seventh tspan element's textual data with new text.

Example: Updating character data directly

<rex xmlns='http://www.w3.org/2006/rex'>
  <event target='/svg:svg/svg:g[2]/svg:tspan[7]/text()' name='DOMCharacterDataModified' newValue='Hello World!'/>

2. Structure of a REX message

The namespace for the REX language is: http://www.w3.org/2006/rex.

Future versions of this specification will use the same namespace, unless the language is changed in such radical ways that an implementation of previous versions would not be able to process it in a meaningful manner. Implementations of this specification therefore MUST be able to process extensions to the syntax defined in this version, as detailed in the Extensibility section.

All REX messages MUST be contained within a <rex> element. REX messages MAY be contained within other XML elements in other namespaces, but each REX fragment MUST still have a <rex> element as its root.

2.1. The <rex> element

The <rex> element serves as the root container for the entire REX message. It MUST be present, even if there is only one <event> element. Elements in the REX namespace that do not have a <rex> ancestor MUST be ignored by the user-agent.

Element rex

<define name='rex'>
  <element name='rex'>
      <attribute name='version'>
    <ref name='ns'/>
      <ref name='event'/>

Attributes list

Indicates the minimum version of the REX specification required to usefully process this message. While the version value has the form of a float it is actually processed as a string and user-agents MUST therefore compare the provided 'version' against the strings of all versions that they know and MUST NOT perform numeric comparisons. This entails that 1.0, 1, or 1.00 are all different versions. A user-agent supporting this version of the specification MUST accept version identifier 1.0. If the version number is not in the list of versions of this specification supported by the user-agent, the user-agent MUST reject the message completely and immediately, ignoring the entirety of its content.
Other attributes
See 'ns' .

The <rex> element MUST contain one or more <event> elements. Otherwise, the message is invalid and the user-agent MUST ignore it entirely.

Example: a complete REX message

<rex xmlns='http://www.w3.org/2006/rex'

  <event target='id("shiny-donkey")' name='DOMNodeRemoved'/>
  <event target='/svg:svg/svg:g[5]/svg:a[2]' name='activate'/>
  <event target='/svg:svg/svg:g[7]' name='DOMNodeInserted' position='9'>
    <svg:rect x='9' y='42' width='432' height='217' fill='red'/>
  <event target='id("dahut")' name='DOMNodeRemoved'>
    <svg:circle cx='19' cy='17' r='42' fill='orange'/>

2.2. The 'ns' attribute

The 'ns' attribute defines the namespace that applies to DOM event names within the scope of the element on which it occurs. For any given DOM event name, if there is no 'ns' attribute on any of its ancestor elements, that event name's IRI component is http://www.w3.org/2001/xml-events. Otherwise, it will have the namespace component corresponding to the first 'ns' attribute found on its ancestor elements in reverse document order. The content of the 'ns' attribute is either an IRI or the empty string. If the empty string then event names in its applicable scope will have no namespace IRI component.

If the 'ns' attribute contains a non-empty string and it is not a valid IRI then processing of the entire subtree inclusive of the element on which the 'ns' attribute occurs MUST be ignored.

Attribute ns

<define name='ns'>
    <attribute name='ns'>
        <data type='anyURI'/>

2.3. The <event> element

The <event> element is used to encode any kind of event that may be captured in REX. While the 'name' and 'target' attributes MUST always be specified, the rest of its content model depends on the event that it captures. Each <event> element MUST produce at least one corresponding DOM event (and on some occasions a modification of the DOM tree) unless it is ignored according to a part of this specification.

Element event

<define name='event'>
  <element name='event'>
    <ref name='ns'/>
    <attribute name='target'>
    <attribute name='name'>
      <data type='NMTOKEN'/>
    <attribute name='timeStamp'>
      <ref name='DOMNodeInserted'/>
      <ref name='DOMNodeRemoved'/>
      <ref name='DOMAttrModified'/>
      <ref name='DOMCharacterDataModified'/>

Attributes list

Contains the local name component of the name of the event represented by this <event> element. The namespace IRI component of the event's name MUST be resolved based on the 'ns' attribute.
The 'target' attribute contains the target path as described in the Referencing target nodes section.
Contains an integer in milliseconds relative to the epoch (defined to be 00:00:00 UTC 1st January 1970) at which the event is to be dispatched.
This feature may be modified to specify a more useful (or generic) epoch. Also, it has not yet been fully integrated into the processing model (though the required changes are minor).
Other attributes
See 'ns' .

3. Referencing target nodes

Target nodes are referenced using a subset of XPath [XPATH] that corresponds to the level of expressivity that meets most needs while at the same time remaining easy to implement. There is never a need to resolve a relative path as they are always anchored either at the root (absolute paths) or at an element ID.

3.1. Processing target paths

Target paths MUST be processed as follows, even if internal details of implementation differ. The result of evaluating the target path against the target document is a node-set, ordered according to the axes used in the target path, as per XPath. Note however that the limited set of axes available in this subset will always cause the node-set to be in document order.

If the size of the node-set is superior to one, the event MUST be dispatched in the exact same way to each node in the node-set in order, exactly as if the <event> element had been copied multiple times in a row in the REX message, and each had had its target path modified to match only the corresponding node in the node-set. If an event in that expanded list is required by this specification to be ignored, only that event MUST be ignored, and the remaining expanded events MUST be processed.

If the size of the node-set is zero, the event MUST be ignored and thus nothing happens.

The set of namespace declarations made available to the target path are those in scope on the element on which the target path occurs; this includes the implicit declaration of the prefix xml required by Namespaces in XML [XMLNS]; the default namespace (as declared by xmlns) is not part of this set.

3.2. Path syntax

The syntax for target paths is a very simple subset of XPath described by the following syntax, in which the Name token is taken from the XML specification [XML] and the NCName token is from the Namespaces in XML specification [XMLNS].

EBNF for target paths

FullPath  ::= RPath | Root | IDPath
SubPath   ::= Step* FullTest
RPath     ::= '/' SubPath
Root      ::= '/'
IDPath    ::= 'id(' NCNameStr ')' RPath?
Step      ::= StepTest '/'
StepTest  ::= Name ('[' Num ']')?
FullTest  ::= (Name | 'text()' | '@' Name) ('[' Num ']')?
NCNameStr ::= "'" NCName "'" | '"' NCName '"'
Num       ::= [0-9]+

User-agents MAY support a superset of this syntax so long as it is a valid instance of the XPath language [XPATH]. Content producers however SHOULD NOT use such extensions as they hamper interoperability.

The subset of XPath normatively defined in the above grammar can be summarised by a few general ideas. Target paths may only begin at the root or with an id() function. The id() function itself is limited to a single string argument, which in turn must contain exactly one identifier (as opposed to a white space separated list in XPath). Only abbreviated axes are supported in the syntax. Following the beginning of the path may be a list of steps, making use of either the child axis, which may only use element name tests. The final step in the list is more powerful and may also reference text and attribute nodes. For each step a predicate may be used, which is limited to only containing an integer indicating position.

Some examples of target paths include:

Note that it is possible using this syntax to produce target paths that will never match anything (for instance /element[2]). Such constructions simply cause the event to be ignored.

4. Processing model

This section defines how REX messages are processed by user-agents. Its intent is not to prescribe implementation details — the processing MAY be implemented in ways that differ from the steps described below, but if so the effect MUST be exactly equivalent.

It is RECOMMENDED that REX messages be processed in a streaming fashion, so that the user-agent is not required to build a tree representation of the message. This is of particular importance in that a single REX message MAY capture a very long list of individual events over a long period of time, which would cause the resulting tree to consume potentially large amounts of memory.

Implementations SHOULD dispatch events encoded in REX messages as soon as they have finished parsing the corresponding <event> element. Because of this a REX message containing a well-formedness error SHOULD still cause previous <event> elements to be fully processed. Upon encountering a well-formedness error, a REX user-agent MUST stop processing immediately such that the remainder of the XML document MUST be ignored. If the well-formedness error is contained inside an <event> element, the corresponding event MUST also be ignored.

As soon as an <event> element is parsed, and provided that it is not ignored according to this specification, the following steps take place:

  1. an Event object (as defined in DOM 3 Events [DOM3EV]) MUST be created as defined in the Mapping event elements to Event objects section below. Note that in some cases, multiple Event objects may be created by a single <event> element (e.g. for the 'DOMNodeRemoved' event).
  2. the target path MUST be resolved, as defined in Referencing target nodes
  3. for each node in the node-set returned by the previous step that is not ignored according to this specification, the event or events initialised in step 1 MUST be dispatched as if by a call to EventTarget.dispatchEvent(). If the event is defined to have side-effect (such as modifying the DOM tree, as is the case with mutation events), this is the moment at which the side-effect MUST occur. Whether the side-effect occurs immediately preceding or following the event being dispatched is specified for each such event.

As soon as an <event> element has been processed, the implementation MAY discard it from memory so as to consume fewer resources.

There is no requirement on the user-agent to support a DOM interface in order to still implement events received through REX messages. For instance, specifications such as SMIL [SMIL2] or XML Events [XMLEV] may be handling events received through REX messages in the absence of a DOM representation of the document tree.

4.1. Mapping <event> elements to Event objects

In processing <event> elements and converting them into Event objects, the user-agent MUST inform the various fields of the object in the following manner:

Set to the 'name' attribute of the <event> element.
Set to the value of the 'ns' attribute, resolved as described in its own section.
Set dynamically to be in turn each node in the node-set obtained by resolving the target path.
Set dynamically as the event is being processed, as described in the DOM event flow.
Set dynamically depending on whether the event is currently progressing through the capture, target, or bubble phase. Note that this specification does not require that given phases be supported by the implementation, this is left to the specifications with which it is used in conjunction to define.
Specifies whether an event is one that bubbles or not. The implementation sets that using its knowledge of the given event type.
Specifies whether an event can have its default action prevented or not. The implementation sets that using its knowledge of the given event type.
If the implementation supports the 'timeStamp' attribute and it has been set, this field specifies the time at which the event comes into effect. As defined in the DOM 3 Events specification [DOM3EV] if this field is not specified, it MUST always be set to zero.

When the event type is recognised by the processor, it needs to create an object of the appropriate subclass of Event. The precise details of doing so are defined in the sections that handle mappings of specific event types. In this specification there is only one such section, Encoding Mutation Events.

4.2. Processing unknown events

The are two types of unknown events:

When encountering an unknown even, a user-agent MUST ignore the entire <event> element and all its descendants.

Note that we could make this extensible, but it would require adding a bunch of attributes (bubbles, cancellable, etc.) so that unknown events could be processed. This should be done in the next version.

4.3. Processing unsupported node types

There is almost always a mismatch between the information that an XML document is able to capture and the information that an in-memory representation of the same document is able to expose. In some cases, this mismatch is strong enough that some major XML constructs such as processing instructions or comments cannot be represented. This section defines how a user-agent is to handle node types that it is unable to produce a representation of.

It should be noted that there is no requirement that a node type captured in a REX message have a corresponding object or interface in the DOM variant used by the user-agent. For instance, the SVG 1.2 MicroDOM [SVGT12] has no interface to represent text nodes but it is nevertheless able to store text content and even mixed content. Therefore a user-agent using the MicroDOM will be able to process text nodes that it receives from REX messages.

The are two situations in which unsupported node types may be encountered:

If the target path requires support for a node type that is not supported by the implementation, then the user-agent MUST ignore the entire <event> element and all of its descendants.

If the payload of the <event> element contains node types that are not supported by the user-agent's DOM implementation the payload MUST be modified so that nodes that have no usable representation in the user-agent's DOM implementation are removed. For instance, given an SVG Tiny 1.2 MicroDOM [SVGT12], processing instructions would be removed as they can have no known impact or representation in the tree, but text nodes would not: they may not have an object type corresponding to them but they are still accessible through the textContent interface. If removing these nodes from the payload causes the payload to become empty, then the entire <event> element MUST be ignored since no useful Event object could be derived from it.

5. Extensibility

In order for REX to be extensible, it is necessary to define a strict extensibility model that allows future versions to introduce new constructs into messages that will still be understood to the best of their abilities by older user-agents.

A REX message that is intended to be understood if and only if the user-agent supports a minimal version of the REX specification MUST set the 'version' attribute correspondingly. A user-agent that does not support the required version MUST then discard the entire message. Otherwise, it MUST apply the following forward-compatibility rules.

5.1. Unknown elements

There are three categories of unknown elements:

Outside of <event> payloads, when encountering an unknown element a user-agent MUST ignore it together with all of its attributes and descendant nodes.

Inside <event> payloads, all elements whether they are in the REX namespace or not are considered to constitute the content of that event, and MUST be processed as if they were in a foreign namespace. REX elements in event payloads MUST NOT be processed as REX elements.

5.2. Unknown attributes on REX elements

There are two types of unknown attributes that MAY occur on REX elements:

When encountering an unknown attribute, a user-agent MUST process the corresponding element as if the attribute had not been specified at all.

Likewise, if a known attribute with an invalid value is encountered, it MUST be ignored as if it had not been specified.

6. Error handling

6.1. Errors specific to the DOM or to the target language

Some of the events that can be captured in REX messages will cause the DOM tree that they target to be modified. In addition to the specific error handling specified in the respective event definitions, the following rules apply:

DOM errors
If the modification corresponds to something that is invalid in the DOM (e.g. inserting an element after the root element node) then the event is ignored.
Target language errors
If the modification causes the target language to find itself in a state that is erroneous according to its specification, the modification takes place regardless and it is up to the host language to handle the error, as if the modification had been performed through script manipulation of the DOM. The exception to this rule is if such a modification being performed by using the DOM directly had caused an exception to be raised: in that case the error is treated as a DOM error, and the event is ignored.

6.2. Ignored events and elements

For every part of this specification for which a given event or element is said to be ignored, a user-agent MUST skip it as if it had not at all occurred within the REX message (and if the entire REX message is ignored, as if it had never been received at all). The user SHOULD NOT be informed of such occurrences.

However if instead of a user-agent the REX processor is a content checker, then each given occurrence of an item that is said to be ignored MUST be considered to be an error. Such errors MUST be reported to the user of the content checker. More information is available on classes of REX processors in the Conformance section.

7. Encoding Mutation Events

All mutations events are in the http://www.w3.org/2001/xml-events namespace. Only the following events are supported by this specification: 'DOMNodeInserted' , 'DOMNodeRemoved' , 'DOMAttrModified' , and 'DOMCharacterDataModified' .

Mutation events are specific in REX processing in that they cause the DOM tree to be modified. When a user-agent processes a mutation event received in a REX message, in addition to dispatching the event it MUST also modify the tree (either before or after the event, as specified depending on the event type) according to the event type.

7.1. Mapping Mutation Events to objects

In processing an <event> element that captures a mutation event, the user-agent MUST produce a MutationEvent object, and MUST inform the fields of the object in the following manner:

Set dynamically by the user-agent according to the DOM 3 Events specification [DOM3EV]. For attribute modifications applying to DOM subsets that do not have a representation for Attr nodes this field MUST be null.
Set dynamically by the user-agent to hold the previous value for applicable events, as per DOM 3 Events [DOM3EV].
Set to the value of the 'newValue' attribute for 'DOMAttrModified' and 'DOMCharacterDataModified' events.
The name of the attribute being added, changed, or removed for 'DOMAttrModified' , as derived from the target path.
Set to match the value of the 'attrChange' attribute when applicable.

7.2. The 'DOMSubtreeModified' event

The DOMSubtreeModified is not supported. Implementations MUST process it as an unknown event.

7.3. The 'DOMNodeInserted' event

The DOMNodeInserted indicates that a node has been inserted into the DOM tree. The inserted node MUST be either of an element, a text node, a comment, or a processing instruction. The target path is used to specify the parent of the node that is to be inserted, and MUST point either to an element or to the document root. If the element that it points to does not exist then the event MUST be ignored.

After all direct child elements of the <event> element that are in the REX namespace have been removed together with their descendants, the remaining child nodes constitute the event's payload. If there is more than one remaining child node in the payload, they MUST be inserted one after the other in document order, as if a DOM DocumentFragment were being inserted. Each of them in turn MUST produce a DOMNodeInserted event as if they had been transmitted in separate <event> elements, and the 'position' MUST be incremented by one for each.

Note that as specified in DOM 3 Events [DOM3EV] this event MUST be dispatched after the node has been inserted.

When this event is transmitted, the <event> element MUST allow arbitrary XML as its content. This is not specified in the schema fragment below but left to compounding schemata (e.g. defined using NVDL) to define.


<define name='DOMNodeInserted'>
    <attribute name='position'>
      <data type='integer'/>

Attributes list

Specifies the position at which the payload MUST be inserted in the target element's child nodes such that a hypothetical call to parent.childNodes.item(position) would return the first node of the payload. If position is not specified, or if the specified value is higher than the number of item or lower than zero then the nodes MUST be inserted at the end of the list of child nodes.

7.4. The 'DOMNodeRemoved' event

The DOMNodeRemoved event indicates that a node has been removed from the DOM tree. The target path MUST point to either an element, a text node, a comment, or a processing instruction. If it points to an attribute the event MUST be ignored. If the node pointed to by the target path does not exist, then the event MUST be ignored.

If the <event> element capturing this has a payload as defined in the 'DOMNodeInserted' event, then a second event MUST be created and dispatched immediately after this event (if the target path resolved to a node-set containing more than one item, then each generated event immediately follows the one dispatched on a given node).

The following parameters MUST be set for the generated event. It is of type 'DOMNodeInserted' . Its target node is the parent of the one pointed to by the current 'DOMNodeRemoved' event, unless the latter was pointing to the root node (using '/') in which case the generated event also points to the root node. Its 'position' is that of the removed node within its siblings, in document order. Its payload is set to be that of the current event.

Note that the above processing is compatible with that of DOM 3 Core [DOM3] Node.replaceChild() but more powerful since it can also operate on the document itself.

Note that as specified in DOM 3 Events [DOM3EV] this event MUST be dispatched before the node is removed.

The event adds no attribute to the <event> element.


<define name='DOMNodeRemoved'>

Attributes list

No additional attributes

7.5. The 'DOMNodeRemovedFromDocument' event

The DOMNodeRemovedFromDocument is not supported. Implementations MUST process it as an unknown event. It is nevertheless dispatched after a DOMNodeRemoved event as described in DOM 3 Events [DOM3EV].

7.6. The 'DOMNodeInsertedIntoDocument' event

The DOMNodeInsertedIntoDocument is not supported. Implementations MUST process it as an unknown event. It is nevertheless dispatched after a DOMNodeInserted event as described in DOM 3 Events [DOM3EV].

7.7. The 'DOMAttrModified' event

The DOMAttrModified event indicates that an attribute has been modified, added, or removed.

When representing a 'DOMAttrModified' event, the <event> element's 'target' attribute MUST have an attribute step as its last step (i.e. the FullStep construct). If the 'attrChange' attribute is set to removal then the attribute pointed to by the target path MUST exists, and if it does not the event MUST be ignored. If however it is set to modification or addition then there are two possible options:

Note that as specified in DOM 3 Events [DOM3EV] this event MUST be dispatched after the node has been modified.

The following attributes are added to the <event> element.


<define name='DOMAttrModified'>
      <attribute name='attrChange'>
      <attribute name='newValue'>

Attributes list

Indicates the type of change that concerns this attribute, one of modification, addition, or removal. The default value is modification.
If the value is modification, then the 'newValue' attribute MUST be present, and the value of the target attribute MUST be changed to be that contained in 'newValue' . If 'newValue' is not specified, the event MUST be ignored. If the target attribute does not exist, the event MUST be processed as if 'attrChange' had had a value of addition.
If the value is addition, then the 'newValue' attribute MUST be present, and the value of the target attribute MUST be created with a value being that contained in 'newValue' . If 'newValue' is not specified, the event MUST be ignored. If the target attribute already exists, the event MUST be processed as if 'attrChange' had had a value of modification.
If the value is removal, then the target attribute MUST be removed. If the target attribute is not present, then the event MUST be ignored. If 'newValue' is specified then it MUST be ignored.
Specifies the value that the attribute is set to, for values of 'attrChange' for which a value is required.

7.8. The 'DOMCharacterDataModified' event

The DOMCharacterDataModified event indicates that character data has been modified, where that character data can be either a text node, a comment node, or the data of a processing instruction node. When representing a 'DOMCharacterDataModified' event, the <event> element's 'target' attribute MUST therefore point to a text node, a comment node, or a processing instruction node. If the node pointed to by the target path does not exist then the event MUST be ignored.

Note that as specified in DOM 3 Events [DOM3EV] this event MUST be dispatched after the node has been modified.


<define name='DOMCharacterDataModified'>
  <attribute name='newValue'>

Attributes list

Specifies the value that the character data is set to. This attribute is required, if it is absent the event MUST be ignored.

7.9. Mutation name events

Neither of the mutation name events (DOMElementNameChanged and DOMAttributeNameChanged) is supported. Implementation MUST process them as unknown events.

8. Conformance

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

Unless otherwise specified immediately following the header, all sections in this document — to the exclusion of examples which are all informative — are normative.

8.1. Parsing attribute values

The parsing of attribute values MUST be performed as follows:

Things currently missing from this section:

GP1. Classes of products: content, content producers, user-agents. For UAs, two levels: one with a DOM (indicate variations) and one without.

GP3. Not sure exactly how to best do this. Could be useful, need to ask for input.

GP4. Do this as soon as test are being written.

GP5. Delayed until GP3 & GP4 are done.

GP7. Not sure if this is examples or if it's test suite. If former done, if latter starting right after FPWD.

Req3. See GP1.

GP8. Once the text is a little bit more stable, go through the list of bibrefs and check to see which ones are good.

Req5. Implement proper <dfn> support, and based on that do exactly this.

Req6. Do this as part of GP1.

GP9. Do this with Req5.

GP10. Left for later check (at FPWD time I would expect).

GP12. Testable assertions will need further checking. Do this as part of the post FPWD work on testing.

GP19. Add some text in the section on extensibility to make sure implementers understand how not to get extensibility wrong.

8.2. Conformance to the QA Framework Specification Guidelines

This table is derived from the checklist of all defined requirements and good practices from the QA Framework: Specification Guidelines [QAF-SPEC]. For each requirement and good practice, the table links to the part of the REX specification that satisfies the requirement or best practice, except where the entry corresponds to many parts of the specification, or even the specification as a whole.

Guidelines YES NO N/A Comments
2.1 Specifying Conformance
Requirement 01: Include a conformance clause. YES
Good Practice 01: Define the specification's conformance model in the conformance clause.
Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content. YES
Good Practice 03: Provide the wording for conformance claims.
Good Practice 04: Provide an Implementation Conformance Statement Pro Forma.
Good Practice 05: Require an Implementation Conformance Statement as part of conformance claims.
2.2 Setting up ground rules
Requirement 02: Define the scope. YES
Good Practice 06: Provide examples, use cases, and graphics. YES
Good Practice 07: Write sample code or tests.
Requirement 03: Identify who and/or what will implement the specification.
Requirement 04: Make a list of normative references. YES
Good Practice 08: When imposing requirements by normative references, address conformance dependencies.
2.3 Defining and using terminology
Requirement 05: Define the terms used in the normative parts of the specification.
Requirement 06: Create conformance labels for each part of the conformance model.
Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section.
Good Practice 10: Use terms already defined without changing their definition.
Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them. YES
Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional. YES
Good Practice 11: Use formal languages when possible. YES A RelaxNG schema is provided both as fragments for each item being defined and as a separate complete schema.
Good Practice 12: Write Test Assertions.
2.4 Managing Variability
Good Practice 13: Create subdivisions of the technology when warranted. n/a While there is optionality, it is insufficient to justify the cost of introducing subdivisions.
Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. n/a The technology is not subdivided.
Requirement 10: If the technology is subdivided, then address subdivision constraints. n/a The technology is not subdivided.
Good Practice 14: If the technology is profiled, define rules for creating new profiles. n/a The technology is not profiled.
Good Practice 15:Use optional features as warranted. YES See the list of optional features.
Good Practice 16: Clearly identify optional features. YES
Good Practice 17: Indicate any limitations or constraints on optional features. YES
Requirement 11: Address Extensibility. YES
Good Practice 18: If extensibility is allowed, define an extension mechanism. YES
Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.
Good Practice 20: Define error-handling for unknown extensions. YES
Requirement 12: Identify deprecated features. n/a This is the first version, there is nothing to deprecate.
Requirement 13: Define how each class of product handles each deprecated feature. n/a This is the first version, there is nothing to deprecate.
Good Practice 21: Explain how to avoid using a deprecated feature. n/a This is the first version there is nothing to deprecate.
Good Practice 22: Identify obsolete features. n/a This is the first version, there are no obsolete features.
Good Practice 23: Define an error handling mechanism. YES

8.3. Optional features

There are two features for which optionality is to be found:

Processing XML as a stream
There are two major manners in which XML may be processed: either the processor performs actions as soon as a given token in the source is parsed (this is generally referred to as processing in a "streaming" fashion), or the entire document is first parsed into an in-memory representation and then walked through to perform actions (a.k.a. tree-based processing). The major difference between the two as far as this specification is concerned is that an implementation processing XML in a streaming fashion will dispatch events that it has parsed in their entirety immediately even if there is an XML well-formedness error further into the document, whereas tree-based processing will detect the well-formedness problem before any action is taken. Since it is preferable at least for performance reasons to process documents in a streaming manner, the specification recommends that approach but does not mandate it. We did not wish to enforce only one kind, as both may be impractical, if only because some constrained devices will only have one type of processing or the other.
Support for varied DOM representations
This specification has be created with the goal of being reusable in many situations, notably in case in which the DOM support of the user-agent may vary greatly, and in fact in some cases be to some degree absent (which is to say, there needs to be a tree representation that can usefully be understood as a DOM, but it need not be exposed for instance to scripting). To enforce this would have severely reduced the applicability of this specification. Instead, it describes normatively how to handle node types that cannot be usefully represented in the user-agent's DOM of choice.

9. Acknowledgements

The editor would like to thank Dave Raggett for his excellent input and comments. This specification is a collective work that derives from other solutions in the domain. Notable amongst the influences are an input document from Nokia the ideas from which were incorporated into this specification, XUpdate which has been a major de facto solution since the year 2000 and was influential in REX's technical design, and the IETF WiDeX Working Group.

A. Media Type registration for application/rex+xml

10.1. Introduction

This appendix registers a new MIME media type, "application/rex+xml" in conformance with RegMedia and W3CRegMedia.

10.2. Registration of Media Type application/rex+xml

MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:


The encoding of a REX 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.

Encoding considerations:
Same as for application/xml. See RFC 3023 [RFC3023], section 3.2.
Restrictions on usage:
Security considerations:

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.

REX 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 REX 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 REX and of XML in general, it is possible that "application/rex+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 REX 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.

Interoperability considerations:

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 REX and XML Events namespaces and in other namespaces.

Because REX is extensible, conformant "application/rex+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.

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

Published specification:

This media type registration is extracted from Appendix A of the REX 1.0 specification.

Additional information:
Person & email address to contact for further information:
Robin Berjon (member-rex-media-type@w3.org).
Intended usage:
Author/Change controller:
The REX specification is a joint work product of the World Wide Web Consortium's SVG and Web APIs Working Groups. The W3C has change control over this specification.

B. References

Document Object Model (DOM) Level 3 Core Specification, Arnaud Le Hors (IBM), Philippe Le Hégaret (W3C), Lauren Wood (SoftQuad, Inc.), Gavin Nicol (Inso EPS), Jonathan Robie (Texcel Research and Software AG), Mike Champion (Arbortext and Software AG), and Steve Byrne (JavaSoft).
Document Object Model (DOM) Level 3 Events Specification, Philippe Le Hégaret (W3C), and Tom Pixley (Netscape Communications Corporation).
QA Framework: Specification Guidelines, Karl Dubost, Lynne Rosenthal, Dominique Hazaël-Massieux, and Lofton Henderson.
GZIP file format specification version 4.3, P. Deutsch.
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
XML Media Types, M. Murata, S. St.Laurent, and D. Kohn.
Synchronized Multimedia Integration Language (SMIL 2.1), Dick Bulterman (CWI), Guido Grassel (Nokia), Jack Jansen (CWI), Antti Koivisto (Nokia), Nabil Layaïda (INRIA), Thierry Michel (W3C), Sjoerd Mullender (CWI), and Daniel Zucker (Access Co., Ltd.).
Scalable Vector Graphics (SVG) Tiny 1.2 Specification, Ola Andersson <ola.andersson@ikivo.com>, Robin Berjon <robin.berjon@expway.fr>, Jon Ferraiolo <jon.ferraiolo@adobe.com>, Vincent Hardy <vincent.hardy@sun.com>, Scott Hayman, Dean Jackson <dean@w3.org>, Craig Northway <craign@cisra.canon.com.au>, and Antoine Quint <aq@fuchsia-design.com>.
All references to XML in this specification refer to both XML 1.0 and XML 1.1.
XML Events, Shane McCarron (Applied Testing and Technology, Inc.), Steven Pemberton (CWI/W3C®), and T. V. Raman (IBM Corporation).
All references to Namespaces in XML in this specification refer both to versions 1.0 and 1.1, applying respectively to XML 1.0 and XML 1.1.
XML Path Language (XPath), James Clark <jjc@jclark.com>, and Steve DeRose <Steven_DeRose@Brown.edu>.