WD-exi-evaluation-20090407 53.8 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  <title>Efficient XML Interchange Evaluation</title>
  <!-- Greg's advice:
  Style:
  * Do not capitalize "use case", except in proper case of XBC
  * Do not capitalize proper nouns like Properties unless refering specifically
  to XBC's use
  * Use perfect tenses to indicate maturity of work
  * Only the last item in a list takes a period.
  -->
  <style type="text/css">
        table,td,th { border: 1px black solid; padding: 3px; border-collapse: collapse; }
        div.ai,
        div.issue { font-family: monospace;  }
        div.status { font-family: monospace; display: none; }
        .editorial { color: gray; }
        p, ul, ol, dd {margin-right: 2cm}
        hr { margin-right: 2cm}
        th { text-align: left; }
        td { vertical-align: top; }
        li { margin-bottom: 0.5em; }
        h2, h3, h4 { margin-top: 1.2em; }
        h5 { margin-bottom: -.5em; }
        div.toc ul {list-style:none;}
  </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 id="title">Efficient XML Interchange Evaluation</h1>

<h2 id="maturity">W3C Working Draft 7 April 2009</h2>

<!--
<p>$Id: Overview.html,v 1.8 2009/04/06 13:55:22 cbournez Exp $</p>
-->
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2009/WD-exi-evaluation-20090407">http://www.w3.org/TR/2009/WD-exi-evaluation-20090407</a></dd>
  <dt>Latest version:</dt>
      <dd><a href="http://www.w3.org/TR/exi-evaluation">http://www.w3.org/TR/exi-evaluation</a></dd>
  <dt>Previous version:</dt>
      <dd><a href="http://www.w3.org/TR/2008/WD-exi-evaluation-20080728">http://www.w3.org/TR/2008/WD-exi-evaluation-20080728</a></dd>
  <dt>Editors:</dt>
    <dd>Carine Bournez, W3C</dd>
</dl>

<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 2009 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</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>

<hr />

<div>
<h2><a name="abstract" id="abstract">Abstract</a></h2>

<p>This Working Group Note is an evaluation of the Efficient XML Interchange
(EXI) Format 1.0 with reference to the <a
href="http://www.w3.org/TR/xbc-properties">Properties</a> identified by the <a
href="http://www.w3.org/XML/Binary/">XML Binary Characterization (XBC) Working
Group</a>, relative to XML, gzipped XML and ASN.1 PER. It is conducted using
the <a href="http://www.w3.org/TR/xbc-measurement/">XBC Measurement
methodology</a>. For the <a
href="http://www.w3.org/TR/xbc-properties/#compactness">"compactness"</a> and
<a
href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">"processing
efficiency"</a> Properties, the performance is measured with <a
href="http://www.w3.org/TR/exi-measurements/#methodology-japex">EXI Measurement
framework</a>, over the <a
href="http://www.w3.org/TR/exi-measurements/#Ax-testsuite">test data</a>
collected for the EXI measurements, representing XBC Use Cases. </p>
</div>

<div>
<h2><a name="status" id="status">Status of this Document</a></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 the second Working Draft of the evaluation of the EXI Format 1.0 conducted by the EXI Working Group. It
presents an evaluation of the EXI Format 1.0 conducted by the EXI Working
Group. This draft includes results for all properties, including <a
href="http://www.w3.org/XML/Binary/Properties/xbc-properties.html#compactness">"compactness"</a>
and <a
href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">"processing
efficiency"</a>.</p>

<p>This document 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
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>
<hr />

<h2><a name="toc" id="toc">Table of Contents</a></h2>

<div class="toc">
<ul>
  <li><a href="#objectives">1. Objectives</a></li>
  <li><a href="#background">2. Background</a></li>
  <li><a href="#results">3. Evaluation Results</a>
    <ul>
      <li><a href="#compactness-results">3.1. Compactness results</a></li>
      <li><a href="#processing-results">3.2. Processing efficiency
      results</a></li>
      <li><a href="#table">3.3. Summary</a></li>
    </ul>
  </li>
  <li><a href="#discussion">4. Discussion</a></li>
  <li><a href="#references">5. References</a></li>
  <li><a href="#properties">Appendix A. Properties definitions</a>
    <ul>
      <li><a href="#directrw">A.1. Directly Readable and Writable</a></li>
      <li><a href="#transportind">A.2. Transport Independence</a></li>
      <li><a href="#compactness">A.3. Compactness</a></li>
      <li><a href="#langneutral">A.4. Human Language Neutral</a></li>
      <li><a href="#platformneutral">A.5. Platform Neutrality</a></li>
      <li><a href="#xmlstack">A.6. Integratable into XML Stack</a></li>
      <li><a href="#rf">A.7. Royalty Free</a></li>
      <li><a href="#fragmentable">A.8. Fragmentable</a></li>
      <li><a href="#streamable">A.9. Streamable</a></li>
      <li><a href="#roundtrip">A.10. Roundtrip Support</a></li>
      <li><a href="#generality">A.11. Generality</a></li>
      <li><a href="#schemadev">A.12. Schema Extensions and Deviations</a></li>
      <li><a href="#versionid">A.1A. Format Version Identifier</a></li>
      <li><a href="#contenttype">A.14. Content Type Management</a></li>
      <li><a href="#selfcontained">A.15. Self Contained</a></li>
      <li><a href="#PE">A.16. Processing Efficiency</a></li>
      <li><a href="#footprint">A.17. Small Footprint</a></li>
      <li><a href="#adoption">A.18. Widespread Adoption</a></li>
      <li><a href="#implcost">A.19. Implementation Cost</a></li>
      <li><a href="#spaceefficiency">A.20. Space Efficiency</a></li>
      <li><a href="#fwdcompat">A.21. Forward Compatibility</a></li>
    </ul>
  </li>
  <li><a href="#generality-details">Appendix B. Generality evaluation</a></li>
