index.html
45.4 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
<!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) Best Practices</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note { margin-left: 2em; }
div.notice { margin-left: 2em; font-weight: bold; font-size: larger; color: red }
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}
.bp { border: 1px solid black; background-color: #c0e0e0; padding: 5pt; }
.bp:before { font-weight: bold; content: "Best Practice: "; }
</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) Best Practices</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 19 December 2007</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2007/WD-exi-best-practices-20071219/">http://www.w3.org/TR/2007/WD-exi-best-practices-20071219/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/exi-best-practices/">http://www.w3.org/TR/exi-best-practices/</a>
</dd><dt>Editors:</dt><dd>Mike Cokus, MITRE Corporation</dd><dd>Daniel Vogelheim, Siemens AG</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <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 purpose of this document is to provide guidelines for the interoperable deployment of the Efficient XML Interchange (EXI) format. It provides explanations of format features and techniques to support interoperable information exchanges using EXI. While intended primarily as a practical guide for systems architects and programmers, it also presents information suitable for the general reader interested in EXI's intended role in the expanding Web.</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 First Public Working Draft was developed by the <a href="http://www.w3.org/XML/EXI">Efficient XML Interchange (EXI) Working Group</a>. A complete list of changes to this document is available.
</p><p>
Comments on this document are invited and are to be sent to the public <a href="mailto:public-exi@w3.org">public-exi@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/public-exi/">public archive</a>). If substantive comments are received, the Working Group may revise this Working Draft or publish it as a final Working Group Note.
</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 rel="disclosure" 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="#introduction">Introduction</a><br>
2. <a href="#whether-to-use-exi">Deciding Whether or Not to Use EXI</a><br>
3. <a href="#interop">XML/EXI Interoperability</a><br>
3.1 <a href="#family">EXI's Place in the XML Family of Technologies</a><br>
3.2 <a href="#preserve">Preserving XML Features in EXI</a><br>
3.3 <a href="#security">Security</a><br>
3.3.1 <a href="#signature">XML Signature</a><br>
3.3.2 <a href="#encryption">XML Encryption</a><br>
3.3.3 <a href="#alternatives">Alternatives to XML Security</a><br>
4. <a href="#mixed-XML-EXI">Mixed XML/EXI Environments</a><br>
4.1 <a href="#N65832">Identifying EXI Content</a><br>
4.1.1 <a href="#distinguishing-bits">Distinguish EXI from XML</a><br>
4.1.2 <a href="#filename-extension">Filename Extensions and MIME Types</a><br>
4.2 <a href="#http-content-negotiation">Negotiating Content in HTTP</a><br>
5. <a href="#sharing-knowledge">Shared Encoding Knowledge</a><br>
5.1 <a href="#sharing-schemas">Schemas</a><br>
5.2 <a href="#pluggable-codecs">Pluggable Codecs</a><br>
5.3 <a href="#prior-agreements">Out-of-Band Encoding Knowledge from Prior Agreements</a><br>
6. <a href="#view-source">Maintain a "View Source" Capability for Debugging</a><br>
7. <a href="#references">References</a><br>
7.1 <a href="#Normative-References">Normative References</a><br>
7.2 <a href="#Informative-References">Other References</a><br>
</p>
<h3><a name="appendices" id="appendices"></a>Appendix</h3><p class="toc">A <a href="#acknowledgements">Acknowledgements</a> (Non-Normative)<br>
</p><p class="toc"><a href="#endnotes">End Notes</a></p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>The EXI Best Practices are guidelines for effectively employing the EXI format. The guidelines pertain not only to EXI's effective use in constrained environments, but also to addressing interoperability in environments where both XML and EXI are options for serializing the <a href="#XMLInfoset">[XML Information Set]</a>. The EXI format is interoperable with XML technologies. However, since it is an alternative serialization of the XML Infoset, consideration is warranted when employing EXI in environments in which textual XML is also used. While EXI features support interoperability with XML, specific techniques for addressing mixed XML/EXI environments is beyond the scope of the format specification. These techniques are included in this document.
</p></div><div class="div1">
<h2><a name="whether-to-use-exi" id="whether-to-use-exi"></a>2. Deciding Whether or Not to Use EXI</h2><p class="bp">Use EXI only in cases where a primary objective is to leverage XML technologies, but use of the XML 1.x format cannot support the required efficiency. Optimized implementations and parsing technologies should be considered
in this determination.</p><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section will recommended a process (e.g., a decision tree) as guidance for determining the applicability of EXI in a given scenario/environment.</td></tr></table></div><div class="div1">
<h2><a name="interop" id="interop"></a>3. XML/EXI Interoperability</h2><div class="div2">
<h3><a name="family" id="family"></a>3.1 EXI's Place in the XML Family of Technologies</h3><p>"XML is a family of technologies" <a href="#xml10points">[XML In 10 Points]</a>. These technologies have been developed to accomplish frequent, important tasks and their number continues to grow. The majority of XML technologies interact with XML1.x instance documents via an abstract model defined in <a href="#XMLInfoset">[XML Information Set]</a>. In other words, an XML instance document can be viewed as a serialization of an XML Infoset. In this manner, XML 1.x serves as an interchange format between XML technologies.</p><p>EXI is also intended as an interchange format within the XML Family of Technologies. Like XML, it can be used to serialize an XML Infoset, but more efficiently than XML. Thus EXI is an alternative interchange format, designed for resource constrained environments. EXI is interoperable with XML technologies which operate at the level of XML Infosets (as most do). XML technologies which operate at the text (or octet) level can interoperate with EXI, but require special considerations and may affect how EXI is employed. These are discussed below in <a href="#security"><b>3.3 Security</b></a>
</p></div><div class="div2">
<h3><a name="preserve" id="preserve"></a>3.2 Preserving XML Features in EXI</h3><p>Even though XML has been enormously successful in diverse areas and use cases, different applications often require different XML feature sets. Treatment of those unused features implies unnecessary overhead. The EXI Format addresses this imbalance by offering a simple way to set <em>fidelity options</em>. Via these fidelity options, EXI supports preserving the following lexical characteristics: comments, processing instructions, insignificant whitespace, doctypes (entity references), namespace prefixes, and element/attribute content. As discussed above, these options are set in the "preserve" section of the EXI header.</p><p>While the meaning of preserving XML features like comments, processing instructions, and doctypes might be rather evident, additional explanation is required for other features. For instance, the option of preserving or not preserving whitespace does not pertain to all whitespace characters. In fact, if whitespace is not preserved, only insignificant whitespace characters are eliminated. Mixed content elements and XML elements set to preserve spaces (xml:space="preserve") are understood as significant whitespace and therefore retained in any case.</p><p>In addition, consider namespace prefixes. XML prefixes are by definition bound to namespaces, but the precise lexical expression of the namespace prefix can be suppressed without loosing information required to resolve the references. All that is really needed is to maintain consistent namespace references. However, the precise lexical representation of a prefix (e.g. "xsi") can aid a human reader in understanding certain namespace references. In cases like these, the actual strings used as namespace references can be preserved in EXI.</p><p>EXI also provides the option to preserve the lexical form of element/attribute content. In an XML instance document, a single value may be represented by more than one lexical string. Equivalent lexical representations are mapped to a single value in the EXI format by default. Mapping to a distinct representation enables a more efficient serialization. However, if the lexical representation plays a important role in an application, EXI provides the option to preserve all lexical content, regardless of whether they can be mapped to the same value.</p><p>It is important to note that all fidelity options in EXI are by default set such that no lexical features are preserved. This is in order to achieve high compression and processing efficiency. The option to preserve a particular category of lexical values must be explicitly set in the EXI header. The EXI fidelity options are defined in <a href="#fidoptions">[EXI Fidelity Options]</a>
</p></div><div class="div2">
<h3><a name="security" id="security"></a>3.3 Security</h3><table border="1" summary="Editorial note: MC"><tr><td align="left" valign="top" width="50%"><b>Editorial note: MC</b></td><td align="right" valign="top" width="50%">19 November, 2007</td></tr><tr><td colspan="2" align="left" valign="top">The EXI and XML Security working groups met during the 2007 W3C Technical Plenary on 9 November to dicuss this material. No issues were uncovered concerning the proposed approach.</td></tr></table><p></p><div class="bp"><p>Use EXI fidelity options with XML Encryption and Signature.</p><ul><li><p>Any XML canonicalization algorithms employed by encryption or signature require
the following options to be enabled: Preserve.pis, Preserve.prefixes, and Preserve.lexicalValues.</p></li><li><p>If the canonicalization algorithm also preserves comments, then Preserve.comments must also be enabled.</p></li></ul></div><p>The phrase <em>XML Security</em> generally refers to a set of technologies that enable integrity, confidentiality and authentication of XML messages. <a href="#XMLEncryption">[XML Encryption]</a> and <a href="#XMLSignature">[XML Signature]</a> are two W3C recommendations that address these requirements. XML Encryption defines a mechanism by which messages and message parts can be encrypted with a key to provide confidentiality. XML Signature defines a mechanism by which messages and message parts can be digitally signed to provide integrity, to ensure that the data is not tampered with, and authentication, to verify the identity of the message producer (although, in practice, other methods like User-Token are preferred means of establishing a producer's identity). If more than one property is required, such as integrity and confidentiality, these technologies can be combined to produce messages with encrypted parts and signed parts, or even parts that have been both encrypted and signed.</p><p>In general, XML technologies that operate at the level of the <a href="#XMLInfoset">[XML Information Set]</a> require no modifications to use the EXI format. Digital signature and digital encryption technologies operate at the level of octets. Thus, an XML Infoset needs to be serialized into an octet stream before it can be signed or encrypted. Furthermore, in the case of XML signature, this serialization must be clearly defined so that the processor that verifies the signature can do so unambiguously, thus enabling interoperability. For this reason, the XML Signature recommendation mandates the inclusion of a canonicalization method element as part of the meta-data describing a signature. Several XML canonicalization methods exist, typically varying on which XML Infoset items they ignore and on how they handle namespaces. Regardless of these differences, they all define a proper function (i.e., not just a relation) between XML Infosets and octet streams.</p><p>Conceptually, the operation of securing a message can be regarded as an XML Infoset transformation <sup>[<a name="FN-ANCH-N65767" id="FN-ANCH-N65767" href="#N65767">1</a>]</sup> guided by certain configuration parameters defined by the application's developer. In this sense, securing a message takes place after its Infoset is produced and before it is serialized; conversely, unsecuring a message takes place after a message is parsed and before it is consumed. In this regard, and provided that the appropriate encoding options are chosen, the EXI format can still be used as the on-the-wire encoding without affecting these two pre-serialization and post-parsing steps. Note that, as long as the process of mapping XML Infosets into octet streams is not altered, this approach still requires the use of an XML parser and an XML serializer during the message securing and unsecuring phases. Therefore, a software stack that supports this type of processing will have to include libraries for both XML and EXI. Although we expect this to be the norm in most cases, it nonetheless can present an architectural challenge in small devices where memory capacity is at a premium.</p><div class="div3">
<h4><a name="signature" id="signature"></a>3.3.1 XML Signature</h4><p>As indicated earlier, XML Signature provides a way to specify the canonicalization method or algorithm as part of its meta-data. Canonicalization algorithms are identified via the use of URIs. Since there are multiple ways of encoding an XML Infoset into EXI, for example by using different fidelity options, it cannot be used as a way of mapping an XML Infoset into an octet stream. However, if a canonical EXI and a new URI to identify it are defined, the extensibility points in XML Signature could be used without requiring any additional changes to the existing recommendation.</p><p>XML canonicalization can be inclusive or exclusive, depending on what contextual information is included, as well as with or without comments. Regardless of the XML canonicalization algorithm, the following <a href="#fidoptions">[EXI Fidelity Options]</a> must be enabled to ensure that the relevant Infoset items are available to the signature verifier: <em>Preserve.pis</em>, <em>Preserve.prefixes</em>, and <em>Preserve.lexicalValues</em>. When EXI is used as the on-the-wire encoding and comments are preserved by the canonicalization algorithm, then the fidelity option, <em>Preserve.comments</em> must also be enabled. There may be cases for which the preservation of lexical values is not required, but this is not a general rule. For example, both "true" and "1" are in the lexical space of an xs:boolean and an EXI processor is free to pick either one at decoding time. Similarly, there are cases in which the lexical representation of an xs:float is not preserved when encoded as EXI float.</p></div><div class="div3">
<h4><a name="encryption" id="encryption"></a>3.3.2 XML Encryption</h4><p>XML Encryption defines a mechanism by which elements or their content can be replaced by a new element containing a cipher and meta-data describing how the cipher was generated. The cipher generation process requires the transformation of the XML items into a sequence of octets. The cipher that results from an encryption step is a binary sequence of octets that is encoded in base64. Although XML canonicalization is not a requirement to produce these octets, many XML encryption processors rely on exclusive XML canonicalization in order to reduce the amount of contextual information in the fragment being encrypted. This process simplifies not only the fragment but also the process by which it can be re-inserted (re-enveloped) in a different context.</p><p>Transmitting self-contained fragments as ciphers in base64 format (and their related meta-data) using EXI as the on-the-wire encoding is not affected by any of the EXI fidelity options. Unlike the XML signature case, confidentiality requires the data being secured to be removed from the Infoset that is ultimately encoded using EXI.</p></div><div class="div3">
<h4><a name="alternatives" id="alternatives"></a>3.3.3 Alternatives to XML Security</h4><p>For certain applications, transport level security is an alternative to XML security. In transport level security, the mechanisms that provide integrity, confidentiality and authentication are not part of the message but are instead built into the transport layer. The most popular solution is HTTP over TLS, also known to as HTTPS. Although HTTPS is commonly used to provide confidentiality (encryption) between two parties, it also includes capabilities for integrity and authentication. Naturally, since the transport layer operates at the level of octets, there is no distinction between XML packets and EXI packets. Thus, the use of transport level security is an alternative for EXI in the same way it is for XML.</p><p>Although simpler and more efficient, transport level security is not as versatile as the message level security offered by XML Security. Message level security has a number of advantages over transport level solutions in that security information, as an intrinsic part of a message, can persist over the lifetime of a connection. Thus, for example, secured messages can be copied to secondary storage and their properties (integrity, authentication and confidentiality) verified at later point in time. Moreover, message level security enables system architectures wherein messages flow through multiple nodes before reaching their destination, that is, architectures that are not just point to point. </p><p>To summarize, the choice of message security over transport security depends on the application in question. It is often a trade-off between processing efficiency and flexibility. Regardless of the selection, there are ways of integrating EXI to enable message interchange in a secure manner.</p></div></div></div><div class="div1">
<h2><a name="mixed-XML-EXI" id="mixed-XML-EXI"></a>4. Mixed XML/EXI Environments</h2><p>Use caution when employing EXI in Mixed XML/EXI Environment (options in order of preference):</p><ol class="enumar"><li><p>Don't send EXI to recipients unless they want it/ask for it/can use it (may be agreed ahead of time).</p></li><li><p>Negotiate EXI content via protocols like HTTP.</p></li><li><p>Identify content by examining file/stream before feeding to an XML processor.</p></li><li><p>Let the XML processor produce an error when fed EXI.</p></li></ol><div class="div2">
<h3><a name="N65832" id="N65832"></a>4.1 Identifying EXI Content</h3><div class="div3">
<h4><a name="distinguishing-bits" id="distinguishing-bits"></a>4.1.1 Distinguish EXI from XML</h4><p class="bp">Use the <em>Distinguishing Bits</em> to distinguish between XML and EXI content before deciding on which processor to use. Do not send EXI content to an XML processor.</p><p>The seamless introduction of EXI in existing environments is a major goal. To non interrupt existing applications on one hand and to facilitate the use of EXI on the other hand Distinguishing Bits were introduced.</p><p>The EXI Distinguishing Bits, a leading bit sequence ("10"), are a non optional part of the EXI Header. They distinguish EXI from any well-formed XML in any conventional character encoding <sup>[<a name="FN-ANCH-N65849" id="FN-ANCH-N65849" href="#N65849">2</a>]</sup>. They may therefore be used as a reliable distinguisher, even in cases where no external type content information is available.</p><p>Note that XML processors do not give standardized error messages when parsing non-XML content - such as EXI - and it is therefore recommended to check for EXI's distinguishing bits before feeding data to an XML parser.</p><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The EXI WG is thinking about introducing a more powerful "header" to distinguish EXI from more than XML.</td></tr></table></div><div class="div3">
<h4><a name="filename-extension" id="filename-extension"></a>4.1.2 Filename Extensions and MIME Types</h4><p class="bp">Do not use per-application MIME types or filename extensions for EXI-encoded XML data in a mixed XML/EXI environment, to allow a generic EXI processor to transform EXI into equivalent XML.</p><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This item is still under discussion within the WG.
The current thinking is that, in a mixed XML/EXI environment, an EXI processor should have the means to transform the content back into its XML form.</td></tr></table></div></div><div class="div2">
<h3><a name="http-content-negotiation" id="http-content-negotiation"></a>4.2 Negotiating Content in HTTP</h3><p class="bp">Use HTTP content negotiation to determine whether a recipient can process EXI. Do not send EXI to recipients unless they specifically request it.</p><p>EXI can naturally be used to more efficiently transfer XML resources
over <a href="#rfc2616">[HTTP 1.1]</a>. Since EXI - by its very definition - will retain the full
identity and structure of any XML document, it is suitable as an HTTP
transfer encoding. This enables HTTP's built-in content negotiation
features to ensure that clients which understand EXI can transparently
take full advantage of it, without forcing any clients or servers
without such capability or requirement to change.</p><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The following represents the current thinking of the EXI WG and has not been blessed by the IETF, which is responsible for maintaining the HTTP protocol and the allowed content encodings. So neither the encoding identifier nor the actual use of EXI for an HTTP content encoding can presently be considered final.
</td></tr></table><p>The presumed standard pattern for an EXI-enabled client would therefore
be to include exi in the <code>Accept-Encoding:</code>-Header of an HTTP GET, POST or
PUT request. If the server agrees to use EXI, it will put a suitable
<code>Content-Encoding:</code>-Header into the reply.
</p><p>Mock-up GET request:</p><pre>
GET /XML/Group/EXI/docs/best/exi-best-practices.xml HTTP/1.1
Host: www.w3.org
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: x-exi,gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
</pre><p>Mock-up reply:</p><pre>
HTTP/1.1 200 OK
Last-Modified: Mon, 01 Oct 2007 20:34:06 GMT
Accept-Ranges: bytes
Content-Length: 7360
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Encoding: x-exi
Content-Type: application/xhtml+xml; charset=utf-8
{EXI data goes here...}
</pre><p>Some situations may require a pre-agreement between client and server,
for example if an initial PUT or POST request contains large amounts of
data. In this case, the HTTP OPTIONS method can be used by a client to
inquire ahead of time about the availability of EXI as a transfer
encoding.
</p><p>If a server receives a request for an EXI-encoded resource that it
cannot fulfill, it is expected that the server will return a status code
406 (Not Acceptable).</p><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The EXI WG intends to discuss the use of EXI within "AJAX" environments with the respective working groups, to ensure that those clients that choose to implement EXI as HTTP content encoding would do so in an API-compatible and backwards-compatible manner.</td></tr></table></div></div><div class="div1">
<h2><a name="sharing-knowledge" id="sharing-knowledge"></a>5. Shared Encoding Knowledge</h2><div class="div2">
<h3><a name="sharing-schemas" id="sharing-schemas"></a>5.1 Schemas</h3><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section will recommend best practices for sharing schemas used for EXI encoding/decoding.</td></tr></table></div><div class="div2">
<h3><a name="pluggable-codecs" id="pluggable-codecs"></a>5.2 Pluggable Codecs</h3><p id="BP-pluggable-codecs" class="bp">Use EXI pluggable codecs only when there is explicit agreement between the communicating parties and not for encoding documents intended for general recipients. Using pluggable codecs without prior understanding and agreement will adversely affect interoperability.</p><ul><li><p>Pluggable codecs are very useful in closed systems, but their use is strongly discouraged beyond
the circle of the pre-supposed parties.</p></li><li><p>If pluggable codecs must be employed, standardization of codecs within the applicable communities is strongly
encouraged.</p></li></ul><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section will recommend best practices for using pluggable codecs for EXI encoding/decoding.</td></tr></table></div><div class="div2">
<h3><a name="prior-agreements" id="prior-agreements"></a>5.3 Out-of-Band Encoding Knowledge from Prior Agreements</h3><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section will discuss recommended approaches for coordinating and documenting encoding options (including schemas and pluggable codecs) which are
pre-agreed, rather than declared or negotiated at the time of the information exchange.</td></tr></table></div></div><div class="div1">
<h2><a name="view-source" id="view-source"></a>6. Maintain a "View Source" Capability for Debugging</h2><p class="bp">Provide EXI to XML translation as a "View Source" capability for debugging purposes.</p><p>"XML is text, but isn't meant to be read" <a href="#xml10points">[XML In 10 Points]</a>. Taken in context, this statement refers to the advantage offered by a textual format like XML. While XML is text that people shouldn't normally have to read in unprocessed form, it can be viewed with a compatible <sup>[<a name="FN-ANCH-N65965" id="FN-ANCH-N65965" href="#N65965">3</a>]</sup> text editor. This is particularly useful in cases where the text gives a comprehensive view of XML structure and data, without needing to reference this information via an API. In effect, this provides a "view source" capability for debugging purposes.</p><p>The XML expression of an EXI document is also useful for debugging purposes. On occasion, application developers may need a human-readable form to get a comprehensive view of structures and/or data which may be causing problems. The EXI format is designed such that EXI documents may be translated into equivalent XML documents. After translation, the resulting XML can be viewed in a text editor, if needed. This translation capability may also used in conjunction with other commonly available tools, including web browsers.</p><p>It is recommended that whenever practical, EXI-capable system maintain an ability to process textual XML data, and allow it to be switched back and forth between EXI and XML. This has in the past proven useful is similar systems for debugging purposes, as it allows to easily determine whether any occurring problems are due to a faulty EXI deployment or whether such problems occur similarly in a pure XML setting as well.</p></div><div class="div1">
<h2><a name="references" id="references"></a>7. References</h2><div class="div2">
<h3><a name="Normative-References" id="Normative-References"></a>7.1 Normative References</h3><dl><dt class="label"><a name="RFC2119" id="RFC2119"></a>IETF RFC 2119</dt><dd>
<a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate
Requirement Levels</cite></a>, S. Bradner, Author. Internet
Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt.
(See http://www.ietf.org/rfc/rfc2119.txt.)</dd><dt class="label"><a name="exiform" id="exiform"></a>EXI Format</dt><dd>
<a href="http://www.w3.org/TR/exi/"><cite>Efficient XML Interchange Format</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/.)</dd><dt class="label"><a name="desprin" id="desprin"></a>EXI Design Principles</dt><dd>
<a href="http://www.w3.org/TR/exi/exi.html#principles"><cite>Efficient XML Interchange Format, Design Principles</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/exi.html#principles.)</dd><dt class="label"><a name="options" id="options"></a>EXI Options</dt><dd>
<a href="http://www.w3.org/TR/exi/exi.html#options"><cite>Efficient XML Interchange, Options</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/exi.html#options.)</dd><dt class="label"><a name="fidoptions" id="fidoptions"></a>EXI Fidelity Options</dt><dd>
<a href="http://www.w3.org/TR/exi/exi.html#fidelityOptions"><cite>Efficient XML Interchange, Fidelity Options</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/exi.html#fidelityOptions.)</dd><dt class="label"><a name="compress" id="compress"></a>EXI Compression</dt><dd>
<a href="http://www.w3.org/TR/exi/exi.html#compression"><cite>Efficient XML Interchange, Compression</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/exi.html#compression.)</dd><dt class="label"><a name="codecs" id="codecs"></a>EXI Pluggable Codecs</dt><dd>
<a href="http://www.w3.org/TR/exi/exi.html#pluggableCodecs"><cite>Efficient XML Interchange, Pluggable Codecs</cite></a>, John Schneider, Takuki Kamiya, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2007/WD-exi-20070716/.
(See http://www.w3.org/TR/exi/exi.html#pluggableCodecs.)</dd><dt class="label"><a name="XML10" id="XML10"></a>XML 1.0</dt><dd>
<a href="http://www.w3.org/TR/2006/REC-xml-20060816"><cite>Extensible Markup Language (XML) 1.0 (Fourth Edition)</cite></a>,
T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors.
World Wide Web Consortium, 10 February 1998, revised 16 August 2006.
This version is http://www.w3.org/TR/2006/REC-xml-20060816.
The latest version is available at
<a href="http://www.w3.org/TR/REC-xml/">
http://www.w3.org/TR/REC-xml</a>.
(See http://www.w3.org/TR/2006/REC-xml-20060816.)</dd><dt class="label"><a name="XMLInfoset" id="XMLInfoset"></a>XML Information Set</dt><dd>
<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/"><cite>XML Information Set (Second Edition)</cite></a>,
J. Cowan and R. Tobin, Editors. World Wide Web Consortium,
24 October 2001, revised 4 February 2004.
This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204.
The latest version is available at
<a href="http://www.w3.org/TR/xml-infoset/">
http://www.w3.org/TR/xml-infoset</a>.
(See http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.)</dd><dt class="label"><a name="schema1" id="schema1"></a>XML Schema Structures</dt><dd>
<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1: Structures Second
Edition</cite></a>, H. Thompson, D. Beech, M. Maloney, and
N. Mendelsohn, Editors. World Wide Web Consortium, 2 May
2001, revised 28 October 2004.
This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028.
The latest version is available at
<a href="http://www.w3.org/TR/xmlschema-1">
http://www.w3.org/TR/xmlschema-1</a>.
(See http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.)</dd><dt class="label"><a name="schema2" id="schema2"></a>XML Schema Datatypes</dt><dd>
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second
Edition</cite></a>, P. Byron and A. Malhotra,
Editors. World Wide Web Consortium, 2 May 2001, revised 28
October 2004.
This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028.
The latest version is available at
<a href="http://www.w3.org/TR/xmlschema-2">
http://www.w3.org/TR/xmlschema-2</a>.
(See http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.)</dd></dl></div><div class="div2">
<h3><a name="Informative-References" id="Informative-References"></a>7.2 Other References</h3><dl><dt class="label"><a name="eximeas" id="eximeas"></a>EXI Measurements Note</dt><dd>
<a href="http://www.w3.org/TR/exi-measurements/"><cite>Efficient XML Interchange Measurements Note</cite></a>,
Greg White, Don Brutzman, Stephen Williams and Jaakko Kangasharju, Editors.
World Wide Web Consortium.
The latest version at the time of this writing is
http://www.w3.org/TR/2006/WD-exi-measurements-20060718/.
(See http://www.w3.org/TR/exi-measurements/.)</dd><dt class="label"><a name="relaxng" id="relaxng"></a>ISO/IEC 19757-2:2003</dt><dd>
<a href="http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37605"><cite>Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG</cite></a>
(See http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37605.)</dd><dt class="label"><a name="soap12" id="soap12"></a>SOAP 1.2</dt><dd>
<a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"><cite>SOAP Version 1.2 Part 1: Messaging
Framework</cite></a>, M. Gudgin, M. Hadley, N. Mendelsohn,
J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web
Consortium, 24 June 2003.
This version is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
The latest version is available at
<a href="http://www.w3.org/TR/soap12-part1/">
http://www.w3.org/TR/soap12-part1/</a>.
(See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)</dd><dt class="label"><a name="xbcmeas" id="xbcmeas"></a>XBC Measurement Methodologies</dt><dd>
<a href="http://www.w3.org/TR/2005/NOTE-xbc-measurement-20050331/"><cite>XML Binary Characterization, Measurement Methodologies</cite></a>, S. D. Williams and P. Haggar,
Editors. World Wide Web Consortium, 31 March 2005.
This version is http://www.w3.org/TR/2005/NOTE-xbc-measurement-20050331/.
The latest version is available at
<a href="http://www.w3.org/TR/xbc-measurement">
http://www.w3.org/TR/xbc-measurement</a>.
(See http://www.w3.org/TR/2005/NOTE-xbc-measurement-20050331/.)</dd><dt class="label"><a name="xbcusecases" id="xbcusecases"></a>XBC Use Cases</dt><dd>
<a href="http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/"><cite>XML Binary Characterization Use Cases</cite></a>,
Mike Cokus and Santiago Pericas-Geertsen, Editors.
World Wide Web Consortium, 31 March 2005.
This version is http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/.
The latest version is available at
<a href="http://www.w3.org/TR/xbc-use-cases">
http://www.w3.org/TR/xbc-use-cases</a>.
(See http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/.)</dd><dt class="label"><a name="xbcproperties" id="xbcproperties"></a>XBC Properties</dt><dd>
<a href="http://www.w3.org/TR/2005/NOTE-xbc-properties-20050331/"><cite>XML Binary Characterization Properties</cite></a>,
Mike Cokus and Santiago Pericas-Geertsen, Editors.
World Wide Web Consortium, 31 March 2005.
This version is http://www.w3.org/TR/2005/NOTE-xbc-properties-20050331/
The latest version is available at
<a href="http://www.w3.org/TR/xbc-properties/">
http://www.w3.org/TR/xbc-properties/</a>.
(See http://www.w3.org/TR/2005/NOTE-xbc-properties-20050331/.)</dd><dt class="label"><a name="XMLEncryption" id="XMLEncryption"></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>,
Takeshi Imamura, Blair Dillaway, and Ed Simon, Authors.
World Wide Web Consortium, 10 December 2002.
This version is http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
The latest version is available at
<a href="http://www.w3.org/TR/xmlenc-core/">http://www.w3.org/TR/xmlenc-core/</a>.
(See http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ .)</dd><dt class="label"><a name="XMLSignature" id="XMLSignature"></a>XML Signature</dt><dd>
<a href="http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210 "><cite>Decryption Transform for XML Signature</cite></a>,
Merlin Hughes, Takeshi Imamura, and Hiroshi Maruyama, Editors.
World Wide Web Consortium, 10 December 2002.
This version ishttp://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210
The latest version is available at
<a href="http://www.w3.org/TR/xmlenc-decrypt">http://www.w3.org/TR/xmlenc-decrypt</a>.
(See http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210 .)</dd><dt class="label"><a name="xml10points" id="xml10points"></a>XML In 10 Points</dt><dd>
<a href="http://www.w3.org/XML/1999/XML-in-10-points.html"><cite>XML In 10 Points</cite></a>, World Wide Web Consortium, 1999.
(See http://www.w3.org/XML/1999/XML-in-10-points.html.)</dd><dt class="label"><a name="rfc2616" id="rfc2616"></a>HTTP 1.1</dt><dd>
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html"><cite>Hypertext Transfer Protocol -- HTTP/1.1</cite></a>
, Fielding, et al. The Internet Society, June 1999.
(See http://www.w3.org/Protocols/rfc2616/rfc2616.html.)</dd></dl></div></div></div><div class="back"><div class="div1">
<h2><a name="acknowledgements" id="acknowledgements"></a>A Acknowledgements (Non-Normative)</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 writing, sorted alphabetically by last name): </p><ul><li>Carine Bournez, W3C/ERCIM (<em>staff contact</em>)</li><li>Don Brutzman, Web3D Consortium</li><li>Alex Ceponkus, AgileDelta, Inc.</li><li>Michael Cokus, MITRE Corporation</li><li>Roger Cutler, Chevron</li><li>Ed Day, Objective Systems, Inc.</li><li>Philippe de Cuetos, Expway</li><li>Rajul Gupta, OSS Nokalva, Inc.</li><li>Joerg Heuer, Siemens AG</li><li>Alan Hudson, Web3D Consortium</li><li>Takuki Kamiya, Fujitsu Laboratories of America, Inc.</li><li>Jaakko Kangasharju, University of Helsinki</li><li>Don McGregor, Web3D Consortium</li><li>Daniel Peintner, Siemens AG</li><li>Santiago Pericas-Geertsen, Sun Microsystems, Inc.</li><li>Liam Quin, W3C/MIT (<em>staff contact</em>)</li><li>Kimmo Raatikainen, Nokia</li><li>Rich Rollman, AgileDelta, Inc.</li><li>Paul Sandoz, Sun Microsystems, Inc.</li><li>John Schneider, AgileDelta, Inc.</li><li>Cedric Thienot, Expway</li><li>Paul Thorpe, OSS Nokalva, Inc.</li><li>Daniel Vogelheim, Siemens AG (<em>co-chair</em>)</li><li>Yun Wang, Intel Corporation</li><li>Greg White, Stanford University (<em>co-chair</em>)</li><li>Stephen Williams, High Performance Technologies, Inc.</li></ul><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><ul><li>Robin Berjon, Expway (<em>former co-chair</em>) (until 17 October 2006) </li><li>Oliver Goldman, Adobe Systems, Inc. (<em>former co-chair</em>) (until 08 June 2006) </li><li>Peter Haggar, IBM (until 07 March 2007) </li></ul></div></div><hr><div class="endnotes">
<h3><a name="endnotes" id="endnotes"></a>End Notes</h3><dl><dt>[<a name="N65767" id="N65767" href="#FN-ANCH-N65767">1</a>]</dt><dd><p>Except for detached signatures where the document being signed isn't altered.</p></dd><dt>[<a name="N65849" id="N65849" href="#FN-ANCH-N65849">2</a>]</dt><dd><p>These "conventional Character encodings" include all required encodings (UTF-8, UTF-16) and every other commonly used encoding known to the Editors at time of publication, including but not limited to UCS-2, UCS-4, EBCDIC, ISO 8859, Shift-JIS, EUC, and GB18030.</p></dd><dt>[<a name="N65965" id="N65965" href="#FN-ANCH-N65965">3</a>]</dt><dd><p>That is, compatible with respect to the character encoding used in the text file to be viewed.</p></dd></dl></div></body></html>