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.
374 lines
25 KiB
374 lines
25 KiB
|
|
<!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>
|