</ul>
</div>
</div>
<hr />

<h2 id="objectives">1. Objectives</h2>

<p>This document presents the anticipated benefits of the EXI format 1.0
compared to <a href="#ref-XML1.0">XML</a> and gzipped XML. Additionally, tests
for compactness include comparison to <a href="#ref-PER">ASN.1 PER</a>. The
points of comparison are the requirements set by the EXI Working Group charter,
based on the results of the <a href="http://www.w3.org/XML/Binary">XML Binary
Characterization Working Group</a>.</p>

<p>This summarized evaluation of the EXI format uses the testing framework
built during the first phase of the EXI Working Group's work so as to select a
baseline candidate technology. Although this evaluation aims at demonstrating
EXI benefits in the targeted <a href="http://www.w3.org/TR/xbc-use-cases/">XBC
Use Cases</a>, it can be read as a summary of the <a
href="http://www.w3.org/TR/exi-measurements/">EXI measurements</a> Note.</p>

<h2 id="background">2. Background</h2>

<p>The methodology used in the evaluation relies on previous work on
measurements. The <a href="http://www.w3.org/TR/xbc-properties/">Properties</a>
referred to in this document have been defined by the <a
href="http://www.w3.org/XML/Binary/">XBC Working Group</a>. The methodology for
measurement is detailed in the <a
href="http://www.w3.org/TR/xbc-measurement/">XBC measurement methodology</a>
document. For convenience, Appendix A gives an overview of the properties
definitions, as well as some details of their measurements. </p>

<p>In addition, two Properties require an implementation to be evaluated:
Compactness and Processing Efficiency. These Properties have been tested using
the <a href="http://www.w3.org/XML/EXI/#TestingFramework">EXI measurement
framework</a> and the associated <a
href="http://www.w3.org/TR/2006/WD-exi-measurements-20060718/#methodology">methodology</a>.</p>

<h2 id="results">3. Evaluation Results</h2>

<p>At the time of the first publication of this document, the Working Group has
not tested conformance of implementations. The methodology and framework
designed and implemented on <a href="#ref-japex">Japex</a> by the Working Group
are used for the properties that require implementation testing. The other
properties can be asserted by checking the specification only.</p>

<h3 id="compactness-results">3.1. Compactness results</h3>

<p>This test has been run over the EXI Working Group's <a
href="http://www.w3.org/TR/exi-measurements/#Ax-testsuite">framework test
data</a>, which contains 94 test documents from 21 test groups. The following
graphs show the resulting size as a percentage of the original XML document
size, sorted by the EXI result, for the sake of legibility (i.e. "best" results
on the left). The implementation of EXI used for the measurements is <a
href="#ref-effXML">Efficient XML 4.0</a>. It implements the specification of
the EXI format 1.0 at the time of writing.</p>

<p>For each test case, the testing framework uses the most appropriate <a
href="http://www.w3.org/TR/exi-measurements/#methodology-compaction-classes">application
class</a>: Whenever a schema is available, EXI uses the schema information, and
when a document-analysis-based technique leads to a better result, the
compression option is turned on.</p>

<div>
<img src="compactness-exi-vs-gzip.PNG"
alt="comparison for compactness of EXI against gzipped XML" /> </div>

<p>The graph above compares EXI to Gzipped XML. As shown by the graph, EXI is
consistently smaller than gzipped XML regardless of document size, document
structure or the availability of schema information. In some cases, EXI is over
10 times smaller than gzip. In addition, EXI works well in cases where gzip has
little effect or even makes documents bigger, such as high volume streams of
small messages typical of geolocation, financial exchange and sensor
applications.</p>

<div>
<img src="compactness-exi-vs-asn1.PNG"
alt="comparison for compactness of EXI against ASN.1 PER" /> </div>

<p>The graph above compares the same EXI numbers to the ASN.1 PER file sizes.
Each EXI encoded file is smaller than the equivalent ASN.1 PER, and sometimes
20 times smaller. This holds true even for cases where EXI is preserving XML
comments, processing instructions and namespace prefixes that are not preserved
by ASN.1 PER. In addition, EXI works well in cases where ASN.1 PER actually
increases the size of the document or fails to produce an encoding at all
(e.g., due to schema deviations.) </p>

<h3 id="processing-results">3.2. Processing efficiency results</h3>

<p>The processing efficiency tests were run using the EXI Working Group's <a
href="http://www.w3.org/TR/exi-measurements/#Ax-testsuite">framework test
data</a> and <a
href="http://www.w3.org/TR/exi-measurements/#methodology">test
methodology</a> on a Windows XP machine with a 3.0 Ghz Pentium 4 CPU and 1.5
Gbytes of RAM. Processing efficiency was measured in transactions per second
(TPS) and the following graphs show results as a percentage of XML speed and
Gzipped XML speed, sorted by EXI result for legibility. So, for example, a
measurement of 200% is two times faster, a measurement of 300% is three times
faster, etc. </p>

<p>It is important to note that processing efficiency is also implementation dependent and not all EXI implementations will achieve the performance results
illustrated here. The implementation of EXI used for these measurements was <a
href="#ref-effXML">Efficient XML 4.0</a>, that
implements the EXI 1.0 format specification.</p>

