WD-exi-impacts-20080903
24.7 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
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en-US"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Efficient XML Interchange (EXI) Impacts</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p>
<h1><a name="title" id="title"></a>Efficient XML Interchange (EXI) Impacts</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 03 September 2008</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2008/WD-exi-impacts-20080903">http://www.w3.org/TR/2008/WD-exi-impacts-20080903</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/exi-impacts/">http://www.w3.org/TR/exi-impacts/</a>
</dd><dt>Editor:</dt><dd>Jaakko Kangasharju, University of Helsinki</dd></dl><p>This document is also available in these non-normative formats: <a href="exi-impacts.xml">XML</a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 <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><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
The Efficient XML Interchange (EXI) format defines a new
representation for the Extensible Markup Language (XML)
Information Set. The introduction of such a format may cause
disruption in systems that have so far been able to assume XML
as the only representation of XML Information Set data. This
document reviews areas where the introduction of EXI may
disrupt or otherwise have an impact on existing XML
technologies, XML processors, and applications. It also
describes EXI design features and steps that may be taken by
implementors to reduce or eliminate disruption and impacts.
</p></div><div>
<h2><a name="status" id="status"></a>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 W3C publications and the latest
revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical
reports index</a> at http://www.w3.org/TR/.
</em>
</p><p>
This is a First Public Working Draft of “Efficient XML
Interchange (EXI) Impacts.”
</p><p>
This document is intended to aid people in the XML community
to determine whether their particular area of interest is
affected by the introduction of EXI. It currently contains
the significant impacts identified by the Efficient XML Interchange
Working Group, and
the group would also appreciate hearing from the XML community
if any potential impacts have been missed.
</p><p>
This document was developed by the <a href="http://www.w3.org/XML/EXI/">Efficient XML
Interchange (EXI) Working Group</a>.
</p><p>
Please send comments about this document to <a href="mailto:public-exi@w3.org">public-exi@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-exi/">public archive</a>).
</p><p>
Publication as a Working Draft does not imply endorsement by
the W3C Membership. This is a draft document and may be
updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite this document as other than
work in progress.
</p><p>
This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent
Policy</a>. The group does not expect this document to
become a W3C Recommendation. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/38502/status#specs">public list of any patent
disclosures</a> made in connection with the deliverables of
the group; 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 W3C Patent
Policy</a>.
</p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#intro">Introduction</a><br>
2 <a href="#terminology">Terminology and Discussion</a><br>
3 <a href="#xml-processors">Existing XML Processors and Applications</a><br>
4 <a href="#xml-technologies">Existing XML Technologies</a><br>
4.1 <a href="#xml-security">XML Security</a><br>
4.1.1 <a href="#xml-signature">XML Signature</a><br>
4.1.2 <a href="#xml-encryption">XML Encryption</a><br>
4.1.3 <a href="#s-xml-c14n">XML Canonicalization</a><br>
4.2 <a href="#api-impact">Existing XML Processing APIs</a><br>
4.3 <a href="#other-binary">XML and Binary Attachments</a><br>
5 <a href="#human-readability">Sacrificing Human Readability</a><br>
6 <a href="#other-impact">Other Impacts</a><br>
7 <a href="#conclusions">Conclusions</a><br>
8 <a href="#references">References</a><br>
</p>
<h3><a name="appendices" id="appendices"></a>Appendix</h3><p class="toc">A <a href="#acknowledgements">Acknowledgements</a><br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="intro" id="intro"></a>1 Introduction</h2><p>
While the introduction of EXI has the potential to bring XML
to new communities, it can also have adverse effects on the
existing XML community. The precise scope of these effects
may not be fully knowable in advance, but based on experience
with existing binary formats, educated estimates can be made.
</p><p>
The main goals of EXI in regards to existing systems are to
provide maximally seamless compatibility with XML and to avoid
disruption of existing XML technologies and specifications. In
particular, EXI should not require modifications to existing
XML systems, unless these systems are extended to adopt EXI.
The purpose of this document is to identify any immediate
impacts that require changes to existing XML-based
specifications or XML-using applications. It also identifies
cases where changes to existing specifications or applications
are not required, but might be desirable to increase
efficiency.
</p></div><div class="div1">
<h2><a name="terminology" id="terminology"></a>2 Terminology and Discussion</h2><p>
This section collects relevant definitions from the <a href="#xml">[XML]</a> and <a href="#exi-format">[EXI]</a> specifications.
</p><dl><dt class="label">
<a href="http://www.w3.org/TR/2006/REC-xml-20060816#dt-xml-proc">XML Processor</a>
</dt><dd><p>
A module used to read XML documents and provide access
to their content and structure
</p></dd><dt class="label">
<a href="http://www.w3.org/TR/exi#key-exiprocessor">EXI Processor</a>
</dt><dd><p>
A module used to encode structured data into EXI streams
and/or to decode EXI streams to make structured data
accessible
</p></dd><dt class="label">
<a href="http://www.w3.org/TR/2006/REC-xml-20060816#dt-app">Application</a>
</dt><dd><p>
A module on behalf of which an XML processor or an EXI
processor does its work
</p></dd></dl><p id="app-structure">
In a system containing both an XML and an EXI processor, the
modules would normally be completely separate from each other.
The application would be responsible for deciding which
processor is to process each document. It could use
either out-of-band means, such as communication protocol
metadata, or in-band means, such as the distinguishing bits of
EXI, to make this decision.
</p></div><div class="div1">
<h2><a name="xml-processors" id="xml-processors"></a>3 Existing XML Processors and Applications</h2><p>
EXI offers two in-band means to distinguish it from other
formats: the mandatory <a href="http://www.w3.org/TR/exi#DistinguishingBits">Distinguishing
Bits</a> and the optional <a href="http://www.w3.org/TR/exi#EXICookie">EXI Cookie</a>. In
particular, either of these is sufficient to distinguish EXI
from XML when using any conventional character encoding (see
<a href="#exi-bp">[EXI Best Practices]</a>, <a href="http://www.w3.org/TR/exi-best-practices#distinguishing-bits">section
4.1.1</a>). Assuming such a conventional character encoding,
the first octet of an EXI document, either one that includes
the distinguishing bits or the first octet of the EXI cookie,
can not appear as the first octet of a <a href="http://www.w3.org/TR/2006/REC-xml-20060816#dt-wellformed">well-formed</a>
XML document. Therefore, an XML processor is required by the
XML specification to reject any EXI document immediately upon
reading that first octet.
</p><p>
XML is often used in conjunction with other protocols and
technologies. In some such cases, in particular the World Wide
Web and Web services where HTTP is common, the protocol
supports content negotiation to allow applications to indicate
which content types and encodings they are prepared to handle.
<a href="#exi-bp">[EXI Best Practices]</a> describes <a href="http://www.w3.org/TR/exi-best-practices#http-content-negotiation">how
such support can be used</a> to introduce EXI to such an
environment with no impact to applications that have not
adopted EXI.
</p><p>
More generally, in an environment consisting of multiple XML
applications, where some but not all applications wish to
adopt EXI, coordination is needed to avoid transmitting EXI to
applications that are not prepared to handle it. Following the
<a href="http://www.w3.org/TR/exi-best-practices#mixed-XML-EXI">EXI
best practices</a>, the burden of such coordination should
fall only on the applications that adopt EXI, as they should
not send EXI to applications that are not known to understand
it. In processing of incoming transmissions, an application
adopting EXI will need to implement an internal mechanism for
routing the incoming content to the appropriate processor (XML
or EXI), but a non-EXI-aware application can continue using
its XML processor for everything. If the communication
protocol does not offer any method for content negotiation, it
may be that a non-EXI-aware application occasionally gets sent
EXI content. In such cases, the aforementioned immediate
rejection should be communicated to the sender so that it can
avoid sending EXI content to that receiver in the future.
</p></div><div class="div1">
<h2><a name="xml-technologies" id="xml-technologies"></a>4 Existing XML Technologies</h2><p>
Most existing XML technologies are specified based on the
<a href="#infoset">[XML Infoset]</a>. EXI has been designed as an encoding
format of the Infoset and is therefore immediately applicable
to such technologies. Some technologies, however, are
specified in terms of character or octet data, and therefore
require further consideration on the impacts of EXI. This also
means that applications requiring byte-for-byte preservation
of XML documents cannot always use EXI, though EXI is capable
of preserving all the information relevant to <a href="#xml-c14n">[Canonical XML]</a>. Other technologies may gain additional
significant benefits if modified to support EXI. While such
modifications are not required immediately, they may be
desirable in future versions of the relevant specifications.
</p><div class="div2">
<h3><a name="xml-security" id="xml-security"></a>4.1 XML Security</h3><p>
The XML security specifications <a href="#xml-sig">[XML Signature]</a> and
<a href="#xml-enc">[XML Encryption]</a> can be used as they currently exist
with EXI, so EXI has no immediate impact on them. For
interoperability in current environments, this requires
computing signatures over an XML serialization and making
sure that any encrypted content has been serialized as XML.
</p><div class="div3">
<h4><a name="xml-signature" id="xml-signature"></a>4.1.1 XML Signature</h4><p>
In current environments, XML Signature can be used with
EXI by specifying an existing XML canonicalization
algorithm, such as <a href="#xml-c14n">[Canonical XML]</a>. A signed
document can be transmitted using EXI, as long as the <a href="http://www.w3.org/TR/exi-best-practices#security">necessary
fidelity options</a> are enabled. As with XML, the
receiver will need to serialize the signed content using
the selected XML canonicalization algorithm to verify the
signatures. In the future, XML use could be avoided
completely by using a URI that designates a to-be-defined
EXI canonicalization algorithm, rather than an XML
canonicalization.
</p></div><div class="div3">
<h4><a name="xml-encryption" id="xml-encryption"></a>4.1.2 XML Encryption</h4><p>
Use of XML Encryption in mixed XML/EXI environments may
require using XML as the format for any data that is
encrypted, as the producer may not know whether the
ultimate recipient of the document is capable of
understanding EXI. If it is known that the recipient
understands EXI, the <code>MimeType</code> attribute of
the <code><a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210#sec-EncryptedData">EncryptedData</a></code>
element could be used to indicate EXI as the format of the
encrypted data (though this appears to require a minor
modification to <a href="#xml-enc">[XML Encryption]</a>).
</p></div><div class="div3">
<h4><a name="s-xml-c14n" id="s-xml-c14n"></a>4.1.3 XML Canonicalization</h4><p>
EXI has no impact on existing XML canonicalization
algorithms (<a href="#xml-c14n">[Canonical XML]</a>, <a href="#exc-xml-c14n">[Excl XML Canonicalization]</a>). For use in signatures, it may be
beneficial in the future to define a URI for
“canonical EXI” that defines a specific EXI
Options document to use in generating a canonical form,
but this consideration is completely separate from
existing specifications.
</p></div></div><div class="div2">
<h3><a name="api-impact" id="api-impact"></a>4.2 Existing XML Processing APIs</h3><p>
As EXI is an encoding of the XML Infoset, an EXI
implementation can support any of the commonly-used XML APIs
for XML processing, so EXI has no immediate impact on
existing XML APIs. However, using an existing XML API also
requires that all names and text appearing in the EXI
document be converted into strings. In the future, more
efficiency might be achievable if the higher layers could
directly use these data as typed values appearing in the EXI
document. For instance, if a higher layer needs typed data,
going through its string form can produce a performance
penalty, so an extended API that supports typed data
directly could improve performance when used with EXI.
</p></div><div class="div2">
<h3><a name="other-binary" id="other-binary"></a>4.3 XML and Binary Attachments</h3><p>
Some use cases require the inclusion of binary data in XML
documents, and to avoid the required base64 conversions,
specifications such as <a href="#xop">[XOP]</a> exist to package
the binary data separately from XML. Since EXI is capable
of encoding binary data directly, it is possible to simply
include the binary data inside an EXI document without a
loss in efficiency. If a use case requires a packaging
where XML content is separated from the binary data, EXI can
still be used as the format for the XML part.
</p></div></div><div class="div1">
<h2><a name="human-readability" id="human-readability"></a>5 Sacrificing Human Readability</h2><p>
As a text-based format, XML allows direct editing with generic
text editors as well as debugging generated XML by simply
using “view source” features. EXI, as a binary format,
does not conveniently permit this, so generating and
inspecting EXI is therefore mostly in the domain of specific
tools that include an EXI processor.
</p><p>
Already many applications that support viewing and editing XML
parse the XML to present a structured view of the data, more
attractive than unformatted text. Such applications are
usually easy to modify to include recognition of new data
formats, so plugging in an existing EXI processor would have
low cost and would provide the same data inspection
opportunities as the application already provides for XML.
Thus the sacrifice of human readability is not as large a
concern as it might initially seem due to the XML
compatibility that EXI provides.
</p></div><div class="div1">
<h2><a name="other-impact" id="other-impact"></a>6 Other Impacts</h2><p>
Content negotiation in protocols like HTTP is based on peers
informing each other what content types and encodings they
support. While this is sufficient for basic usage of EXI, many
use cases also require information on common schemas and
datatype representation maps. Negotiation of such additional
parameters might be accomplished through a variety of methods,
and it is not yet clear which methods are best suited for the
task.
</p></div><div class="div1">
<h2><a name="conclusions" id="conclusions"></a>7 Conclusions</h2><p>
EXI has been designed to be compatible with XML and can be
introduced into the existing family of XML technologies
without immediate disruption to XML-using applications.
However, with certain modifications to existing XML-related
specifications in the future it may be possible to achieve
additional benefits when using EXI, still without disruption
to existing XML-based applications. Furthermore, in a
multi-application system where only some applications adopt
EXI, sending EXI data to the other applications can
potentially cause disruption, so care is needed to account for
differing format support among the participating applications.
</p></div><div class="div1">
<h2><a name="references" id="references"></a>8 References</h2><dl><dt class="label"><a name="exi-format" id="exi-format"></a>EXI</dt><dd>
<a href="http://www.w3.org/TR/exi/"><cite>Efficient XML Interchange (EXI) Format 1.0
(Working Draft)</cite></a>, John Schneider and Takuki
Kamiya, Editors. World Wide Web Consortium.
(See http://www.w3.org/TR/exi/.)</dd><dt class="label"><a name="xml" id="xml"></a>XML</dt><dd>
<a href="http://www.w3.org/TR/2006/REC-xml-20060816/"><cite>Extensible Markup Language (XML) 1.0 (Fourth
Edition)</cite></a>, Tim Bray, Jean Paoli,
C. M. Sperberg-McQueen, Eve Maier, and François Yergeau,
Editors. World Wide Web Consortium, 16 August 2006.
(See http://www.w3.org/TR/2006/REC-xml-20060816/.)</dd><dt class="label"><a name="infoset" id="infoset"></a>XML Infoset</dt><dd>
<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"><cite>XML Information Set (Second Edition)</cite></a>,
John Cowan and Richard Tobin, Editors. World Wide Web
Consortium, 4 February 2004.
(See http://www.w3.org/TR/2004/REC-xml-infoset-20040204.)</dd><dt class="label"><a name="xml-sig" id="xml-sig"></a>XML Signature</dt><dd>
<a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/"><cite>XML-Signature Syntax and Processing</cite></a>,
Donald Eastlake, Joseph Reagle, and David Solo, Editors.
World Wide Web Consortium, 12 February 2002.
(See http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.)</dd><dt class="label"><a name="xml-enc" id="xml-enc"></a>XML Encryption</dt><dd>
<a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/"><cite>XML Encryption Syntax and Processing</cite></a>,
Donald Eastlake and Joseph Reagle, Editors. World Wide Web
Consortium, 10 December 2002.
(See http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.)</dd><dt class="label"><a name="xml-c14n" id="xml-c14n"></a>Canonical XML</dt><dd>
<a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"><cite>Canonical XML Version 1.0</cite></a>, John Boyer,
Editor. World Wide Web Consortium, 15 March 2001.
(See http://www.w3.org/TR/2001/REC-xml-c14n-20010315.)</dd><dt class="label"><a name="exc-xml-c14n" id="exc-xml-c14n"></a>Excl XML Canonicalization</dt><dd>
<a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/"><cite>Exclusive XML Canonicalization Version
1.0</cite></a>, John Boyer, Donald E. Eastlake, and Joseph
Reagle, Editors. World Wide Web Consortium, 18 July 2002.
(See http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/.)</dd><dt class="label"><a name="xop" id="xop"></a>XOP</dt><dd>
<a href="http://www.w3.org/TR/2005/REC-xop10-20050125/"><cite>XML-binary Optimized Packaging</cite></a>, Martin
Gudgin, Noah Mendelsohn, Mark Nottingham, and Hervé Ruellan,
Editors. World Wide Web Consortium, 25 January 2005.
(See http://www.w3.org/TR/2005/REC-xop10-20050125/.)</dd><dt class="label"><a name="exi-bp" id="exi-bp"></a>EXI Best Practices</dt><dd>
<a href="http://www.w3.org/TR/exi-best-practices"><cite>Efficient XML Interchange (EXI) Best Practices
(Working Draft)</cite></a>, Mike Cokus and Daniel Vogelheim,
Editors. World Wide Web Consortium.
(See http://www.w3.org/TR/exi-best-practices.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a name="acknowledgements" id="acknowledgements"></a>A Acknowledgements</h2><p>
This document is the work of the <a href="http://www.w3.org/XML/EXI/">Efficient XML Interchange
(EXI) WG</a>.
</p><p>
Members of the Working Group are (at the time of publication,
sorted alphabetically by last name):
</p><blockquote><p>Carine Bournez, W3C/ERCIM (<em>staff contact</em>)<br>Don Brutzman, Web3D Consortium<br>Alex Ceponkus, AgileDelta, Inc.<br>Michael Cokus, MITRE Corporation (<em>chair</em>)<br>Roger Cutler, Chevron<br>Ed Day, Objective Systems, Inc.<br>Philippe de Cuetos, Expway<br>Joerg Heuer, Siemens AG<br>Alan Hudson, Web3D Consortium<br>Takuki Kamiya, Fujitsu Limited<br>Jaakko Kangasharju, University of Helsinki<br>Richard Kuntschke, Siemens AG<br>Don McGregor, Web3D Consortium<br>Daniel Peintner, Siemens AG<br>Santiago Pericas-Geertsen, Sun Microsystems, Inc.<br>Liam Quin, W3C/MIT<br>Rich Rollman, AgileDelta, Inc.<br>Paul Sandoz, Sun Microsystems, Inc.<br>John Schneider, AgileDelta, Inc.<br>Cedric Thienot, Expway<br>Yun Wang, Intel Corporation<br>Greg White, Stanford University (<em>former co-chair</em>)</p></blockquote><p>
The EXI Working Group would like to acknowledge the following
former members of the group for their leadership, guidance and
expertise they provided throughout their individual tenure in
the WG. (sorted alphabetically by last name)
</p><blockquote><p>Robin Berjon, Expway (<em>former co-chair</em>) (until 17 October 2006)<br>Oliver Goldman, Adobe Systems, Inc. (<em>former co-chair</em>) (until 08 June 2006)<br>Peter Haggar, IBM (until 07 March 2007)<br>Kimmo Raatikainen, Nokia (until 18 March 2008)<br>Paul Thorpe, OSS Nokalva, Inc. (until 11 September 2007)<br>Daniel Vogelheim, Invited Expert (<em>former co-chair</em> then from Siemens AG) (until 28 February 2008)<br>Stephen Williams, High Performance Technologies, Inc. (until 30 June 2008)</p></blockquote></div></div></body></html>