NOTE-rex-reqs-20060202
16.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
<?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">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Remote Events for XML (REX) Requirements</title>
<link rel="stylesheet" href="respec-w3c.css" type="text/css"/>
<link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" type="text/css"/>
<meta name="revision" content="$Id: Overview.html,v 1.1 2006/02/16 16:38:55 matthieu Exp $"/>
</head>
<body><div class="head"><p><a href="http://www.w3.org/"><img class="head" src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C"/></a></p><h1 class="head">Remote Events for XML (REX) Requirements</h1><h2 id="pagesubtitle">W3C Working Group Note <em>02 February 2006</em></h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2006/NOTE-rex-reqs-20060202">http://www.w3.org/TR/2006/NOTE-rex-reqs-20060202</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/rex-reqs">http://www.w3.org/TR/rex-reqs</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>
This document lists the requirements for an <acronym title="Extensible Markup Language">XML</acronym>
grammar intended for representing events as they are defined in
<acronym title="Document Object Model">DOM</acronym> 3 Events,
primarily but not exclusively for purposes of transmission or synchronisation
of remote documents. Such a vocabulary would enable one endpoint to interact
remotely with another endpoint holding a <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 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>
The patent policy for this document is 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>.
Patent disclosures relevant to this specification may be found on the
<a href="http://www.w3.org/Graphics/SVG/Disclosures" rel="disclosure"><acronym title="Scalable Vector Graphics">SVG</acronym> Working Group's patent disclosure page</a>
and <a href="http://www.w3.org/2004/01/pp-impl/38482/status" rel="disclosure">Web API Working Group's patent
disclosure page</a>. An individual who has actual knowledge of a patent which the individual believes
contains Essential Claim(s) with respect to this specification should disclose the information in
accordance with <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>
This document does not necessarily represent the full and complete consensus of the
REX Task Force, the Web API Working Group, or the <acronym title="Scalable Vector Graphics">SVG</acronym> Working Group at the time of
its publication, some issues being still considered to some degree contentious.
It is made available for public review in the hope that access from a wider audience
early in the process will help increase the quality and timeliness of the
specification.
</p>
<p>
Publication as a Working Group Note 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="#functional-requirements">1. Functional Requirements</a></li><li><a href="#format-requirements">2. Format Requirements</a></li><li><a href="#ecosystem-requirements">3. Ecosystem Requirements</a></li></ul>
</div>
<div class="section"><h2 id="functional-requirements">1. Functional Requirements</h2>
<p>
These requirements cover what pertains directly to the functionality
desired in REX.
</p>
<dl>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> permit a document tree to be modified, locally or remotely</dt>
<dd>
It must be possible, through use of REX, to cause a remote document tree
to be updated as if by manipulation through the <acronym title="Document Object Model">DOM</acronym> 3 Core API. This does
not entail that all of the <acronym title="Document Object Model">DOM</acronym> 3 Core API needs be exposed, simply that
it must be possible to perform modifications corresponding to the
following <acronym title="Document Object Model">DOM</acronym> 3 Events events: DOMNodeInserted, DOMNodeRemoved,
DOMAttrModified, and DOMCharacterDataModified.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> rely on an event-based processing model</dt>
<dd>
The chosen method of providing orthogonality across <acronym title="World Wide Web Consortium">W3C</acronym> specifications
covering interaction languages is to communicate both across and
within language boundaries using events. This ensure the integrity of
the processing model, and that minimal information be available
between the various parts that may be integrated within a user-agent.
This is of specific importance where REX is concerned, since it cannot
be useful without a tree to target that is presumably in another
language. The baseline event specification with which to conform
is <acronym title="Document Object Model">DOM</acronym> 3 Events.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> support multiple Document Object Model variants</dt>
<dd>
Multiple technologies on the Web support multiple Document Object
Models, some of which are standard or being standardised (e.g. <acronym title="Document Object Model">DOM</acronym>
3 Core, <acronym title="Document Object Model">DOM</acronym> 2 HTML, <acronym title="Scalable Vector Graphics">SVG</acronym> <acronym title="Document Object Model">DOM</acronym> 1.1, <acronym title="Scalable Vector Graphics">SVG</acronym> Tiny 1.2 uDOM) while others are
found "in the wild" and may be de facto variants specific to a domain
or to an implementation. In as far as technically reasonable, REX must
support targeting multiple such object models.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> specify a minimal timing model</dt>
<dd>
In order to properly support the ability to be transmitted over
streaming protocols, REX must support timing facilities (at least
to differentiate between delivery time and activation time). However
these facilities must be limited to the strict set that is required
to achieve the ability to be streamed and must not overlap with
existing protocols.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> support addressing nodes using XPath</dt>
<dd>
The proven way of addressing nodes in the <acronym title="Extensible Markup Language">XML</acronym> stack is to rely
on XPath. The support for XPath required in REX may be a subset
of XPath 1.0.
</dd>
</dl>
</div>
<div class="section"><h2 id="format-requirements">2. Format Requirements</h2>
<p>
These requirements cover how the functionality available in REX
is to be captured by a format, and what constraints this format
is to follow.
</p>
<dl>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be specified in a declarative manner</dt>
<dd>
REX must support functionality that is currently possible using
scripting, but without introducing the level of complexity and
functionality that a scripting language permits. A simpler, more limited
declarative approach is easier to handle on constrained platforms
and high-performance environments.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be expressed in an <acronym title="Extensible Markup Language">XML</acronym> syntax </dt>
<dd>
In order to better integrate into the <acronym title="Extensible Markup Language">XML</acronym> and Web stacks, and
as a straightforward manner of specifying a declarative language
compared to inventing a completely new syntax, REX needs to be
expressed in <acronym title="Extensible Markup Language">XML</acronym>.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be extensible</dt>
<dd>
It must be possible to create new versions of REX as well as
proprietary extensions to it without interfering with the way in
which an implementation of the current version that is unaware of
extensions processes the parts of the content that are not
extensions. Such extensions cover both the markup in which REX
is expressed and the events that it captures.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> support be forwards and backwards compatibility</dt>
<dd>
REX must be specified in such a way that new vocabulary items
(e.g. elements, attributes) and new events can be easily added
in version n+1 content without causing implementations of version
n to abort processing, and so that implementations of versions
n+1 can still process the entirety of version n content.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> precisely define error handling</dt>
<dd>
Error handling must be defined in such a way that user-agents
will interpret non-conformant content in an interoperable
manner.
</dd>
</dl>
</div>
<div class="section"><h2 id="ecosystem-requirements">3. Ecosystem Requirements</h2>
<p>
These requirements cover the way in which REX needs to integrate
with the existing ecosystem of surrounding specifications.
</p>
<dl>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> integrate into the QA framework </dt>
<dd>
The REX specification must take into account all relevant
QA requirements, in such a manner that these requirements
can be easily verified.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be applicable to any <acronym title="Extensible Markup Language">XML</acronym> language</dt>
<dd>
REX needs to be specified so that it is not a silo technology
that only operates on one <acronym title="Extensible Markup Language">XML</acronym> language, or a subset of possible
<acronym title="Extensible Markup Language">XML</acronym> languages, but rather a general technology that can be
reused across the board.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be implementable on top of <acronym title="Scalable Vector Graphics">SVG</acronym> Tiny 1.2 uDOM</dt>
<dd>
The <acronym title="Scalable Vector Graphics">SVG</acronym> Tiny 1.2 uDOM provides a convenient measure of a
<acronym title="Document Object Model">DOM</acronym> subset that corresponds to the requirements of constrained
devices. Ensuring that this specification can be implemented
on the uDOM is a practical way of assessing whether it can
be supported on mobile devices.
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> integrate into the <acronym title="Extensible Markup Language">XML</acronym> ecosystem and reuse <acronym title="Extensible Markup Language">XML</acronym> technology</dt>
<dd>
The <acronym title="Extensible Markup Language">XML</acronym> stack is now so vast that checking a new specification
for applicability to others is at best impractical. This requirement
is to support the
<a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into <acronym title="Extensible Markup Language">XML</acronym> Stack</a>
property as defined in the <a href="http://www.w3.org/TR/xbc-properties/">XBC Properties</a>
document: <cite><acronym title="Extensible Markup Language">XML</acronym> as a data format is surrounded by a large body of
specifications that provide additional features considered to form the
<acronym title="Extensible Markup Language">XML</acronym> Stack. A format is said to integrate well into the <acronym title="Extensible Markup Language">XML</acronym> Stack if it
can easily find its place into the large body of <acronym title="Extensible Markup Language">XML</acronym>-related technologies,
with minimal effort in defining new or modified specifications.</cite>
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be transport independent</dt>
<dd>
In order to be reusable across a large set of varied networks, REX must
not rely on excessive requirements from the transport layer that it is
being delivered on top of. This requirement is to support the
<a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
property as defined in the <a href="http://www.w3.org/TR/xbc-properties/">XBC Properties</a>
document: <cite>A format is transport independent if the only assumptions
of transport service are error-free and ordered delivery of messages
without any arbitrary restrictions on the message length.</cite>
</dd>
<dt><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> integrate in the Architecture of the WWW</dt>
<dd>
REX needs to support the requirements set forth in the
<a href="http://www.w3.org/TR/webarch/">Architecture of the World Wide
Web: Volume One</a>.
</dd>
</dl>
</div>
</body>
</html>