<h4 id="decoding-results">3.2.1. Decoding speed results</h4>

<p>The following two graphs illustrate the decoding (i.e., parsing) speed of
Efficient XML with and without EXI compression for each test case. </p>

<div>
<img src="decode-exi-nocompression.PNG"
alt="EXI decode speed without comparison" /> </div>

<p>The graph above shows EXI decoding speed without compression compared to
XML. The average decoding speed of EXI was 14.5 times faster than the average
decoding speed of XML. The median speed increase was 6.7 times faster. To
improve readibility, the graph does not show the four best cases, which ranged
from 54 times faster to 257 times faster. These four test cases were SOAP
web-service messages that were marshalled from a binding layer and contained
repeating structures with elements and attributes from several different
namespaces. As is typical for such use cases, the repeated structures contained
a large number of repeated namespace declarations. EXI eliminates most of the
overhead associated with namespace processing, which is why EXI achieved such a
speed increase for these cases. </p>

<div>
<img src="decode-exi-withcompression.PNG"
alt="EXI decode speed with compression" /> </div>

<p>The graph above shows EXI decoding speed with compression compared to XML
with compression. The average decoding speed of EXI was 9.2 times faster than
the average decoding speed of GZipped XML. The median speed was 4.4
times faster. To improve readibility, the graph does not show the four best
cases, which ranged from 30 times faster to 102 times faster. These were the
same four SOAP web-service test cases described in the previous paragraph. </p>

<h4 id="encoding-results">3.2.2. Encoding speed results</h4>

<p>The following two graphs illustrate the encoding (i.e., serialization) speed
of Efficient XML with and without EXI compression for each test case. </p>

<div>
<img src="encode-exi-nocompression.PNG"
alt="EXI encode speed without compression" /> </div>

<p>The graph above shows EXI encoding speed without compression compared to
XML. The average encoding speed of EXI was 6.0 times faster than the average
encoding speed of XML. The median speed increase was 2.4 times faster. To
improve readibility, the graph does not show the best case, which was 21 times
faster. </p>

<div>
<img src="encode-exi-withcompression.PNG"
alt="EXI encode speed with compression" /> </div>

<p>The graph above shows EXI encoding speed with compression compared to XML
with compression. The average encoding speed of EXI was 5.4 times faster than
the average encoding speed of Gzipped XML. The median speed increase was 2.7
times faster. The graph does no show the best case, which was just over 18
times faster. </p>

<h3 id="table">3.3. Summary</h3>

<p>The <a href="http://www.w3.org/XML/Binary/">XBC working group</a> analyzed all the <a href="http://www.w3.org/TR/xbc-properties/">properties</a> desired
by the <a href="http://www.w3.org/TR/xbc-use-cases/">XBC use cases</a> and identified a minimum set of required properties for the W3C EXI format in its <a href="http://www.w3.org/TR/xbc-characterization/#N102EC">XBC Characterization document</a>. For several of these properties, the XBC working group defined specific thresholds a data format must achieve to satisfy the requirements of the XBC use cases. For example, several XBC use cases required a data format with compactness similar to custom binary formats. In discussing the needs of these use cases, it was determined that the format must be no larger than ASN.1 PER + 20% when schemas optimizations are used to satisfy the "compactness" requirements of these use cases. The table below lists those properties and scores EXI for each. For comparison purposes, scores are also given for XML(+gzip). </p>

<p id="SummaryCaveat">these properties were designed to determine whether candidate EXI formats meet the requirements and specific performance
thresholds of the XBC use cases. So, when the table says XML(+gzip) does not meet the compactness requirement, it means it does not meet the specific compactness threshold required by the XBC use cases. Similarly, when the table says XML(+gzip) does not meet the processing efficiency requirement, it means that XML(+gzip) does not meet the specific processing efficiency requirements of the XBC use cases. Several of these use cases specify a need for a format that was "faster
to process than XML" (e.g., to be competitive with binary RPC mechanisms), so
by definition it was impossible for XML to achieve this requirement.</p>

<p>The XBC working group classified these properties into two categories based on the observation that some properties are inherent to the format (e.g., compactness), while some are also properties of implementations of the format (e.g., processing efficiency), but characteristics of the format could prohibit implementations from achieving them. As such, the first category lists properties the format must support inherently. The second category lists properties of implementations the format must not prevent.</p>

<p>The score given for each property is the evaluation result of the format or
implementation thereof, obtained by following the methodology defined in the
<a href="http://www.w3.org/TR/xbc-measurement/">XBC Measurement Methodologies document.</a></p>


