You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2516 lines
142 KiB
2516 lines
142 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<!--
|
|
******* WARNING *********************************************************
|
|
This document was automatically generated using the Re-Spec specification
|
|
publishing system. Edits made here will be lost when it is regenerated
|
|
and chances are high that the editor will do something quite unpleasant
|
|
to you should that happen.
|
|
******* WARNING *********************************************************
|
|
-->
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|
<title>Remote Events for XML (REX) 1.0</title>
|
|
<link rel="stylesheet" href="respec-w3c.css" type="text/css" />
|
|
<link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD" type="text/css" />
|
|
<meta name="revision" content="$Id: Overview.html,v 1.4 2006/10/13 14:39:46 dean Exp $" />
|
|
</head>
|
|
<body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C" /></a></p><h1 class="head">Remote Events for XML (REX) 1.0</h1><h2 id="pagesubtitle">W3C Working Draft <em>13 October 2006</em></h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2006/WD-rex-20061013/">http://www.w3.org/TR/2006/WD-rex-20061013/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/rex">http://www.w3.org/TR/rex</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2006/WD-rex-20060202">http://www.w3.org/TR/2006/WD-rex-20060202</a></dd><dt>Editor:</dt><dd><span class="person"><a href="http://berjon.com/">Robin Berjon</a> (<a href="http://expway.com/">Expway</a>) <<a href="mailto:robin.berjon@expway.fr">robin.berjon@expway.fr</a>></span></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2006
|
|
<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
(<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
|
|
<a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C
|
|
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
|
|
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
|
|
</p></div><hr />
|
|
|
|
|
|
<h2 id="specabstract">Abstract</h2><div class="section">
|
|
|
|
|
|
<p>
|
|
Remote Events for <acronym title="Extensible Markup Language">XML</acronym> (<acronym title="Remote Events for XML">REX</acronym>) 1.0 is an <acronym title="Extensible Markup Language">XML</acronym>
|
|
[<cite><a href="#" class="bibref"><acronym title="Extensible Markup Language">XML</acronym></a></cite>] grammar for representing events as they are defined in
|
|
<acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>], primarily
|
|
but not exclusively for purposes of transmission. It enables one endpoint to
|
|
interact remotely with another endpoint holding a <acronym title="Document Object Model">DOM</acronym> representation by
|
|
sending it <acronym title="Document Object Model">DOM</acronym> Events as if they had occurred directly at the same location.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="sotd">Status of this Document</h2>
|
|
|
|
|
|
|
|
<p>
|
|
<em>This section describes the status of this document at the time of its publication.
|
|
Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the
|
|
latest revision of this technical report can be found in the
|
|
<a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym>
|
|
technical reports index</a> at http://www.w3.org/TR/.</em>
|
|
</p>
|
|
|
|
<p>
|
|
This document is a Working Draft produced by a joint task force of the
|
|
<a href="http://www.w3.org/Graphics/SVG/"><acronym title="Scalable Vector Graphics">SVG</acronym>
|
|
<acronym title="Working Group">WG</acronym></a> (part of the
|
|
<a href="http://www.w3.org/Graphics/Activity">Graphics Activity</a>) and the
|
|
<a href="http://www.w3.org/2006/webapi">Web API <acronym title="Working Group">WG</acronym></a> (part of the
|
|
<a href="http://www.w3.org/2006/rwc/Activity">Rich Web Clients Activity</a>).
|
|
Please send comments to <a href="mailto:public-webapi@w3.org">public-webapi@w3.org</a>
|
|
(<a href="http://lists.w3.org/Archives/Public/public-webapi/">Archive</a>),
|
|
the public email list for issues related to Web APIs.
|
|
</p>
|
|
<p>
|
|
This document is governed by the
|
|
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.
|
|
<acronym title="World Wide Web Consortium">W3C</acronym> maintains the
|
|
<a href="http://www.w3.org/Graphics/SVG/Disclosures" rel="disclosure"><acronym title="Scalable Vector Graphics">SVG</acronym> Working Group's public list of patent disclosures</a>
|
|
and the <a href="http://www.w3.org/2004/01/pp-impl/38482/status" rel="disclosure">Web API Working Group's public list of patent
|
|
disclosures</a> made in connection with the deliverables of these groups; that page also includes instructions for disclosing a
|
|
patent. An individual who has actual knowledge of a patent which the individual believes
|
|
contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a>
|
|
must disclose the information in accordance with
|
|
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6
|
|
of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.
|
|
</p>
|
|
|
|
<p>
|
|
Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> 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.
|
|
</p>
|
|
|
|
</div>
|
|
|
|
<div class="section"><h2 id="contents">Table of Contents</h2>
|
|
|
|
<ul class="toc"><li><a href="#overview">1. Overview</a></li><li><ul class="toc"><li><a href="#usage">1.1. Examples of usage</a></li><li><ul class="toc"><li><a href="#eg-setattr">1.1.1. Setting an attribute</a></li><li><a href="#eg-addelem">1.1.2. Inserting an element</a></li><li><a href="#eg-delelem">1.1.3. Removing an element</a></li><li><a href="#eg-repelem">1.1.4. Replacing an element</a></li><li><a href="#eg-newdoc">1.1.5. Replacing the entire document</a></li><li><a href="#eg-cdata">1.1.6. Updating text</a></li></ul></li></ul></li><li><a href="#structure">2. Structure of a <acronym title="Remote Events for XML">REX</acronym> message</a></li><li><ul class="toc"><li><a href="#elem-rex">2.1. The <code class="elem-name"><rex></code> element</a></li><li><a href="#attr-ns">2.2. The
|
|
'<code class="attr-name">ns</code>'
|
|
attribute</a></li><li><a href="#elem-event">2.3. The <code class="elem-name"><event></code> element</a></li></ul></li><li><a href="#referencing">3. Referencing target nodes</a></li><li><ul class="toc"><li><a href="#processing-paths">3.1. Processing target paths</a></li><li><a href="#path-syntax">3.2. Path syntax</a></li></ul></li><li><a href="#processing">4. Processing model</a></li><li><ul class="toc"><li><a href="#proc-mapping-ev">4.1. Mapping <code class="elem-name"><event></code> elements to Event objects</a></li><li><a href="#proc-ukn-ev">4.2. Processing unknown events</a></li><li><a href="#proc-ukn-nodes">4.3. Processing unsupported node types</a></li></ul></li><li><a href="#extensibility">5. Extensibility</a></li><li><ul class="toc"><li><a href="#ext-ukn-el">5.1. Unknown elements</a></li><li><a href="#ext-ukn-at">5.2. Unknown attributes on <acronym title="Remote Events for XML">REX</acronym> elements</a></li></ul></li><li><a href="#error">6. Error handling</a></li><li><ul class="toc"><li><a href="#error-target-doc">6.1. Errors specific to the <acronym title="Document Object Model">DOM</acronym> or to the target language</a></li><li><a href="#error-ignore">6.2. Ignored events and elements</a></li></ul></li><li><a href="#streaming">7. Streaming Module</a></li><li><ul class="toc"><li><a href="#reference-event">7.1. Defining the Reference Event</a></li><li><a href="#attr-timeRef">7.2. The
|
|
'<code class="attr-name">timeRef</code>'
|
|
attribute</a></li><li><a href="#attr-timeStamp">7.3. The
|
|
'<code class="attr-name">timeStamp</code>'
|
|
attribute</a></li><li><a href="#tune-in">7.4. Tuning in to an event stream</a></li></ul></li><li><a href="#mutation">8. Encoding Mutation Events</a></li><li><ul class="toc"><li><a href="#mutation-mapping-ev">8.1. Mapping Mutation Events to objects</a></li><li><a href="#event-DOMSubtreeModified">8.2. The
|
|
'<code class="event-name">DOMSubtreeModified</code>'
|
|
event</a></li><li><a href="#event-DOMNodeInserted">8.3. The
|
|
'<code class="event-name">DOMNodeInserted</code>'
|
|
event</a></li><li><a href="#event-DOMNodeRemoved">8.4. The
|
|
'<code class="event-name">DOMNodeRemoved</code>'
|
|
event</a></li><li><a href="#event-DOMNodeRemovedFromDocument">8.5. The
|
|
'<code class="event-name">DOMNodeRemovedFromDocument</code>'
|
|
event</a></li><li><a href="#event-DOMNodeInsertedIntoDocument">8.6. The
|
|
'<code class="event-name">DOMNodeInsertedIntoDocument</code>'
|
|
event</a></li><li><a href="#event-DOMAttrModified">8.7. The
|
|
'<code class="event-name">DOMAttrModified</code>'
|
|
event</a></li><li><a href="#event-DOMCharacterDataModified">8.8. The
|
|
'<code class="event-name">DOMCharacterDataModified</code>'
|
|
event</a></li><li><a href="#mutation-namechange">8.9. Mutation name events</a></li></ul></li><li><a href="#conformance">9. Conformance</a></li><li><ul class="toc"><li><a href="#attribute-values">9.1. Parsing attribute values</a></li><li><a href="#conform-checklist">9.2. Conformance to the QA Framework Specification Guidelines</a></li><li><a href="#optional-features">9.3. Optional features</a></li></ul></li><li><a href="#acknow">10. Acknowledgements</a></li></ul><ul class="toc"><li><a href="#media-type">A. Media Type registration for <code>application/rex+xml</code></a></li><li><a href="#changes">B. Changes since the last version</a></li><li><a href="#bibref">C. References</a></li></ul>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="overview">1. Overview</h2><p><strong>This section is informative.</strong></p>
|
|
|
|
|
|
<p>
|
|
The <strong>Remote Events for <acronym title="Extensible Markup Language">XML</acronym></strong> (<acronym title="Remote Events for XML">REX</acronym>) specification
|
|
defines a <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">transport agnostic</a>
|
|
<acronym title="Extensible Markup Language">XML</acronym> syntax for the transmission of <acronym title="Document Object Model">DOM</acronym> events as specified in the <acronym title="Document Object Model">DOM</acronym> 3 Events
|
|
specification [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] in such a way as to be compatible with streaming protocols. <acronym title="Remote Events for XML">REX</acronym> assumes that the transport
|
|
provides for reliable, timely and in sequence delivery of <acronym title="Remote Events for XML">REX</acronym> messages. <acronym title="Remote Events for XML">REX</acronym> does not cover the process of session
|
|
initiation and termination which are presumed to be handled by other means.
|
|
</p>
|
|
<p>
|
|
The first version of this specification deliberately restricts itself to the transmission of mutation
|
|
events (events which notify of changes to the structure or content of the document) 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.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="usage">1.1. Examples of usage</h3>
|
|
|
|
|
|
<p>
|
|
A variety of usage situations in for which <acronym title="Remote Events for XML">REX</acronym> can be used are exemplified
|
|
below, also showing some specific features available when using <acronym title="Remote Events for XML">REX</acronym>.
|
|
</p>
|
|
|
|
<div class="section"><h4 id="eg-setattr">1.1.1. Setting an attribute</h4>
|
|
|
|
<p>
|
|
The following <acronym title="Remote Events for XML">REX</acronym> message sets the <code>fetch</code> attribute to "ball"
|
|
on an element that has an ID of <code>spot</code>.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Setting an attribute</span></div><pre class="example" title="Setting an attribute"><rex xmlns='http://www.w3.org/ns/rex#'>
|
|
<event target='id("spot")' attrName='fetch' name='DOMAttrModified' newValue='ball'/>
|
|
</rex></pre></div>
|
|
|
|
<p>
|
|
Note that we do not specify the
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
|
|
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.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h4 id="eg-addelem">1.1.2. Inserting an element</h4>
|
|
|
|
<p>
|
|
The following <acronym title="Remote Events for XML">REX</acronym> message adds a row at the seventh position (that is,
|
|
after the current sixth and before the current seventh, which becomes the
|
|
eighth) in the second table contained in the document's body.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Inserting an element</span></div><pre class="example" title="Inserting an element"><rex xmlns='http://www.w3.org/ns/rex#' xmlns:x='http://www.w3.org/1999/xhtml'>
|
|
<event target='/x:html/x:body/x:table[2]' name='DOMNodeInserted' position='7'>
|
|
<tr xmlns='http://www.w3.org/1999/xhtml'>
|
|
<td>Rover</td>
|
|
<td>Alpine Labrador</td>
|
|
<td class='food'>bone</td>
|
|
</tr>
|
|
</event>
|
|
</rex></pre></div>
|
|
</div>
|
|
|
|
<div class="section"><h4 id="eg-delelem">1.1.3. Removing an element</h4>
|
|
|
|
<p>
|
|
The following <acronym title="Remote Events for XML">REX</acronym> message removes the <em>first</em> circle
|
|
that is a child of the element with id <code>poodle-stylist-location-layer</code>.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Removing an element</span></div><pre class="example" title="Removing an element"><rex xmlns='http://www.w3.org/ns/rex#' xmlns:svg='http://www.w3.org/2000/svg'>
|
|
<event target='id("poodle-stylist-location-layer")/svg:circle' name='DOMNodeRemoved'/>
|
|
</rex></pre></div>
|
|
|
|
<p>
|
|
Note that while the target path may match multiple elements, <acronym title="Remote Events for XML">REX</acronym>
|
|
limits the list to the first one that matches. Future versions may
|
|
include a flag to target multiple elements.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h4 id="eg-repelem">1.1.4. Replacing an element</h4>
|
|
|
|
<p>
|
|
The following <acronym title="Remote Events for XML">REX</acronym> message replaces an element with ID <code>femur</code>
|
|
with the new one provided in the payload.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Replacing an element</span></div><pre class="example" title="Replacing an element"><rex xmlns='http://www.w3.org/ns/rex#'>
|
|
<event target='id("femur")' name='DOMNodeRemoved'>
|
|
<bone xmlns='http://example.org/BoneML' xml:id='tibia'>
|
|
<taste>good</taste>
|
|
<smell>excellent</smell>
|
|
<solidity>medium</solidity>
|
|
<availability>common</availability>
|
|
</bone>
|
|
</event>
|
|
</rex></pre></div>
|
|
|
|
<p>
|
|
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 <acronym title="Remote Events for XML">REX</acronym> user-agent
|
|
processes both in the exact same manner — which also matches the manner in
|
|
which a <acronym title="Document Object Model">DOM</acronym> 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).
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h4 id="eg-newdoc">1.1.5. Replacing the entire document</h4>
|
|
|
|
<p>
|
|
The following <acronym title="Remote Events for XML">REX</acronym> message replaces an entire <acronym title="Scalable Vector Graphics">SVG</acronym> document with a new one.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Replacing an entire document</span></div><pre class="example" title="Replacing an entire document"><rex xmlns='http://www.w3.org/ns/rex#'>
|
|
<event target='/' name='DOMNodeRemoved'>
|
|
<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 300 400'>
|
|
<defs>
|
|
<!-- ... --->
|
|
</defs>
|
|
<g>
|
|
<rect x='42' y='27' width='100' height='200' fill='orange'/>
|
|
<!-- ... --->
|
|
</g>
|
|
</svg>
|
|
</event>
|
|
</rex></pre></div>
|
|
|
|
<p>
|
|
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 "<code>/</code>".
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h4 id="eg-cdata">1.1.6. Updating text</h4>
|
|
|
|
<p>
|
|
All nodes, including text, can be updated directly. However character
|
|
data has specific events in the <acronym title="Document Object Model">DOM</acronym> that are more straightforward and
|
|
can be more lightweight to use. <acronym title="Remote Events for XML">REX</acronym> supports encapsulating such
|
|
updates as well. The following example updates the seventh <code>tspan</code>
|
|
element's textual data with new text.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Updating character data directly</span></div><pre class="example" title="Updating character data directly"><rex xmlns='http://www.w3.org/ns/rex#' xmlns:svg='http://www.w3.org/2000/svg'>
|
|
<event target='/svg:svg/svg:g[2]/svg:tspan[7]/text()' name='DOMCharacterDataModified' newValue='Hello World!'/>
|
|
</rex></pre></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="structure">2. Structure of a <acronym title="Remote Events for XML">REX</acronym> message</h2>
|
|
|
|
|
|
<p>
|
|
The namespace for the <acronym title="Remote Events for XML">REX</acronym> language is: <code>http://www.w3.org/ns/rex#</code>.
|
|
</p>
|
|
<p>
|
|
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 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be able to process extensions to the syntax defined in this version,
|
|
as detailed in the <a href="#extensibility">Extensibility</a> section.
|
|
</p>
|
|
<p>
|
|
All <acronym title="Remote Events for XML">REX</acronym> messages <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be contained within a <a href="#elem-rex" class="elem-name"><rex></a> element. <acronym title="Remote Events for XML">REX</acronym> messages <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be
|
|
contained within other <acronym title="Extensible Markup Language">XML</acronym> elements in other namespaces, but each <acronym title="Remote Events for XML">REX</acronym> fragment <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
still have a <a href="#elem-rex" class="elem-name"><rex></a> element as its root.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="elem-rex">2.1. The <code class="elem-name"><rex></code> element</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="#elem-rex" class="elem-name"><rex></a> element serves as the root container for the entire <acronym title="Remote Events for XML">REX</acronym> message.
|
|
It <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be present, even if there is only one <a href="#elem-event" class="elem-name"><event></a> element. Elements in
|
|
the <acronym title="Remote Events for XML">REX</acronym> namespace that do not have a <a href="#elem-rex" class="elem-name"><rex></a> ancestor <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored by
|
|
the user-agent.
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="schemaTitle">Element rex</span></p><pre class="schema" title="Element rex"><define name='<a id="rng-rex" title="Definition of |rex|" class="rngref">rex</a>'>
|
|
<element name='<strong >rex</strong>'>
|
|
<optional>
|
|
<attribute name='<strong >minimal-version</strong>'>
|
|
<value>1.0</value>
|
|
</attribute>
|
|
</optional>
|
|
<optional>
|
|
<attribute name='<strong >target-document</strong>'>
|
|
<text/>
|
|
</attribute>
|
|
</optional>
|
|
<ref name='<a href="#rng-ns" title="Reference to the |ns| definition" class="rngref">ns</a>'/>
|
|
<ref name='<a href="#rng-rex.AT" title="Reference to the |rex.AT| definition" class="rngref">rex.AT</a>'/>
|
|
<oneOrMore>
|
|
<ref name='<a href="#rng-event" title="Reference to the |event| definition" class="rngref">event</a>'/>
|
|
</oneOrMore>
|
|
</element>
|
|
</define>
|
|
</pre></div>
|
|
|
|
<h4 class="attrlist" id="attr-list-elem-rex">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-rex-minimal-version">minimal-version</dt>
|
|
<dd>
|
|
Indicates the minimum version of the <acronym title="Remote Events for XML">REX</acronym> 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 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> therefore compare the provided
|
|
'<a href="#attr-rex-minimal-version" class="attr-name">minimal-version</a>'
|
|
against the strings
|
|
of all versions that they know and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> perform numeric comparisons. This entails that
|
|
<code>1.0</code>, <code>1</code>, or <code>1.00</code> are all different versions.
|
|
A user-agent supporting this version of the specification <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> accept version identifier
|
|
<code>1.0</code>. If the version number is not in the list of versions of this specification
|
|
supported by the user-agent, the user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> reject the message completely and
|
|
immediately, ignoring the entirety of its content.
|
|
</dd>
|
|
<dt id="attr-rex-target-document">target-document</dt>
|
|
<dd>
|
|
In some cases a user-agent may have multiple document in memory, or even inside
|
|
the current view. The
|
|
'<a href="#attr-rex-target-document" class="attr-name">target-document</a>'
|
|
attribute is used to identify
|
|
which document is being addressed by this given <acronym title="Remote Events for XML">REX</acronym> message. Its content is an
|
|
opaque string, and the manner in which the user-agent maps such identifiers to
|
|
the documents that it contains as well as the absence of a
|
|
'<a href="#attr-rex-target-document" class="attr-name">target-document</a>'
|
|
|
|
identifier to a "default" or "active" document is left for the target environments
|
|
to define. An empty
|
|
'<a href="#attr-rex-target-document" class="attr-name">target-document</a>'
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed as if the attribute
|
|
had not been specified. If a user-agent receives a <acronym title="Remote Events for XML">REX</acronym> message with a
|
|
|
|
'<a href="#attr-rex-target-document" class="attr-name">target-document</a>'
|
|
that it cannot map onto a document then the entire <acronym title="Remote Events for XML">REX</acronym>
|
|
message <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</dd>
|
|
<dt>Other attributes</dt>
|
|
<dd>
|
|
See
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
.
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>
|
|
The <a href="#elem-rex" class="elem-name"><rex></a> element <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> contain one or more <a href="#elem-event" class="elem-name"><event></a> elements. Otherwise,
|
|
the message is invalid and the user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> ignore it entirely.
|
|
</p>
|
|
|
|
<div class="boxed"><div><span class="exampleTitle">Example: a complete REX message</span></div><pre class="example" title="a complete REX message"><rex xmlns='http://www.w3.org/ns/rex#'
|
|
xmlns:svg='http://www.w3.org/2000/svg'>
|
|
|
|
<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>
|
|
<event target='id("dahut")' name='DOMNodeRemoved'>
|
|
<svg:circle cx='19' cy='17' r='42' fill='orange'/>
|
|
</event>
|
|
</rex></pre></div>
|
|
</div>
|
|
|
|
|
|
<div class="section"><h3 id="attr-ns">2.2. The
|
|
'<code class="attr-name">ns</code>'
|
|
attribute</h3>
|
|
|
|
|
|
<p>
|
|
The
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute defines the namespace that applies to <acronym title="Document Object Model">DOM</acronym> event names within the
|
|
scope of the element on which it occurs. For any given <acronym title="Document Object Model">DOM</acronym> event name, if there is no
|
|
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute on any of its ancestor elements, that event name's URI component is
|
|
the empty string. Otherwise, it will have the namespace
|
|
component corresponding to the first
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute found on its ancestor
|
|
elements in reverse document order. The content of the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute is either
|
|
an IRI or the empty string. If the empty string then event names in its applicable
|
|
scope will have no namespace URI component.
|
|
</p>
|
|
<p>
|
|
If the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute contains a non-empty string, then it <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be a valid IRI.
|
|
However, given the complexity involved in checking IRI validity it is not <em class="rfc2119" title="Keyword in RFC 2119 context">RECOMMENDED</em>
|
|
that user-agents validate them. If however IRI validation is performed and the IRI value
|
|
of the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute is found to be false, then the entire subtree inclusive of
|
|
the element on which the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute occurs <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="schemaTitle">Attribute ns</span></p><pre class="schema" title="Attribute ns"><define name='<a id="rng-ns" title="Definition of |ns|" class="rngref">ns</a>'>
|
|
<optional>
|
|
<attribute name='<strong >ns</strong>'>
|
|
<choice>
|
|
<data type='anyURI'/>
|
|
<empty/>
|
|
</choice>
|
|
</attribute>
|
|
</optional>
|
|
</define>
|
|
</pre></div>
|
|
</div>
|
|
|
|
|
|
<div class="section"><h3 id="elem-event">2.3. The <code class="elem-name"><event></code> element</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="#elem-event" class="elem-name"><event></a> element is used to encode any kind of event that may be captured in <acronym title="Remote Events for XML">REX</acronym>.
|
|
While the
|
|
'<a href="#attr-event-name" class="attr-name">name</a>'
|
|
and
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attributes <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always be specified, the rest
|
|
of its content model depends on the event that it captures. Each <a href="#elem-event" class="elem-name"><event></a> element
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> produce at least one corresponding <acronym title="Document Object Model">DOM</acronym> event (and on some occasions a modification
|
|
of the <acronym title="Document Object Model">DOM</acronym> tree) unless it is ignored according to a part of this specification.
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="schemaTitle">Element event</span></p><pre class="schema" title="Element event"><define name='<a id="rng-event" title="Definition of |event|" class="rngref">event</a>'>
|
|
<element name='<strong >event</strong>'>
|
|
<ref name='<a href="#rng-ns" title="Reference to the |ns| definition" class="rngref">ns</a>'/>
|
|
<attribute name='<strong >target</strong>'>
|
|
<text/>
|
|
</attribute>
|
|
<attribute name='<strong >name</strong>'>
|
|
<data type='NMTOKEN'/>
|
|
</attribute>
|
|
<ref name='<a href="#rng-timeStamp.AT" title="Reference to the |timeStamp.AT| definition" class="rngref">timeStamp.AT</a>'/>
|
|
<ref name='<a href="#rng-timeRef.AT" title="Reference to the |timeRef.AT| definition" class="rngref">timeRef.AT</a>'/>
|
|
<choice>
|
|
<ref name='<a href="#rng-DOMNodeInserted" title="Reference to the |DOMNodeInserted| definition" class="rngref">DOMNodeInserted</a>'/>
|
|
<ref name='<a href="#rng-DOMNodeRemoved" title="Reference to the |DOMNodeRemoved| definition" class="rngref">DOMNodeRemoved</a>'/>
|
|
<ref name='<a href="#rng-DOMAttrModified" title="Reference to the |DOMAttrModified| definition" class="rngref">DOMAttrModified</a>'/>
|
|
<ref name='<a href="#rng-DOMCharacterDataModified" title="Reference to the |DOMCharacterDataModified| definition" class="rngref">DOMCharacterDataModified</a>'/>
|
|
</choice>
|
|
</element>
|
|
</define>
|
|
</pre></div>
|
|
|
|
<h4 class="attrlist" id="attr-list-elem-event">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-event-name">name</dt>
|
|
<dd>
|
|
Contains the local name component of the name of the event represented by this <a href="#elem-event" class="elem-name"><event></a>
|
|
element. The namespace URI component of the event's name <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be resolved based on the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
|
|
attribute.
|
|
</dd>
|
|
<dt id="attr-event-target">target</dt>
|
|
<dd>
|
|
The
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attribute contains the target path
|
|
as described in the <a href="#referencing">Referencing target nodes</a> section.
|
|
</dd>
|
|
<dt>Other attributes</dt>
|
|
<dd>
|
|
See
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="referencing">3. Referencing target nodes</h2>
|
|
|
|
|
|
<p>
|
|
Target nodes are referenced using a <a href="#path-syntax">subset of XPath</a> [<cite><a href="#XPATH" class="bibref">XPATH</a></cite>]
|
|
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.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="processing-paths">3.1. Processing target paths</h3>
|
|
|
|
<p>
|
|
Target paths <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> 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 unless a superset of the minimal
|
|
syntax is used.
|
|
</p>
|
|
<p>
|
|
If the size of the node-set is superior to one, only the first item in that node-set
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be considered for processing, and the rest <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be discarded.
|
|
</p>
|
|
|
|
<p>
|
|
If the size of the node-set is zero, the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored and thus nothing happens.
|
|
</p>
|
|
<p>
|
|
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 <code>xml</code> required by Namespaces in <acronym title="Extensible Markup Language">XML</acronym> [<cite><a href="#XMLNS" class="bibref">XMLNS</a></cite>]; the default namespace
|
|
(as declared by <code>xmlns</code>) is <em>not</em> part of this set.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="path-syntax">3.2. Path syntax</h3>
|
|
|
|
|
|
<p>
|
|
The syntax for target paths is a very simple subset of XPath described by the following
|
|
syntax, in which the <code>Name</code> token is taken from the <acronym title="Extensible Markup Language">XML</acronym> specification [<cite><a href="#" class="bibref"><acronym title="Extensible Markup Language">XML</acronym></a></cite>]
|
|
and the <code>NCName</code> token is from the Namespaces in <acronym title="Extensible Markup Language">XML</acronym> specification [<cite><a href="#XMLNS" class="bibref">XMLNS</a></cite>].
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="ebnfTitle">EBNF for target paths</span></p><pre class="ebnf" title="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()') ('[' Num ']')?
|
|
NCNameStr ::= "'" NCName "'" | '"' NCName '"'
|
|
Num ::= [0-9]+
|
|
</pre></div>
|
|
|
|
<p>
|
|
User-agents <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> support a superset of this syntax so long as it is a valid instance of
|
|
the XPath language [<cite><a href="#XPATH" class="bibref">XPATH</a></cite>]. Content producers however <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em> use such extensions
|
|
as they hamper interoperability.
|
|
</p>
|
|
<p>
|
|
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 <code>id()</code>
|
|
function. The <code>id()</code> 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 only of the child
|
|
axis, and only element name tests. The final step in the list is more
|
|
powerful and may also reference text nodes. For each step a predicate may
|
|
be used, which is limited to only containing an integer indicating position.
|
|
</p>
|
|
<p>
|
|
Some examples of target paths include:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>/svg:svg</code> will match the root <code>svg</code> element, in the namespace
|
|
that has been bound to the 'svg' prefix.
|
|
</li>
|
|
<li>
|
|
<code>/lodges/donkey[8]</code> will match the eighth <code>donkey</code> element in the
|
|
<code>lodges</code> element with no namespace.
|
|
</li>
|
|
<li>
|
|
<code>/</code> will match the root node, which is to say the document itself.
|
|
</li>
|
|
<li>
|
|
<code>/foo/text()</code> will match the first text node that is a child of the
|
|
the <code>foo</code> element.
|
|
</li>
|
|
<li>
|
|
<code>/xhtml:html/xhtml:body/svg:svg[3]</code> will match the third <code>svg</code>
|
|
element that is a child of the root <code>body</code> and then <code>html</code>
|
|
elements.
|
|
</li>
|
|
<li>
|
|
<code>id("dahut")</code> will match the element with ID 'dahut'.
|
|
</li>
|
|
<li>
|
|
<code>id("dahut")/svg:circle</code> will match the first <code>circle</code> element
|
|
that is a child of the element with ID 'dahut'.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Note that it is possible using this syntax to produce target paths that will never match
|
|
anything (for instance <code>/element[2]</code>). Such constructions simply cause the
|
|
event to be ignored.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="processing">4. Processing model</h2>
|
|
|
|
|
|
<p>
|
|
This section defines how <acronym title="Remote Events for XML">REX</acronym> messages are processed by user-agents. Its intent is not to
|
|
prescribe implementation details — the processing <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be implemented in ways that differ
|
|
from the steps described below, but if so the effect <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be exactly equivalent.
|
|
</p>
|
|
<p>
|
|
It is <em class="rfc2119" title="Keyword in RFC 2119 context">RECOMMENDED</em> that <acronym title="Remote Events for XML">REX</acronym> 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 <acronym title="Remote Events for XML">REX</acronym> message <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> 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.
|
|
</p>
|
|
<p>
|
|
Events that do not have a time stamp <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched in the same order in which they occur
|
|
in the <acronym title="Remote Events for XML">REX</acronym> message. If the user-agent supports the <a href="#streaming">Streaming Module</a>
|
|
then events that have a time stamp <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be caused to be processed in an order different from
|
|
the one in which they occur in the <acronym title="Remote Events for XML">REX</acronym> message, as described below.
|
|
</p>
|
|
<p>
|
|
Because user-agents are encouraged to process events that do not have a time stamp as soon as
|
|
possible, a <acronym title="Remote Events for XML">REX</acronym> message containing a well-formedness error <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> still cause previous
|
|
<a href="#elem-event" class="elem-name"><event></a> elements to be fully processed. Upon encountering a well-formedness error, a <acronym title="Remote Events for XML">REX</acronym>
|
|
user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> stop processing immediately such that the remainder of the <acronym title="Extensible Markup Language">XML</acronym> document <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
ignored and any event scheduled to be dispatched at a later time due to its time stamp <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
discarded. If the well-formedness error is contained inside an <a href="#elem-event" class="elem-name"><event></a> element, the
|
|
corresponding event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> also be ignored.
|
|
</p>
|
|
<p>
|
|
As soon as an <a href="#elem-event" class="elem-name"><event></a> element is parsed, and provided that it is not
|
|
ignored according to this specification, the following steps take place:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
an <code>Event</code> object (as defined in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>]) <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be created as defined
|
|
in the <a href="#proc-mapping-ev">Mapping event elements to Event objects</a>
|
|
section below. Note that in some cases, multiple <code>Event</code> objects may be created
|
|
by a single <a href="#elem-event" class="elem-name"><event></a> element (e.g. for the
|
|
'<a href="#event-DOMNodeRemoved" class="event-name">DOMNodeRemoved</a>'
|
|
event).
|
|
</li>
|
|
<li>
|
|
if the event has an explicit time stamp and the user-agent supports the
|
|
<a href="#streaming">Streaming Module</a>, the time stamp is evaluated as an offset from the
|
|
<a href="#reference-event">reference event</a> and the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched that many
|
|
ticks after the current reference event. If the time resolved thus has already occurred,
|
|
the the event is processed immediately as if the time stamp had not been specified.
|
|
Likewise, if the user-agent does not support the <a href="#streaming">Streaming Module</a>,
|
|
the the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed immediately. When an event is queued to be dispatched at
|
|
a later time, its processing <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> resume with the next step.
|
|
</li>
|
|
<li>
|
|
the target path <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be resolved, as defined in <a href="#referencing">Referencing
|
|
target nodes</a>.
|
|
</li>
|
|
<li>
|
|
if the previous step produced a node and it is not ignored according to this specification,
|
|
the event or events initialised in step 1 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched as if by a call to
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTarget-dispatchEvent">EventTarget.dispatchEvent()</a>.
|
|
If the event is defined to have side-effect (such as modifying the <acronym title="Document Object Model">DOM</acronym> tree,
|
|
as is the case with <a href="#mutation">mutation events</a>), this is the moment
|
|
at which the side-effect <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> occur. Whether the side-effect occurs immediately
|
|
preceding or following the event being dispatched is specified for each such
|
|
event.
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
As soon as an <a href="#elem-event" class="elem-name"><event></a> element has been processed, the implementation <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> discard it
|
|
from memory so as to consume fewer resources.
|
|
</p>
|
|
<p>
|
|
There is no requirement on the user-agent to support a <acronym title="Document Object Model">DOM</acronym> interface in order to still implement
|
|
events received through <acronym title="Remote Events for XML">REX</acronym> messages. For instance, specifications such as SMIL [<cite><a href="#SMIL2" class="bibref">SMIL2</a></cite>]
|
|
or <acronym title="Extensible Markup Language">XML</acronym> Events [<cite><a href="#XMLEV" class="bibref">XMLEV</a></cite>] may be handling events received through <acronym title="Remote Events for XML">REX</acronym> messages in the absence
|
|
of a <acronym title="Document Object Model">DOM</acronym> representation of the document tree.
|
|
</p>
|
|
<p>
|
|
Note that given the presence of time stamps, it is possible for content to require of the
|
|
user-agent that it queue up a potentially unlimited number of events, which may lead to
|
|
exhausting available memory. In order to avoid this, servers <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> arrange to deliver
|
|
events in a sequence that minimises memory requirements for user-agents. Also,
|
|
user-agents <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> process events earlier than indicated if not doing so would result
|
|
in exhausting memory resources. If doing so, then user-agents <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> process these events
|
|
in the order in which the timing would have required that they process them.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="proc-mapping-ev">4.1. Mapping <code class="elem-name"><event></code> elements to Event objects</h3>
|
|
|
|
<p>
|
|
In processing <a href="#elem-event" class="elem-name"><event></a> elements and converting them into Event objects,
|
|
the user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> inform the various fields of the object in the following manner:
|
|
</p>
|
|
<dl>
|
|
<dt>type</dt>
|
|
<dd>
|
|
Set to the
|
|
'<a href="#attr-event-name" class="attr-name">name</a>'
|
|
attribute of the <a href="#elem-event" class="elem-name"><event></a> element.
|
|
</dd>
|
|
<dt>namespaceURI</dt>
|
|
<dd>
|
|
Set to URI equivalent of the value of the
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
attribute, resolved as described in its
|
|
own section.
|
|
</dd>
|
|
<dt>target</dt>
|
|
<dd>
|
|
Set dynamically to be in turn each node in the node-set obtained by resolving
|
|
the target path.
|
|
</dd>
|
|
<dt>currentTarget</dt>
|
|
<dd>
|
|
Set dynamically as the event is being processed, as described in the
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-flow"><acronym title="Document Object Model">DOM</acronym> event flow</a>.
|
|
</dd>
|
|
<dt>eventPhase</dt>
|
|
<dd>
|
|
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.
|
|
</dd>
|
|
<dt>bubbles</dt>
|
|
<dd>
|
|
Specifies whether an event is one that bubbles or not. The implementation
|
|
sets that using its knowledge of the given event type.
|
|
</dd>
|
|
<dt>cancelable</dt>
|
|
<dd>
|
|
Specifies whether an event can have its default action prevented or not.
|
|
The implementation sets that using its knowledge of the given event type.
|
|
</dd>
|
|
<dt>timeStamp</dt>
|
|
<dd>
|
|
If the implementation supports the
|
|
'<a href="#attr-timeStamp" class="attr-name">timeStamp</a>'
|
|
attribute and it
|
|
has been set, this field specifies the time at which the event comes into
|
|
effect. As defined in the <acronym title="Document Object Model">DOM</acronym> 3 Events specification [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] if this
|
|
field is not specified, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always be set to zero.
|
|
</dd>
|
|
</dl>
|
|
<p>
|
|
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,
|
|
<a href="#mutation">Encoding Mutation Events</a>.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="proc-ukn-ev">4.2. Processing unknown events</h3>
|
|
|
|
|
|
<p>
|
|
The are two types of unknown events:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Events the names of which do not match any known event in the version of the specification supported
|
|
by the user-agent.
|
|
</li>
|
|
<li>
|
|
Events which the user-agent understands as being defined in the specification but that have no
|
|
meaningful effect within the context in which the user-agent operates (e.g. a <code>mousemove</code>
|
|
event on a device that has no pointer device cursor).
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
When encountering an unknown even, a user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> ignore the entire <a href="#elem-event" class="elem-name"><event></a> element and
|
|
all its descendants.
|
|
</p>
|
|
<div class="ednote">
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="proc-ukn-nodes">4.3. Processing unsupported node types</h3>
|
|
|
|
|
|
<p>
|
|
There is almost always a mismatch between the information that an <acronym title="Extensible Markup Language">XML</acronym> 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 <acronym title="Extensible Markup Language">XML</acronym> 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.
|
|
</p>
|
|
<p>
|
|
It should be noted that there is no requirement that a node type captured in a <acronym title="Remote Events for XML">REX</acronym>
|
|
message have a corresponding object or interface in the <acronym title="Document Object Model">DOM</acronym> variant used by the
|
|
user-agent. For instance, the <acronym title="Scalable Vector Graphics">SVG</acronym> 1.2 MicroDOM [<cite><a href="#SVGT12" class="bibref">SVGT12</a></cite>] 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 <acronym title="Remote Events for XML">REX</acronym> messages.
|
|
</p>
|
|
<p>
|
|
The are two situations in which unsupported node types may be encountered:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
If the
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attribute points to one such node type, either directly (i.e. at the
|
|
end of the target path) or indirectly (i.e. as a step in the target path).
|
|
</li>
|
|
<li>
|
|
In the payload of the <a href="#elem-event" class="elem-name"><event></a> element.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
If the target path requires support for a node type that is not supported by the
|
|
implementation, then the user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> ignore the entire <a href="#elem-event" class="elem-name"><event></a> element and
|
|
all of its descendants.
|
|
</p>
|
|
<p>
|
|
If the payload of the <a href="#elem-event" class="elem-name"><event></a> element contains node types that are not supported
|
|
by the user-agent's <acronym title="Document Object Model">DOM</acronym> implementation the payload <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be modified so that nodes
|
|
that have no usable representation in the user-agent's <acronym title="Document Object Model">DOM</acronym> implementation are removed.
|
|
For instance, given an <acronym title="Scalable Vector Graphics">SVG</acronym> Tiny 1.2 MicroDOM [<cite><a href="#SVGT12" class="bibref">SVGT12</a></cite>], 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 <code>textContent</code> interface. If removing these nodes
|
|
from the payload causes the payload to become empty, then the entire <a href="#elem-event" class="elem-name"><event></a>
|
|
element <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored since no useful Event object could be derived from it.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="extensibility">5. Extensibility</h2>
|
|
|
|
|
|
<p>
|
|
In order for <acronym title="Remote Events for XML">REX</acronym> 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.
|
|
</p>
|
|
<p>
|
|
A <acronym title="Remote Events for XML">REX</acronym> message that is intended to be understood if and only if the user-agent supports
|
|
a minimal version of the <acronym title="Remote Events for XML">REX</acronym> specification <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> set the
|
|
'<a href="#attr-rex-minimal-version" class="attr-name">minimal-version</a>'
|
|
attribute
|
|
correspondingly. A user-agent that does not support the required version <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> then discard
|
|
the entire message. Otherwise, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> apply the following forward-compatibility rules.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="ext-ukn-el">5.1. Unknown elements</h3>
|
|
|
|
|
|
<p>
|
|
There are three categories of unknown elements:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>Elements in foreign namespaces (namespaces that are not the <acronym title="Remote Events for XML">REX</acronym> namespace)</li>
|
|
<li>Elements in the <acronym title="Remote Events for XML">REX</acronym> namespace with unknown local names</li>
|
|
<li>Elements in the <acronym title="Remote Events for XML">REX</acronym> namespace with known local names, but located in places where the grammar does not allow them</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Outside of <a href="#elem-event" class="elem-name"><event></a> payloads, when encountering an unknown element a user-agent
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> ignore it together with all of its attributes and descendant nodes.
|
|
</p>
|
|
<p>
|
|
Inside <a href="#elem-event" class="elem-name"><event></a> payloads, all elements whether they are in the <acronym title="Remote Events for XML">REX</acronym> namespace
|
|
or not are considered to constitute the content of that event, and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed
|
|
as if they were in a foreign namespace. <acronym title="Remote Events for XML">REX</acronym> elements in event payloads <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be
|
|
processed as <acronym title="Remote Events for XML">REX</acronym> elements.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="ext-ukn-at">5.2. Unknown attributes on <acronym title="Remote Events for XML">REX</acronym> elements</h3>
|
|
|
|
|
|
<p>
|
|
There are two types of unknown attributes that <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> occur on <acronym title="Remote Events for XML">REX</acronym> elements:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>Attributes in a namespace that is not the <acronym title="Extensible Markup Language">XML</acronym> namespace as defined in the Namespaces in <acronym title="Extensible Markup Language">XML</acronym> specification [<cite><a href="#XMLNS" class="bibref">XMLNS</a></cite>]</li>
|
|
<li>Attributes in no namespace that are not known to be allowed on the element on which they occur</li>
|
|
</ul>
|
|
|
|
<p>
|
|
When encountering an unknown attribute, a user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> process the corresponding element as
|
|
if the attribute had not been specified at all.
|
|
</p>
|
|
<p>
|
|
Likewise, if a known attribute with an invalid value is encountered, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored
|
|
as if it had not been specified.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="error">6. Error handling</h2>
|
|
|
|
|
|
<div class="section"><h3 id="error-target-doc">6.1. Errors specific to the <acronym title="Document Object Model">DOM</acronym> or to the target language</h3>
|
|
|
|
<p>
|
|
Some of the events that can be captured in <acronym title="Remote Events for XML">REX</acronym> messages will cause the <acronym title="Document Object Model">DOM</acronym> tree
|
|
that they target to be modified. In addition to the specific error handling
|
|
specified in the respective event definitions, the following rules apply:
|
|
</p>
|
|
<dl>
|
|
<dt><acronym title="Document Object Model">DOM</acronym> errors</dt>
|
|
<dd>
|
|
If the modification corresponds to something that is invalid in the <acronym title="Document Object Model">DOM</acronym>
|
|
(e.g. inserting an element after the root element node) then the event
|
|
is ignored.
|
|
</dd>
|
|
<dt>Target language errors</dt>
|
|
<dd>
|
|
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 the error is handled by the mechanisms prescribed in the
|
|
specification of the host language, as if the
|
|
modification had been performed through script manipulation of the <acronym title="Document Object Model">DOM</acronym>. The
|
|
exception to this rule is if such a modification being performed by using the
|
|
<acronym title="Document Object Model">DOM</acronym> directly had caused an exception to be raised: in that case the error
|
|
is treated as a <acronym title="Document Object Model">DOM</acronym> error, and the event is ignored.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="error-ignore">6.2. Ignored events and elements</h3>
|
|
|
|
<p>
|
|
For every part of this specification for which a given event or element is
|
|
said to be <em>ignored</em>, a user-agent <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> skip it as if it had not at all occurred
|
|
within the <acronym title="Remote Events for XML">REX</acronym> message (and if the entire <acronym title="Remote Events for XML">REX</acronym> message is ignored, as if it
|
|
had never been received at all). The user <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em> be informed of such
|
|
occurrences.
|
|
</p>
|
|
<p>
|
|
However if instead of a user-agent the <acronym title="Remote Events for XML">REX</acronym> processor is a content checker, then
|
|
each given occurrence of an item that is said to be <em>ignored</em> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
considered to be an error. Such errors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be reported to the user of the content
|
|
checker. More information is available on classes of <acronym title="Remote Events for XML">REX</acronym> processors in the
|
|
<a href="#conformance">Conformance section</a>.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="streaming">7. Streaming Module</h2>
|
|
|
|
|
|
<p>
|
|
This chapter of the specification contains aspects of <acronym title="Remote Events for XML">REX</acronym> that are only
|
|
useful within streaming environments in which features such as timing,
|
|
synchronisation, or tune-in are relevant. As such, it is optional for
|
|
implementations not intended to operate in such environments, and constitutes
|
|
a separate conformance level.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="reference-event">7.1. Defining the Reference Event</h3>
|
|
|
|
<p>
|
|
The reference event is an event, of any type, that is defined to serve
|
|
as the reference point for time stamps on events following this one.
|
|
Any <a href="#elem-event" class="elem-name"><event></a> element that has a
|
|
'<a href="#attr-timeRef" class="attr-name">timeRef</a>'
|
|
|
|
attribute set to <code>anchor</code> becomes a reference event. All
|
|
events that follow it in the stream and have a time stamp have that time
|
|
stamp defined as an offset from when the reference event became active.
|
|
If an <a href="#elem-event" class="elem-name"><event></a> element has both a
|
|
'<a href="#attr-timeStamp" class="attr-name">timeStamp</a>'
|
|
attribute
|
|
and a
|
|
'<a href="#attr-timeRef" class="attr-name">timeRef</a>'
|
|
attribute set to <code>anchor</code>, then the
|
|
|
|
'<a href="#attr-timeStamp" class="attr-name">timeStamp</a>'
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored, and the event processed
|
|
as if it hadn't been specified.
|
|
</p>
|
|
<div class="ednote">
|
|
The gist is correct but we need style here.
|
|
</div>
|
|
<p>
|
|
When no reference event has yet been seen, the time from which
|
|
time stamps are offset defaults to the beginning of the session.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="attr-timeRef">7.2. The
|
|
'<code class="attr-name">timeRef</code>'
|
|
attribute</h3>
|
|
|
|
<p>
|
|
The
|
|
'<a href="#attr-timeRef" class="attr-name">timeRef</a>'
|
|
attribute is used to mark an event as a
|
|
<a href="#reference-event">reference event</a> for the timing for time
|
|
stamps. It has two values, <code>anchor</code> and <code>implicit</code>.
|
|
When set to <code>anchor</code>, the corresponding event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be used as
|
|
a reference event, as defined above. When set to <code>implicit</code>
|
|
the behaviour of the <a href="#elem-event" class="elem-name"><event></a> element is untouched. The absence of
|
|
this attribute is equivalent to it being set to <code>implicit</code>.
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="schemaTitle">Attribute timeRef</span></p><pre class="schema" title="Attribute timeRef"><define name='<a id="rng-timeRef.AT" title="Definition of |timeRef.AT|" class="rngref">timeRef.AT</a>' combine='interleave'>
|
|
<optional>
|
|
<attribute name='<strong >timeRef</strong>'>
|
|
<choice>
|
|
<value>implicit</value>
|
|
<value>anchor</value>
|
|
</choice>
|
|
</attribute>
|
|
</optional>
|
|
</define>
|
|
</pre></div>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="attr-timeStamp">7.3. The
|
|
'<code class="attr-name">timeStamp</code>'
|
|
attribute</h3>
|
|
|
|
<p>
|
|
The
|
|
'<a href="#attr-timeStamp" class="attr-name">timeStamp</a>'
|
|
attribute contains a non-negative integer which defines
|
|
the time in <em>ticks</em> relative to the current
|
|
<a href="#reference-event">reference event</a> at which the event is to be
|
|
triggered. A tick is defined against the synchronisation clock, which defaults
|
|
to making a tick last exactly one millisecond, but <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be set to another value
|
|
in a user-agent dependent manner (e.g. because the user-agent is synchronising
|
|
with an audio or video stream that has a different time, or because the user
|
|
has requested that time run slower or faster).
|
|
</p>
|
|
|
|
<div class="boxed"><p><span class="schemaTitle">Attribute timeStamp</span></p><pre class="schema" title="Attribute timeStamp"><define name='<a id="rng-timeStamp.AT" title="Definition of |timeStamp.AT|" class="rngref">timeStamp.AT</a>'>
|
|
<optional>
|
|
<attribute name='<strong >timeStamp</strong>'>
|
|
<data type='nonNegativeInteger'/>
|
|
</attribute>
|
|
</optional>
|
|
</define>
|
|
</pre></div>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="tune-in">7.4. Tuning in to an event stream</h3>
|
|
|
|
<p>
|
|
In continuous streaming and broadcast scenarios it is important that a user-agent be
|
|
able to tune into a stream at an arbitrary moment and nevertheless be able to start
|
|
using it as early as possible. This requires three distinct but related pieces of
|
|
functionality:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
the ability to send the same message several times (carouselling) so that important
|
|
content can be guaranteed to be available promptly to the user-agent, and also to
|
|
compensate for network errors;
|
|
</li>
|
|
<li>
|
|
the ability to identify that a given message has been processed already in order
|
|
to save processing time and to avoid applying the same action multiple times;
|
|
</li>
|
|
<li>
|
|
the ability to distinguish between a message that is immediately usable, and one
|
|
that is a delta that is only meaningful if the previous content that it refers
|
|
to has also been received.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
The above functionality is obtained through the use of two attributes on the
|
|
<a href="#elem-rex" class="elem-name"><rex></a> element,
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
and
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
:
|
|
</p>
|
|
<div class="boxed"><p><span class="schemaTitle">Attributes seq and target</span></p><pre class="schema" title="Attributes seq and target"><define name='<a id="rng-rex.AT" title="Definition of |rex.AT|" class="rngref">rex.AT</a>' combine='interleave'>
|
|
<optional>
|
|
<attribute name='<strong >seq</strong>'>
|
|
<data type='integer'/>
|
|
</attribute>
|
|
</optional>
|
|
<optional>
|
|
<attribute name='<strong >target</strong>'>
|
|
<data type='integer'/>
|
|
</attribute>
|
|
</optional>
|
|
</define>
|
|
</pre></div>
|
|
|
|
<h4 class="attrlist" id="attr-list-tune-in">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-seq">seq</dt>
|
|
<dd>
|
|
This attribute is a positive integer that identifies a <acronym title="Remote Events for XML">REX</acronym> message uniquely
|
|
within a given session. If, within a session, a user-agent receives
|
|
a messages with a
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
that it has already seen for that session,
|
|
then it <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> ignore the entirety of that message. Within a stream of
|
|
messages that is intended to support tune-in, all messages <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> have
|
|
a
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
attribute. This attribute has no default value, and if
|
|
a message does not have a
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
attribute then it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed
|
|
normally and cannot be ignored.
|
|
</dd>
|
|
<dt id="attr-target">target</dt>
|
|
<dd>
|
|
This attribute is a positive integer that identifies a message
|
|
that cannot be usefully processed without having received the the message
|
|
the
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
of which has the number that is the value of the
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
|
|
attribute. If a user-agent receives a message with a
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
that doesn't
|
|
correspond to a
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
that it has seen then it <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> ignore the
|
|
entire message. User-agents are only required to remember the number of the last
|
|
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
that wasn't accompanied by a
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
, therefore content
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> only use
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
attributes that refer to the latest standalone
|
|
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
value.
|
|
</dd>
|
|
</dl>
|
|
<p>
|
|
This functionality can be used as follows. A message containing enough of the
|
|
document for tune-in would be transmitted with a
|
|
'<a href="#attr-seq" class="attr-name">seq</a>'
|
|
and no
|
|
'<a href="#attr-target" class="attr-name">target</a>'
|
|
:
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: A REX message suitable as a tune-in point</span></div><pre class="example" title="A REX message suitable as a tune-in point"><rex xmlns='http://www.w3.org/ns/rex#' seq='1'>
|
|
<event target='/' name='DOMNodeInserted'>
|
|
<svg xmlns='http://www.w3.org/2000/svg'>
|
|
<!-- more content -->
|
|
</svg>
|
|
</event>
|
|
</rex></pre></div>
|
|
<p>
|
|
The above can be processed immediately, whether or not the user-agent has received
|
|
previous messages in the stream or not. The following one on the other hand is a
|
|
message that is only relevant if the user-agent has already received the previous
|
|
message. If it hasn't, then it will ignore it.
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: A REX message meaningful only in context</span></div><pre class="example" title="A REX message meaningful only in context"><rex xmlns='http://www.w3.org/ns/rex#' seq='2' target='1'>
|
|
<event target='id("dahut")' name='DOMAttrModified' attrName='fill' newValue='red'/>
|
|
</rex></pre></div>
|
|
<p>
|
|
Therefore, in a broadcast or multicast environment one may see sequences of events
|
|
similar to the following:
|
|
</p>
|
|
<ol>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=1: creating new document A</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=2, target=1: update document A</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=1: creating new document A (ignore if seen)</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=3, target=1: update document A</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=2, target=1: update document A (ignore if seen)</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=3, target=1: update document A (ignore if seen)</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=4: creating new document B</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=5, target=4: update document A</li>
|
|
<li><acronym title="Remote Events for XML">REX</acronym> message seq=6, target=4: update document A</li>
|
|
<li>...</li>
|
|
</ol>
|
|
<p>
|
|
In the above, if a user-agent starts receiving the stream of <acronym title="Remote Events for XML">REX</acronym> messages from
|
|
the first <code>seq=3</code>, it will ignore all the following ones until it
|
|
receives <code>seq=4</code> which provides it with sufficient context to
|
|
display something.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="mutation">8. Encoding Mutation Events</h2>
|
|
|
|
|
|
<p>
|
|
All <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-mutationevents">mutations events</a>
|
|
are in no namespace. Only the following events are
|
|
supported by this specification:
|
|
'<a href="#event-DOMNodeInserted" class="event-name">DOMNodeInserted</a>'
|
|
,
|
|
'<a href="#event-DOMNodeRemoved" class="event-name">DOMNodeRemoved</a>'
|
|
,
|
|
|
|
'<a href="#event-DOMAttrModified" class="event-name">DOMAttrModified</a>'
|
|
, and
|
|
'<a href="#event-DOMCharacterDataModified" class="event-name">DOMCharacterDataModified</a>'
|
|
.
|
|
</p>
|
|
<p>
|
|
Mutation events are specific in <acronym title="Remote Events for XML">REX</acronym> processing in that they cause the <acronym title="Document Object Model">DOM</acronym> tree to be modified.
|
|
When a user-agent processes a mutation event received in a <acronym title="Remote Events for XML">REX</acronym> message, in addition to dispatching
|
|
the event it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> also modify the tree (either before or after the event, as specified depending
|
|
on the event type) according to the event type.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="mutation-mapping-ev">8.1. Mapping Mutation Events to objects</h3>
|
|
|
|
<p>
|
|
In processing an <a href="#elem-event" class="elem-name"><event></a> element that captures a mutation event, the user-agent
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> produce a <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MutationEvent">MutationEvent</a>
|
|
object, and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> inform the fields of the object in the following manner:
|
|
</p>
|
|
<dl>
|
|
<dt>relatedNode</dt>
|
|
<dd>
|
|
Set dynamically by the user-agent according to the <acronym title="Document Object Model">DOM</acronym> 3 Events specification [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>].
|
|
For attribute modifications applying to <acronym title="Document Object Model">DOM</acronym> subsets that do not have a
|
|
representation for Attr nodes this field <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be null.
|
|
</dd>
|
|
<dt>prevValue</dt>
|
|
<dd>
|
|
Set dynamically by the user-agent to hold the previous value for applicable events,
|
|
as per <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>].
|
|
</dd>
|
|
<dt>newValue</dt>
|
|
<dd>
|
|
Set to the value of the
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
attribute for
|
|
|
|
'<a href="#event-DOMAttrModified" class="event-name">DOMAttrModified</a>'
|
|
and
|
|
'<a href="#event-DOMCharacterDataModified" class="event-name">DOMCharacterDataModified</a>'
|
|
events.
|
|
</dd>
|
|
<dt>attrName</dt>
|
|
<dd>
|
|
The name of the attribute being added, changed, or removed
|
|
for
|
|
'<a href="#event-DOMAttrModified" class="event-name">DOMAttrModified</a>'
|
|
, as obtained from the
|
|
'<a href="#attr-DOMAttrModified-attrName" class="attr-name">attrName</a>'
|
|
|
|
attribute when applicable.
|
|
</dd>
|
|
<dt>attrChange</dt>
|
|
<dd>
|
|
Set to match the value of the
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
|
|
attribute when applicable.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMSubtreeModified">8.2. The
|
|
'<code class="event-name">DOMSubtreeModified</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMSubtreeModified">DOMSubtreeModified</a>
|
|
is not supported. Implementations <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> process it as an unknown event.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMNodeInserted">8.3. The
|
|
'<code class="event-name">DOMNodeInserted</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMNodeInserted">DOMNodeInserted</a>
|
|
indicates that a node has been inserted into the <acronym title="Document Object Model">DOM</acronym> tree. The inserted node <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> 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 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> point either to an element or to the document root. If the
|
|
element that it points to does not exist then the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</p>
|
|
<p>
|
|
|
|
If there is more than one child node in the payload, they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be inserted one after
|
|
the other in document order, as if a <acronym title="Document Object Model">DOM</acronym> DocumentFragment were being inserted. Each of
|
|
them in turn <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> produce a
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMNodeInserted">DOMNodeInserted</a>
|
|
event as if they had been transmitted in separate <a href="#elem-event" class="elem-name"><event></a> elements, and the
|
|
|
|
'<a href="#attr-DOMNodeInserted-position" class="attr-name">position</a>'
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be incremented by one for each.
|
|
</p>
|
|
<p>
|
|
Note that as specified in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] this event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched <em>after</em>
|
|
the node has been inserted.
|
|
</p>
|
|
<p>
|
|
When this event is transmitted, the <a href="#elem-event" class="elem-name"><event></a> element <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> allow arbitrary <acronym title="Extensible Markup Language">XML</acronym> as its content.
|
|
This is not specified in the schema fragment below but left to compounding schemata (e.g.
|
|
using NVDL) to define.
|
|
</p>
|
|
<div class="boxed"><p><span class="schemaTitle">DOMNodeInserted</span></p><pre class="schema" title="DOMNodeInserted"><define name='<a id="rng-DOMNodeInserted" title="Definition of |DOMNodeInserted|" class="rngref">DOMNodeInserted</a>'>
|
|
<optional>
|
|
<attribute name='<strong >position</strong>'>
|
|
<data type='integer'/>
|
|
</attribute>
|
|
</optional>
|
|
</define>
|
|
</pre></div>
|
|
<h4 class="attrlist" id="attr-list-event-DOMNodeInserted">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-DOMNodeInserted-position">position</dt>
|
|
<dd>
|
|
Specifies the position at which the payload <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be inserted in the target element's
|
|
child nodes such that a hypothetical call to <code>parent.childNodes.item(position)</code>
|
|
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 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be inserted
|
|
at the end of the list of child nodes.
|
|
</dd>
|
|
</dl>
|
|
<p>
|
|
Please note that the payload of
|
|
'<a href="#event-DOMNodeInserted" class="event-name">DOMNodeInserted</a>'
|
|
events <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be normalised prior to
|
|
insertion and therefore that indentation, if undesirable in the targeted result, has to be
|
|
absent from the event payload as well. For instance, given the following target tree:
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Source document</span></div><pre class="example" title="Source document"><document>
|
|
...
|
|
<section xml:id='poodle-mania'>
|
|
<title></title>
|
|
...
|
|
</section>
|
|
...
|
|
</document></pre></div>
|
|
<p>
|
|
And given the following
|
|
'<a href="#event-DOMNodeInserted" class="event-name">DOMNodeInserted</a>'
|
|
event:
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Adding a link</span></div><pre class="example" title="Adding a link"><rex xmlns='http://www.w3.org/ns/rex#'>
|
|
<event target='id("poodle-mania")/title' name='DOMNodeInserted'>
|
|
Poodles are for maniacs!
|
|
</event>
|
|
</rex></pre></div>
|
|
<p>
|
|
Will produce the following result:
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Real result</span></div><pre class="example" title="Real result"><document>
|
|
...
|
|
<section xml:id='poodle-mania'>
|
|
<title>
|
|
Poodles are for maniacs!
|
|
</title>
|
|
...
|
|
</section>
|
|
...
|
|
</document></pre></div>
|
|
<p>
|
|
And not what some may have expected:
|
|
</p>
|
|
<div class="boxed"><div><span class="exampleTitle">Example: Possible expected result</span></div><pre class="example" title="Possible expected result"><document>
|
|
...
|
|
<section xml:id='poodle-mania'>
|
|
<title>Poodles are for maniacs!</title>
|
|
...
|
|
</section>
|
|
...
|
|
</document></pre></div>
|
|
<p>
|
|
In order to obtain the above, the white space before and after
|
|
"Poodles are for maniacs!" would have had to be removed.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMNodeRemoved">8.4. The
|
|
'<code class="event-name">DOMNodeRemoved</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMNodeRemoved">DOMNodeRemoved</a> event
|
|
indicates that a node has been removed from the <acronym title="Document Object Model">DOM</acronym> tree. The target path <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> point to either an element,
|
|
a text node, a comment, or a processing instruction. If it points to an attribute the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
ignored. If the node pointed to by the target path does not exist, then the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</p>
|
|
<p>
|
|
If the <a href="#elem-event" class="elem-name"><event></a> element capturing this has a payload as defined in the
|
|
'<a href="#event-DOMNodeInserted" class="event-name">DOMNodeInserted</a>'
|
|
|
|
event, then a second event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> 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).
|
|
</p>
|
|
<p>
|
|
The following parameters <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be set for the generated event. It is of type
|
|
|
|
'<a href="#event-DOMNodeInserted" class="event-name">DOMNodeInserted</a>'
|
|
. Its target node is the parent of the one pointed to
|
|
by the current
|
|
'<a href="#event-DOMNodeRemoved" class="event-name">DOMNodeRemoved</a>'
|
|
event, unless the latter was pointing
|
|
to the root node (using '<code>/</code>') in which case the generated event
|
|
also points to the root node. Its
|
|
'<a href="#attr-DOMNodeInserted-position" class="attr-name">position</a>'
|
|
is
|
|
that of the removed node within its siblings, in document order. Its payload
|
|
is set to be that of the current event.
|
|
</p>
|
|
<p>
|
|
Note that the above processing is compatible with that of <acronym title="Document Object Model">DOM</acronym> 3 Core [<cite><a href="#DOM3" class="bibref">DOM3</a></cite>]
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-785887307">Node.replaceChild()</a>
|
|
but more powerful since it can also operate on the document itself.
|
|
</p>
|
|
<p>
|
|
Note that as specified in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] this event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched <em>before</em>
|
|
the node is removed.
|
|
</p>
|
|
<p>
|
|
The event adds no attribute to the <a href="#elem-event" class="elem-name"><event></a> element. When this event is transmitted,
|
|
the <a href="#elem-event" class="elem-name"><event></a> element <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> allow arbitrary <acronym title="Extensible Markup Language">XML</acronym> as its content. This is not specified in
|
|
the schema fragment below but left to compounding schemata (e.g. using NVDL) to define.
|
|
</p>
|
|
<div class="boxed"><p><span class="schemaTitle">DOMNodeRemoved</span></p><pre class="schema" title="DOMNodeRemoved"><define name='<a id="rng-DOMNodeRemoved" title="Definition of |DOMNodeRemoved|" class="rngref">DOMNodeRemoved</a>'>
|
|
<empty/>
|
|
</define>
|
|
</pre></div>
|
|
<h4 class="attrlist" id="attr-list-event-DOMNodeRemoved">Attributes list</h4><dl class="attrlist">
|
|
<dt>No additional attributes</dt>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMNodeRemovedFromDocument">8.5. The
|
|
'<code class="event-name">DOMNodeRemovedFromDocument</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMNodeRemovedFromDocument">DOMNodeRemovedFromDocument</a>
|
|
is not supported. Implementations <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> process it as an unknown event. It is nevertheless dispatched after a DOMNodeRemoved event
|
|
as described in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>].
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMNodeInsertedIntoDocument">8.6. The
|
|
'<code class="event-name">DOMNodeInsertedIntoDocument</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMNodeInsertedIntoDocument">DOMNodeInsertedIntoDocument</a>
|
|
is not supported. Implementations <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> process it as an unknown event. It is nevertheless dispatched after a DOMNodeInserted event
|
|
as described in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>].
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMAttrModified">8.7. The
|
|
'<code class="event-name">DOMAttrModified</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMAttrModified">DOMAttrModified</a>
|
|
event indicates that an attribute has been modified, added, or removed.
|
|
</p>
|
|
<p>
|
|
When representing a
|
|
'<a href="#event-DOMAttrModified" class="event-name">DOMAttrModified</a>'
|
|
event, the <a href="#elem-event" class="elem-name"><event></a>
|
|
element's
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> point to an element node.
|
|
That element node is the one on which the attribute pointed to by
|
|
|
|
'<a href="#attr-DOMAttrModified-attrName" class="attr-name">attrName</a>'
|
|
is to be modified, added, or removed.
|
|
</p>
|
|
<p>
|
|
If the
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
attribute is set to <code>removal</code>
|
|
then the attribute pointed to by the target path and
|
|
'<a href="#attr-DOMAttrModified-attrName" class="attr-name">attrName</a>'
|
|
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> exists, and if it does not the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored. If however it is set to
|
|
<code>modification</code> or <code>addition</code> then there are two possible options:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
if the attribute exists, then the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed as if the value of
|
|
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
were <code>modification</code>;
|
|
</li>
|
|
<li>
|
|
conversely, if the attribute does not exist, then the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed
|
|
as if the value of
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
had been
|
|
<code>addition</code>;
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Note that as specified in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] this event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched <em>after</em>
|
|
the node has been modified.
|
|
</p>
|
|
<p>
|
|
The following attributes are added to the <a href="#elem-event" class="elem-name"><event></a> element.
|
|
</p>
|
|
<div class="boxed"><p><span class="schemaTitle">DOMAttrModified</span></p><pre class="schema" title="DOMAttrModified"><define name='<a id="rng-DOMAttrModified" title="Definition of |DOMAttrModified|" class="rngref">DOMAttrModified</a>'>
|
|
<group>
|
|
<attribute name='<strong >attrName</strong>'>
|
|
<text/>
|
|
</attribute>
|
|
<optional>
|
|
<attribute name='<strong >attrChange</strong>'>
|
|
<choice>
|
|
<value>modification</value>
|
|
<value>addition</value>
|
|
<value>removal</value>
|
|
</choice>
|
|
</attribute>
|
|
</optional>
|
|
<optional>
|
|
<attribute name='<strong >newValue</strong>'>
|
|
<text/>
|
|
</attribute>
|
|
</optional>
|
|
</group>
|
|
</define>
|
|
</pre></div>
|
|
<h4 class="attrlist" id="attr-list-event-DOMAttrModified">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-DOMAttrModified-attrName">attrName</dt>
|
|
<dd>
|
|
The name of the target attribute on the context element. Its value is a QName resolved
|
|
in the same manner as QNames in XSLT [<cite><a href="#XSLT" class="bibref">XSLT</a></cite>]. Specifically, if the QName does not
|
|
have a prefix, then the namespace URI component of the name is <code>null</code>.
|
|
If it does have a prefix, then its namespace URI component <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be that corresponding
|
|
to that prefix in the namespace declarations in scope for the <a href="#elem-event" class="elem-name"><event></a> element
|
|
being processed; inclusive of the implicit declaration of the prefix <code>xml</code>
|
|
required by Namespaces in <acronym title="Extensible Markup Language">XML</acronym> [<cite><a href="#XMLNS" class="bibref">XMLNS</a></cite>] and exclusive of the default namespace. If the
|
|
QName is not namespace well-formed [<cite><a href="#XMLNS" class="bibref">XMLNS</a></cite>] either because the prefix cannot be resolved
|
|
to a namespace declaration in the current scope, or because it is syntactically
|
|
invalid, then the entire event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored. This attribute is required.
|
|
</dd>
|
|
<dt id="attr-DOMAttrModified-attrChange">attrChange</dt>
|
|
<dd>
|
|
Indicates the type of change that concerns this attribute, one of <code>modification</code>,
|
|
<code>addition</code>, or <code>removal</code>. The default value is <code>modification</code>.
|
|
Note that the distinction between <code>addition</code> and <code>modification</code> is
|
|
largely for documentation purposes as the user-agent changes one into the other depending
|
|
on the presence or not of the attribute.
|
|
</dd>
|
|
<dd>
|
|
If the value is <code>modification</code>, then the
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be present, and the value of the target attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be changed to be
|
|
that contained in
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
. If
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
|
|
is not specified, the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored. If the target attribute does not exist, the event
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed as if
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
had had a value of <code>addition</code>.
|
|
</dd>
|
|
<dd>
|
|
If the value is <code>addition</code>, then the
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be present, and the value of the target attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be created with
|
|
a value being that contained in
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
. If
|
|
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
is not specified, the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
If the target attribute already exists, the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be processed as
|
|
if
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
had had a value of <code>modification</code>.
|
|
</dd>
|
|
<dd>
|
|
If the value is <code>removal</code>, then the target attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be removed. If the
|
|
target attribute is not present, then the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored. If
|
|
'<a href="#attr-DOMAttrModified-newValue" class="attr-name">newValue</a>'
|
|
is
|
|
specified then it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</dd>
|
|
<dt id="attr-DOMAttrModified-newValue">newValue</dt>
|
|
<dd>
|
|
Specifies the value that the attribute is set to, for values of
|
|
'<a href="#attr-DOMAttrModified-attrChange" class="attr-name">attrChange</a>'
|
|
for which
|
|
a value is required.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="event-DOMCharacterDataModified">8.8. The
|
|
'<code class="event-name">DOMCharacterDataModified</code>'
|
|
event</h3>
|
|
|
|
|
|
<p>
|
|
The <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMCharacterDataModified">DOMCharacterDataModified</a>
|
|
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
|
|
'<a href="#event-DOMCharacterDataModified" class="event-name">DOMCharacterDataModified</a>'
|
|
|
|
event, the <a href="#elem-event" class="elem-name"><event></a> element's
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> 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 <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</p>
|
|
<p>
|
|
Note that as specified in <acronym title="Document Object Model">DOM</acronym> 3 Events [<cite><a href="#DOM3EV" class="bibref">DOM3EV</a></cite>] this event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be dispatched <em>after</em>
|
|
the node has been modified.
|
|
</p>
|
|
<div class="boxed"><p><span class="schemaTitle">DOMCharacterDataModified</span></p><pre class="schema" title="DOMCharacterDataModified"><define name='<a id="rng-DOMCharacterDataModified" title="Definition of |DOMCharacterDataModified|" class="rngref">DOMCharacterDataModified</a>'>
|
|
<attribute name='<strong >newValue</strong>'>
|
|
<text/>
|
|
</attribute>
|
|
</define>
|
|
</pre></div>
|
|
<h4 class="attrlist" id="attr-list-event-DOMCharacterDataModified">Attributes list</h4><dl class="attrlist">
|
|
<dt id="attr-DOMCharacterDataModified-newValue">newValue</dt>
|
|
<dd>
|
|
Specifies the value that the character data is set to. This attribute is required, if it is absent
|
|
the event <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be ignored.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="mutation-namechange">8.9. Mutation name events</h3>
|
|
|
|
|
|
<p>
|
|
Neither of the mutation name events
|
|
(<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMElementNameChanged">DOMElementNameChanged</a> and
|
|
<a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-DOMAttributeNameChanged">DOMAttributeNameChanged</a>)
|
|
is supported. Implementation <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> process them as unknown events.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="conformance">9. Conformance</h2>
|
|
|
|
|
|
<p>
|
|
The key words "<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">SHALL</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">SHALL NOT</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em>",
|
|
"<em class="rfc2119" title="Keyword in RFC 2119 context">RECOMMENDED</em>", "<em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>", and "<em class="rfc2119" title="Keyword in RFC 2119 context">OPTIONAL</em>" in this document are to be interpreted as described in
|
|
RFC 2119 [<cite><a href="#RFC2119" class="bibref">RFC2119</a></cite>].
|
|
</p>
|
|
<p>
|
|
Unless otherwise specified immediately following the header, all sections in this
|
|
document — to the exclusion of examples which are all informative — are normative.
|
|
</p>
|
|
|
|
<div class="section"><h3 id="attribute-values">9.1. Parsing attribute values</h3>
|
|
|
|
<p>
|
|
The parsing of attribute values <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be performed as follows:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
The white space in attribute values <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be normalised such that XXX.
|
|
<div class="ednote">
|
|
the rules here must be defined better, see other specs
|
|
</div>
|
|
</li>
|
|
<li>
|
|
Attribute values are case-sensitive. If the value of an attribute can be
|
|
understood as being case-insensitive in a given vocabulary that they are
|
|
being applied to (e.g. a
|
|
'<a href="#attr-event-target" class="attr-name">target</a>'
|
|
attribute's path applying
|
|
to an HTML document) then it is up to the user-agent to map the case-sensitive
|
|
value that it receives to one that may operate on the target vocabulary.
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="ednote">
|
|
<p>
|
|
Things currently missing from this section:
|
|
</p>
|
|
<p>
|
|
GP1. Classes of products: content, content producers, user-agents. For UAs, two levels: one with
|
|
a <acronym title="Document Object Model">DOM</acronym> (indicate variations) and one without.
|
|
</p>
|
|
<p>
|
|
GP3. Not sure exactly how to best do this. Could be useful, need to ask for input.
|
|
</p>
|
|
<p>
|
|
GP4. Do this as soon as test are being written.
|
|
</p>
|
|
<p>
|
|
GP5. Delayed until GP3 & GP4 are done.
|
|
</p>
|
|
<p>
|
|
GP7. Not sure if this is examples or if it's test suite. If former done, if latter
|
|
starting right after FPWD.
|
|
</p>
|
|
<p>
|
|
Req3. See GP1.
|
|
</p>
|
|
<p>
|
|
GP8. Once the text is a little bit more stable, go through the list of
|
|
bibrefs and check to see which ones are good.
|
|
</p>
|
|
<p>
|
|
Req5. Implement proper <dfn> support, and based on that do exactly this.
|
|
</p>
|
|
<p>
|
|
Req6. Do this as part of GP1.
|
|
</p>
|
|
<p>
|
|
GP9. Do this with Req5.
|
|
</p>
|
|
<p>
|
|
GP10. Left for later check (at FPWD time I would expect).
|
|
</p>
|
|
<p>
|
|
GP12. Testable assertions will need further checking. Do this as part of the
|
|
post FPWD work on testing.
|
|
</p>
|
|
<p>
|
|
GP19. Add some text in the section on extensibility to make sure implementers
|
|
understand how not to get extensibility wrong.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="conform-checklist">9.2. Conformance to the QA Framework Specification Guidelines</h3><p><strong>This section is informative.</strong></p>
|
|
|
|
<p>
|
|
This table is derived from the checklist of all defined requirements
|
|
and good practices from the <a href="http://www.w3.org/TR/qaframe-spec/">QA Framework:
|
|
Specification Guidelines</a> [<cite><a href="#QAF-SPEC" class="bibref">QAF-SPEC</a></cite>]. For each requirement and good
|
|
practice, the table links to the part of the <acronym title="Remote Events for XML">REX</acronym> 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.
|
|
</p>
|
|
|
|
<table border="1" class="qa">
|
|
<tr class="legend">
|
|
<th>Guidelines</th>
|
|
<th class="yes">YES</th>
|
|
<th class="no">NO</th>
|
|
<th class="na">N/A</th>
|
|
<th class="comment">Comments</th>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="5">
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#specifying-conformance">2.1 Specifying Conformance</a>
|
|
</th>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#include-conformance-clause-principle">Requirement 01:
|
|
Include a conformance clause.</a>
|
|
</td>
|
|
<td class="yes"><a href="#conformance">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-model-gp">Good Practice 01:
|
|
Define the specification's conformance model in the conformance clause.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#norm-informative-gp">Good Practice 02:
|
|
Specify in the conformance clause how to distinguish normative from informative content.</a>
|
|
</td>
|
|
<td class="yes"><a href="#conformance">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-claim-gp">Good Practice 03:
|
|
Provide the wording for conformance claims.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-gp">Good Practice 04:
|
|
Provide an Implementation Conformance Statement Pro Forma.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-claim-gp">Good Practice 05:
|
|
Require an Implementation Conformance Statement as part of conformance claims.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="5">
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#nature">2.2 Setting up ground rules</a>
|
|
</th>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-scope-principle">Requirement 02: Define the scope.</a>
|
|
</td>
|
|
<td class="yes"><a href="#overview">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#use-example-gp">Good Practice 06:
|
|
Provide examples, use cases, and graphics.</a>
|
|
</td>
|
|
<td class="yes"><a href="#usage">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-sample-gp">Good Practice 07: Write sample code or tests.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#implement-principle">Requirement 03:
|
|
Identify who and/or what will implement the specification.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ref-norm-principle">Requirement 04: Make a list of normative references.</a>
|
|
</td>
|
|
<td class="yes"><a href="#bibref">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ref-define-practice">Good Practice 08: When imposing requirements by normative references, address conformance dependencies.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="5">
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#specify-conformance-need">2.3 Defining and using terminology</a>
|
|
</th>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-terms-principle">Requirement 05:
|
|
Define the terms used in the normative parts of the specification.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conf-label-principle">Requirement 06:
|
|
Create conformance labels for each part of the conformance model.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-terms-inline-gp">Good Practice 09:
|
|
Define unfamiliar terms in-line and consolidate the definitions in a glossary section.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#reuse-terms-gp">Good Practice 10:
|
|
Use terms already defined without changing their definition.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#consistent-style-principle">Requirement 07:
|
|
Use a consistent style for conformance requirements and explain how to distinguish them.</a>
|
|
</td>
|
|
<td class="yes"><a href="#conformance">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#req-opt-conf-principle">Requirement 08:
|
|
Indicate which conformance requirements are mandatory, which are recommended, and which are optional.</a>
|
|
</td>
|
|
<td class="yes">YES</td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#formal-language-gp">Good Practice 11:
|
|
Use formal languages when possible.</a>
|
|
</td>
|
|
<td class="yes">YES</td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment">
|
|
A RelaxNG schema is provided both as fragments for each item being defined and as
|
|
a separate complete schema.
|
|
</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-assertion-gp">Good Practice 12:
|
|
Write Test Assertions.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="5">
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#variability">2.4 Managing Variability</a>
|
|
</th>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdivide-foster-gp">Good Practice 13:
|
|
Create subdivisions of the technology when warranted.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">
|
|
While there is optionality, it is insufficient to justify the cost of introducing subdivisions.
|
|
</td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdivide-mandatory-principle">Requirement 09:
|
|
If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">The technology is not subdivided.</td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdiv-constraints-principle">Requirement 10:
|
|
If the technology is subdivided, then address subdivision constraints.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">The technology is not subdivided.</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#rules-profiles-gp">Good Practice 14:
|
|
If the technology is profiled, define rules for creating new profiles.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">The technology is not profiled.</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#need-option-gp">Good Practice 15:Use optional features as warranted.</a>
|
|
</td>
|
|
<td class="yes">YES</td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment">
|
|
See the <a href="#optional-features">list of optional features</a>.
|
|
</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#label-options-gp">Good Practice 16:
|
|
Clearly identify optional features.</a>
|
|
</td>
|
|
<td class="yes"><a href="#optional-features">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#constraints-gp">Good Practice 17:
|
|
Indicate any limitations or constraints on optional features.</a>
|
|
</td>
|
|
<td class="yes"><a href="#optional-features">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#likehood-extension-principle">Requirement 11:
|
|
Address Extensibility.</a>
|
|
</td>
|
|
<td class="yes"><a href="#extensibility">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#extensions-prohibited-gp">Good Practice 18:
|
|
If extensibility is allowed, define an extension mechanism.</a>
|
|
</td>
|
|
<td class="yes"><a href="#extensibility">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#breaking-conformance-gp">Good Practice 19:
|
|
Warn extension creators to create extensions that do not interfere with conformance.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-error-gp">Good Practice 20:
|
|
Define error-handling for unknown extensions.</a>
|
|
</td>
|
|
<td class="yes"><a href="#extensibility">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#deprecated-feature-principle">Requirement 12:
|
|
Identify deprecated features.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">This is the first version, there is nothing to deprecate.</td>
|
|
</tr>
|
|
<tr class="principle">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#degree-support-principle">Requirement 13:
|
|
Define how each class of product handles each deprecated feature.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">This is the first version, there is nothing to deprecate.</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#workaround-gp">Good Practice 21:
|
|
Explain how to avoid using a deprecated feature.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">This is the first version there is nothing to deprecate.</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#obsolete-gp">Good Practice 22:
|
|
Identify obsolete features.</a>
|
|
</td>
|
|
<td class="yes"></td>
|
|
<td class="no"></td>
|
|
<td class="na">n/a</td>
|
|
<td class="comment">This is the first version, there are no obsolete features.</td>
|
|
</tr>
|
|
<tr class="practice">
|
|
<td>
|
|
<a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#error-handling-gp">Good Practice 23:
|
|
Define an error handling mechanism.</a>
|
|
</td>
|
|
<td class="yes"><a href="#error">YES</a></td>
|
|
<td class="no"></td>
|
|
<td class="na"></td>
|
|
<td class="comment"></td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="optional-features">9.3. Optional features</h3>
|
|
|
|
<p>
|
|
There are two features for which optionality is to be found:
|
|
</p>
|
|
<dl>
|
|
<dt>Processing <acronym title="Extensible Markup Language">XML</acronym> as a stream</dt>
|
|
<dd>
|
|
There are two major manners in which <acronym title="Extensible Markup Language">XML</acronym> 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
|
|
<acronym title="Extensible Markup Language">XML</acronym> in a streaming fashion will dispatch events that it has parsed in
|
|
their entirety immediately even if there is an <acronym title="Extensible Markup Language">XML</acronym> 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.
|
|
</dd>
|
|
<dt>Support for varied <acronym title="Document Object Model">DOM</acronym> representations</dt>
|
|
<dd>
|
|
This specification has be created with the goal of being reusable in
|
|
many situations, notably in case in which the <acronym title="Document Object Model">DOM</acronym> 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 <acronym title="Document Object Model">DOM</acronym>, 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 <acronym title="Document Object Model">DOM</acronym> of choice.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="acknow">10. Acknowledgements</h2><p><strong>This section is informative.</strong></p>
|
|
|
|
|
|
<p>
|
|
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 its initial influences are an input document from Nokia the ideas from which were
|
|
incorporated into this specification, <a href="http://xmldb-org.sourceforge.net/xupdate/">XUpdate</a>
|
|
which has been a major de facto solution since the year 2000 and was influential in
|
|
<acronym title="Remote Events for XML">REX</acronym>'s technical design, and the <a href="http://www.w3.org/TR/xup">XUP</a>
|
|
<acronym title="World Wide Web Consortium">W3C</acronym> Member Submission (now <a href="http://openxup.org">OpenXUP</a>) from which much
|
|
inspiration was drawn.
|
|
</p>
|
|
<p>
|
|
The <a href="http://www.ietf.org/html.charters/widex-charter.html">IETF WiDeX Working Group</a>
|
|
has been a pleasure to collaborate with and has provided a substantial amount of input, much of
|
|
which has made its way directly into this specification. Many thanks are also due to the MWI
|
|
and <acronym title="Extensible Markup Language">XML</acronym> Core <acronym title="Working Group">WG</acronym> for their excellent comments and suggestions. Takanari Hayama designed the
|
|
tune-in part of the specification.
|
|
</p>
|
|
<p>
|
|
Many thanks to Karl Dubost and the QA <acronym title="Working Group">WG</acronym> for their very helpful review.
|
|
</p>
|
|
<p>
|
|
The following individuals, in no particular order, have provided valuable comments that have
|
|
helped shape <acronym title="Remote Events for XML">REX</acronym>: Ola Andersson, Stéphane Bortzmeyer, Gerd Castan, John Cowan, Elliotte Rusty Harold,
|
|
Takanari Hayama, Ian Hickson, Björn Hörhmann, Philippe Le Hégaret, Paul Libbrecht,
|
|
Chris Lilley, Cameron McCormack, David Rivron, Elin Röös, Dave Singer, Maciej Stachowiak,
|
|
Ruud Steltenpool, and Jin Yu.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="media-type">A. Media Type registration for <code>application/rex+xml</code></h2>
|
|
|
|
|
|
<div class="section"><h3 id="media-intro">11.1. Introduction</h3>
|
|
|
|
<p>
|
|
This appendix registers a new MIME media type, "<code>application/rex+xml</code>"
|
|
in conformance with
|
|
<a href="http://www.ietf.org/rfc/rfc4288.txt">RegMedia</a> and
|
|
<a href="http://www.w3.org/2002/06/registering-mediatype.html">W3CRegMedia</a>.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="section"><h3 id="media-registration">11.2. Registration of Media Type <code>application/rex+xml</code></h3>
|
|
|
|
|
|
<dl>
|
|
<dt>MIME media type name:</dt>
|
|
<dd>
|
|
application
|
|
</dd>
|
|
|
|
<dt>MIME subtype name:</dt>
|
|
<dd>
|
|
rex+xml
|
|
</dd>
|
|
|
|
<dt>Required parameters:</dt>
|
|
<dd>
|
|
None.
|
|
</dd>
|
|
|
|
<dt>Optional parameters:</dt>
|
|
<dd>
|
|
<p>
|
|
None
|
|
</p>
|
|
<p>
|
|
The encoding of a <acronym title="Remote Events for XML">REX</acronym> document <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be determined by the <acronym title="Extensible Markup Language">XML</acronym>
|
|
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 [<cite><a href="#RFC3023" class="bibref">RFC3023</a></cite>] sections
|
|
8.9, 8.10 and 8.11.
|
|
</p>
|
|
</dd>
|
|
|
|
<dt>Encoding considerations:</dt>
|
|
<dd>
|
|
Same as for application/xml. See RFC 3023 [<cite><a href="#RFC3023" class="bibref">RFC3023</a></cite>], section 3.2.
|
|
</dd>
|
|
|
|
<dt>Restrictions on usage:</dt>
|
|
<dd>
|
|
None
|
|
</dd>
|
|
|
|
<dt>Security considerations:</dt>
|
|
<dd>
|
|
<p>
|
|
As with other <acronym title="Extensible Markup Language">XML</acronym> types and as noted in RFC 3023 [<cite><a href="#RFC3023" class="bibref">RFC3023</a></cite>] section 10,
|
|
repeated expansion of maliciously constructed <acronym title="Extensible Markup Language">XML</acronym> entities can be used
|
|
to consume large amounts of memory, which may cause <acronym title="Extensible Markup Language">XML</acronym> processors in
|
|
some environments to fail.
|
|
</p>
|
|
<p>
|
|
<acronym title="Remote Events for XML">REX</acronym> 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 [<cite><a href="#RFC1952" class="bibref">RFC1952</a></cite>] section 2.3.1.
|
|
</p>
|
|
|
|
<p>
|
|
It must be noted that <acronym title="Remote Events for XML">REX</acronym> events <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> 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.
|
|
</p>
|
|
|
|
<p>
|
|
In addition, because of the extensibility features for <acronym title="Remote Events for XML">REX</acronym> and of <acronym title="Extensible Markup Language">XML</acronym> in
|
|
general, it is possible that "<code>application/rex+xml</code>" 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 <acronym title="Remote Events for XML">REX</acronym> namespace and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> 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.
|
|
</p>
|
|
|
|
</dd>
|
|
|
|
<dt>Interoperability considerations:</dt>
|
|
<dd>
|
|
<p>
|
|
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 <acronym title="Remote Events for XML">REX</acronym> and <acronym title="Extensible Markup Language">XML</acronym> Events namespaces and in other
|
|
namespaces.
|
|
</p>
|
|
|
|
<p>
|
|
Because <acronym title="Remote Events for XML">REX</acronym> is extensible, conformant "<code>application/rex+xml</code>"
|
|
processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> expect that content received is well-formed <acronym title="Extensible Markup Language">XML</acronym>, 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.
|
|
</p>
|
|
|
|
<p>
|
|
<acronym title="Remote Events for XML">REX</acronym> 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.
|
|
</p>
|
|
|
|
</dd>
|
|
|
|
<dt>Published specification:</dt>
|
|
<dd>
|
|
<p>
|
|
This media type registration is extracted from Appendix A of the
|
|
<a href="http://www.w3.org/TR/rex"><acronym title="Remote Events for XML">REX</acronym> 1.0 specification</a>.
|
|
</p>
|
|
</dd>
|
|
|
|
<dt>Additional information:</dt>
|
|
<dd>
|
|
n/a
|
|
</dd>
|
|
|
|
<dt>Person & email address to contact for further information:</dt>
|
|
<dd>
|
|
Robin Berjon (<a href="mailto:member-rex-media-type@w3.org">member-rex-media-type@w3.org</a>).
|
|
</dd>
|
|
|
|
<dt>Intended usage:</dt>
|
|
<dd>
|
|
COMMON
|
|
</dd>
|
|
|
|
<dt>Author/Change controller:</dt>
|
|
<dd>
|
|
The <acronym title="Remote Events for XML">REX</acronym> specification is a joint work product of the World Wide Web Consortium's
|
|
<acronym title="Scalable Vector Graphics">SVG</acronym> and Web APIs Working Groups. The <acronym title="World Wide Web Consortium">W3C</acronym> has change control over this
|
|
specification.
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="changes">B. Changes since the last version</h2><p><strong>This section is informative.</strong></p>
|
|
|
|
|
|
<p>
|
|
This sections lists the changes that were made to this specification since it
|
|
was last published. Many thanks too all those who have provided feedback.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
miscellaneous fixes to the examples
|
|
</li>
|
|
<li>
|
|
a number of typos, spotted by
|
|
<a href="http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0005.html">Elliotte Harold (UNC)</a>, and
|
|
<a href="http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0011.html">Ruud Steltenpool (University of Twente)</a>
|
|
</li>
|
|
<li>
|
|
attribute version changed to
|
|
'<a href="#attr-rex-minimal-version" class="attr-name">minimal-version</a>'
|
|
based on feedback from Dave Singer.
|
|
</li>
|
|
<li>
|
|
clarified transport independence in the overview (Dave Raggett, Chris Lilley)
|
|
</li>
|
|
<li>
|
|
IRI validation now not recommended, and <code>namespaceURI</code> is defined to be
|
|
its URI equivalent (John Cowan).
|
|
</li>
|
|
<li>
|
|
the processing model no longer contradicts timeStamp processing (Philippe Le Hégaret)
|
|
</li>
|
|
<li>
|
|
changed default
|
|
'<a href="#attr-ns" class="attr-name">ns</a>'
|
|
value as well as event namespaces in accordance with
|
|
<acronym title="Document Object Model">DOM</acronym> 3 Events changes. Also substituted URI and IRI in some places.
|
|
</li>
|
|
<li>
|
|
all the parts that have to do with streaming are now in a separate module
|
|
</li>
|
|
<li>
|
|
clearly indicate that the events are to be dispatched in document order when they
|
|
are not timed (Dave Singer)
|
|
</li>
|
|
<li>
|
|
added the ability to specify a target document, if multiple documents are present
|
|
</li>
|
|
<li>
|
|
modified the XPath matching rules such that they only ever return a single
|
|
node (text or element, attributes are no longer needed). It is expected that a
|
|
future version of this specification will add a flag indicating that multiple
|
|
nodes can be matched.
|
|
</li>
|
|
<li>
|
|
DOMAttrModified no longer targets attributes directly from the target path, but
|
|
rather targets the owner element and has an additional
|
|
'<a href="#attr-DOMAttrModified-attrName" class="attr-name">attrName</a>'
|
|
|
|
attribute to specify which is the targeted attribute. Without this implementations
|
|
could not directly reused an external XPath implementation but rather had to perform
|
|
at least some parsing of the target path themselves (David Rivron).
|
|
</li>
|
|
<li>
|
|
clarified that text is not normalised in any particular way (David Rivron).
|
|
</li>
|
|
<li>
|
|
added
|
|
'<a href="#attr-timeRef" class="attr-name">timeRef</a>'
|
|
and the accompanying reference event section (Dave Raggett).
|
|
</li>
|
|
<li>
|
|
updated the processing model to be clearer with respect to timing (Dave Raggett).
|
|
</li>
|
|
<li>
|
|
created a separate <a href="#streaming">Streaming Module</a>.
|
|
</li>
|
|
<li>
|
|
added tune-in support (Takanari Hayama)
|
|
</li>
|
|
<li>
|
|
slight incoherence between 5.1 and 8.3
|
|
</li>
|
|
<li>
|
|
clarification of the abstract
|
|
</li>
|
|
<li>
|
|
new namespace using the new improved nsuri rules
|
|
</li>
|
|
<li>
|
|
RelaxNG improvements
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="section"><h2 id="bibref">C. References</h2>
|
|
|
|
|
|
<dl class="bibliography"><dt id="DOM3">DOM3</dt><dd><cite><a href="http://www.w3.org/TR/DOM-Level-3-Core/">Document Object Model (DOM) Level 3 Core Specification</a></cite>,
|
|
<span class="person">Arnaud Le Hors (IBM)</span>, <span class="person">Philippe Le Hégaret (W3C)</span>, <span class="person">Lauren Wood (SoftQuad, Inc.)</span>, <span class="person">Gavin Nicol (Inso EPS)</span>, <span class="person">Jonathan Robie (Texcel Research and Software AG)</span>, <span class="person">Mike Champion (Arbortext and Software AG)</span>, and <span class="person">Steve Byrne (JavaSoft)</span>.</dd><dt id="DOM3EV">DOM3EV</dt><dd><cite><a href="http://www.w3.org/TR/DOM-Level-3-Events/">Document Object Model (DOM) Level 3 Events Specification</a></cite>,
|
|
<span class="person">Philippe Le Hégaret (W3C)</span>, and <span class="person">Tom Pixley (Netscape Communications Corporation)</span>.</dd><dt id="QAF-SPEC">QAF-SPEC</dt><dd><cite><a href="http://www.w3.org/TR/qaframe-spec/">QA Framework: Specification Guidelines</a></cite>,
|
|
<span class="person">Karl Dubost</span>, <span class="person">Lynne Rosenthal</span>, <span class="person">Dominique Hazaël-Massieux</span>, and <span class="person">Lofton Henderson</span>.</dd><dt id="RFC1952">RFC1952</dt><dd><cite><a href="http://www.ietf.org/rfc/rfc1952.txt">GZIP file format specification version 4.3</a></cite>,
|
|
<span class="person">P. Deutsch</span>.</dd><dt id="RFC2119">RFC2119</dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a></cite>,
|
|
<span class="person">S. Bradner</span>.</dd><dt id="RFC3023">RFC3023</dt><dd><cite><a href="http://www.ietf.org/rfc/rfc3023.txt">XML Media Types</a></cite>,
|
|
<span class="person">M. Murata</span>, <span class="person">S. St.Laurent</span>, and <span class="person">D. Kohn</span>.</dd><dt id="SMIL2">SMIL2</dt><dd><cite><a href="http://www.w3.org/TR/SMIL2/">Synchronized Multimedia Integration Language (SMIL 2.1)</a></cite>,
|
|
<span class="person">Dick Bulterman (CWI)</span>, <span class="person">Guido Grassel (Nokia)</span>, <span class="person">Jack Jansen (CWI)</span>, <span class="person">Antti Koivisto (Nokia)</span>, <span class="person">Nabil Layaïda (INRIA)</span>, <span class="person">Thierry Michel (W3C)</span>, <span class="person">Sjoerd Mullender (CWI)</span>, and <span class="person">Daniel Zucker (Access Co., Ltd.)</span>.</dd><dt id="SVGT12">SVGT12</dt><dd><cite><a href="http://www.w3.org/TR/SVGMobile12/">Scalable Vector Graphics (SVG) Tiny 1.2 Specification</a></cite>,
|
|
<span class="person">Ola Andersson <<a href="mailto:ola.andersson@ikivo.com">ola.andersson@ikivo.com</a>></span>, <span class="person">Robin Berjon <<a href="mailto:robin.berjon@expway.fr">robin.berjon@expway.fr</a>></span>, <span class="person">Jon Ferraiolo <<a href="mailto:jon.ferraiolo@adobe.com">jon.ferraiolo@adobe.com</a>></span>, <span class="person">Vincent Hardy <<a href="mailto:vincent.hardy@sun.com">vincent.hardy@sun.com</a>></span>, <span class="person">Scott Hayman</span>, <span class="person">Dean Jackson <<a href="mailto:dean@w3.org">dean@w3.org</a>></span>, <span class="person">Craig Northway <<a href="mailto:craign@cisra.canon.com.au">craign@cisra.canon.com.au</a>></span>, and <span class="person">Antoine Quint <<a href="mailto:aq@fuchsia-design.com">aq@fuchsia-design.com</a>></span>.</dd><dt id="XML">XML</dt><dd>
|
|
All references to <acronym title="Extensible Markup Language">XML</acronym> in this specification refer to both <acronym title="Extensible Markup Language">XML</acronym> 1.0 and <acronym title="Extensible Markup Language">XML</acronym> 1.1.
|
|
</dd><dd><ul><li><cite><a href="http://www.w3.org/TR/REC-xml/">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>,
|
|
<span class="person">Tim Bray <<a href="mailto:tbray@textuality.com">tbray@textuality.com</a>></span>, <span class="person">Jean Paoli <<a href="mailto:jeanpa@microsoft.com">jeanpa@microsoft.com</a>></span>, <span class="person">C. M. Sperberg-McQueen <<a href="mailto:cmsmcq@w3.org">cmsmcq@w3.org</a>></span>, <span class="person">Eve Maler <<a href="mailto:eve.maler@east.sun.com">eve.maler@east.sun.com</a>></span>, and <span class="person">François Yergeau <<a href="mailto:fyergeau@alis.com">fyergeau@alis.com</a>></span>.</li><li><cite><a href="http://www.w3.org/TR/xml11/">Extensible Markup Language (XML) 1.1</a></cite>,
|
|
<span class="person">Tim Bray <<a href="mailto:tbray@textuality.com">tbray@textuality.com</a>></span>, <span class="person">Jean Paoli <<a href="mailto:jeanpa@microsoft.com">jeanpa@microsoft.com</a>></span>, <span class="person">C. M. Sperberg-McQueen <<a href="mailto:cmsmcq@w3.org">cmsmcq@w3.org</a>></span>, <span class="person">Eve Maler <<a href="mailto:eve.maler@east.sun.com">eve.maler@east.sun.com</a>></span>, <span class="person">François Yergeau <<a href="mailto:fyergeau@alis.com">fyergeau@alis.com</a>></span>, and <span class="person">John Cowan <<a href="mailto:cowan@ccil.org">cowan@ccil.org</a>></span>.</li></ul></dd><dt id="XMLEV">XMLEV</dt><dd><cite><a href="http://www.w3.org/TR/xml-events/">XML Events</a></cite>,
|
|
<span class="person">Shane McCarron (Applied Testing and Technology, Inc.)</span>, <span class="person">Steven Pemberton (CWI/W3C®)</span>, and <span class="person">T. V. Raman (IBM Corporation)</span>.</dd><dt id="XMLNS">XMLNS</dt><dd>
|
|
All references to Namespaces in <acronym title="Extensible Markup Language">XML</acronym> in this specification refer both to
|
|
versions 1.0 and 1.1, applying respectively to <acronym title="Extensible Markup Language">XML</acronym> 1.0 and <acronym title="Extensible Markup Language">XML</acronym> 1.1.
|
|
</dd><dd><ul><li><cite><a href="http://www.w3.org/TR/REC-xml-names/">Namespaces in XML</a></cite>,
|
|
<span class="person">Tim Bray <<a href="mailto:tbray@textuality.com">tbray@textuality.com</a>></span>, <span class="person">Dave Hollander <<a href="mailto:dmh@contivo.com">dmh@contivo.com</a>></span>, and <span class="person">Andrew Layman <<a href="mailto:andrewl@microsoft.com">andrewl@microsoft.com</a>></span>.</li><li><cite><a href="http://www.w3.org/TR/xml-names11">Namespaces in XML 1.1</a></cite>,
|
|
<span class="person">Tim Bray <<a href="mailto:tbray@textuality.com">tbray@textuality.com</a>></span>, <span class="person">Dave Hollander <<a href="mailto:dmh@contivo.com">dmh@contivo.com</a>></span>, <span class="person">Andrew Layman <<a href="mailto:andrewl@microsoft.com">andrewl@microsoft.com</a>></span>, and <span class="person">Richard Tobin <<a href="mailto:richard@cogsci.ed.ac.uk">richard@cogsci.ed.ac.uk</a>></span>.</li></ul></dd><dt id="XPATH">XPATH</dt><dd><cite><a href="http://www.w3.org/TR/xpath">XML Path Language (XPath)</a></cite>,
|
|
<span class="person">James Clark <<a href="mailto:jjc@jclark.com">jjc@jclark.com</a>></span>, and <span class="person">Steve DeRose <<a href="mailto:Steven_DeRose@Brown.edu">Steven_DeRose@Brown.edu</a>></span>.</dd><dt id="XSLT">XSLT</dt><dd><cite><a href="http://www.w3.org/TR/xslt">XSL Transformations (XSLT)</a></cite>,
|
|
<span class="person">James Clark <<a href="mailto:jjc@jclark.com">jjc@jclark.com</a>></span>.</dd></dl>
|
|
</div>
|
|
</body>
|
|
</html>
|