<table border="1" cellpadding="0">
  <thead>
    <tr>
      <td><p style="text-align:center"><b>Property</b></p>
      </td>
      <td colspan="2"><p style="text-align:center"><b>XML (+gzip)</b></p>
      </td>
      <td colspan="2"><p style="text-align:center"><b>EXI</b></p>
      </td>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td colspan="5"
      style="border:inset 1.0pt;border-right:none;padding:.75pt .75pt .75pt .75pt"><p><b>MUST
        support</b></p>
      </td>
    </tr>
    <tr>
      <td><p>Directly Readable and Writable</p>
      </td>
      <td><p>No</p>
      </td>
      <td><p>The XML format itself satisfies this property, but naturally gzip
        compression applied to a file format requires creating the intermediate
        form (XML) first.</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>Implementations can read and write EXI streams directly via
        standard XML APIs, such as DOM, SAX and StAX. At least one current
        implementation also support typed APIs for increased performance. </p>
      </td>
    </tr>
    <tr>
      <td><p>Transport Independence</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI can be used over TCP, UDP, HTTP and various wireless and
        satellite transports.</p>
      </td>
    </tr>
    <tr>
      <td><p>Compactness</p>
      </td>
      <td><p>No</p>
      </td>
      <td><p>XML and gzip cannot take advantage of schema information, so this
        format fails in the Schema and Both classes (It does not achieve
        compactness typically required by applications that use binary data
        formats, like ASN.1, CORBA, XDR, etc.) </p>

        <p>By definition, it succeeds in the Document class and fails in the
        Neither class (due to the different requirements, in the Neither class,
        it would have to be smaller than itself). (See <a
        href="#SummaryCaveat">Note</a> above this table)</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>See <a href="#compactness-results">compactness results.</a></p>
      </td>
    </tr>
    <tr>
      <td><p>Human Language Neutral</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI supports all standard character set encodings.</p>
      </td>
    </tr>
    <tr>
      <td><p>Platform Neutrality</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p><!--Java and .NET implementations exist for UNIX, MS-Windows
        and various mobile devices. interoperability has been tested for
        hundreds of use cases using thousands of instance documents.-->The EXI
        format specification does not make particular assumption about the
        platform architecture. Implementation already exists for several
        popular server, desktop and mobile platforms, including Java EE/SE,
        Microsoft .NET, Java Mobile Edition and .NET Compact Framework.</p>
      </td>
    </tr>
    <tr>
      <td><p>Integratable into XML Stack</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI was designed to integrate well into the XML stack, neither
        duplicating nor requiring changes to functionality at other layers in
        the XML stack. It builds on the XML Infoset data model. It implements
        the same character encodings as text XML and supports the common
        interfaces as existing XML parsers and serializers. As such, it can be
        inserted into existing XML applications with minimal time and cost. </p>
      </td>
    </tr>
    <tr>
      <td><p>Royalty Free</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>Per the W3C PP.</p>
      </td>
    </tr>
    <tr>
      <td><p>Fragmentable</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI can represent any collection of XML fragments extracted from
        any collection of XML documents. All schema optimization, bit-packing
        and XML compression algorithms apply equally to fragments. </p>
      </td>
    </tr>
    <tr>
      <td><p>Streamable</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td>
      </td>
    </tr>
    <tr>
      <td><p>Roundtrip Support</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>The equivalence is exact in both cases.</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI supports lossless equivalence for PSVI, Infoset and lexical
        applications, such as XML Digital Signatures. The EXI "preserve" option
        can be used when this property is needed.</p>
      </td>
    </tr>
    <tr>
      <td><p>Generality </p>
      </td>
      <td><p>No</p>
      </td>
      <td><p>XML scores 8/20, Gzipped XML 10/20 (see <a
        href="#generality-details">appendix B</a>.)</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI scores 19/20 (see <a href="#generality-details">appendix
        B</a>.)</p>
      </td>
    </tr>
    <tr>
      <td><p>Schema Extensions and Deviations</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI includes schema optimizations that support arbitrary schema
        extensions and deviations. Applications may specify strict or
        extensible schema handling and may provide a full schema, partial
        schema or no schema at all.</p>
      </td>
    </tr>
    <tr>
      <td><p>Format Version Identifier</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>Both XML and gzip include an identifier in the header.</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI header includes version.</p>
      </td>
    </tr>
    <tr>
      <td><p>Content Type Management</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>EXI can be used in various contexts, some which use a media type
        and some which use content encoding, or both.</p>
      </td>
    </tr>
    <tr>
      <td><p>Self-Contained</p>
      </td>
      <td><p>Yes</p>
      </td>
      <td></td>
      <td><p>Yes</p>
      </td>
      <td><p>When schema optimizations are not used, EXI documents are always
        self-contained.</p>
      </td>
    </tr>
    <tr>
      <td colspan="5"
      style="border:inset 1.0pt;border-right:none;padding:.75pt .75pt .75pt .75pt"><p><b>MUST
        NOT Prevent</b></p>
      </td>
    </tr>
    <tr>
      <td><p>Processing Efficiency</p>
      </td>
      <td><p>Prevents (See <a href="#SummaryCaveat">Note</a> above)</p>
      </td>
      <td>XBC Measurement methodology defines processing efficiency relative to
        XML. This renders XML implementations unable to exceed the threshold by
        definition. The score given on the left merely reflects this, and does
        not mean anything but that XML is the norm used by the methodology. See
        how EXI outperforms XML(+gzip) as demonstrated in <a
        href="#processing-results">Processing efficiency results</a> and
        summarized in the subsequent column on the right. </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td><p>Current implementations achieve performance several times faster
        than XML using both in-memory tests and more realistic scenarios that
        involve file and network IO. These implementations do not depend on
        compile-time schema-binding techniques that make dynamically acquiring,
        loading or updating schemas impractical or impossible.</p>
      </td>
    </tr>
    <tr>
      <td><p>Small Footprint</p>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td></td>
      <td><p>Does Not Prevent</p>
      </td>
      <td><p>TBD in CR phase: check implementation for a variety of small,
        mobile devices.</p>
      </td>
    </tr>
    <tr>
      <td><p>Widespread Adoption</p>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td><p>Both XML and gzip have been widely adopted and included in many
        protocol standards.</p>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td>
      </td>
    </tr>
    <tr>
      <td><p>Space Efficiency</p>
      </td>
      <td><p>Prevents</p>
      </td>
      <td>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td><p>TBD on CR phase: check implementations for small, mobile
        devices.</p>
      </td>
    </tr>
    <tr>
      <td><p>Implementation Cost</p>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td></td>
      <td><p>Does Not Prevent</p>
      </td>
      <td><p>TBD in CR phase.</p>
      </td>
    </tr>
    <tr>
      <td><p>Forward Compatibility</p>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td>
      </td>
      <td><p>Does Not Prevent</p>
      </td>
      <td>
      </td>
    </tr>
  </tbody>
</table>

<h2 id="discussion">4. Discussion</h2>

<p>DRAFT @@ other items for discussion?</p>
<ul>
  <li>For a variety of test cases that were collected so as to cover the XBC
    Use Cases, the achieved compactness is better than gzipped XML and ASN.1
    PER (in some cases by a significant margin): While there are cases for
    which those solutions don't work or are useless, using the right option in
    EXI gives a reasonable result. Therefore EXI is usable and customizable for
    a broadest range of use cases. </li>
  <li>The required properties are met (as far as we can evaluate at this time).
    The desirable additional properties are not prevented by the use of EXI.
    Some properties are achieved by enabling given EXI options. The EXI Working
    Group provides information in the EXI format specification and in
    additional resources to help users understand the options and their correct
    use, as well as guiding their choice of options for their data usage.</li>
</ul>

<h2 id="references">5. References</h2>
<dl>
  <dt id="ref-EXI-meas">[EXI Measurements]</dt>
    <dd><cite><a href="http://www.w3.org/TR/exi-measurements/">EXI
      Measurements</a></cite>, Greg White, Jaakko Kangasharju, Don Brutzman,
      Stephen Williams editors, World Wide Web Consortium, 25 July 2007.
      http://www.w3.org/TR/exi-measurements/.</dd>
  <dt id="ref-XBC-UC">[XBC Use Cases]</dt>
    <dd><cite><a href="http://www.w3.org/TR/xbc-use-cases/">XML Binary
      Characterization Use Cases</a></cite>, Mike Cokus, Santiago
      Pericas-Geertsen editors, World Wide Web Consortium, 31 March 2005.
      http://www.w3.org/TR/xbc-use-cases/.</dd>
  <dt id="ref-XBC-properties">[XBC Properties]</dt>
    <dd><cite><a href="http://www.w3.org/TR/xbc-properties/">XML Binary
      Characterization Properties</a></cite>, Oliver Goldman, Dmitry Lenkov
      editors, World Wide Web Consortium, 31 March 2005.
      http://www.w3.org/TR/xbc-properties/.</dd>
  <dt id="ref-XBC-meas">[XBC Measurements]</dt>
    <dd><cite><a href="http://www.w3.org/TR/xbc-measurement/">XML Binary
      Characterization Measurement Methodologies</a></cite>, Stephen D.
      Williams, Peter Haggar editors, World Wide Web Consortium, 31 March 2005.
      http://www.w3.org/TR/xbc-measurement/.</dd>
  <dt id="ref-XBC-characterization">[XBC Characterization]</dt>
    <dd><cite><a href="http://www.w3.org/TR/xbc-characterization/">XML Binary
      Characterization</a></cite>, Oliver Goldman, Dmitry Lenkov editors, World
      Wide Web Consortium, 31 March 2005.
      http://www.w3.org/TR/xbc-characterization/.</dd>
  <dt id="ref-PER">[PER]</dt>
    <dd><cite><a
      href="http://www.itu.int/ITU-T/studygroups/com17/languages/X.691-0207.pdf">Information
      Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules
      (PER)</a></cite> [The ASN.1 PER Standard (ITU-T Rec X.691 | ISO/IEC
      8825-2)], International Telecommunication Union (ITU), July 2002.
      http://www.itu.int/ITU-T/studygroups/com17/languages/X.691-0207.pdf.</dd>
  <dt id="ref-XML1.0">[XML 1.0]</dt>
    <dd><cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204/">Extensible
      Markup Language (XML) 1.0</a></cite>, Tim Bray et al editors, World Wide
      Web Consortium, 4 February 2004 (Third Ed). Latest version
      http://www.w3.org/TR/REC-xml/.</dd>
  <dt id="ref-effXML">[Efficient XML]</dt>
    <dd><cite><a
      href="http://www.agiledelta.com/product_efxsdk.html">AgileDelta's
      Efficient XML 4.0</a></cite>, accessed March 2009.</dd>
  <dt id="ref-japex">[JAPEX]</dt>
    <dd><cite><a href="https://japex.dev.java.net/docs/manual.html">Japex
      Manual</a></cite>, Santiago Pericas-Geertsen, java.net, April 2006.
      https://japex.dev.java.net/docs/manual.html.</dd>
</dl>

<h2 id="properties">Appendix A. Properties definitions</h2>

<h3 id="directrw">A.1. Directly Readable and Writable</h3>

<p>A format is directly readable and writable if it can be serialized from an
instance of a data model and parsed into an instance of a data model without
first being transformed to an intermediate representation. The retained data
model for EXI is the XML Infoset.</p>

<h3 id="transportind">A.2. Transport Independence</h3>

<p>A format is transport independent if the only assumptions of transport
service are "error-free and ordered delivery of messages without any arbitrary
restrictions on the message length".<br />
However, a protocol binding can specify how a format is transmitted as payload
in a specific transport (e.g., TCP/IP) or messaging (e.g., HTTP) protocol.</p>

<h3 id="compactness">A.3. Compactness</h3>

<p>The Compactness property measurement represents the amount of compression a
particular format achieves when encoding data model items. There are three
categories of methods to reduce the size of a data object or data model
items:</p>
<ul>
  <li>Compression is the transformation of data into corresponding data that
    takes less storage through the removal or reuse of redundant information
    and more efficient coding of data.</li>
  <li>Decimation is the process of eliminating some details that are not used
    or of less importance than more important components of the original data
    (e.g. comments). This is called "lossy compression" as opposed to "lossless
    compression" or just "compression".</li>
  <li>Externalization is the process of representing an original data model
    items as an external representation with varying degrees of reuse and a
    data object that relies on that external instance as a source of
    redundancy. This external information can be considered shared information
    between a sender and receiver. A schema-based method for certain aggregate
    data types, structure, and/or values is a type of externalization</li>
</ul>

<p>This property is measured in the EXI testing framework in 4 measurement
modes: "Neither" optimization (pure tokenization), "Schema" (schema-based
compression), "Document" (data analysis), "Both" (data analysis + schema-based
compression).</p>

<h3 id="langneutral">A.4. Human Language Neutral</h3>

<p>A format is human language neutral if it is not significantly more optimal
for processing when its content is in a given language or set thereof, and does
not impose restrictions on the languages or combinations of languages that may
be used with it. Historically, it has often been a property of many data and
document formats that they only supported certain character encodings. XML do
not suffer from similar limitations, and it is expected that EXI will not limit
the usage of particular human languages.<br />
In terms of compactness or processing efficiency, it is not possible to ensure
the same performance for a language that can be entirely captured using a
single byte per character and for one that requires a multi-byte encoding, but
an internationalization support equivalent to XML is necessary for a wide
adoption.</p>

<h3 id="platformneutral">A.5. Platform Neutrality</h3>

<p>Platform neutrality is the property of formats that are not significantly
more optimal for processing on some computing platforms or architectures than
on others (e.g. endianness, native structures for programming language).
Platform neutrality ensures not only that wide adoption is possible, but also
makes the format more resilient to the passing of time.<br />
In some cases, options in the format may be used based on the preferred
parameters of the systems involved. Thus, the XBC Working Group proposed 3
possible values:</p>
<ul>
  <li>not platform neutral at all (for instance, may be the native
    serialization of a given programming platform)</li>
  <li>defined in a platform-neutral manner, but with fixed values for certain
    parameters that may advantage a platform over another.</li>
  <li>defined in a platform-neutral manner, and multiple options (word-length,
    float format, etc.) can be set so that users may choose locally optimal
    encodings when the platforms involved in a given interchange are known.</li>
</ul>

<p>It must also be noted that allowing too many mechanisms (options or
parameters) for optimization may in fact prove to be a pessimisation.</p>

<h3 id="xmlstack">A.6. Integratable into XML Stack</h3>

<p>Per the EXI Working Group charter, this property must be seen as a strong
requirement. The integration of the EXI format in the stack of the existing XML
specifications for validation, transformation, querying, APIs,
canonicalization, signatures, encryption, etc. is a key to a wide adoption.</p>

<h3 id="rf">A.7. Royalty Free</h3>

<p>The EXI format will be unencumbered and royalty-free as ensured by the
process W3C. It will lead this technology to a better adoption across the
industry. A free format is also more likely to have free, open source code for
processing it and free tools for building applications which use it. In
addition, per the EXI Working Group charter, the EXI format will be proven to
have at least one publicly available implementation before becoming a W3C
Recommendation.</p>

<h3 id="fragmentable">A.8. Fragmentable</h3>

<p>Fragmentability is the ability to encode instances that do not represent the
entirety of a document together with sufficient context for the decoder to
process them. In addition to this ability to process fragments in isolation, it
covers storing one or more parts of a document instance as immediately
extractable fragments, so that they can be pulled out with little or no
additional processing cost.</p>

<h3 id="streamable">A.9. Streamable</h3>

<p>Streamability is the ability to generate correct partial output from partial
input. This property is needed in memory-constrained environments where it is
important to be able to handle data as it is generated to avoid buffering of
data inside the processor. Hence it is also characterized by the amount of
buffering that needs to be done in the processors. In particular, required
buffer space for encoding or decoding must be constant, no matter what the
input document is or how it is mapped to the data model. This requirement
precludes some serialization techniques (e.g. Gzip compression over the entire
XML document).</p>

<p>A particular attention must be paid to the need for lookahead in the format
parser, since it is not always available. For some types of sequences it can be
beneficial to have the length of the full serialized form of the sequence that
precede the actual sequence, so the serializer must buffer the whole sequence
before outputting anything. If such sequences can be arbitrarily long, this
sacrifices output streamability.</p>

<h3 id="roundtrip">A.10. Roundtrip Support</h3>

<p>A format supports roundtripping if converting a file from XML to that format
and back produces an output equivalent to the original input. A format supports
roundtripping via XML if converting a file from that format to XML and back
produces an output equivalent to the original input.</p>

<p>This property is measured by comparing the data which can be represented in
XML with those that can be represented in the EXI format:</p>
<ul>
  <li>Evaluation of Roundtrip Support (XML to EXI to XML):<br />
    If the XML Infoset is a proper superset of the data model supported by the
    format, the measurement is "Does Not Roundtrip". If the transformations to
    and from the EXI format are byte preserving, the measurement is "Exact
    Equivalence". Otherwise, the measurement is "Lossless Equivalence". </li>
  <li>Evaluation of Roundtripping via XML (EXI to XML to EXI):<br />
    If the XML Infoset is a proper subset of the data model supported by the
    format, the measurement is "Does Not Roundtrip". If the transformations to
    and from the EXI format are byte preserving, the measurement is "Exact
    Equivalence". Otherwise, the measurement is "Lossless Equivalence".</li>
</ul>

<h3 id="generality">A.11. Generality</h3>

<p>A format has the property of generality if it is competitive with
alternatives across a diverse range of XML documents, applications and use
cases. The EXI testing framework covers the XBC use cases. The goal of this set
of test cases is to include a range of different document sizes, different uses
of schemas and various XML features (comments, whitespaces, etc.) </p>

<p>The measurement of this property is defined by the XBC Working Group as a
score over 20 items, 1 point per item:</p>
<ul>
  <li>Can represent documents without a schema</li>
  <li>Can represent documents that include elements and attributes not defined
    in the associated schema (i.e., open content)</li>
  <li>Can represent any schema-invalid document</li>
  <li>Can leverage available schema information to improve compactness,
    processing speed, and resource utilization</li>
  <li>Can leverage available schema information to improve compactness,
    processing speed, and resource utilization even when documents contain
    elements and attributes not defined in the schema</li>
  <li>Can leverage available schema information to improve compactness,
    processing speed, and resource utilization for any schema-invalid
  document.</li>
  <li>Can leverage document analysis to improve compactness</li>
  <li>Can suppress document analysis to increase speed and reduce resource
    utilization</li>
  <li>[optional] Can adjust document analysis to meet application performance
    and resource utilization criteria</li>
  <li>Can structure the binary XML stream to increase net compactness when
    off-the-shelf compression software is built in to the communications
    infrastructure</li>
  <li>[optional] Supports high fidelity XML representations that preserve an
    exact copy of the original XML document, including all whitespace and
    formatting</li>
  <li>Supports reduced fidelity XML representations that preserve all data
    model items, but discard whitespace and formatting to improve
  compactness</li>
  <li>Supports reduced fidelity XML representations that preserve all
    information needed by a particular application, but discard specified
    information items that are not needed (e.g., comments and processing
    instructions) to improve compactness</li>
  <li>Supports reduced fidelity XML representations that preserve the logical
    structures and values of an XML document, but discard lexical and syntactic
    constructs to improve compactness</li>
  <li>Can consistently produce XML representations that are close to the same
    size or smaller than XML documents compressed using gzip</li>
  <li>Can consistently produce more compact XML representations than XML
    documents compressed using gzip</li>
  <li>Can consistently produce more compact XML representations than binary XML
    documents created with document analysis suppressed, then compressed using
    gzip</li>
  <li>Can consistently produce XML representations that are close to the same
    size or smaller than the equivalent ASN.1 PER encoding plus 20%</li>
  <li>Can consistently produce XML representations that are more compact than
    the equivalent ASN.1 PER encoding plus 20%</li>
  <li>[optional] Can consistently produce XML representations that are more
    compact than the equivalent ASN.1 PER encoding plus 20% compressed using
    gzip</li>
</ul>

<h3 id="schemadev">A.12. Schema Extensions and Deviations</h3>

<p>A format supports schema extensions and deviations if it allows applications
to encode XML Infosets that are not conformant to the schema or not defined in
the schema associated with the document.</p>

<h3 id="versionid">A.13. Format Version Identifier</h3>

<p>This property refers to the ability to efficiently determine the version of
a format from a document instance. It is desirable to access this information
as early as possible, so a format that does not make this information available
when the processing starts should be considered inefficient as far as this
property is concerned.</p>

<h3 id="contenttype">A.14. Content Type Management</h3>

<p>This property refers to the definition in the format of one or more media
types and/or encodings to be used when transferring documents. It is required
for content negotiation, hence its importance for the Web.</p>

<p>The XBC Working Group proposed four degrees of support:</p>
<ul>
  <li>provides no media type or encoding specification</li>
  <li>provides a media type but not a content coding</li>
  <li>provides a media type suffix akin to "+xml"</li>
  <li>provides a content coding</li>
</ul>
<!--<p>Note: the EXI format specification does not define a dedicated
content-type. The original XML document content-type should be used, along
with a content coding information specifying that EXI has been used to encode
the Infoset.</p>-->

<h3 id="selfcontained">A.15. Self Contained</h3>

<p>An XML format is self-contained if the only information that is required to
reproduce the data model instance is (i) the representation of the data model
instance and (ii) the specification of the XML format. When no external
information is known by the receiver, the document needs to be self-contained.
</p>

<h3 id="PE">A.16. Processing Efficiency</h3>

<p>This property refers to the speed at which a new format can be generated
and/or consumed for processing. It covers serialization, parsing and data
binding. The XBC Working Group proposed the following criteria for its
measurement:</p>
<ol>
  <li>Parsing into a DOM - The time it takes to parse into a DOM memory
    structure.</li>
  <li>Parsing to SAX - The time it takes to parse to SAX events (push or
  pull).</li>
  <li>Parsing to a new proposed interface (optional) - The time it takes to
    parse into a DOM-like memory structure proposed for binary XML as an
    improvement of DOM.</li>
  <li>Query processing - The time it takes to process standard queries.</li>
  <li>Update (creation, insertion, deletion) - The time it takes to modify an
    instance in a predetermined pattern of operations.</li>
  <li>Retrieval - The time it takes to retrieve information from an
  instance.</li>
  <li>XPath streaming - The time it takes to find a series of xpaths and
    associated data in a stream of data.</li>
  <li>Serialization - The time it takes to generate the alternate format from a
    memory structure including DOM, SAX-related, and an optional proposed
    interface.</li>
  <li>Lifecycle - Using the best available method, create an instance with
    data, interpret instance to get partial data, and modify or create new
    instance with some changes. Memory of the instance at each write/read point
    must not be reused at the next step.</li>
</ol>

<p>Each measurement should be recorded as a percentage faster than a standard
text-based alternative for each type of operation. </p>

<p>The EXI testing framework implements parsing from SAX and serialization
through SAX. Alternative APIs can be used.</p>

<h3 id="footprint">A.17. Small Footprint</h3>

<p>This property refers to the size of a processor implementing a new format
with respect to that of a processor implementing XML. Ideally, the evaluation
of this property would be done through a range of implementations in different
languages on various platforms. Since a complete evaluation could not be easily
achieved during the development of the format itself, due to the small number
of implementations at this time, an alternate solution consists in considering
the number and/or complexity of the mandatory features (which impacts the size
of the code segment) and the amount of data that must be available to a
processor in order to support the format (which impacts the size of the
initialized data segment).</p>

<h3 id="adoption">A.18. Widespread Adoption</h3>

<p>A format is more ubiquitous to the extent it has been implemented on a
greater range and number of devices and used in a wider variety of
applications. There is a tradeoff between the format implementation cost and
complexity and the adequation to the applications' needs.</p>

<h3 id="implcost">A.19. Implementation Cost</h3>

<p>A requirement on XML was "It shall be easy to write programs which process
XML documents." A rough estimate of implementation cost can be made by
considering how much time does it take for a solitary programmer to implement
sufficiently robust processing of the format (the so-called Desperate Perl
Hacker measure).</p>

<p>The possibility to reuse common APIs (including DOM, SAX, StAX) lowers the
cost of implementation of an alternate encoding of the XML Infoset. This
property benefits from the Integration in the XML Stack property.</p>

<h3 id="spaceefficiency">A.20. Space Efficiency</h3>

<p>This property refers to the memory requirements of a processor implementing
EXI with respect to that of a processor implementing XML. The measurement is a
percentage of the dynamic memory costs for equivalent XML processing.</p>

<p>The measurement for this property is by inspection of format specification,
logical analysis, and empirical testing on test scenarios. The EXI testing
framework measures the heap size in each test case.</p>

<h3 id="fwdcompat">A.21. Forward Compatibility</h3>

<p>A format must support the evolution of data models and must allow
corresponding implementation of layered standards. Format version and extension
points are related to this property. Evolution of XML and its data models could
mean additional character encodings, additional element/attribute/body
structure, or new predefined behavior similar to ID attributes. Integration of
the EXI format into the XML Stack is also related to this property.</p>

<h2 id="generality-details">Appendix B. Generality evaluation</h2>

<table border="1" style="width: 100%">
  <caption></caption>
  <tbody>
    <tr>
      <td><b>Criteria</b></td>
      <td>XML</td>
      <td>XML+gzip</td>
      <td>EXI</td>
    </tr>
    <tr>
      <td>Can represent documents without a schema</td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can represent documents that include elements and attributes not
        defined in the associated schema (i.e., open content) </td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can represent any schema-invalid document</td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can leverage available schema information to improve compactness,
        processing speed, and resource utilization </td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can leverage available schema information to improve compactness,
        processing speed, and resource utilization even when documents contain
        elements and attributes not defined in the schema </td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can leverage available schema information to improve compactness,
        processing speed, and resource utilization for any schema-invalid
        document </td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can leverage document analysis to improve compactness</td>
      <td>0</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can suppress document analysis to increase speed and reduce resource
        utilization </td>
      <td>1</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>[optional] Can adjust document analysis to meet application
        performance and resource utilization criteria </td>
      <td>0</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can structure the binary XML stream to increase net compactness when
        off-the-shelf compression software is built in to the communications
        infrastructure </td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>[optional] Supports high fidelity XML representations that preserve
        an exact copy of the original XML document, including all whitespace
        and formatting</td>
      <td>1</td>
      <td>1</td>
      <td>0</td>
    </tr>
    <tr>
      <td>Supports reduced fidelity XML representations that preserve all data
        model items, but discard whitespace and formatting to improve
        compactness </td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Supports reduced fidelity XML representations that preserve all
        information needed by a particular application, but discard specified
        information items that are not needed (e.g., comments and processing
        instructions) to improve compactness</td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Supports reduced fidelity XML representations that preserve the
        logical structures and values of an XML document, but discard lexical
        and syntactic constructs to improve compactness</td>
      <td>1</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can consistently produce XML representations that are close to the
        same size or smaller than XML documents compressed using gzip</td>
      <td>0</td>
      <td>1</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can consistently produce more compact XML representations than XML
        documents compressed using gzip</td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can consistently produce more compact XML representations than binary
        XML documents created with document analysis suppressed, then
        compressed using gzip</td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can consistently produce XML representations that are close to the
        same size or smaller than the equivalent ASN.1 PER encoding plus
      20%</td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Can consistently produce XML representations that are more compact
        than the equivalent ASN.1 PER encoding plus 20%</td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td>[optional] Can consistently produce XML representations that are more
        compact than the equivalent ASN.1 PER encoding plus 20% compressed
        using gzip</td>
      <td>0</td>
      <td>0</td>
      <td>1</td>
    </tr>
    <tr>
      <td></td>
      <td>8</td>
      <td>10</td>
      <td>19</td>
    </tr>
  </tbody>
</table>
<hr style="margin-left: 2cm; margin-right: 4cm" />

</body>
</html>