index.html 258 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>XML Binary Characterization Use Cases</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1><a id="title" name="title"></a>XML Binary Characterization Use Cases</h1>
<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Group Note
    31 March 2005</h2><dl><dt>This version:</dt><dd>
   <a href="http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/">http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/</a>
   </dd><dt>Latest version:</dt><dd>
   <a href="http://www.w3.org/TR/xbc-use-cases">http://www.w3.org/TR/xbc-use-cases</a>
   </dd><dt>Previous version:</dt><dd>
   <a href="http://www.w3.org/TR/2005/WD-xbc-use-cases-20050224">http://www.w3.org/TR/2005/WD-xbc-use-cases-20050224</a>
   </dd><dt>Editors:</dt><dd>Mike Cokus, MITRE Corporation</dd><dd>Santiago Pericas-Geertsen, Sun Microsystems</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;&copy;&nbsp;2005&nbsp;<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>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a id="abstract" name="abstract"></a>Abstract</h2><p> This document describes use cases for evaluating the potential benefits of an efficient
	    serialization format for XML. The use cases are documented here to understand the constraints
        involved in environments for which XML employment may be problematic because of one or more
        characteristics of XML. Desirable properties of XML and alternative formats to
        address the use cases are derived and discussed in a separate publication of the XML Binary
        Characterization Working Group (XBC WG) <a href="#XBC-Properties">[XBC Properties]</a>.

      </p></div><div>
<h2><a id="status" name="status"></a>Status of this Document</h2><p><em>This section describes the status of this document at
      the time of its publication. Other documents may supersede this
      document. A list of current W3C publications and the latest
      revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
      at http://www.w3.org/TR/.</em></p><p>This is a <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#WGNote">Working Group Note</a>, produced by the <a href="http://www.w3.org/XML/Binary/">XML Binary Characterization Working Group</a> as part of the <a href="http://www.w3.org/XML/">XML Activity</a>.</p><p>This document is part of a set of documents
produced according to the Working Group's <a href="http://www.w3.org/2003/09/xmlap/xml-binary-wg-charter.html">charter</a>, in which the Working Group has been determining Use Cases, characterizing the Properties that are
required by those Use Cases, and establishing objective, shared Measurements
to help judge whether XML 1.x and alternate binary encodings provide the
required properties.</p><p>
The XML Binary Characterization Working Group has ended its work.
This document is not expected to become a Recommendation later. It will be
maintained as a WG Note.
</p><p>
Discussion of this document takes place on the public
<a href="mailto:public-xml-binary@w3.org">public-xml-binary@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/public-xml-binary/">public archives</a>).
</p><p>
Publication as a Working Group Note 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></div><div class="toc">
<h2><a id="contents" name="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#intro">Introduction</a><br>
2 <a href="#use-case-meta-data">Use Case Structure</a><br>
3 <a href="#documented-use-cases">Documented Use Cases</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#broadcast">Metadata in Broadcast Systems</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1 <a href="#broadcast-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2 <a href="#broadcast-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.3 <a href="#broadcast-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.4 <a href="#broadcast-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.5 <a href="#broadcast-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.5.1 <a href="#broadcast-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.5.2 <a href="#broadcast-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.5.3 <a href="#broadcast-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.6 <a href="#broadcast-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.7 <a href="#broadcast-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#FPenergy">Floating Point Arrays in the Energy Industry</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.1 <a href="#FPenergy-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.2 <a href="#FPenergy-dom">Domain</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.3 <a href="#FPenergy-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.4 <a href="#FPenergy-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.5 <a href="#FPenergy-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.5.1 <a href="#FPenergy-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.5.2 <a href="#FPenergy-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.5.3 <a href="#FPenergy-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.6 <a href="#FPenergy-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.7 <a href="#FPenergy-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#x3dtrans">X3D Graphics Model Compression, Serialization and Transmission</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.1 <a href="#x3dtrans-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.2 <a href="#x3dtrans-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.3 <a href="#x3dtrans-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.4 <a href="#x3dtrans-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.5 <a href="#x3dtrans-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.5.1 <a href="#x3dtrans-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.5.2 <a href="#x3dtrans-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.5.3 <a href="#x3dtrans-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.6 <a href="#x3dtrans-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.3.7 <a href="#x3dtrans-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#ws-for-small-devices">Web Services for Small Devices</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.1 <a href="#ws-for-small-devices-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.2 <a href="#ws-for-small-devices-dom">Domain</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.3 <a href="#ws-for-small-devices-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.4 <a href="#ws-for-small-devices-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.5 <a href="#ws-for-small-devices-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.5.1 <a href="#ws-for-small-devices-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.5.2 <a href="#ws-for-small-devices-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.5.3 <a href="#ws-for-small-devices-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.6 <a href="#ws-for-small-devices-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.7 <a href="#ws-for-small-devices-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.5 <a href="#ws-for-enterprise">Web Services within the Enterprise</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.1 <a href="#ws-for-enterprise-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.2 <a href="#ws-for-enterprise-dom">Domain</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.3 <a href="#ws-for-enterprise-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.4 <a href="#ws-for-enterprise-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.5 <a href="#ws-for-enterprise-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.5.1 <a href="#ws-for-enterprise-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.5.2 <a href="#ws-for-enterprise-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.5.3 <a href="#ws-for-enterprise-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.6 <a href="#ws-for-enterprise-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.5.7 <a href="#ws-for-enterprise-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.6 <a href="#edocs">Electronic Documents</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.1 <a href="#edocs-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.2 <a href="#edocs-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.3 <a href="#edocs-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.4 <a href="#edocs-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.5 <a href="#edocs-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.5.1 <a href="#edocs-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.5.2 <a href="#edocs-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.5.3 <a href="#edocs-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.6 <a href="#edocs-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.6.7 <a href="#edocs-ref">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.7 <a href="#fixml">FIXML in the Securities Industry</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.1 <a href="#fixml-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.2 <a href="#fixml-dom">Domain</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.3 <a href="#fixml-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.4 <a href="#fixml-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.5 <a href="#fixml-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.5.1 <a href="#fixml-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.5.2 <a href="#fixml-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.5.3 <a href="#fixml-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.6 <a href="#fixml-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.7.7 <a href="#fixml-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.8 <a href="#xml-docs-mobile">Multimedia XML Documents for Mobile Handsets</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.1 <a href="#xml-docs-mobile-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href="#xml-docs-mobile-dom">Domain</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.3 <a href="#xml-docs-mobile-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.4 <a href="#xml-docs-mobile-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.5 <a href="#xml-docs-mobile-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.5.1 <a href="#xml-docs-mobile-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.5.2 <a href="#xml-docs-mobile-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.5.3 <a href="#xml-docs-mobile-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.6 <a href="#xml-docs-mobile-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.7 <a href="#xml-docs-mobile-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.9 <a href="#non-op">Intra/Inter Business Communication</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.1 <a href="#non-op-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.2 <a href="#non-op-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.3 <a href="#non-op-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.4 <a href="#non-op-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.5 <a href="#non-op-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.5.1 <a href="#non-op-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.5.2 <a href="#non-op-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.5.3 <a href="#non-op-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.6 <a href="#non-op-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.9.7 <a href="#non-op-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.10 <a href="#xmpp">XMPP Instant Messaging Compression</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.1 <a href="#xmpp-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.2 <a href="#xmpp-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.3 <a href="#xmpp-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.4 <a href="#xmpp-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.5 <a href="#xmpp-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.5.1 <a href="#xmpp-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.5.2 <a href="#xmpp-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.5.3 <a href="#xmpp-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.6 <a href="#xmpp-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.7 <a href="#xmpp-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.11 <a href="#xml-docs-persistent-store">XML Documents in Persistent Store</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.1 <a href="#xml-docs-persistent-store-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.2 <a href="#xml-docs-persistent-store-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.3 <a href="#xml-docs-persistent-store-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.4 <a href="#xml-docs-persistent-store-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.5 <a href="#xml-docs-persistent-store-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.5.1 <a href="#xml-docs-persistent-store-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.5.2 <a href="#xml-docs-persistent-store-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.5.3 <a href="#xml-docs-persistent-store-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.6 <a href="#xml-docs-persistent-store-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.11.7 <a href="#xml-docs-persistent-store-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.12 <a href="#trans-rule-engines">Business and Knowledge Processing</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.1 <a href="#trans-rule-engines-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.2 <a href="#trans-rule-engines-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.3 <a href="#trans-rule-engines-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.4 <a href="#trans-rule-engines-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.5 <a href="#trans-rule-engines-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.5.1 <a href="#trans-rule-engines-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.5.2 <a href="#trans-rule-engines-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.5.3 <a href="#trans-rule-engines-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.6 <a href="#trans-rule-engines-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.12.7 <a href="#trans-rule-engines-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.13 <a href="#xml-content-based-routing">XML Content-based Routing and Publish Subscribe</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.1 <a href="#xml-content-based-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.2 <a href="#xml-content-based-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.3 <a href="#xml-content-based-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.4 <a href="#xml-content-based-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.5 <a href="#xml-content-based-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.5.1 <a href="#xml-content-based-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.5.2 <a href="#xml-content-based-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.5.3 <a href="#xml-content-based-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.6 <a href="#xml-content-based-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.13.7 <a href="#xml-content-based-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.14 <a href="#ws-routing">Web Services Routing</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.1 <a href="#ws-routing-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.2 <a href="#ws-routing-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.3 <a href="#ws-routing-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.4 <a href="#ws-routing-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.5 <a href="#ws-routing-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.5.1 <a href="#ws-routing-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.5.2 <a href="#ws-routing-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.5.3 <a href="#ws-routing-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.6 <a href="#ws-routing-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.14.7 <a href="#ws-routing-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.15 <a href="#military">Military Information Interoperability</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.1 <a href="#military-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.2 <a href="#military-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.3 <a href="#military-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.4 <a href="#military-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.5 <a href="#military-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.5.1 <a href="#military-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.5.2 <a href="#military-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.5.3 <a href="#military-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.6 <a href="#military-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.15.7 <a href="#military-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.16 <a href="#sensor">Sensor Processing and Communication</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.1 <a href="#sensor-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.2 <a href="#sensor-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.3 <a href="#sensor-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.4 <a href="#sensor-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.5 <a href="#sensor-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.5.1 <a href="#sensor-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.5.2 <a href="#sensor-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.5.3 <a href="#sensor-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.6 <a href="#sensor-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.16.7 <a href="#sensor-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.17 <a href="#syncml">SyncML for Data Synchronization</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.1 <a href="#syncml-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.2 <a href="#syncml-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.3 <a href="#syncml-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.4 <a href="#syncml-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.5 <a href="#syncml-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.5.1 <a href="#syncml-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.5.2 <a href="#syncml-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.5.3 <a href="#syncml-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.6 <a href="#syncml-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.17.7 <a href="#syncml-refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.18 <a href="#super-comp">Supercomputing and Grid Processing</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.1 <a href="#super-comp-desc">Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.2 <a href="#super-comp-dom">Domain &amp; Stakeholders</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.3 <a href="#super-comp-justi">Justification</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.4 <a href="#super-comp-ana">Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.5 <a href="#super-comp-prop">Properties</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.5.1 <a href="#super-comp-must-props">Must Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.5.2 <a href="#super-comp-should-props">Should Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.5.3 <a href="#super-comp-nice-props">Nice To Have</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.6 <a href="#super-comp-alt">Alternatives</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.18.7 <a href="#super-comp-refs">References</a><br>
4 <a href="#N119A9">References</a><br>
</p>
<h3><a id="appendices" name="appendices"></a>Appendix</h3><p class="toc">A <a href="#N11E10">Acknowledgments</a><br>
</p></div><hr><div class="body"><div class="div1">
<h2><a id="intro" name="intro"></a>1 Introduction</h2><p>While XML has been enormously successful as a markup language for documents and data, the
        overhead associated with generating, parsing, transmitting, storing, or accessing XML-based
        data has hindered its employment in some environments. The question has been raised as to
        whether some optimized serialization of XML is appropriate to satisfy the constraints
        present in such environments. In order to address this question, a compatible means of
        classifying the requirements posed by specific use cases and the applicable characteristics
        of XML must be devised. This allows a characterization of the potential gap between what
        XML currently supports and use case requirements. In addition, it also provides a way to compare
        use case requirements to determine the degree to which an alternate serialization could be beneficial.</p><p>Use cases describing situations where some characteristics of XML may prevent its effective
        use are presented in this document. The XBC WG has made efforts through internal discussion
        and dialog with the XML community to define a comprehensive set of use cases to examine and
        compare potential solutions, including alternate serializations of XML as well 	as
        other available means. Comments are invited, especially if important use cases 	or
        solutions to address them have been omitted.</p></div><div class="div1">
<h2><a id="use-case-meta-data" name="use-case-meta-data"></a>2 Use Case Structure</h2><p>In this section we elaborate on the template used to present the use cases. All the use
        cases collected by this WG are listed in <a href="#documented-use-cases"><b>3 Documented Use Cases</b></a>.</p><ul><li><p>
            <b>Description</b>: Provides an overview of the use case.</p></li><li><p>
            <b>Domain &amp; Stakeholders</b>: Identifies the functional and/or business
            area(s) and users to which the use case pertains.</p></li><li><p>
            <b>Justification</b>: This is a discussion of why (or why not) a standard solution for
            efficient XML encoding should be pursued.</p></li><li><p>
            <b>Analysis</b>: Examines why XML is appropriate for addressing the use case, and the
            limitations of XML which hinder its use. Requirements for the use case are discussed in this section.</p></li><li><p>
            <b>Properties</b>: References/discusses the properties required to support the
            	 use case.  For each use case the properties are partitioned into three categories:</p><ol class="enumar"><li><p>
				     <em>Must Have</em>:  This is the set of properties which must be supported for a format to be adopted in the use case domain. This is intended to be a high bar in that an unsupported "must have" property would not simply make a format undesirable but actually unusable.
				  </p></li><li><p>
				     <em>Should Have</em>:  This is the set of properties which are important, but not critical, to the use case.  A format which did not support "should have" properties would be significantly less desirable than one that did.  However, formats not supporting "should have" properties would still be usable for that use case.

				  </p></li><li><p>
				     <em>Nice To Have</em>:  This is the set of properties which are not important, but supporting them brings some benefit to the use case. However, the benefit is generally minor and would be traded off to support "should have" or "must have" properties for that use case.
				  </p></li></ol></li><li><p>
            <b>Alternatives</b>: Presents alternatives to XML for addressing the use case.</p></li><li><p>
            <b>References</b>: Lists references to industries, standards, etc. that are related to
            the use case.</p></li></ul></div><div class="div1">
<h2><a id="documented-use-cases" name="documented-use-cases"></a>3 Documented Use Cases</h2><p>The use cases identified by or submitted to the working group are documented below, in
        accordance with the meta data defined in <a href="#use-case-meta-data"><b>2 Use Case Structure</b></a>.</p><div class="div2">
<h3><a id="broadcast" name="broadcast"></a>3.1 Metadata in Broadcast Systems</h3><div class="div3">
<h4><a id="broadcast-desc" name="broadcast-desc"></a>3.1.1 Description</h4><p>The constant progress of digital TV, the multiplication of channels, the competition
                and convergence with the Web, and the widespread deployment of a variety of set-top
                boxes (notably Personal Video Recorders, or PVRs for short) call for services on TV
                sets that extend beyond simply broadcasting audio/video content.</p><p>For instance, above a certain number of channels, broadcasters find themselves having
                to provide EPG (Electronic Program Guide) services to their users, without which
                they would be overwhelmed with the sheer amount of available content. These EPGs
                also allow PVRs to automatically pick up recording schedules for given programs,
                based on user-defined criteria that match against metadata broadcasted alongside the data.</p><p>Similarly, efforts are under way to define a world-wide standard for
timed text systems under the leadership of the W3C Timed Text Working
Group. Timed text is an essential service for a large variety of video
use cases, such as broadcasting subtitles for foreign movies, providing
accessible video information, or implementing karaoke systems.</p><p>However, there are constraints that cause problems when trying to deploy such
                services, all of which rely on XML, to television sets and other video devices:</p><ul><li><p>Bandwidth: TV bandwidth is extremely expensive, and how much data you
use for  services directly constrains the number of channels that you
are able to broadcast. In addition to the potential technical issues,
there are strong  economic motivations to reduce bandwidth usage as much
as possible. One week of electronic program guide data easily amounts to
roughly 30Mb of XML data.
</p></li><li><p>Processing Power: Most set-top boxes are inexpensive, and the low-end
ones suffer from low processing power.  Contrary to mobile devices,
there are few limitations as to the processing  power that can be
embarked in a box the size of the average set-top box  (STB), notably
the problems relating to heat and battery life are of little or no
concern. However, the large-scale deployment of STBs and  similar
devices into households requires them to be extremely inexpensive  and
therefore as limited as possible (an average mid-end STB may have up to
16Mb of memory and processors up to 80Mhz, but frequently less, and
systems anticipated for deployment in 2008 may have up to 120Mhz
processors and up to 64Mb of memory). Also convergence with  mobile
devices remains a prime motivator for the television industry and
constraints applicable to mobile devices apply equally to broadcasted
XML metadata notably because of efforts such as DVB-H (Digital Video
Broadcast for Handsets).</p></li><li><p>Unidirectional Network: This being broadcast, there is not typically a
way  for TVs to request data. Instead, it is being continuously streamed
and  re-streamed to them, a process which is called carouselling (the
data itself  being 'on a carousel'). Some set-top boxes do in fact have
a return channel but the vast majority don't and it is not expected
that most would support one in the near future.</p></li><li><p>Change Resilience. Upgrading several million STBs is often very impractical.
                        Therefore, it must be possible to evolve the broadcast format without
                        breaking older hardware. While XML is perfectly suited to this, the above
                        issues make it unusable. It is thus required that the binary XML format
                        replacing it be resilient to changes in the schema.</p></li></ul><p>These constraints translate into a set of requirements: a decoder should
be able to begin decoding at any point in the stream without waiting for
an entire document to have been received and be able to reconstruct the
document progressively; if a decoder fails to receive a fragment, then,
within a limited time duration, it should be able to receive a repeated
copy of that same fragment, knowing that some fragments may be more
important than others and therefore repeated more frequently; and the
transmission size of the data as well as the amount of processing power
required to process it should be minimized.
			</p><p>As a result, MPEG-7 BiM (a binary encoding of XML originally created to carry video
                metadata), has been integrated into a number of broadcasting standards, notably
                ARIB, DVB, and TV Anytime.</p></div><div class="div3">
<h4><a id="broadcast-dom" name="broadcast-dom"></a>3.1.2 Domain &amp; Stakeholders</h4><p>This use case is relevant to the entirety of the television distribution industry,
                comprising content providers, broadcast infrastructure deployers, television and
                set-top box manufacturers, and of course the broadcasting companies themselves.</p><p>It also covers similar requirements that can be found in digital radio broadcasting,
                where one equally needs to broadcast EPG metadata to very limited devices, to
                integrate with mobile devices (for instance by sending SVG ads as part of the radio stream).</p><p>And finally, convergence with TV is considered to be a major next step in mobile
                services, and all participants on both sides of the fence are presently being
                extremely active in making television available anywhere, at any time, and on any
                device. Quite naturally, this leads to the need for common technology between the TV
                industry and the rest of the Web. As such, the major stakeholders in the domain have
                expressed interest in reusing a solution commonly agreed upon across several industries.</p></div><div class="div3">
<h4><a id="broadcast-justi" name="broadcast-justi"></a>3.1.3 Justification</h4><p>Television is a very large market that has a strong need for program metadata, and is
                increasingly converging with the Web at large (with a strong emphasis on mobile
                devices at first), notably using technologies such as XHTML, SVG, XForms, SMIL, and  Time Text.</p><p>Deployed systems already use binary XML, currently standardized as part of ISO MPEG
                and industry fora such as ARIB, DVB, or TV-Anytime, but have expressed interest in
                using more broadly adopted technologies.</p></div><div class="div3">
<h4><a id="broadcast-ana" name="broadcast-ana"></a>3.1.4 Analysis</h4><p>XML is appropriate for these situations because:</p><ol class="enumar"><li><p>existing specifications based on XML are being reused wholesale;</p></li><li><p>most major TV standards in the area are already XML-based, and the industry
                        has no wish to go through another standards cycle;</p></li><li><p>XML is well-suited to describing structured information such as metadata;</p></li><li><p>XML has proven to be a good format to specify user interfaces in, using
                        notably XHTML, SVG, or XForms. These are needed for TV applications, and
                        they need to be broadcasted;</p></li><li><p>the industry wishes to publish its data, especially the Electronic Program
                        Guides, to as many media as possible. XML enables it to publish directly to
                        desktops, mobile devices, and TVs using off-the-shelf or Open Source software.</p></li></ol></div><div class="div3">
<h4><a id="broadcast-prop" name="broadcast-prop"></a>3.1.5 Properties</h4><div class="div4">
<h5><a id="broadcast-must-props" name="broadcast-must-props"></a>3.1.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
			<a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
		  </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="broadcast-should-props" name="broadcast-should-props"></a>3.1.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
			<a href="http://www.w3.org/TR/xbc-properties/#localized-changes">Localized Changes</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
		  </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li></ul></div><div class="div4">
<h5><a id="broadcast-nice-props" name="broadcast-nice-props"></a>3.1.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="broadcast-alt" name="broadcast-alt"></a>3.1.6 Alternatives</h4><p>DVB EIT schedules provide a small subset of the required functionality and do not
                integrate well with a more generic information ecosystem.</p><p>Without a W3C format of binary XML, application domains will likely adopt different
                formats--a phenomenon that already started in the Broadcast domain. This would
                further cluster the market. A convergence (which can be recognized right now)
                between the broadcast and the mobile communication services would be hindered by
                this clustering. In this concrete case, mobile devices would be required to
                implement codecs of both domains to enable value added services like interactive and
                location aware TV broadcast. This drives up the initial investment, which translates
                into a great obstacle for a converged service in the marketplace.</p></div><div class="div3">
<h4><a id="broadcast-refs" name="broadcast-refs"></a>3.1.7 References</h4><ol class="enumar"><li><p>
                        <a href="#DVB">[DVB]</a>
                    </p></li><li><p>
                        <a href="#TVAnytime">[TV Anytime]</a>
                    </p></li><li><p>
                        <a href="#ARIB">[ARIB]</a>
                    </p></li><li><p>
                        <a href="#MPEG-7">[MPEG-7]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="FPenergy" name="FPenergy"></a>3.2 Floating Point Arrays in the Energy Industry</h3><div class="div3">
<h4><a id="FPenergy-desc" name="FPenergy-desc"></a>3.2.1 Description</h4><p> The upstream segment of the energy industry is concerned with exploration for and
                production of oil and gas.  XML-based techniques have made very little penetration
                into the upstream technology part of the energy industry.  The most basic reason for
                this is the nature of the data, which does not at this time lend itself to being
                represented usefully in XML. </p><p> There are basically two core types of data in this industry: well logs and seismic
                data.  Well logs are moderately large datasets while seismic datasets are very
                large, typically in the order of gigabytes.  Although the Petrotechnical Open
                Standards Consortium <a href="#POSC">[POSC]</a> has produced an XML schema for well logs
                <a href="#WellLogML">[WellLogML]</a>, it has not been widely adopted by the industry.  At the
                time of writing, we are not aware of anyone even considering a schema definition for seismic data. </p><p> One example of the magnitude of data and processing needs is data from marine
	        seismic surveys.  A typical data collection arrangement includes a ship, traveling
	        at a fairly slow speed, trailing a cable behind it that is about two miles long and
	        which contains about a hundred listening devices (geophones) spaced evenly along the
	        cable.  An air gun array on the boat fires every thirty seconds or so and the echos
	        from the subsurface received by each geophone are recorded for about six seconds at
	        a two millisecond sampling rate.  That's 36 million words of floating point data per
	        hour.  The ship travels back and forth covering in a systematic way an area several
	        miles on a side, resulting in a highly redundant 3D sampling of echos from the
	        subsurface.  The redundancy, loosely speaking, results from the fact that the cable
	        is moving so that, for example, a given subsurface point might be sampled by
	        geophone 10 on shot 100, geophone 14 on shot 101, geophone 18 on shot 102 and so on.
	        The high degree of redundancy later results in a large number of processing
	        operations involving reordering and sub-setting the data.  The communication of this
	        data and the necessity of these operations influences the formats and structures
	        that are appropriate.</p><p> Both seismic and well log data include control data, easily represented in XML, as
                well as large arrays of floating point numbers, not easily represented
                <em>efficiently</em> in XML.  Although in practice an XML representation is not
                used, such data may be represented as shown in the following fragment (with a whole
                document consisting of a large number of these fragments): </p><div class="exampleInner"><pre>    &lt;seisdata&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&lt;lineheader&gt;...&lt;lineheader&gt;&nbsp;
  &nbsp;&nbsp;&nbsp; &lt;header&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;linename&gt;westcam 2811&lt;/linename&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ntrace&gt;1207&lt;/ntrace&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nsamp&gt;3001&lt;/nsamp&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;tstart&gt;0.0&lt;/tstart&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;tinc&gt;4.0&lt;/tinc&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;shot&gt;120&lt;/shot&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;geophone&gt;7&lt;/geophone&gt;
  &nbsp;&nbsp;&nbsp; &lt;/header&gt;
  &nbsp;&nbsp;&nbsp; &lt;trace&gt;0.0 0.0 468.34 3.245672E04 6.9762345E05 ... (3001 floats)&lt;/trace&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;&lt;header&gt;
        ...&nbsp;
      &lt;/header&gt;
      &lt;trace&gt; ... &lt;/trace&gt;
  &nbsp;&nbsp;&nbsp;&nbsp;...
  &nbsp; &lt;/seisdata&gt;</pre></div></div><div class="div3">
<h4><a id="FPenergy-dom" name="FPenergy-dom"></a>3.2.2 Domain</h4><p> The scope within the Energy Industry as discussed above is very broad, encompassing
                a very large number of technical issues and usage scenarios involving, for example,
                integration of drilling information, processing of seismic and well data,
                integration of seismic and well data into interpretation systems, and so on. </p></div><div class="div3">
<h4><a id="FPenergy-justi" name="FPenergy-justi"></a>3.2.3 Justification</h4><p> There are a number of dominant technology vendors in this sector as well as a number
                of small companies that "work around the edges".  The dominant technology vendors in
                this field provide proprietary solutions that do not interoperate easily with each
                other.  Providing communications between these products within a company, or between
                companies, is a constant problem: this is the main motivator to develop Web service
                interfaces for these products.  A second motivator for a standard is that it will
                open the door for smaller companies to provide useful add-on products.  Large
                budgets in this sector are allocated to the purchase of software packages and
                display devices, but these budgets are small compared to the leverage of mass-market
                devices, so a longer term objective is to encourage a situation where more
                technologies with mass-market cost leverage can be used. </p></div><div class="div3">
<h4><a id="FPenergy-ana" name="FPenergy-ana"></a>3.2.4 Analysis</h4><p> Given that this scenario involves interoperability between companies using disparate
                systems, XML is a natural choice due to its ubiquity and tool availability.</p><p> The main shortcoming of XML for this application is the processing expense incurred
                while converting floating point data to and from a character representation, as well
                as the extra size of some representations.  Thus, the main requirement for this use
                case is the ability to represent sequences of scalars like floating point numbers in
                a native binary format in order to facilitate efficient use in application
                processing.  In the example shown above, the header information would still have a
                textual value representation (useful for any infoset-based processing), but the data
                composed of floating point numbers would appear as a binary stream that is as
                directly usable as possible.</p><p> A candidate format must support floating point numbers in multiple native formats
                representative of common architectures with appropriate type indication.  This
                allows reader-makes-right conversion only when needed and direct memory load
                otherwise.  In practice, most operations involve moving data between machines with
                the same floating point formats so the solution should not impose undue overhead on
                the most common situation in order to handle the less common ones.  It is generally
                considered too expensive to incur processing overhead of conversion between floating
                point and character representation for this data.  The ecosystem of data
                communication and processing involving multiple independently developed applications
                indicates the need for exchange formats that are very processing efficient and space
                efficient in ways that are not processing intensive.  This implies that a directly
                random access, random update, and efficient update capable format would be very
                useful and that transmitting low-level deltas might make sense to support update or
                repetitive communication.</p><p> Developers working in this industry find it most desirable to use a coherent library
	        interface to get efficient access to the usually-native scalar data in the most
	        direct way after receiving a block of data in the format.  Similar efficiency is
	        needed in the creation or update of an instance of the format.  This need is not
	        fulfilled by something that operates like a traditional parser.  A parser-driven
	        architecture usually involves considering each byte of the entire object first,
	        generating many parse events, and then building a memory representation involving
	        memory allocation and data copies, often through interfaces that must be invoked
	        repeatedly.  The goal of infrastructure for applications in this industry is to have
	        the overall minimum net overhead in processing.  To support adoption as a common
	        interchange format, the industry needs a standard format that can support this
	        lightweight low-overhead processing model.</p></div><div class="div3">
<h4><a id="FPenergy-prop" name="FPenergy-prop"></a>3.2.5 Properties</h4><div class="div4">
<h5><a id="FPenergy-must-props" name="FPenergy-must-props"></a>3.2.5.1 Must Have</h5><ul><li><p><a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a></p></li></ul></div><div class="div4">
<h5><a id="FPenergy-should-props" name="FPenergy-should-props"></a>3.2.5.2 Should Have</h5><ul><li><p><a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a></p></li></ul></div><div class="div4">
<h5><a id="FPenergy-nice-props" name="FPenergy-nice-props"></a>3.2.5.3 Nice To Have</h5><ul><li><p><a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a></p></li></ul></div></div><p>Notes: Specialized Codecs makes sense if it is the property that allows direct
	representation of binary scalars.  Platform Neutrality is needed in the sense that native
	scalars from all needed platforms must be supported by any implementation if the format has
	a Single Conformance Class.</p><div class="div3">
<h4><a id="FPenergy-alt" name="FPenergy-alt"></a>3.2.6 Alternatives</h4><ul><li><p> Data Compression: One expert in this area has said, "For us, binary
                        compression is probably not that important because transmission speeds are
                        constantly improving. The additional time needed to compress and decompress
                        seismic data would probably slow things down. We also place a greater value
                        in the message structures than the transmission mechanics". Or, in more
                        picturesque words, again from an expert in the field when asked about
                        compressing seismic data, "Been there, done that, doesn't work, not
                        interested". Bear in mind that this epigram encapsulates decades of
                        experience and highly sophisticated R&amp;D. </p></li><li><p> CORBA: There is, in fact, a CORBA-based integration platform currently
                        deployed (although perhaps not widely) in this space. Without diving into
                        technical details, it is clear that some companies would prefer an approach
                        based on Web services. </p></li><li><p> XML Protocol Attachments: It is possible to represent seismic data control
                        information in XML and to put the floating point arrays in a binary
                        attachment using XOP. This data architecture is certainly viable, assuming
                        that the issues involving floating point numbers are addressed, as evidenced
                        by the fact that many of the proprietary vendor data formats work this way.
                        It is, however, less flexible than the header-trace architecture described
                        above, which is probably one reason why the latter is used in industry-wide
                        seismic data standards (e.g. SEGY). Nonetheless, Web services that return
                        data using XOP are an attractive alternative for dealing with seismic data. </p></li></ul></div><div class="div3">
<h4><a id="FPenergy-refs" name="FPenergy-refs"></a>3.2.7 References</h4><ol class="enumar"><li><p>
                        <a href="#POSC">[POSC]</a>
                    </p></li><li><p>
                        <a href="#WellLogML">[WellLogML]</a>
                    </p></li><li><p>
                        <a href="#SEGY">[SEGY]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="x3dtrans" name="x3dtrans"></a>3.3 X3D Graphics Model Compression, Serialization and Transmission</h3><div class="div3">
<h4><a id="x3dtrans-desc" name="x3dtrans-desc"></a>3.3.1 Description</h4><p> Extensible 3D (X3D) Graphics <a href="#X3D">[Extensible 3D (X3D) Graphics]</a> is an XML-enabled ISO Standard 3D
                file format to enable real-time communication of 3D data across all applications and
                networks. It is used for commercial applications, engineering and scientific
                visualization, medical imaging, training, modeling and simulation (M&amp;S),
                multimedia, entertainment, education, and more. <a href="#X3D-Markets">[X3D Markets]</a>
                Computer-Aided Design (CAD) and architecture scenes are also supported, though
                because they have larger file sizes and are more complex they are not typically
                streamed for web-delivered viewing. </p><p> Web-delivered file sizes in this use case typically range from 1-1000 KB of data
                while CAD files may run to several hundred megabytes apiece. An optimized
                serialization of the X3D data may be performed in concert with application-specific
                compression (e.g. combining coplanar polygons, quantizing colors, etc.) Lossy
                geometric compression is sometimes acceptable. Due to interaction requirements, the
                latency time associated with deserialization, decompression and parsing must be
                minimal. Digital signature and encryption compatibilities are also important for
                protecting digital content assets.</p></div><div class="div3">
<h4><a id="x3dtrans-dom" name="x3dtrans-dom"></a>3.3.2 Domain &amp; Stakeholders</h4><p> Support of Web-based interchange, rendering and interactivity for 3D graphics
                scenes. Stakeholders include tool builders, content authors, application developers
                and end users of 3D graphics models.</p></div><div class="div3">
<h4><a id="x3dtrans-justi" name="x3dtrans-justi"></a>3.3.3 Justification</h4><p> The X3D Compressed Binary Encoding Request For Proposals (RFP) from the X3D
                Consortium <a href="#X3D-RFP">[X3D RFP]</a> lists and justifies ten separate technical
                requirements. Many of these have parallels to a general optimized serialization
                format. The Web3D Consortium and X3D designers see great value in aligning with W3C
                standardization efforts in this area. This serves as significant evidence of the
                need for an industry standard.</p></div><div class="div3">
<h4><a id="x3dtrans-ana" name="x3dtrans-ana"></a>3.3.4 Analysis</h4><p> Taken together, the following technical requirements for the X3D Compressed Binary
                Encoding RFP (indicated by <em>emphasized</em> type) include many requirements
                for an optimized serialization format. Strictly speaking, such an efficient
                serialization is not necessarily "compressed", though it is very likely to be more
                compact. Other factors, such as speed of parsing or databinding performance, may
                override the desire for compact representation for some applications, such as CAD.
                The X3D Consortium's RFP has chosen to include the ability to perform
                application-specific size optimizations, both lossless and lossy, as part of the
                process of converting the document from XML to the optimized serialization. However,
                the optimized format can still be represented as XML; in other words, a lossy
                geometric compression to an efficient format can be translated back to a lossy XML
                representation.</p><ul><li><p>
                        <em>
                            <b>X3D Compatibility</b>: The compressed binary encoding shall be able
                            to encode all of the abstract functionality described in X3D Abstract
                        Specification.</em> Since X3D is expressed in XML, any optimized
                        serialization that encodes all XML features will also be capable of encoding
                        an X3D document.</p></li><li><p>
                        <em>
                            <b>Interoperability</b>: The compressed binary encoding shall contain
                            identical information to the other X3D encodings (XML and Classic VRML).
                            It shall support an identical round-trip conversion between the X3D
                        encodings.</em> This corresponds to the <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a> property.</p></li><li><p>
                        <em>
                            <b>Multiple, separable data types</b>: The compressed binary encoding
                            shall support multiple, separable media data types, including all node
                            (element) and field (attribute) types in X3D.</em> The RFC allows the
                        possibility of performing domain-specific compressions or encodings of data
                        in the XML document, for example of polygons and textures. The ability to
                        make use of <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a> is essential to meeting this requirement.</p></li><li><p>
                        <em>
                            <b>Processing Performance</b>: The compressed binary encoding shall be
                            easy and efficient to process in a runtime environment.</em> Because
                        the data for interactive applications is delivered across the web low
                        latency is important. The ability to quickly process documents is important.
                        In the case of CAD files, which may be several hundred megabytes in size,
                        the ability to quickly process the file is very important. Often 3D files
                        have long arrays of numeric data. Using XML format requires that a reader
                        extract the string information and convert it to a binary representation.
                        This is a computationally expensive process. Experimental data has shown
                        that an optimized format can be 20 times as fast as XML. The ability to
                        rapidly process arrays of floating point data is also important. Thus the
                        <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a> property is also relevant to this use case.</p></li><li><p>
                        <em>
                            <b>Ease of Implementation</b>: Binary compression algorithms shall be
                            easy to implement.</em> This corresponds to <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>.</p></li><li><p>
                        <em>
                            <b>Streaming</b>: Compressed binary encoding will operate in a variety
                            of network-streaming environments.</em> X3D documents are often
                        streamed in web environments, and portions of the 3D scene are rendered as
                        they arrive on the client computer. This corresponds to the <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a> property.</p></li><li><p>
                        <em>
                            <b>Compression</b>: Compressed binary encoding algorithms will
                            together enable effective compression of diverse datatypes.</em> 3D
                        data often consists of large arrays of floating point data that can be
                        compressed in various ways. The ability to employ <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>,
                        either lossless or lossy, would meet this requirement.</p></li><li><p>
                        <em>
                            <b>Security</b>: Compressed binary encoding will optionally enable
                            security, content protection, privacy preferences and metadata such as
                            encryption, conditional access, and watermarking.</em> This
                        corresponds to the <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a> property.</p></li><li><p>
                        <em>
                            <b>Bundling</b>: Mechanisms for bundling multiple files (e.g. X3D
                            scene, inlined sub-scenes, image files, audio file, etc.) into a single
                            archive file will be considered.</em> This corresponds to <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>.</p></li><li><p>
                        <em>
                            <b>Intellectual Property Rights (IPR)</b>: Technology submissions must
                            meet the Web3D Consortium IPR policy.</em> The W3C Patent Policy
                            <a href="#W3C-PP">[W3C PP]</a> is compatible with this.</p></li></ul></div><div class="div3">
<h4><a id="x3dtrans-prop" name="x3dtrans-prop"></a>3.3.5 Properties</h4><div class="div4">
<h5><a id="x3dtrans-must-props" name="x3dtrans-must-props"></a>3.3.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="x3dtrans-should-props" name="x3dtrans-should-props"></a>3.3.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="x3dtrans-nice-props" name="x3dtrans-nice-props"></a>3.3.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-readable-editable">Human Readable and Editable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="x3dtrans-alt" name="x3dtrans-alt"></a>3.3.6 Alternatives</h4><p> GZIP is the specified compression scheme for Virtual Reality Modeling Language (VRML
                97) specification, the second-generation ISO predecessor to X3D. GZIP is not
                type-aware and does not compress large sets of floating-point numbers as well. GZIP
                allows staged decompression of 64KB blocks, which might be used to support streaming
                capabilities. GZIP outputs are strings and require a second pass for any parsing,
                thus degrading parsing and loading performance. A GZIPed file would not gain the
                parsing speed and databinding advantages of an optimized format.</p><p> Numerous piecemeal, incompatible proprietary solutions exist in the 3D graphics
                industry for Web-page plug-ins. None address the breadth of technical capabilities
                that might be enabled by a general purpose optimized serialization format.</p><p> An X3D-specific compression and serialization algorithm for XML is certainly
                feasible and demonstrated. Compatibility with a general recommendation for an
                optimized format is desirable in order to maximize interoperability with other XML
                technologies, and reduce implementation cost. Many of these issues are common to
                other use-case domains; broad mutual benefits become possible via a common recommendation.</p></div><div class="div3">
<h4><a id="x3dtrans-refs" name="x3dtrans-refs"></a>3.3.7 References</h4><ol class="enumar"><li><p>
                        <a href="#X3D">[Extensible 3D (X3D) Graphics]</a>
                    </p></li><li><p>
                        <a href="#X3D-Markets">[X3D Markets]</a>
                    </p></li><li><p>
                        <a href="#X3D-RFP">[X3D RFP]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="ws-for-small-devices" name="ws-for-small-devices"></a>3.4 Web Services for Small Devices</h3><div class="div3">
<h4><a id="ws-for-small-devices-desc" name="ws-for-small-devices-desc"></a>3.4.1 Description</h4><p>As Web services become more and more ubiquitous, there is a greater demand to use
                this technology as a way to deliver content to small devices such PDAs, pagers and
                mobile phones. All these devices often share the following characteristics:</p><ol class="enumar"><li><p>They have limited memory and limited processing power.</p></li><li><p>Battery life is at a premium.</p></li><li><p>They are connected to low-bandwidth, high-latency networks which in some
                        cases are regulated by "pay-per-byte" policies.</p></li></ol><p>XML-based messaging is at the heart of the current Web services technology. XML's
                self-describing nature has significant advantages, but they come at the price of
                bandwidth and performance. XML-based messages are larger and require more processing
                than other protocols, and are therefore not well suited for a domain having the
                characteristics outlined above. Increased bandwidth usage affects wireless networks
                due to bandwidth restrictions allotted for communication by each device. In
                addition, the larger the message the higher the probability of a retransmission as a
                result of an on-the-air collision.</p><p>The target platforms for this use case include a broad range of PDAs, handhelds and
                mobile handsets, including mass market devices that limit code size to 64K and heap
                size to 230K. The transport packet size may vary from network to network, but it is
                typically measured in bytes (e.g. 128 bytes).</p></div><div class="div3">
<h4><a id="ws-for-small-devices-dom" name="ws-for-small-devices-dom"></a>3.4.2 Domain</h4><p>Small devices connected to low-bandwidth, high-latency networks. Two examples in this
                domain are cellular phone networks and PDA networks employed by the military.</p></div><div class="div3">
<h4><a id="ws-for-small-devices-justi" name="ws-for-small-devices-justi"></a>3.4.3 Justification</h4><p>XML is the fundamental technology underlying a Web services infrastructure, and one
                of the main reasons why Web services are not being deployed on the mobile space. A
                number of alternative serializations have already been developed to deliver XML
                content to small devices, however, many of these are not interoperable. This lack of
                interoperability results in fragmentation and the need for specialized gateways to
                transcode proprietary formats.</p></div><div class="div3">
<h4><a id="ws-for-small-devices-ana" name="ws-for-small-devices-ana"></a>3.4.4 Analysis</h4><p>In order to satisfy the requirements of this use case, an alternative serialization
                must be faster to process and must produce smaller packets. Faster processing will
                result in lesser battery consumption while smaller packets will result in reduced
                latency as well as, assuming a pay-per-byte model, a more cost-effective service. In
                addition to small and fast, an alternative serialization should also be streamable,
                i.e. it should be possible for the client application to operate on any prefix of
                the serialized data.</p><p>Assuming that the same amount of information is encoded in an alternative
                serialization, a way to quantify efficiency is to consider the instruction to data
                ratio. In other words, the amount of <em>effort</em> that is needed to produce
                or consume a unit of data. Even though this is an implementation requirement, an
                alternative serialization must enable the creation of "thin" stacks with a low
                instruction to data ratio.</p><p>The reduction in latency that results by improving parsing speed may or may not be
                noticeable to the consumer depending on the transport latency of the network
                --transport latency is the dominant factor in many existing networks. Nevertheless,
                a more efficient parsing method will improve battery life on the device as well as
                throughput on the server.</p></div><div class="div3">
<h4><a id="ws-for-small-devices-prop" name="ws-for-small-devices-prop"></a>3.4.5 Properties</h4><div class="div4">
<h5><a id="ws-for-small-devices-must-props" name="ws-for-small-devices-must-props"></a>3.4.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-for-small-devices-should-props" name="ws-for-small-devices-should-props"></a>3.4.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-for-small-devices-nice-props" name="ws-for-small-devices-nice-props"></a>3.4.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="ws-for-small-devices-alt" name="ws-for-small-devices-alt"></a>3.4.6 Alternatives</h4><p>Proprietary solutions result in the so-called <em>gatewayed</em> networks, where
                communication is always routed through a single point that translates to and from
                XML. This architecture not only creates a single point of failure within a network
                but also fragments the entire network by creating non-interoperable, domain-specific solutions.</p><p>Message size reductions are attainable via the use of standard data compression
                techniques. Even though in general decompression is less expensive than compression,
                it is still too costly for most small devices. Additionally, the extra burden of
                compressing packets has a negative impact on the overall system throughput.</p><p>In addition to the added cost, redundancy-based compression algorithms tend to
                perform very poorly on small messages, in many cases resulting in larger messages.
                Mobile clients often carry on dialogs with servers which consist of a large number
                of small messages. Examples of this include: data synchronization, stateful web
                services, multi-player games, querying and browsing data. In all of these use cases,
                the cumulative stream of messages that make up the dialog can grow very large even
                though all of the individual messages are rather small. Thus, there is still a need
                to reduce the amount of data exchanged, but doing this by compressing each message
                individually is not a viable solution.</p></div><div class="div3">
<h4><a id="ws-for-small-devices-refs" name="ws-for-small-devices-refs"></a>3.4.7 References</h4><ol class="enumar"><li><p>
                        <a href="#Comparing-SOAP-Performance">[Comparing SOAP Performance]</a>
                    </p></li><li><p>
                        <a href="#SOAP-Performance-Wireless-Networks">[SOAP Performance in Wireless Networks]</a>
                    </p></li><li><p>
                        <a href="#FWS">[Fast Web Services]</a>
                    </p></li><li><p>
                        <a href="#SOAPPerf">[SOAP Performance]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="ws-for-enterprise" name="ws-for-enterprise"></a>3.5 Web Services within the Enterprise</h3><div class="div3">
<h4><a id="ws-for-enterprise-desc" name="ws-for-enterprise-desc"></a>3.5.1 Description</h4><p>A large number of existing enterprise systems are built using distributed
                technologies such as RMI, DCOM and CORBA. As the industry moves from distributed
                object systems to Service Oriented Architectures (SOAs), the use of Web services
                technologies becomes more significant even within the confines of a single
                enterprise. Many of the concepts behind SOAs are applicable to divisions within an
                corporation, so it is only natural to extend the applicability of Web services to
                intranet systems.</p><p>A stumbling block that several re-architected systems are facing is that XML-based
                messages are larger and require more processing than those from existing protocols:
                data is represented inefficiently and binding requires more computation. It has been
                shown that an RMI service can perform up to an order of magnitude faster than an
                equivalent Web Service due to the processing required to parse and bind XML data
                into programmatic objects.</p></div><div class="div3">
<h4><a id="ws-for-enterprise-dom" name="ws-for-enterprise-dom"></a>3.5.2 Domain</h4><p>The domain is that of distributed systems, typically based on binary protocols, which
                for technical reasons (e.g., interoperability) or for economic reasons (e.g.,
                reduction of software licenses) need to be re-architected as Web services. An
                important constraint for these type of re-deployments is to maintain (or improve)
                the system's performance, a task that has been found challenging given the
                additional processing requirements of XML-based protocols.</p></div><div class="div3">
<h4><a id="ws-for-enterprise-justi" name="ws-for-enterprise-justi"></a>3.5.3 Justification</h4><p>There are some important economic reasons that support the use of Web services as an
                alternative to existing technologies for building distributed systems. First,
                preliminary results show more powerful hardware is needed to re-deploy existing
                systems using Web services technologies given the additional processing requirements
                of an XML messaging system. Second, assuming the company in question already
                develops (or is planning to develop) Web services to communicate outside their
                firewall, there is the extra incentive in using the same set of tools and the same
                development team to build intranet applications. This reduces both software fees
                (e.g., by reusing application servers and development tools) as well as training
                costs associated with having separate development teams for each technology. Third,
                some companies that have successfully deployed CORBA-based systems, but are not
                planning on deploying Web services, may find an additional incentive to do so if a
                more efficient serialization is standardized.</p></div><div class="div3">
<h4><a id="ws-for-enterprise-ana" name="ws-for-enterprise-ana"></a>3.5.4 Analysis</h4><p>Intranet Web services differ from Internet Web services especially in the areas of
                deployment and security: deployments are easier to manage and security is typically
                defined by a single domain. The requirements for intranet systems are somewhat
                different from those for Internet systems, permitting the use of certain
                optimizations in the former which would be difficult or simply impossible to
                implement in the latter. Consequently, in many cases the degree of
                <em>coupling</em> of the systems can be adjusted if this helps in achieving the
                desired performance goals.</p><p>The main requirement for this use case is reducing XML processing time in order to
                achieve a level of performance comparable to the existing systems. Due to the
                availability of high-speed networks in these scenarios, reducing message sizes is of
                a lesser priority. It is worth pointing out that not <em>all</em> systems
                re-deployed using Web services will be unable to achieve their performance
                requirements. Therefore, this use case applies only to a subset of the
                aforementioned re-deployments.</p></div><div class="div3">
<h4><a id="ws-for-enterprise-prop" name="ws-for-enterprise-prop"></a>3.5.5 Properties</h4><div class="div4">
<h5><a id="ws-for-enterprise-must-props" name="ws-for-enterprise-must-props"></a>3.5.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-for-enterprise-should-props" name="ws-for-enterprise-should-props"></a>3.5.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-for-enterprise-nice-props" name="ws-for-enterprise-nice-props"></a>3.5.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="ws-for-enterprise-alt" name="ws-for-enterprise-alt"></a>3.5.6 Alternatives</h4><p>In some cases, it may be possible to re-design the system's interfaces to make them
                more coarse grained in order to reduce the number of messages exchanged. Although
                this is technically feasible in most cases, the costs associated with this effort
                can be prohibitive.</p></div><div class="div3">
<h4><a id="ws-for-enterprise-refs" name="ws-for-enterprise-refs"></a>3.5.7 References</h4><ol class="enumar"><li><p>
                        <a href="#FWS">[Fast Web Services]</a>
                    </p></li><li><p>
                        <a href="#SOAPPerf">[SOAP Performance]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="edocs" name="edocs"></a>3.6 Electronic Documents</h3><div class="div3">
<h4><a id="edocs-desc" name="edocs-desc"></a>3.6.1 Description</h4><p> Documents are the most basic form of recorded human communication, dating back
                thousands of years. Electronic documents are the transition of this invention to the
                online, computerized world. Books, forms, contracts, e-mails, spreadsheets, and Web
                pages are only some of the forms in which electronic documents are used. Unlike
                paper-based documents, electronic documents are not limited to static text and
                images. Electronic documents regularly contain both static content, dynamic content
                (e.g., animations, video), and interactive content (e.g., form fields). This wide
                range of content has a great affect on selecting an appropriate representation
                format and must be considered in evaluating this use case.</p><p> Documents are first created in some authoring environment. During the creation
                process the author may elect to include text, fonts, image, videos, or other
                resources which are to be rendered more than once when the document is displayed.
                For example, a company logo may appear in the header of each page of a document, but
                this should not require adding the logo to the document more than once.</p><p> In a special case of document creation, new documents are created by assembling a
                set of existing documents into a single aggregate document. For example, this may
                done to combine a basic product manual with additional documentation for optional
                product accessories into a customized manual for an individual purchaser. When
                documents are bound together in this way it may be important that the data in the
                original documents is not modified, so as to preserve signatures or other properties
                of the file, or it may be desirable to identify and eliminate duplicated resources,
                such as fonts.</p><p> After a document has been created it is usually read, in whole or in part. Documents
                are not necessarily read front to back; a particular reader may select a different
                order or read only part of a document. A reader may, for example, obtain the
                document by traversing a hyperlink which points to a specific location within the
                document. It is important that rendering a document for reading be fast, even when
                starting at an arbitrary location in this way, and even when documents are large
                (millions of pages). This implies that it must be possible to navigate to specific
                sections within a document quickly, as well as follow links to shared resources
                within the document, as mentioned above under document creation. Finally, if a
                document is being retrieved over a slow link, it may be useful to fetch portions of
                the document in the order in which they are being rendered and read (e.g., starting
                at page 700), as opposed to document order (i.e., starting at page 1).</p><p> Documents often contain information of a sensitive or proprietary nature and so can
                be secured using encryption technologies. Encrypting the document can serve either
                to keep the contents confidential, to--in conjunction with the rendering
                application--allow only certain operations ("rights") on the document, or both.
                Typically a description of any rights granted is embedded within the document itself
                when it is encrypted. It is often desirable that only portions of a document be
                encrypted so that intermediaries can access some portion of the data in the file.</p><p> Documents, and especially those used in business transactions, are often signed to
                indicate authenticity of, consent to, or agreement with the document. In electronic
                documents, this is implemented by digitally signing the document. The digital
                signature must itself be stored in the document. Multiple signatures may be applied
                to a document, each one signing those which came before it. Additional information
                is sometimes added to a document after it has been signed but without invalidating a
                signature--in the same way one can initial a correction to a paper document--but so
                that it is clear that any subsequent changes were not present when the pre-existing
                signatures were applied. In some cases signatures should apply to only part of a
                document, leaving other parts for later modification. Finally, it must be possible
                for a recipient to validate all of these signatures.</p><p> Documents are often long-lived and, during the course of their lives, used in
                different environments with varying constraints. For example, when a document is
                being published for general consumption, it might be most desirable to select an
                encoding such as XML which is widely understood. If, however, the same document is
                being transmitted between partners with known expectations a more compact format
                such as <a href="#XOP">[XOP]</a> might be preferred. Thus, a single document may sometimes be
                transformed between different encodings at different times and for different
                purposes. Such transformations should preserve the information in the document, but
                these operations cannot be expected to be compatible with encryption mechanisms used
                to secure documents.</p><p> Even when various encodings are available documents tend to push the available
                storage and bandwidth of the devices on which they are created, stored, transmitted,
                and read. In other words, as device capabilities increase, users respond by creating
                larger documents. Note that these documents rarely contain only text; they generally
                contain larger elements such as fonts and images and, increasingly, video and 3D
                models which these same enhanced devices make possible.</p><p> Electronic documents, like their paper counterparts, can be modified or re-purposed.
                In electronic documents, this typically occurs when pages, images, videos, and so
                forth are either copied out of a document to be used elsewhere or removed from a
                document to produce an altered version of that document. Again, these operations
                should be efficient: removing any one page from a one million page document should
                not take significantly longer than doing the same to a ten page document. Documents
                may also be modified by their recipients to include comments of various
                types--editors' marks, sticky notes, etc.--usually intended to communicate responses
                back to the author. These comments may be stored within the document itself; both
                adding them to and extracting them from the document should be efficient.</p><p> Finally, some documents are designed to be interactive beyond the limited
                interactions of rendering, signing, and annotating. These documents may contain form
                fields, GUI widgets such as buttons and listboxes, or other active elements, data
                islands bound to these widgets, and code, scripts, or declarative logic to validate
                input to these elements, enable or disable the elements, transmit the document,
                modify the document, interact with the rendering application, and so forth. It must
                be possible to describe and access all of these elements within the document itself.</p></div><div class="div3">
<h4><a id="edocs-dom" name="edocs-dom"></a>3.6.2 Domain &amp; Stakeholders</h4><p> Electronic documents are used extensively throughout government, business, and
                personal domains as well as in the interchange between these entities.</p></div><div class="div3">
<h4><a id="edocs-justi" name="edocs-justi"></a>3.6.3 Justification</h4><p> XML is in its roots a syntax for marking documents, and so the electronic document
                use cases seem highly relevant. Interestingly, XML has a number of shortcomings
                (discussed below) with respect to many of the requirements derived from this use
                case. Arguably, these occur because XML (and SGML) were focused largely on textual
                documents, but such documents represent a decreasing fraction of all electronic
                documents. Thus, Binary XML as a natural extension of XML to handle new document
                types, and documents containing new content, seems particularly relevant.</p></div><div class="div3">
<h4><a id="edocs-ana" name="edocs-ana"></a>3.6.4 Analysis</h4><p> Documents are almost always exchanged between two or more people, and often between
                larger entities such as corporations or governments. It is, therefore, extremely
                desirable that an electronic document format should be easily consumable by all
                parties involved. XML, as a widely accepted, implemented, and used format, fits this
                need quite well.</p><p> Unfortunately there are a number of requirements imposed by electronic documents which
                XML fails to address:</p><ul><li><p> Documents frequently contain embedded resources such as fonts, images, and
                        video which are themselves encoded in binary formats. It must be possible to
                        efficiently embed these resources in documents.</p></li><li><p> It must be possible to navigate to and render a specified location in better
                        than linear time with respect to the size of the document.</p></li><li><p> The document encoding must be efficient with respect to space, that is, it
                        must have low redundancy.</p></li><li><p> The document encoding must be efficient with respect to space, that is, it
                        must have low entropy.</p></li><li><p> In order to make updates efficient, it must be possible to update a document
                        in time proportional to the size of the update rather than the size of the document.</p></li></ul><p> There are a number of requirements which XML does address, but which are enumerated
                here as well because they would also be requirements on any Binary XML encoding:</p><ul><li><p> The format should be widely accepted, available, and implemented.</p></li><li><p>Re-usable resources may appear, or be referenced from, multiple locations
                        within the document. In order to maintain reasonable document sizes, it must
                        be possible for these resources to be used by reference, rather than by
                        duplication. </p></li><li><p> It must be possible to efficiently assemble even large documents.</p></li><li><p> It must be possible to assemble signed documents in such a way that their
                        signatures are preserved.</p></li><li><p> It must be possible for a document to contain multiple signatures, full or
                        selective, from one or more signers.</p></li><li><p> It must be possible to read a secured (encrypted) document without suffering
                        an unreasonable delay when first viewing the document, without unreasonably
                        exposing the decrypted contents of the document, and while obeying rights
                        associated with the document.</p></li><li><p> It must be possible to efficiently extract data from the document (i.e., a
                        document fragment) and without modification to the extracted data.</p></li></ul><p>Finally, the introduction of multiple formats (i.e., XML and Binary XML), implies the
                following desirable requirement:</p><ul><li><p>The conversion of a document between different encodings must preserve all
                        information in the document, including digital signatures.</p></li></ul></div><div class="div3">
<h4><a id="edocs-prop" name="edocs-prop"></a>3.6.5 Properties</h4><div class="div4">
<h5><a id="edocs-must-props" name="edocs-must-props"></a>3.6.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="edocs-should-props" name="edocs-should-props"></a>3.6.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-readable-editable">Human Readable and Editable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li></ul></div><div class="div4">
<h5><a id="edocs-nice-props" name="edocs-nice-props"></a>3.6.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="edocs-alt" name="edocs-alt"></a>3.6.6 Alternatives</h4><p>The current de facto standard for interchange of electronic documents is Adobe's
                Portable Document Format, or PDF. PDF meets all of the requirements stated here
                except that it is not based on a widely accepted, implemented, and available format,
                and so while widely deployed for document viewing is not sufficiently easy to use
                for general-purpose interchange.</p><p>Earlier formats for electronic documents, such as TIFF, DVI, RTF, AFP, and Postscript
                do not, among other shortcomings, support the full range of required document
                features, such as dynamic and interactive content.</p><p>HTML/XHTML, SVG, XSL-FO, and other XML-based formats can, in combination, provide
                coverage for most of the requirement document features. However, they fail to meet
                certain file format requirements as described under Analysis, above.</p><p>There are other proprietary formats, such as Microsoft Word and SWF, which meet many
                of the functional requirements described here but, due to their proprietary nature,
                also lack sufficiently broad-spread acceptance, implementation, and availability.</p></div><div class="div3">
<h4><a id="edocs-ref" name="edocs-ref"></a>3.6.7 References</h4><ol class="enumar"><li><p>
                        <a href="#PDF">[PDF]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="fixml" name="fixml"></a>3.7 FIXML in the Securities Industry</h3><div class="div3">
<h4><a id="fixml-desc" name="fixml-desc"></a>3.7.1 Description</h4><p>The Securities industry has cooperated to define a standard protocol and a common
                messaging language called FIX which allows real-time, vendor/platform neutral
                electronic exchange of securities transactions between financial institutions. </p><p>The original definition of FIX was as a tag-value pair format. Due to increased
                competition by the year 1999, and to better accommodate business models of emerging
                initiatives, an XML-based message format for application-layer messages called FIXML
                was devised. Even though FIXML was designed to have minimum impact on existing
                systems, in order to protect investments in traditional FIX systems and processes,
                it soon became evident that the new message size was as much as 6 times larger than
                its tag-value predecessor, a condition that precluded key participants in the
                industry to integrate FIXML into their systems. This problem, together with some
                positive findings made through experiments, spurred the discussion for size
                reduction of FIXML messages, which culminated in a new format called Transport
                Optimized FIXML (TO-FIXML) in FIXML version 4.4. TO-FIXML is essentially a
                collection of XML Schema definitions that uses name abbreviations as well as
                attributes instead of elements wherever possible to collectively reduce FIXML
                messages up to 4 times. </p></div><div class="div3">
<h4><a id="fixml-dom" name="fixml-dom"></a>3.7.2 Domain</h4><p>Securities industry engaging in capital markets such as derivatives, equity and
                fixed-income markets, where the FIX protocol is applicable and is moving towards SOA
                architectures based on FIXML. Major roles played in the industry include brokers,
                exchanges and clearing houses.</p></div><div class="div3">
<h4><a id="fixml-justi" name="fixml-justi"></a>3.7.3 Justification</h4><p>Even though TO-FIXML has been designed to minimize message sizes, some industry
                participants still consider it to be a sub-optimal solution and envisage the
                possibility of further optimization by studying binary-compatible XML formats.</p></div><div class="div3">
<h4><a id="fixml-ana" name="fixml-ana"></a>3.7.4 Analysis</h4><p>XML was the natural choice for the securities industry in light of its expandability
                and flexibility, which was required for the continuous and rapid evolution of the
                FIX protocol. There was also a demand for cross-industry interoperability given the
                broad adoption of XML by other financial industries.</p><p>XML Schema is the point of agreement for multiple parties to share a common transport
                format. However, the bloated size of the XML instances resulted in artificial
                changes to the schemas, with the sole purpose of reducing the number of bytes on the
                wire. The methods used for this purpose include the use of name abbreviations and
                the use of attributes in favor of elements wherever possible. Clearly, XML Schema is
                not the right place to tackle this problem given that the syntax verbosity is a
                property exclusive to the XML serialization. Stated differently, XML Schema is the
                point of agreement in terms of vocabulary and structure, not in terms of syntax.</p><p>Shown below are two sample FIXML order messages. The two messages carry the same
                information, yet their appearance is quite different. The first one is in FIXML
                version 4.3 format, while the second is in TO-FIXML format (FIXML version 4.4). As
                shown below, the one in TO-FIXML is much more compact than its equivalent FIXML 4.3
                message. Some items such as 'Sender' and 'TransactTime' that were elements in FIXML
                4.3 became attributes in TO-FIXML with abbreviated names 'SID' and 'TxnTm', respectively.</p><div class="exampleInner"><pre>    &lt;FIXML DTDVersion="2.0.0" FIXVersion="4.3"&gt;
      &lt;FIXMLMessage&gt;
        &lt;Header&gt;
          &lt;Sender&gt;&lt;CompID&gt;CAT&lt;/CompID&gt;&lt;/Sender&gt;
          &lt;Target&gt;&lt;CompID&gt;DOG&lt;/CompID&gt;&lt;/Target&gt;
          &lt;SendingTime&gt;2004-10-13T12:00:00&lt;/SendingTime&gt;
        &lt;/Header&gt;
        &lt;Order&gt;
          &lt;ClOrdID&gt;123456&lt;/ClOrdID&gt;
          &lt;Instrument&gt;
            &lt;Symbol&gt;XYZ&lt;/Symbol&gt;
          &lt;/Instrument&gt;
          &lt;Side Value="1"/&gt;
          &lt;TransactTime&gt;2004-10-13T12:00:00&lt;/TransactTime&gt;
          &lt;OrderQtyData&gt;
            &lt;OrderQty&gt;100&lt;/OrderQty&gt;
          &lt;/OrderQtyData&gt;
          &lt;OrdType Value="2"/&gt;
          &lt;Price&gt;85.00&lt;/Price&gt;
        &lt;/Order&gt;
      &lt;/FIXMLMessage&gt;
    &lt;/FIXML&gt;

    &lt;FIXML v="4.4" r="20030618" s="20031218"&gt;
      &lt;Order ID="123456" Side="1"
             TxnTm="2004-10-13T12:00:00" Typ="2" Px="85.00"&gt;
        &lt;Hdr SID="CAT" TID="DOG"
             Snt="2004-10-13T12:00:00"/&gt;
        &lt;Instrmt Sym="XYZ"/&gt;
        &lt;OrdQty Qty="100"/&gt;
      &lt;/Order&gt;
    &lt;/FIXML&gt;</pre></div></div><div class="div3">
<h4><a id="fixml-prop" name="fixml-prop"></a>3.7.5 Properties</h4><div class="div4">
<h5><a id="fixml-must-props" name="fixml-must-props"></a>3.7.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li></ul></div><div class="div4">
<h5><a id="fixml-should-props" name="fixml-should-props"></a>3.7.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-readable-editable">Human Readable and Editable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="fixml-nice-props" name="fixml-nice-props"></a>3.7.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="fixml-alt" name="fixml-alt"></a>3.7.6 Alternatives</h4><p>Message size alone can be substantially reduced by standard compression methods.
                However, there is a study that shows compression of FIXML instances increases round
                trip time over 10 Mbps networks. Compression may be useful for considerably slower
                networks, which is not the typical case in FIXML. The same study also suggests that
                marshalling/unmarshalling costs do not seem to make tangible performance differences
                in those data sets typically seen in FIX scenarios.</p></div><div class="div3">
<h4><a id="fixml-refs" name="fixml-refs"></a>3.7.7 References</h4><ol class="enumar"><li><p>
                        <a href="#SOAP-Trading">[SOAP in Real-Time Trading Systems]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="xml-docs-mobile" name="xml-docs-mobile"></a>3.8 Multimedia XML Documents for Mobile Handsets</h3><div class="div3">
<h4><a id="xml-docs-mobile-desc" name="xml-docs-mobile-desc"></a>3.8.1 Description</h4><p>The Service Enabler standard for mobile handsets benefits from extensive use of
                XML-based technologies for interoperability. For example, SMIL, SVG and XHTML are
                used as document formats for mobile content services such as:</p><ul><li><p>Multimedia Messaging Services (MMS): MMS in 3G consists of multiple XML
                        documents, such as SMIL, SVG and XHTML. The handset is required to parse and
                        render multi-namespaced XML documents. </p></li><li><p>Map Services: Map data delivered to a handset is split into multiple chunks
                        based on region and level of detail; handsets retrieve additional chunks in
                        response to user zooms and scrolls. Additional data, such as restaurant
                        information supplied by other content providers, can also be overlayed on top.</p></li></ul><p>XML documents in these services are considerably large. For instance, the map data
                represented in SVG could be 100KB or more. Rich content MMS could also be very
                large. Even on today's high-end handsets with 120 MHz 32-bit RISC processors,
                parsing a raw 100 KB XML document takes approximately 10 seconds.</p></div><div class="div3">
<h4><a id="xml-docs-mobile-dom" name="xml-docs-mobile-dom"></a>3.8.2 Domain</h4><p>This use case applies to multimedia services for the mobile handsets.</p></div><div class="div3">
<h4><a id="xml-docs-mobile-justi" name="xml-docs-mobile-justi"></a>3.8.3 Justification</h4><p>XML is required for maximum interoperability. In fact, XML technology is already
                widely adopted in the mobile services space. As this area requires a solution for
                narrow band and limited footprint devices, the importance of this use case should be
                considered high.</p></div><div class="div3">
<h4><a id="xml-docs-mobile-ana" name="xml-docs-mobile-ana"></a>3.8.4 Analysis</h4><p>This use case requires the following capabilities of XML to be preserved:</p><ul><li><p>Interoperability</p></li><li><p>Multiple namespace support</p></li><li><p>In-memory, random access using a DOM</p></li></ul><p>Interoperability is mandatory as the same documents must be shared among different
                handsets. Moreover, for map services, the layering of multiple source map data
                requires interoperability among the providers. Support for multiple namespaces is a
                must in order to deliver multi-format messages (e.g. HTML + SVG) to the devices. DOM
                access is required to support ECMA scripting as well as for efficient rendering of
                formats such as SVG.</p><p>The requirements not satisfied by current XML solutions that must be addressed are:</p><ul><li><p>Efficient transmission of XML documents by reducing their sizes</p></li><li><p>Efficient access to a DOM, i.e. efficient DOM parsing</p></li></ul></div><div class="div3">
<h4><a id="xml-docs-mobile-prop" name="xml-docs-mobile-prop"></a>3.8.5 Properties</h4><div class="div4">
<h5><a id="xml-docs-mobile-must-props" name="xml-docs-mobile-must-props"></a>3.8.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-docs-mobile-should-props" name="xml-docs-mobile-should-props"></a>3.8.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-docs-mobile-nice-props" name="xml-docs-mobile-nice-props"></a>3.8.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="xml-docs-mobile-alt" name="xml-docs-mobile-alt"></a>3.8.6 Alternatives</h4><p>The WAP Forum defined a WAP Binary XML format as an alternative serialization for
                XML. However, this format has a number of shortcomings, the biggest of which is the
                lack of support for multi-namespace documents due to the use of a "single dimension"
                system of 6-bit tags.</p></div><div class="div3">
<h4><a id="xml-docs-mobile-refs" name="xml-docs-mobile-refs"></a>3.8.7 References</h4><ol class="enumar"><li><p>
                        <a href="#Mobile-SVG">[Mobile SVG]</a>
                    </p><p>
                        <a href="#Mobile-XHTML">[Mobile XHTML]</a>
                    </p><p>
                        <a href="#SMIL">[SMIL]</a>
                    </p><p>
                        <a href="#G-XML">[G-XML]</a>
                    </p><p>
                        <a href="#MMS">[MMS]</a>
                    </p><p>
                        <a href="#WAP-WBXML">[WAP WBXML]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="non-op" name="non-op"></a>3.9 Intra/Inter Business Communication</h3><div class="div3">
<h4><a id="non-op-desc" name="non-op-desc"></a>3.9.1 Description</h4><p> A large business communicates via XML with a number of remote businesses, some of
                which can be small business partners. These remote or small businesses often have
                access only to slow transmission lines and have limited hardware and technical
                expertise. The large business cannot expect the smaller partners to upgrade often or
                to use expensive technology. The primary illustrations of this use case come from
                the energy, banking, and retail industries.</p><p> In the energy industry, the major upstream (exploration and production) operations
                of oil companies are largely in developing countries and it is a common problem to
                have very slow and perhaps unreliable communications between the main office and
                remote sites. It's not that the oil companies don't know how to set up a satellite
                feed, it's that they are often required by the local governments to use the
                communication facilities provided by that government, and these communications can
                be technically low-end and expensive. So the common problem is one where there is
                plenty of processing power and bandwidth at both central and remote sites, but the
                communication between the two is slow.</p><p> Although many scenarios illustrating this problem have to do with upstream
                operations, this specific example will be from downstream (refining and marketing).
                It involves transmission of Point of Sale (POS) information back and forth between
                back office systems and remote sites. The data flowing to the remote sites includes
                "incremental price book" for dry goods and wet stock, currency exchange rates,
                promotion codes/rates/groups and so on. The data coming back includes raw sales
                transactions data, tank data, etc. One might have 1000 transactions per day per site
                with an average file size of 3 KB, for a total size of 3 Megs typically broken up
                into 12 documents (transmittal every 2 hours, referred to as "trickle feed"). Each
                document would then average 250 KB.</p><p> Currently the scope is for many thousands of sites connected to several regional
                back-office hubs. Connectivity ranges from VSAT to 32 kbps analog connections. The
                32 kbps connections would only communicate once a day. This downstream situation
                includes a factor which is not common in upstream operations. Not only are there
                communication limitations, but in this case some of the remote sites also have
                limited processing capabilities because they are small businesses with limited resources.</p><p> In the banking industry, there is typically a main data center(s) and several
                connected branch offices, ATM machines, and business partners. The main data center
                may have the latest in technology, however, the connected branch offices, ATM
                machines and partners are often without access to high speed connections and
                powerful hardware. Communicating between the various entities can be accomplished
                with XML Web Services, however, the size and speed issues of XML are troublesome for
                those without access to high speed lines and/or powerful machines.</p><p> These same issues affect the retail industry as stores often are connected to the
                main data center over less than optimal links. In addition, the retail store needs
                to perform real-time purchase/return transactions that require round-trip
                communications with the main center.</p></div><div class="div3">
<h4><a id="non-op-dom" name="non-op-dom"></a>3.9.2 Domain &amp; Stakeholders</h4><p> Retailing operations of large companies, particularly those where the actual retail
                outlets are SME's (Small to Medium Size Enterprises) and large companies with
                various small business partners and/or branch offices. The belief is that the
                experience gained in this situation is likely to be directly applicable to a number
                of other scenarios in the industry.</p><p> Note that the players in this use case have rather different situations and needs.
                The large company has significant sunk investment in complex back-office systems,
                lots of hardware and a team of IT professionals. The objective here is to integrate
                the solution into a complex, high-tech environment. The SME, partner, or branch
                office, may have very limited hardware and technical resources and is probably
                highly motivated toward a simple, low-cost solution, preferably one that
                plugs-and-plays off the shelf without extensive configuration or integration. This
                creates a tension between flexible and capable on one hand and simple and cheap on
                the other.</p></div><div class="div3">
<h4><a id="non-op-justi" name="non-op-justi"></a>3.9.3 Justification</h4><p> The need for compression is clear, but it is not so clear that a binary XML standard
                is required. One solution is to use a standard compression technique, like GZIP, on
                the XML and transmit it that way. This may not be an effective solution for all
                cases. One problem is that the SME, branch office, business partner, and/or ATM
                machine location might not have enough computing power to make the GZIP solution
                attractive. In addition, the data center, which may have a lot of computing power,
                may not want to absorb the increased CPU load that a GZIP solution requires. A
                binary solution that compressed the message and did not increase the CPU load could
                be beneficial in these cases. </p></div><div class="div3">
<h4><a id="non-op-ana" name="non-op-ana"></a>3.9.4 Analysis</h4><p> XML&rsquo;s verboseness and size detract from its use in these scenarios. An alternate
                encoding would be required to be more compact than the original XML encoding with no
                loss of data. This would enable the branch office and other entities that operate
                over less than optimal transmission lines to take better advantage of XML and Web
                Services. </p></div><div class="div3">
<h4><a id="non-op-prop" name="non-op-prop"></a>3.9.5 Properties</h4><div class="div4">
<h5><a id="non-op-must-props" name="non-op-must-props"></a>3.9.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="non-op-should-props" name="non-op-should-props"></a>3.9.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li></ul></div><div class="div4">
<h5><a id="non-op-nice-props" name="non-op-nice-props"></a>3.9.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="non-op-alt" name="non-op-alt"></a>3.9.6 Alternatives</h4><p> This is a case where there is a need to compress entire data files, which are
                composed of a bunch of tags with relatively short data fields. That is, no huge
                arrays of floating point numbers causing special problems. Also note that the energy
                industry expects no particular problem with processing on either end, just the
                transmission, so the overhead of using compression algorithms is not a problem.</p><p> The energy industry currently plans to use native VSAT compression and probably one
                of many standard compression algorithms like ZIP for other transmission mechanisms.
                Initial tests with freeware ZIP compression software yielded a compression of 39:1,
                which is plenty. One problem that did occur, however, on small machines such as
                might be used by a small business, is that the compression algorithm may need to
                read the entire document into memory and work on it globally. On small machines this
                can cause paging and the resulting performance difficulties can be painful. Some
                sort of compression algorithm that works in a streaming mode or on "chunks" of data
                would obviously be preferable in these cases.</p><p> There are cases, however, where the SME is unwilling to use the CPU required by the
                compression. This has been encountered in cases where the small business has a
                computer, perhaps a mainframe, that is overburdened by other routine tasks. In this
                case binary serialization may be an attractive alternative assuming it can be done
                without extra CPU cycles.</p><p> The idea is that if one is going to have to parse the XML anyway (which may or may
                not be the case, depending on the business process), the CPU required to do that
                parsing is a "sunk cost". Once parsed, a binary serialization of the XML will
                probably be smaller than the usual text serialization because the tags are not
                repeated in text and some of the data fields (e.g. some numbers) may be smaller in
                their binary representation. For typical business documents one might expect a
                reduction on the order of a factor of two from binary serialization. This moderate
                reduction in file size may hit the "sweet spot" in cases where CPU is a big problem
                and file size a moderate concern. It seems likely, however, that this scenario will
                be less common than the case where reasonable computational capability is available
                in the small business and the slow transmission lines are the big problem. In these
                cases, as documented above, compression via standard techniques of the conventional
                text serialization of XML is probably the preferred solution.</p><p> Note that in both cases the needs of both small and large businesses can potentially
                be met. The large business gets the XML document it needs in order to integrate with
                its complex systems. The small business either uses inexpensive compression software
                or the parser outputs the binary serialization directly, so the complexity of the
                solution from their viewpoint is minimized.</p></div><div class="div3">
<h4><a id="non-op-refs" name="non-op-refs"></a>3.9.7 References</h4><ol class="enumar"><li><p>
                        <a href="#ACORD">[ACORD]</a>
                    </p></li><li><p>
                        <a href="#HL7">[HL7]</a>
                    </p></li><li><p>
                        <a href="#RosettaNet">[RosettaNet]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="xmpp" name="xmpp"></a>3.10 XMPP Instant Messaging Compression</h3><div class="div3">
<h4><a id="xmpp-desc" name="xmpp-desc"></a>3.10.1 Description</h4><p>
               The Extensible Messaging and Presence Protocol (XMPP) <a href="#RFC3920">[RFC 3920]</a> <a href="#RFC3921">[RFC 3921]</a> formalizes the core Jabber instant messaging and presence protocols <a href="#Jabber">[Jabber]</a> for the IETF. In addition, the Jabber Software Foundation develops extensions to XMPP, known as Jabber Enhancement Proposals <a href="#Jabber-Enhancements">[JEPs]</a>. These protocols use XML as an underlying mechanism for instant messaging, group chat, presence, and other near-real-time functionality such as publish-subscribe and alternative bindings for SOAP and XML-RPC. XMPP is a streaming XML protocol and does not deal directly with XML documents. However, an XMPP session is effectively an XML document that is built up over time as the participants exchange XML "stanzas" (XML document fragments) during an open-ended conversation. The architecture is client-server; clients authenticate to a server, and servers authenticate with each other. Messages sent to a user's ID on a server are forwarded to the client. There is a large and active installed base of XMPP/Jabber clients and servers.
			</p><p>XML is used in XMPP because it offers flexibility, ease of debugging, and
                extensibility. New XML semantics can be added to the protocol, and it is simple to
                examine the contents of messages and determine their meaning. In a very general
                sense, it can be said that XMPP acts as a sort of router for XML messages.</p></div><div class="div3">
<h4><a id="xmpp-dom" name="xmpp-dom"></a>3.10.2 Domain &amp; Stakeholders</h4><p>
              Instant messaging and chat applications, presence servers, publish-subscribe systems (e.g., content syndication), SOAP and XML-RPC exchange.
			</p></div><div class="div3">
<h4><a id="xmpp-ana" name="xmpp-ana"></a>3.10.3 Analysis</h4><p>
               XML may require more computational power to parse than equivalent binary protocols used in other instant messaging and chat protocols. When an XML stanza is received at an XMPP server it is typically routed to an intended recipient other than the server itself (e.g., another server or a client connected to the server). Routing requires parsing enough of the XML stanza to make a routing decision. Typically only part of the XML stanza at a well-known location needs to be examined by the server, and the message payload remains opaque to the server. Therefore, being able to quickly retrieve only the information needed is a significant benefit.
			</p><p>
               The traffic profile is that of a great number of small XML messages that must be parsed quickly. Because a single server may support up to hundreds of thousands of concurrent users in high-traffic environments, parsing speed may become a limiting factor in the number of users a server can support.
			</p><p>
               In order to satisfy this use case, parsing the data required to make a routing decision must be faster using a binary format than using a text XML format.
			</p><p>
               When XMPP data is sent over bandwidth-limited links, it may be helpful for the XML stanzas being exchanged to be more compact than is possible using the text XML format. An XMPP server being accessed across a bandwidth-limited link using uncompressed XML will run out of bandwidth faster than a server using a compact binary format.
			</p><p>
              An XMPP server often sends out slightly modified messages to many people, for example when a client's presence status changes (notifications must be sent to all entities on that person's contact list). In this situation nearly identical messages that differ only in a few respects, such as address, should be sent. The ability to efficiently update an XML message with new data would be useful in this situation.
			</p><p>Any server or client that uses an XML binary standard must maintain the original XML
                format in order to preserve compatibility with the XMPP RFC standards. Thus, any
                binary format must be transcodable back to an equivalent textual XML format.</p></div><div class="div3">
<h4><a id="xmpp-justi" name="xmpp-justi"></a>3.10.4 Justification</h4><p>When the server receives an XML stanza it must parse the document and decide what
                clients or servers should receive the message. Also, across bandwidth-limited links,
                XML is more verbose than binary formats. Binary formats have the potential to
                improve these aspects of XMPP.</p></div><div class="div3">
<h4><a id="xmpp-prop" name="xmpp-prop"></a>3.10.5 Properties</h4><div class="div4">
<h5><a id="xmpp-must-props" name="xmpp-must-props"></a>3.10.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xmpp-should-props" name="xmpp-should-props"></a>3.10.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#localized-changes">Localized Changes</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xmpp-nice-props" name="xmpp-nice-props"></a>3.10.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-readable-editable">Human Readable and Editable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="xmpp-alt" name="xmpp-alt"></a>3.10.6 Alternatives</h4><p>
               The Jabber Software Foundation has addressed compact representations of XML streams through an experimental add-on extension to XMPP that allows the streams to negotiate compression using zlib <a href="#Jabber-Stream-Compression">[Jabber Stream Compression]</a>. The XMPP protocol may also use Transport Layer Security (TLS), which can optionally include zlib compression of encrypted traffic. Using zlib places a somewhat larger computational load on the server above and beyond the parsing duties it must perform. Again, with large numbers of subscribed users or heavy traffic the computational load may become a limiting factor. A compact binary format may be smaller than a zlib compressed stanza, while retaining high processing speed. The Jabber Stream Compression protocol defined in JEP-0138 can easily be modified or extended to cover alternative formats, such as a binary XML format or a binary format that is also compressed.
			</p></div><div class="div3">
<h4><a id="xmpp-refs" name="xmpp-refs"></a>3.10.7 References</h4><ol class="enumar"><li><p>
                        <a href="#RFC3920">[RFC 3920]</a>
                    </p></li><li><p>
                        <a href="#RFC3921">[RFC 3921]</a>
                    </p></li><li><p>
                        <a href="#RFC3922">[RFC 3922]</a>
                    </p></li><li><p>
                        <a href="#RFC3923">[RFC 3923]</a>
                    </p></li><li><p>
                        <a href="#Jabber">[Jabber]</a>
                    </p></li><li><p>
                        <a href="#Jabber-Enhancements">[JEPs]</a>
                    </p></li><li><p>
                        <a href="#Jabber-Stream-Compression">[Jabber Stream Compression]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="xml-docs-persistent-store" name="xml-docs-persistent-store"></a>3.11 XML Documents in Persistent Store</h3><div class="div3">
<h4><a id="xml-docs-persistent-store-desc" name="xml-docs-persistent-store-desc"></a>3.11.1 Description</h4><p>Documents are stored in the persistent store. They are searched and updated. For its
                support, beside compression, it requires multiple techniques such as selective
                indexing, data access using groups of pre-compiled XPath expressions, etc. The size
                of documents varies depending on application domains and particular customer needs
                within those domains. The persistent store management system has to deal with many
                scenarios, from small documents to very, very large ones. The ratio of the space
                taken by actual data and structural information (tags, attribute names, and
                namespace definitions) also varies very significantly.</p><p>When documents are stored in the persistent store or retrieved from it different
                kinds of transformations and processing can be requested by different applications.
                Thus, the persistent store management system has to deal with various tools
                interfacing to it. The ways documents will be manipulated are never known in advance.</p><p>Since documents can be large or very large they have to be processed incrementally in
                many cases. The incremental processing can be of two types: stream like or lazy DOM
                like. The stream like processing requires documents to be transferred by pieces
                where each piece can be fully processed without information in the following pieces.
                The lazy DOM processing allows client applications to request only a part, subtree
                (full or partial), of the document.</p><p>Schema aware documents present multiple opportunities for various optimizations.
                These optimizations affect different aspects of the alternative XML serialization:
                compactness, efficiency of random access, efficiency of sequential processing, etc.
                The alternative XML serialization format must include means to apply these
                optimizations to the representation of XML documents. At the same time it should
                allow schema aware documents to be represented, on request, as non-schema aware
                documents. </p><p>Handling schemas in the persistent store has certain properties that are not
                necessarily present in other use cases. The most important one is the need to
                support schema evolutions. Schema evolutions include additions of new elements and
                attributes, modifications by extension of simple data types, etc. In this respect,
                the forward compatibility of the alternative XML serialization format is very
                important for persistently stored documents. </p><p>There are a couple of important and interesting aspects that need more discussion.
                One of them is versioning. There are two different kinds of versioning: versioning
                of schemas for schema aware documents and versioning of documents (in the course of
                different modifications made to the document) for all XML documents. Both kinds of
                versioning present technical and usability challenges.</p><p>The XQuery Data Model provides an abstract representation of one or more XML
                documents or document fragments. The data model is based on the notion of a
                sequence. A sequence is an ordered collection of zero or more items. An item may be
                a node (document, element, attribute, namespace, text, processing-instruction or
                comment) or an atomic value. The input and output of XQuery are defined in terms of
                the XQuery Data Model. Because of this, the efficient handling of XQuery Data Model
                instances, when storing, retrieving, or searching, is very important. While an XML
                level serialization of XQuery Data Model instances is defined, it is not sufficient
                for applying an alternative XML serialization to XQuery Data Model instances. Thus
                it is important that an alternative XML serialization is rich enough to handle not
                only the XML serialization but also the XQuery Data Model serialization.</p></div><div class="div3">
<h4><a id="xml-docs-persistent-store-dom" name="xml-docs-persistent-store-dom"></a>3.11.2 Domain &amp; Stakeholders</h4><p>Stakeholders are all providers of persistent store management systems and all
                providers of applications using and relying on persistent store management systems.</p></div><div class="div3">
<h4><a id="xml-docs-persistent-store-justi" name="xml-docs-persistent-store-justi"></a>3.11.3 Justification</h4><p>Persistent store technologies are widely and globally used. XML documents have been
                stored (and queried, and manipulated) in persistent stores for some number of years.
                The use of XML capable persistent stores is rapidly growing. And nobody expects any
                decline in this process. </p><p>The efficiency of XML handling in the persistent store is becoming critically
                important. The experience of persistent store management system providers shows that
                the use of alternative XML serializations of documents significantly improves
                performance, both size wise and processing efficiency wise.</p><p>A standard for alternative XML serialization is important for several reasons.
                Persistent stores interoperate with multiple software components (application
                servers, various client applications, mobile devices, etc.) produced by multiple
                vendors. Experience shows that conversions between multiple proprietary formats can
                be quite expensive. In addition, proprietary formats tend to change rapidly. This
                increases development costs. Also, handling of patent related issues is not usually
                helpful in delivering products on time. </p></div><div class="div3">
<h4><a id="xml-docs-persistent-store-ana" name="xml-docs-persistent-store-ana"></a>3.11.4 Analysis</h4><p>While persistent store vendors usually handle several data representations, the
                necessity to handle XML documents is a given. It is not a question whether
                applications using persistent stores can use other data representations or not. It
                is the reality of persistent store customers using XML in more and more
                applications. The use of XML in the persistent store, as described above, leads to
                following requirements: </p><ul><li><p>Efficiently support the alternative XML serialization format for schema aware
                        documents and be friendly to schema evolutions that maintain the validity of documents</p></li><li><p>Efficiently support certain operations in the persistent store and in the
                        memory. These operations should include querying, updating, indexing, access
                        to fragments, and fragment extraction.</p></li><li><p>Efficiently support XML schema datatypes. Transferring data in native binary
                        format is typically more compact. For example, xsd:hexBinary data
                        represented as binary bytes is half the size of the corresponding textual
                        hexadecimal representation.</p></li><li><p>Efficiently support incremental processing where both partial loading and
                        partial transmission are included.</p></li><li><p>The use of an alternative XML serialization should require minimal changes to
                        existing application layers (only the underlying layers need to be changed).
                        The impact to developers should be minimal. </p></li><li><p>Efficiently support multiple ordering. It should be possible to process
                        documents both sequentially and based on subtrees.</p></li></ul></div><div class="div3">
<h4><a id="xml-docs-persistent-store-prop" name="xml-docs-persistent-store-prop"></a>3.11.5 Properties</h4><div class="div4">
<h5><a id="xml-docs-persistent-store-must-props" name="xml-docs-persistent-store-must-props"></a>3.11.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-docs-persistent-store-should-props" name="xml-docs-persistent-store-should-props"></a>3.11.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-docs-persistent-store-nice-props" name="xml-docs-persistent-store-nice-props"></a>3.11.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#localized-changes">Localized Changes</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="xml-docs-persistent-store-alt" name="xml-docs-persistent-store-alt"></a>3.11.6 Alternatives</h4><p>As it was mentioned in the justification section, persistent store vendors are
                required to handle XML to support multiple customer applications using XML. It would
                be absolutely inappropriate for persistent store vendors to offer their customers
                another format instead of XML.</p></div><div class="div3">
<h4><a id="xml-docs-persistent-store-refs" name="xml-docs-persistent-store-refs"></a>3.11.7 References</h4><p>None</p></div></div><div class="div2">
<h3><a id="trans-rule-engines" name="trans-rule-engines"></a>3.12 Business and Knowledge Processing</h3><div class="div3">
<h4><a id="trans-rule-engines-desc" name="trans-rule-engines-desc"></a>3.12.1 Description</h4><p>Large XML documents flow through a business process. During the flow of a document,
                various business processes perform different, disjoint tasks. In addition, each
                distinct business process may only require portions of the entire XML document to
                complete their task. For example, a purchase order document may contain various
                customer information, shipping information, payment and billing information, etc. A
                business process is then defined where this document is passed to various entities,
                some being serviced by outside vendors, to approve and fill the purchase order.
                Another example is a business workflow scenario where XML documents are shared
                between business partners that contain the relevant workflow information.</p><p>These business processes vary greatly in complexity. One successful strategy to
                implementation and maintenance of complex applications is the concentration of
                business rules and business logic in an engine or subsystem of some kind. This
                subsystem is referenced in one or more ways by other parts of an application while
                supporting the architectural principle of non-redundant implementation of changing
                and evolving business aspects. These applications include web-based transactional
                applications implemented as one or more tiers or component layers which can be
                distributed in more than one thread, process, or server system. The thread of
                execution of an application for a specific user is usually represented by a
                "context" which is maintained for the entire user "session". Distributed application
                clusters frequently employ methods for distribution of session context data for load
                balancing and failure recovery. This means that the data that represents a session
                needs to be serialized and copied to another server or to a database on every transaction.</p><p>Business rules may be simple validation descriptions and global variable settings or
                they may consist of complex business logic or declarative logic programming. Logic
                and other intelligent programming can consist of expert system production rules,
                constraint languages, ontology processing, and the integration of multiple
                dissimilar processing engines. The key considerations are the efficient
                representation, exchange, maintenance, and evolution of data and knowledge. Often, a
                knowledge base references or is created from a large template and activity in the
                application produces many distributed incremental changes to represent state and
                acquired knowledge. Many standards and research efforts are layered on the
                representation of entities, relationships, and attributes in RDF and related
                methods. Optimization for this body of work would be very beneficial to this use case.</p><p>The representation of knowledge is a difficult problem to solve generally. It is
                however important to strive in this direction as a major technique in complex
                applications is the combination of engines that use different methods but
                cooperatively work with common data. Representation of knowledge can differ
                qualitatively from simple data because of the maintenance of meta-data such as
                "unknown" status, probability, history, and representation of what rules have
                changed, could change, or are dependent on a particular 'fact'. The alternation of
                activation of different knowledge or other application modules requires that all or
                part of the current, updated, session state be made available to those modules. This
                means there would be frequent interchange of large amounts of changing data,
                optionally represented as many small changes to a large template, between separately
                developed modules that need to access the same data in a standard fashion.</p><p>A specific example of this use case is of a web insurance or loan application. These
                kinds of applications are typically hosted on distributed web application clusters.
                Each processing step, usually a web form submission, involves reception by a web
                server, processing by an application agent, transmission via queues or web services
                to an application engine, and processing through many tiers of applications,
                servers, and communication links.</p><p>Application data in these kinds of applications will involve complex relationships
                and involve complex updates. The organization of data is very likely to be different
                from the multiple relationships between data elements which leads to a need to
                efficiently express arbitrary data structures. This need, along with the need to be
                able to efficiently update data objects while also supporting delta layers, results
                in a requirement to support explicit pointers that are automatically managed in the
                format. These pointers, which can be considered sticky virtual pointers, need to be
                able to be created and maintained within a format instance and have a fixed
                reference convention. Pointers need to be dereferenced about as quickly as
                referencing data items via direct paths. The pointers also need to be able to be
                represented as element or attribute values both internal and external to a format instance.</p></div><div class="div3">
<h4><a id="trans-rule-engines-dom" name="trans-rule-engines-dom"></a>3.12.2 Domain &amp; Stakeholders</h4><p>This Use Case pertains to small, medium, and large businesses that utilize XML to
                support intra and inter business process workflow. An appropriate domain for this
                use case is users of complex applications, especially web, n-tier, or component
                based architectures with distributed processing. This use case is particularly
                suited for knowledge processing systems that include multiple processing subsystems.
                Important emerging work related to this use case include the Service Oriented
                Architecture (SOA), Web Services (WS), and Business Process Execution Language
                (BPEL) related activities.</p></div><div class="div3">
<h4><a id="trans-rule-engines-justi" name="trans-rule-engines-justi"></a>3.12.3 Justification</h4><p>Business processes often utilize a workflow where each step in the process only needs
                and processes certain subsets of the entire document. This results in the different
                steps in the business process performing disjoint tasks on random parts of the
                overall document. These disjoint tasks, since they are only processing a subset of
                the document, do not require the entire schema to perform their task.</p><p>Even though the entire document is not required at each step in the business process,
                the entire document is passed each time and, with current methods, fully parsed and
                processed. In addition, each business process requires a distinct and disjoint
                subset of the entire document to perform its task.</p><p> Existing methods, including data binding methods of rule engines, methods of
                distributing and replicating context, and communication models fall far short of
                possible efficiency levels. Lack of rich data format standardization with any
                efficiency is holding back intelligent component integration in production systems.</p></div><div class="div3">
<h4><a id="trans-rule-engines-ana" name="trans-rule-engines-ana"></a>3.12.4 Analysis</h4><p>The document passed to each entity can be large, meaning that large amounts of
                potentially unused data are passed to each endpoint. GZIP may be an option, however
                you would pay for the zip and unzip at each endpoint, potentially negating its
                benefits. In addition, each endpoint may require random access into the document. If
                the document was compressed with GZIP, it would make this type of access impossible
                without first uncompressing it.</p><p>To avoid the potential zip and unzip problem and the bandwidth problem, a binary
                encoding that represented the data in a more compact fashion could be used. The
                encoding would also need to allow each endpoint to randomly access and randomly
                update a subset of the entire original document.</p><p>In addition, the document can be modified along the way. This requires that each
                endpoint have a way to quickly modify a part of the document, then send it to the
                next step in the workflow process. Modifying the document in place is desirable
                because creating a DOM, making the change, and writing it back out would be too
                costly. To support a much wider variety of processing and data structure needs, an
                ability to support direct, maintained, non-computed pointers is needed.</p><p>In some cases, the requirements include that the alternate form of the data be more
                compact than the original XML. In other cases, processing speed improvement is
                paramount and compactness is a nice-to-have feature. The more compact form must be
                lossless. This means the alternate form can be converted back into the original XML
                with no differences. In addition, the creation of the alternate form and conversion
                back to XML must be efficient such that the entire business process does not take
                more time than it did with XML. Furthermore, the alternate encoding must allow for
                efficient random access and random update into the document such that the entire
                document does not have to be processed only to access a small subset contained at
                some specified location.</p></div><div class="div3">
<h4><a id="trans-rule-engines-prop" name="trans-rule-engines-prop"></a>3.12.5 Properties</h4><div class="div4">
<h5><a id="trans-rule-engines-must-props" name="trans-rule-engines-must-props"></a>3.12.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="trans-rule-engines-should-props" name="trans-rule-engines-should-props"></a>3.12.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#localized-changes">Localized Changes</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li></ul></div><div class="div4">
<h5><a id="trans-rule-engines-nice-props" name="trans-rule-engines-nice-props"></a>3.12.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#single-conformance-class">Single Conformance Class</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-readable-editable">Human Readable and Editable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="trans-rule-engines-alt" name="trans-rule-engines-alt"></a>3.12.6 Alternatives</h4><p>Passing the XML document in its uncompressed or gzipped compressed form are two
                options. Both have drawbacks. Passing the uncompressed document can clog up the
                network whereas passing the gzipped document can alleviate the bandwidth concerns,
                but be too costly to compress and decompress at each intermediary. An efficient
                binary encoding could mitigate the bandwidth issues while at the same time avoiding
                the compress/decompress steps at each intermediary.</p></div><div class="div3">
<h4><a id="trans-rule-engines-refs" name="trans-rule-engines-refs"></a>3.12.7 References</h4><ul><li><p>
                        <a href="#">[OASIS-WS-Business-Process-Execution]</a>
                    </p></li></ul></div></div><div class="div2">
<h3><a id="xml-content-based-routing" name="xml-content-based-routing"></a>3.13 XML Content-based Routing and Publish Subscribe</h3><div class="div3">
<h4><a id="xml-content-based-desc" name="xml-content-based-desc"></a>3.13.1 Description</h4><p>The ability to perform full XML message content-inspection and decision-making based
                on rules applied to the content is a requirement for a wide array of message
                processing systems. Routing, firewall (which is a filtering router), auditing
                gateway (a router that records), a trusted gateway (a firewall that strongly
                implements security policy), and the rich, high-level communications model that
                underlies IM/Presence (a router with sessions, virtualized endpoints, identity
                management, login, high level point to point and pubsub communication all at once)
                are all related by a number of requirements and similar operations. One strong part
                of the essence of presence/IM is that it relies on pub/sub of presence information.</p><p>Some of these routers and routers+ simply inspect messages, possibly just a header or possibly deeper, before sending them to their new destination. More simple types of routing include channel-based where a named channel is established by participants and topic-based where certain keywords are used to make decisions. These types of routing situations may require less raw processing performance than those requiring deep content inspection but their requirements still drive network infrastructure beyond current capacity and cost. Even very simple pure routing situations like NAT/PAT, modify, repackage, or otherwise update messages, requiring extremely efficient XML processing. Header-based routing as described in <a href="#WS-Routing-bib">[WS-Routing]</a> is another form of lighter routing. This form of routing is described in <a href="#ws-routing"><b>3.14 Web Services Routing</b></a>. We note that the concept of header may be problematic. With XML, it often simply means earlier XML ranges or subtrees rather than going deeper. If a reasonably opaque payload is used, the concept of header becomes more concrete, but that subset is not a relevant distinction for most XML messaging systems.</p><p>Layer 7 application-oriented routing devices and content publish subscribe systems
                are currently in use in the financial sector for performance-critical applications
                such as trade routing, where transactions may be routed from the front office to the
                back office, to brokers, and to exchanges. Routing or subscription criteria may be
                based on information in XML messages such as trade, client, task or ticket type, for
                example. Another application example is the dissemination of data services by mobile
                carriers based on granular subscriptions by a mobile user. In general, content-based
                routing and publish subscribe are extremely useful paradigms for all kinds of XML
                message dissemination and are relevant for Web Services, distributed computing,
                instant messaging, tactical military operations, government services, homeland
                security, and many types of online publishing. XML-based routing and publish
                subscribe as filtering technologies can be critical to reducing bandwidth
                utilization on LANs as well as WANs.</p></div><div class="div3">
<h4><a id="xml-content-based-dom" name="xml-content-based-dom"></a>3.13.2 Domain &amp; Stakeholders</h4><p>This use case applies to many domains requiring deep content inspection of XML
                messages in a message processing environment including firewall, routing,
                publish/subscribe, security gateways, and instant messaging. These applications are
                relevant to almost all commercial and public entities concerned with
                enterprise-scale information and transactional infrastructures.</p></div><div class="div3">
<h4><a id="xml-content-based-justi" name="xml-content-based-justi"></a>3.13.3 Justification</h4><p>There exists no approach in software today which can meet all usage scenarios of this
                use case using XML. An alternate XML format could make such an implementation in
                software feasible by increasing the potential performance of the operations needed
                in a content-based routing or publish subscribe system. Reduction or elimination of
                parsing time and the ability to very rapidly find and test XML infoset items is
                necessary. For example, an alternative XML format with support for random access
                could enable extraction of data from the message with only a minimal lookup time and
                could potentially support the low latency needed by routing and the execution of the
                large numbers of rules needed for content-based publish subscribe. The
                <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a> property happens to map very strongly to this use case since
                XPath queries can be used for expressing the logical address of indexed content and
                the routing and subscriber rules. Another property of an alternate XML format which
                could assist in reducing parsing time is <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>.
                Compatibility with data binding could accelerate the matching of routing and
                subscriber rules. For example, such rules often have integer, floating point, and
                data type comparisons which would be more rapidly evaluated if the cost of
                conversion to these types in the programming language could be minimized.</p><p>XML content-based routing and publish subscribe systems may require additional processing such as message transformation. For example, it may be necessary to delete, insert, or change information used to route the message to ensure that the message does not loop back to the same processing node. WS-Eventing specifies the possibility of inserting a subscriber-specified SOAP header in a message before it is passed to the subscriber. <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a> is therefore a critical property of the XML format in such scenarios. In some cases, the <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a> property is required to support extraction and processing of a sub-segment of the message. One example might be filtering text or attachments through virus filters. A situation in which both transformation and handling of fragments is critical is in compound event detection. Here a router monitors a sequence of messages for interesting subsequences. If such a subsequence is identified a single compound message composed from them is transmitted.This requires extraction of fragments and transformation on these fragments to construct the compound message. Message security may also be a concern in routing and publish subscribe systems. An alternate XML format which supports <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a> and <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a> properties in an efficient manner is indispensable in these types of scenarios. In many situations any part of the content may be used to make routing decisions, so those parts need to be decryptable by the routers making those decisions. In this case it is necessary to be able to decrypt only fragments of the message, and the needed level of fragmentation may not be known beforehand. It is important to note that mere compatibility with existing XML Signature and XML Encryption Recommendations without considerable advances in the security processing speed of text XML implementations will not be sufficient. Finally, having an efficient way to ensure validity of the message according to a schema is highly desirable in many content-based routing and publish subscribe systems since this may make routing rules simpler to specify and less costly to evaluate.

</p></div><div class="div3">
<h4><a id="xml-content-based-ana" name="xml-content-based-ana"></a>3.13.4 Analysis</h4><p>Routers at the edge of the LAN responsible for distributing traffic coming from the
                WAN may operate with a relatively limited set of content inspection rules and small
                routing tables, but must deal with considerable quantities of message traffic and
                require very short message processing latency. Publish subscribe applications within
                the LAN will typically deal with less volume and may have more relaxed latency
                requirements compared to routers, but may need to deal with a large number of
                subscribers generating a very large set of rules to be evaluated against every
                published XML message.</p><p>Both XML routers and XML publish subscribe systems have in common that the greatest
                part of processing overhead comes from simply parsing each XML message. Typically,
                each message is converted into an in-memory representation (such as DOM) prior to
                evaluating routing or subscriber rules.</p><p>Evaluation of the rules may also require a great amount of processing power; most
                existing systems cannot, in fact, support complex rules because of the processing
                cost. XML Routers may be confined to processing routing information in message
                headers. XML publish subscribe applications may be unable to achieve dynamic
                subscription matching with full decoupling of publishers and subscribers. Adequate
                performance can only be achieved when subscribers are limited to matching a fixed
                set of keywords recognized by the publisher. The inability to perform full content
                inspection because of its cost in performance has limited architectures to static,
                inflexible, and narrowly-targeted systems which do not meet current needs.</p><p>XPath is sometimes used for expressing routing and subscriber rules. Its ability to
                locate any content item in an XML message and to apply additional node filtering
                criteria corresponds closely to the requirements for rule-based classification of
                XML content. As there are many tools for evaluating XPaths over DOM, we can
                conceptualize the problem of XML content-based routing and publish subscribe as a
                process of making decisions from the results of XPath evaluation.</p></div><div class="div3">
<h4><a id="xml-content-based-prop" name="xml-content-based-prop"></a>3.13.5 Properties</h4><div class="div4">
<h5><a id="xml-content-based-must-props" name="xml-content-based-must-props"></a>3.13.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-content-based-should-props" name="xml-content-based-should-props"></a>3.13.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="xml-content-based-nice-props" name="xml-content-based-nice-props"></a>3.13.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="xml-content-based-alt" name="xml-content-based-alt"></a>3.13.6 Alternatives</h4><p>Streaming XPath is a more efficient XPath implementation usually built on a SAX
                parser and limited to some subset of XPath expressions which can be evaluated in a
                single pass over an XML document. Streaming XPath may be an alternative for
                improving the performance of routing or publish-subscribe rules described with
                XPath expressions. The performance gain may be sufficient for some usage scenarios
                but still will not approach the <em>network speed</em> required for inspection
                and direction of XML messages entering into a LAN.</p><p>Purpose-built hardware devices can perform XML content inspection and make firewall,
                routing, or publish decisions at throughput rates which may be sufficient for this
                use case. This alternative is proprietary and costly and is therefore of limited
                applicability. In addition, the problem is sufficiently challenging even for
                hardware-based solutions. An alternate XML format could have the effect of
                increasing the performance of hardware-based solutions, further extending the
                capacity of such solutions and also lowering their cost.</p></div><div class="div3">
<h4><a id="xml-content-based-refs" name="xml-content-based-refs"></a>3.13.7 References</h4><ol class="enumar"><li><p>
                        <a href="#WS-Eventing">[WS-Eventing]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="ws-routing" name="ws-routing"></a>3.14 Web Services Routing</h3><div class="div3">
<h4><a id="ws-routing-desc" name="ws-routing-desc"></a>3.14.1 Description</h4><p>When SOAP messages flow in a network, rarely do they flow from the source system to
                the destination system directly. More often than not, they flow through various
                intermediaries between the two endpoints. The intermediaries route the message
                between systems for various reasons. These include routing the SOAP message to the
                appropriate endpoint in order to fulfill the request, routing the message based on
                system availability, and so on.</p></div><div class="div3">
<h4><a id="ws-routing-dom" name="ws-routing-dom"></a>3.14.2 Domain &amp; Stakeholders</h4><p>This use case applies to medium to large business that utilize XML and/or Web
                Services in SOAP messaging applications.</p></div><div class="div3">
<h4><a id="ws-routing-justi" name="ws-routing-justi"></a>3.14.3 Justification</h4><p>In a system that is dynamically routing messages to support a real-time messaging
                application, the size of each message as well as the time it takes to determine the
                next intermediary is important for the overall system performance and response time.
                The smaller the message, the less time it takes to transmit it between
                intermediaries, thus freeing up the remaining bandwidth. In addition, an alternate
                encoding has the potential to make the process of determining the next intermediary
                more efficient.</p></div><div class="div3">
<h4><a id="ws-routing-ana" name="ws-routing-ana"></a>3.14.4 Analysis</h4><p>In some messaging systems, the endpoint for a message is not determined by the
                client, but rather in real time by intermediaries. An intermediary will route the
                message based on various factors. These factors include, but are not limited to,
                message type, message content, system availability, etc.</p><p>An intermediary looks only at the SOAP header of the message to determine the route
                the message will take. This is a more efficient process than reading the entire
                message, creating an in memory representation (DOM) and digging into the message to
                determine its route. The more efficient mechanism is to have the intermediary only
                look at some header information at the beginning of a message in order to make an
                intelligent decision about how to route it.</p><p>It is important to note that the message, when received by an intermediary for
                routing, could be digitally signed and/or encrypted. These issues need to be
                considered for the alternate encoding in the same ways they are considered for XML today.</p><p>An alternate encoding needs to support the ability for this type of message routing
                to take place in, at a minimum, without loss of performance. The intermediary needs
                to examine the alternate encoding&rsquo;s header to determine the routing of the message.
                This, ideally, requires random access into the message header to determine the
                routing information.</p></div><div class="div3">
<h4><a id="ws-routing-prop" name="ws-routing-prop"></a>3.14.5 Properties</h4><div class="div4">
<h5><a id="ws-routing-must-props" name="ws-routing-must-props"></a>3.14.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-routing-should-props" name="ws-routing-should-props"></a>3.14.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="ws-routing-nice-props" name="ws-routing-nice-props"></a>3.14.5.3 Nice To Have</h5><p><em>None</em></p></div></div><div class="div3">
<h4><a id="ws-routing-alt" name="ws-routing-alt"></a>3.14.6 Alternatives</h4><p>Various other technologies can be used to achieve routing. However, they would be
                more brittle and often more proprietary compared to XML. Being able to express
                routing information in the header of a message in XML ensures a level of
                interoperability and non-brittleness that XML is known for.</p></div><div class="div3">
<h4><a id="ws-routing-refs" name="ws-routing-refs"></a>3.14.7 References</h4><ol class="enumar"><li><p>
                        <a href="#WS-Addressing">[WS-Addressing]</a>
                    </p></li><li><p>
                        <a href="#WS-Routing-bib">[WS-Routing]</a>
                    </p></li></ol></div></div><div class="div2">
<h3><a id="military" name="military"></a>3.15 Military Information Interoperability</h3><div class="div3">
<h4><a id="military-desc" name="military-desc"></a>3.15.1 Description</h4><p>The United States Department of Defense and its allies are very
large enterprises  and, as such, operate in one of the most challenging
information sharing environments. To be  effective in today's military
environment, thousands of dissimilar information systems,  developed
independently by different organizations in different countries must share
timely,  accurate information in a form that is mutually understandable.
They must do so within the  competing force's decision cycle despite
differences in cooperating force cultures, command  structures, operational
procedures and languages. Information must flow reliably and seamlessly
between command centers, mobile devices and embedded systems, including
aircraft, ships,  submarines, satellites, handheld devices, remote sensors,
unmanned vehicles, etc.
	  </p><p>To address this challenge, the United States and its allies have
invested a great  deal of energy devising technologies and formalizing data
standards to automate information  exchange between command and control (C2)
systems and reduce the ambiguity of natural language.  In the late 1960s and
early 1970s, the U.S. and its allies developed some of the
first hierarchically structured data encoding standards, similar to XML, but
more compact, for  exchanging both text and binary representations of
critical defense information. These military  standards have been deployed
worldwide on a diverse range of platforms and are implemented by  almost all
U.S. and allies' C2 systems. However, as military proprietary standards,
they are  expensive to implement, are supported by a limited number of tools
and do not evolve at the same  pace as technologies driven by the dynamics
of a highly competitive commercial marketplace. In  addition, training
materials, on-line communities and software development tools are sparse and
add to the associated expense.
	  </p><p>With the advent of XML, the U.S. and its allies quickly
recognized the potential of  the commercial marketplace to produce low cost,
high quality, rapidly evolving technologies for  sharing information between
C2 systems (e.g., see <a href="#NATO-XML">[NATO XML]</a>). Key national and international military  data
standards have adopted XML and it is being widely deployed in military C2
systems. Based on  the success of these initiatives, the DoD has issued high
level policies, directives and  programs specifying the adoption of XML
across the DoD enterprise.
	  </p><p>Unfortunately, the overhead associated with XML&rsquo;s text syntax makes it
impractical or impossible  to deploy on systems where efficiency is critical
or bandwidth is limited.  This creates an  interoperability rift between the
systems that can effectively process XML and those that  cannot, making it
difficult to share information between these systems without an expensive
series of proprietary gateways and the associated risk that information
fidelity or accuracy  will be lost.
	  </p><p>The military information environment includes a very diverse set of usage scenarios, data types, systems and networks. Important characteristics of the military operating environments, data and systems are described below.
	  </p><ul><li><p>Bandwidth capacity and cost:  The tactical networking environment is
challenging and  involves, for example, high speed aircraft, dramatic
terrains, varying electromagnetic  conditions, intentional jamming of
frequency bands, communications interception risks, etc. In  addition, it is
not possible to rely on an in-place communications infrastructure. Each
network  participant brings a portion of the communications infrastructure
with them <a href="#Airborne-Networking">[Airborne Networking]</a>. Due to these  characteristics, bandwidth is both limited and
expensive. To maintain current performance  characteristics, information
representations used in this environment must be competitive in  size with
existing hand optimized binary formats, which is to say their size must be
close to  the information theoretic minimum. In addition, it must be
possible to transmit small subsets of  larger information items, e.g.
specified by queries or changes to the underlying data.
	  </p></li><li><p>Diverse data and documents: As a massive enterprise, the military uses
a very diverse range  of documents and data. This includes highly
structured, semi-structured and loosely structured  data. It includes very
large documents, such as aircraft maintenance manuals, and high volume
streams of very small messages, such as position reports. It includes
documents designed for  both human and machine consumption. It also includes
documents that integrate and fuse several  different types of data from
different sources.
	  </p></li><li><p>Information Flexibility: Information sources are often used by a
variety of information  consumers for different purposes. Not all consumers
of an information source are known at the  time the information source is
designed. In addition, information sources and information  consumers must
be able to evolve independently without being tightly coupled. Therefore, it
is  not generally desirable or even possible to build many separate schemas
to define the interfaces  between individual information producers and
consumers. Rather, information producers must be  able to make information
available in a consumer independent form and allow consumers to query  that
information according to their individual needs.
	  </p></li><li><p>Schemas and validity: In many cases, the information exchange
requirements for C2 systems  are well understood and relatively stable.
However, real world data exchanges do not always fit  precisely within the
bounds of their associated schemas, which are often designed well before
systems are deployed that implement them. Therefore, it is important for
systems to be able to  deal flexibly with schema deviations. In addition,
there are times when a schema does not exist  or cannot be relied upon and
scenarios where typed information and untyped information are  interspersed
in a single document.
	  </p></li><li><p>Platform constraints: There are a diverse range of systems connected to
defense networks,  including high powered workstations, low powered remote
sensors, small mobile devices and  hardened systems embedded in military
air, land, sea and space craft. Many of these systems have  very limited
processing power, memory capacity and/or battery life. To maintain current
performance characteristics, the code footprint and time / space complexity
of parsing and  serialization algorithms must be competitive with that of
current hand optimized encoders and  decoders.
	  </p></li><li><p>
	  Upgrade time and cost: Upgrading hardware and software on tactical
systems is time-consuming  and costly.  In many cases, any configuration
change triggers expensive testing (e.g., flight  tests).  In addition, the
number of systems that can be taken out of service simultaneously is
restricted because operational readiness must be maintained.  Thus, system
upgrades are tied to  maintenance cycles, which are not synchronized, and
may even be delayed one or more cycles due  to competing priorities and
budget limitations. Consequently, deployed systems often implement
different versions of the same schema.
	  </p></li></ul><p>The DoD would like a single binary XML standard that works well for the
diverse range of data,  systems and scenarios specified above as opposed to
an incompatible set of binary XML standards  optimized for vertical
industries. We would also like a binary XML standard that leverages  schema
information when it is available to improve performance, but does not depend
on its  existence or accuracy to work. We have sponsored commercial research
and development that  demonstrates that what we want is both possible and
practical <a href="#Extending-XML">[Extending XML]</a>. Additional information about  our objectives and requirements
can be found in the references section below.
	  </p></div><div class="div3">
<h4><a id="military-dom" name="military-dom"></a>3.15.2 Domain &amp; Stakeholders</h4><p>The United States military, government agencies, U.S. allies and others with
which the U.S. military exchanges information.
	  </p></div><div class="div3">
<h4><a id="military-justi" name="military-justi"></a>3.15.3 Justification</h4><p>The US DoD maintains a large number of military facilities, mobile devices,
sensors and vehicle  systems that require timely, accurate information to
achieve their objectives.  These are being  modernized to leverage web
technologies <a href="#NCES">[NCES]</a>, <a href="#GIG-ES">[GIG-ES]</a>. Where possible, the DoD is buying commercial
off-the-shelf hardware and software products, including web servers, mobile
devices, databases,  messaging solutions and security infrastructure, from a
wide range of industries to reduce  development costs. Having a common data
representation that is widely supported across these  industries and
military systems drastically reduces the cost and complexity of military
systems,  while increasing their interoperability and tempo of evolution.
For this reason, many of these  military components have already adopted XML
based solutions.
		</p><p>A large number of systems, however, do not have sufficient bandwidth or
computing resources to  support XML and accomplish this transition.  A major
objective is to extend the benefits of XML  to the edge of military tactical
environments where its use is currently impossible or  impractical due to
bandwidth and platform constraints.
		</p></div><div class="div3">
<h4><a id="military-ana" name="military-ana"></a>3.15.4 Analysis</h4><p>The value of XML to the DoD and its allies is a function of its
wide adoption. The  dynamics of the competitive commercial marketplace have
produced a wide range of high quality,  inexpensive, rapidly evolving XML
products that can be easily integrated into a wide variety of  military
systems. In addition, it has created a vast pool of XML developers,
communities, books  and training materials. Consequently, using XML
drastically reduces the time and cost required  to develop and maintain
military systems. These benefits create a natural incentive for
independently developed military systems and data standards to gravitate
toward a common  information representation, increasing interoperability
across the military enterprise.
		</p><p>Unfortunately, it is not possible or practical to deploy XML on a wide
variety of military  systems due to the characteristics of military
operating environments, data and systems  described above. The systems that
cannot currently use XML are most often located on the edge of  the network
where the most time critical data is both digitized and consumed. It is
critical for  the military network to efficiently connect the observers that
detect real world events, the  decision makers that allocate and direct
resources and the actors that can change the course of  those events. A
widely adopted efficient XML encoding would enable timely XML information to
flow to and from the edge of the network in an efficient, interoperable and
cost effective way.
		</p></div><div class="div3">
<h4><a id="military-prop" name="military-prop"></a>3.15.5 Properties</h4><p>Below are the properties a binary XML standard must, should and may have to
support this use  case. We have included properties we believe are in scope
for a binary XML standard and have  omitted properties they reinvent or
otherwise duplicate functionality at other layers of the  technology stack.
For example, security features were omitted from the list of binary XML
properties because they already exist in the XML technology stack (i.e., XML
signatures and XML  encryption). To the extent possible, we would like to
reuse existing XML technologies with  binary XML instead of developing
duplicate capabilities specific to binary XML. This will result  in a clean
separation of concerns, increasing interoperability and reducing the cost
and  complexity of binary XML.
		  </p><div class="div4">
<h5><a id="military-must-props" name="military-must-props"></a>3.15.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="military-should-props" name="military-should-props"></a>3.15.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="military-nice-props" name="military-nice-props"></a>3.15.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#single-conformance-class">Single Conformance Class</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="military-alt" name="military-alt"></a>3.15.6 Alternatives</h4><ul><li><p>
            A military specific standard for binary XML.
          </p></li><li><p>
            Government/contractor/vendor proprietary solutions.
          </p></li><li><p>
            Translation gateways between XML and systems that cannot use XML.
          </p></li></ul></div><div class="div3">
<h4><a id="military-refs" name="military-refs"></a>3.15.7 References</h4><ol class="enumar"><li><p>
            <a href="#XML-2002-Compression-Study">[XML 2002 Compression Study]</a>
          </p></li><li><p>
            <a href="#USAF-Binary-XML">[USAF Binary XML]</a>
          </p></li><li><p>
            <a href="#NCES">[NCES]</a>
          </p></li><li><p>
            <a href="#AF-CIO">[AF CIO]</a>
          </p></li><li><p>
            <a href="#GIG-ES">[GIG-ES]</a>
          </p></li><li><p>
            <a href="#NATO-XML">[NATO XML]</a>
          </p></li><li><p>
            <a href="#Extending-XML">[Extending XML]</a>
          </p></li><li><p>
            <a href="#Efficient-XML">[Efficient XML]</a>
          </p></li><li><p>
            <a href="#Airborne-Networking">[Airborne Networking]</a>
          </p></li></ol></div></div><div class="div2">
<h3><a id="sensor" name="sensor"></a>3.16 Sensor Processing and Communication</h3><div class="div3">
<h4><a id="sensor-desc" name="sensor-desc"></a>3.16.1 Description</h4><p>Increased use of sensors in military and commercial environments is being
driven by the need for better intelligence data and by technology which provides
smaller, less costly and more capable sensors.  Sensing architectures based on
computer networks lead to increased communication to combine (fuse)
information.  Fixed sensors may have stable communication networks, while
mobile sensors, especially those on the ground, may have communication
networks which form and reform on the fly.  Network links can be
publish/subscribe or point-to-point.  Sensor packaging and missions can vary
widely:</p><ol class="enumar"><li><p>
            Some can be deployed as large, complex sensor assemblies which have
considerable on-board capabilities.
          </p></li><li><p>Unattended sensors with limited battery power, processing and
communication capabilities.  The software stack which supports receiving
commands and sending reports must be the smallest and most efficient
possible.  </p></li><li><p>Sensors with hard real-time requirements, such as those protecting or
navigating a platform.</p></li></ol><p>Sensor communication is typically two-way.  Sensor reports and status are sent
to collectors or specific consumers.  Commands and control messages are sent
to sensors.  Both kinds of communications may need to be persisted.  Persisted
data may be used for investigations, analyses, training and simulation inputs.
Synthetic sensor communication, for training, testing and simulation, may need to
be generated.  Tools should be able to transform sensor communications into
human-readable forms and human-readable forms into sensor communications.
In some cases sensors may be combined with safety-critical devices.
Sensing systems may need to collaborate with other external, heterogeneous
systems.  In this case communication may be a unidirectional flow of sensor
reports to the external system</p></div><div class="div3">
<h4><a id="sensor-dom" name="sensor-dom"></a>3.16.2 Domain &amp; Stakeholders</h4><p>Sensors report data and are controlled over communication networks.  High
latency and low bandwidth may not be constant features of the communication,
but could emerge at any time.  Any organization which uses sensors is a stakeholder.  Military organizations have a strong interest.  Other stakeholders include homeland defense,
commercial organizations which explore for natural resources and government
agencies which monitor or investigate the environment.</p></div><div class="div3">
<h4><a id="sensor-justi" name="sensor-justi"></a>3.16.3 Justification</h4><p>XML has advantages in this domain: it is standards-based, easier for humans to
review and interpret and has the ability to bridge heterogeneous networks and
protocols.  The disadvantages are higher bandwidth requirements and possible
increases in required processing power and time.</p></div><div class="div3">
<h4><a id="sensor-ana" name="sensor-ana"></a>3.16.4 Analysis</h4><p>For XML to be a viable syntax for creating a sensor language, it would need to be
able to produce small packets which are inexpensive to encode and decode.  It
would need to be at least as efficient as existing binary sensor message formats.
It would need to be seen as providing other benefits such as standardization and
commercial tool support.</p><p>Small packet size is important not only for communication, but also for
persistence.  The sensor traffic for a large-scale exercise, recorded for later play-
back, could be quite large.  Persisted data should be susceptible to rapid search
mechanisms, although this capability is mostly a function of storage and retrieval
tools.  Because sensor reports and commands are comparatively small, rapid
access to data within them is not critical.</p><p>Encoding, decoding and packetizing of sensor reports, status messages and
commands needs to be inexpensive.  A worst case is unattended sensors which
have limited power, limited battery life and limited processing resources.
In all cases sensor communication should support high levels of information
assurance.  This is especially important in safety-critical scenarios.  The
communication format should not add any additional cost to
encrypting/decrypting and signing/verifying sensor reports and commands.</p></div><div class="div3">
<h4><a id="sensor-prop" name="sensor-prop"></a>3.16.5 Properties</h4><div class="div4">
<h5><a id="sensor-must-props" name="sensor-must-props"></a>3.16.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="sensor-should-props" name="sensor-should-props"></a>3.16.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li></ul></div><div class="div4">
<h5><a id="sensor-nice-props" name="sensor-nice-props"></a>3.16.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="sensor-alt" name="sensor-alt"></a>3.16.6 Alternatives</h4><p>Existing binary sensor message formats and protocols will continue to be used
and new single-solution formats developed.</p></div><div class="div3">
<h4><a id="sensor-refs" name="sensor-refs"></a>3.16.7 References</h4><ol class="enumar"><li><p>
            <a href="#SensorML">[SensorML]</a>
          </p></li><li><p>
            <a href="#SensorsMag">[SensorsMag]</a>
          </p></li><li><p>
            <a href="#VMF">[VMF]</a>
          </p></li><li><p>
            <a href="#VMF-CCB">[VMF CCB]</a>
          </p></li></ol></div></div><div class="div2">
<h3><a id="syncml" name="syncml"></a>3.17 SyncML for Data Synchronization</h3><div class="div3">
<h4><a id="syncml-desc" name="syncml-desc"></a>3.17.1 Description</h4><p>With the emergence of mobile computing and communications devices, users
want ubiquitous access to their information and applications from any of their
devices. The ability to use applications and information on one
device, then to synchronize any updates with the applications and
information back at the office, or on the network, is key to the utility
and popularity of this pervasive, disconnected way of computing.
Before 2000, there was a proliferation of different, proprietary
data synchronization protocols for mobile devices. Each of these
protocols was (and still is) available only for selected transports,
implemented on a selected subset of devices, and able to access a small
set of networked data.</p><p>OMA (Open Mobile Alliance) Data Sync (also known as SyncML) protocol is a universal
and powerful XML-based synchronization protocol that operates on any
device (phones, handhelds, PCs, etc.) over wireless and conventional networks.
The SyncML initiative has been sponsored by a wide range of mobile industry
leaders, and a large number of small devices are now SyncML-compliant.
Small devices, such as mobile phones, PDAs or pagers, have restricted
memory, processing power and battery life, and are connected to
low-bandwidth, high-latency networks.</p><p>Until now, SyncML was commonly used to synchronize contacts, to-do
lists, and schedule information. With the growing demand for data
synchronization services, a new release of the protocol offers better
support for email, file and folder synchronization.  This will
considerably increase the average size of SyncML messages exchanged over
the network.</p></div><div class="div3">
<h4><a id="syncml-dom" name="syncml-dom"></a>3.17.2 Domain &amp; Stakeholders</h4><p>This use case applies to data synchronization services, and is
particularly significant in the context of small mobile handsets.  Stakeholders include users of synchronizable data sources (e.g., PDA and mobile phone users), and providers of platforms and devices allowing such synchronization.
</p></div><div class="div3">
<h4><a id="syncml-justi" name="syncml-justi"></a>3.17.3 Justification</h4><p>One of the main criticisms of SyncML protocol, made by manufacturers
and service providers who choose to adopt another proprietary data
synchronization protocol, concerns its lack of performance.  XML-based
messages are larger and typically require more processing than other protocols.
Whatever the type of device used (small or not), the synchronization
process has to be efficient with regard to time and resources.  This promotes user
convenience and also minimizes user costs (as very often, he has to pay for the
synchronization communication over the network).</p><p> The popularity of SyncML synchronization and the size
and variety of data commonly synchronized is growing.  Combining this with the limitations of small devices mentioned above makes the need for a more efficient XML
serialization crucial.</p></div><div class="div3">
<h4><a id="syncml-ana" name="syncml-ana"></a>3.17.4 Analysis</h4><p>SyncML is based on XML in order to maximize interoperability.
The speed and efficiency of synchronization is key to the adoption of
the SyncML synchronization protocol, particularly in the context of
band-width limited wireless networks and devices with limited processing power and
other resources.</p><p>The main requirements this use case imposes on an alternate XML serialization would be
faster processing and reduced message size.
Considering that the data conveyed via SyncML messages is often the user's
personal data, it is also important that data privacy be
preserved.  So an encryption capability is also important.</p></div><div class="div3">
<h4><a id="syncml-prop" name="syncml-prop"></a>3.17.5 Properties</h4><div class="div4">
<h5><a id="syncml-must-props" name="syncml-must-props"></a>3.17.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li></ul></div><div class="div4">
<h5><a id="syncml-should-props" name="syncml-should-props"></a>3.17.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="syncml-nice-props" name="syncml-nice-props"></a>3.17.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="syncml-alt" name="syncml-alt"></a>3.17.6 Alternatives</h4><p>SyncML protocol provides support for WBXML.</p></div><div class="div3">
<h4><a id="syncml-refs" name="syncml-refs"></a>3.17.7 References</h4><ol class="enumar"><li><p>
            <a href="#SyncML-Initiative">[SyncML Initiative]</a>
          </p></li><li><p>
            <a href="#OMA-SyncML">[OMA-SyncML]</a>
          </p></li><li><p>
            <a href="#NOKIA-SynchML">[NOKIA-SynchML]</a>
          </p></li></ol></div></div><div class="div2">
<h3><a id="super-comp" name="super-comp"></a>3.18 Supercomputing and Grid Processing</h3><div class="div3">
<h4><a id="super-comp-desc" name="super-comp-desc"></a>3.18.1 Description</h4><p>Supercomputing and grid processing involve multiple computing nodes and
often
involve massive amounts of data and processing.  Supercomputer and
supercomputer clusters usually have very low latency and high bandwidth
network
interconnections.  Grid systems may have any type of network connectivity
depending
on the grid's goal and users.  Supercomputing applications process large
amounts
of data that consist of floating point arrays, genetic sequence strings,
physical particle or molecular systems, images, 3D models, knowledge
representation and queries, or simulation events.  Existing systems make
use of
XML, custom binary formats, and evolving shared access file formats such
as HDF5
(Hierarchical Data Format 5) from NCSA (National Center for Supercomputing Applications
).  HDF5, and the predecessors
including
CD (Common Data Form from NASA) and net (Network Common Data Form
from the
Undated Program Center), are file formats that allow efficient
production, use,
and sharing of data.  These are container formats that are self-describing,
architecture independent, directly accessible, appendable, and sharable (one
writer,
many readers simultaneously).</p><p>Supercomputing applications include weather forecasting, physical
simulation of
many things, Monte Carlo simulation of complex systems, 3D rendering, data
discovery, and knowledge processing.  Applications that are heading toward
supercomputing include massive multiplayer online role-playing games
(MMORPG),
expanded search engine services, and expanded retail services.
Distributed grid
applications include searching for protein folding solutions, testing
cryptographic strength, and searching for extra-terrestrial signals.
Weather
forecasting, as an example of data interchange needed, receives real-time
telemetry from thousands of stations all over the world.  Each node
communicates
results frequently with other nodes.  Continuous results are output,
processed,
and communicated in realtime to many organizations.  Communication between
cluster or grid nodes takes a number of forms and includes MPI or other
interfaces for message queuing and communication, shared filesystems, and
non-uniform shared memory (cache coherent (ccNUMA) and non-cache coherent
memory).</p></div><div class="div3">
<h4><a id="super-comp-dom" name="super-comp-dom"></a>3.18.2 Domain &amp; Stakeholders</h4><p>Users of supercomputers, supercomputing clusters, and computational and
storage
grids.  This includes weather forecasting, physics research, virtual weapons
testing and simulation, manufacturers, 3D rendering, and companies and
developers that communicate with services using computational grid
technology.</p></div><div class="div3">
<h4><a id="super-comp-justi" name="super-comp-justi"></a>3.18.3 Justification</h4><p>Supercomputing developers have created file formats with many of the
characteristics needed for a more complete binary XML standard format.  While
this has interesting properties, it isn't usable by the rest of the IT
market as
a substitute for XML.  Supercomputing applications nearly always need to
consume
large amounts of data from other systems and produce results that must
be used
by external systems.  Much of this data is now XML at points in the
lifecycle.
A binary XML standard that addressed the needs of supercomputing
applications
and is usable for efficient data input and output could greatly improve
efficiency, integratability, and standardization.</p></div><div class="div3">
<h4><a id="super-comp-ana" name="super-comp-ana"></a>3.18.4 Analysis</h4><p>A binary XML format that supports efficient lifecycle data production,
use, and
modification would be a very important mechanism for intra-grid
communication
and for data input and output.  Formats like HDF5 have advanced container
characteristics but have limited management of actual data payloads beyond
typing.  It is probable that the binary XML and HDF5 work will influence
each
other in important ways.</p><p>There are many types of grid and supercomputing applications.  While
some are
classic hard physics particle simulations, others focus on
business-processing simulations or analysis.  The data involved
varies from
very large floating point arrays to complex, tree or graph structured
data.  A
solution to the binary XML requirements may provide a very attractive
tool for
these applications.</p></div><div class="div3">
<h4><a id="super-comp-prop" name="super-comp-prop"></a>3.18.5 Properties</h4><div class="div4">
<h5><a id="super-comp-must-props" name="super-comp-must-props"></a>3.18.5.1 Must Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#explicit-typing">Explicit Typing</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#deltas">Deltas</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#efficient-update">Efficient Update</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#embedding-support">Embedding Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identification</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#random-access">Random Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#directly-readable-and-writable">Directly Readable and Writable</a>
          </p></li></ul></div><div class="div4">
<h5><a id="super-comp-should-props" name="super-comp-should-props"></a>3.18.5.2 Should Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#single-conformance-class">Single Conformance Class</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#localized-changes">Localized Changes</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#specialized-codecs">Specialized Codecs</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#no-arbitrary-limits">No Arbitrary Limits</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#schema-instance-change-resilience">Schema Instance Change Resilience</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#accelerated-sequential-access">Accelerated Sequential Access</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#encryptable">Encryptable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#signable">Signable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a>
          </p></li></ul></div><div class="div4">
<h5><a id="super-comp-nice-props" name="super-comp-nice-props"></a>3.18.5.3 Nice To Have</h5><ul><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#support-for-error-correction">Support for Error Correction</a>
          </p></li><li><p>
            <a href="http://www.w3.org/TR/xbc-properties/#robustness">Robustness</a>
          </p></li></ul></div></div><div class="div3">
<h4><a id="super-comp-alt" name="super-comp-alt"></a>3.18.6 Alternatives</h4><p>Container file formats such as HDF5 provide a partial solution, often
used with
raw arrays of floating point data that must be managed by applications.  In
addition, most applications use either a custom binary data format or
XML.
When the advantages of XML are needed, the performance problems involved are
quite apparent to users of these performance sensitive applications.</p></div><div class="div3">
<h4><a id="super-comp-refs" name="super-comp-refs"></a>3.18.7 References</h4><ol class="enumar"><li><p>
            <a href="#HDF">[HDF]</a>
          </p></li><li><p>
            <a href="#HDF-Software">[HDF Software]</a>
          </p></li><li><p>
            <a href="#SZIP">[SZIP]</a>
          </p></li><li><p>
            <a href="#MPI">[MPI]</a>
          </p></li></ol></div></div></div><div class="div1">
<h2><a id="N119A9" name="N119A9"></a>4 References</h2><dl><dt class="label"><a id="XBC-Properties" name="XBC-Properties"></a>XBC Properties</dt><dd>
          <a href="http://www.w3.org/TR/xbc-properties/"><cite>XML Binary
            Characterization Properties</cite></a>
          (See http://www.w3.org/TR/xbc-properties/.)</dd></dl><dl><dt class="label"><a id="XML-1.0" name="XML-1.0"></a>XML 1.0</dt><dd>
          <a href="http://www.w3.org/TR/REC-xml/"><cite>Extensible Markup
            Language (XML) 1.0</cite></a>
          (See http://www.w3.org/TR/REC-xml/.)</dd></dl><dl><dt class="label"><a id="XML-1.1" name="XML-1.1"></a>XML 1.1</dt><dd>
          <a href="http://www.w3.org/TR/xml11/"><cite>Extensible Markup
            Language (XML) 1.1</cite></a>
          (See http://www.w3.org/TR/xml11/.)</dd></dl><dl><dt class="label"><a id="X3D" name="X3D"></a>Extensible 3D (X3D) Graphics</dt><dd>
          <a href="http://www.web3D.org/x3d/"><cite>Extensible 3D
            (X3D) Graphics</cite></a>
          (See http://www.web3D.org/x3d/.)</dd></dl><dl><dt class="label"><a id="FWS" name="FWS"></a>Fast Web Services</dt><dd>
          <a href="http://java.sun.com/developer/technicalArticles/WebServices/fastWS/"><cite>Fast Web Services</cite></a>
          (See http://java.sun.com/developer/technicalArticles/WebServices/fastWS/.)</dd></dl><dl><dt class="label"><a id="SOAPPerf" name="SOAPPerf"></a>SOAP Performance</dt><dd>
          <a href="http://www.extreme.indiana.edu/xgws/papers/soap-hpdc2002/soap-hpdc2002.pdf"><cite>Investigating the
            Limits of SOAP Performance for Scientific Computing</cite></a>
          (See http://www.extreme.indiana.edu/xgws/papers/soap-hpdc2002/soap-hpdc2002.pdf.)</dd></dl><dl><dt class="label"><a id="MTOM" name="MTOM"></a>MTOM</dt><dd>
          <a href="http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/"><cite>SOAP Message
            Transmission Optimization Mechanism</cite></a>
          (See http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/.)</dd></dl><dl><dt class="label"><a id="XOP" name="XOP"></a>XOP</dt><dd>
          <a href="http://www.w3.org/TR/2004/WD-xop10-20040209/"><cite>SOAP Message
            Transmission Optimization Mechanism</cite></a>
          (See http://www.w3.org/TR/2004/WD-xop10-20040209/.)</dd></dl><dl><dt class="label"><a id="SOAPAttachments" name="SOAPAttachments"></a>SOAP with Attachments</dt><dd>
          <a href="http://www.w3.org/TR/SOAP-attachments"><cite>SOAP Messages
            with Attachments</cite></a>
          (See http://www.w3.org/TR/SOAP-attachments.)</dd></dl><dl><dt class="label"><a id="WSI-AP" name="WSI-AP"></a>WS-I Attachments Profile</dt><dd>
          <a href="http://www.ws-i.org/Profiles/Basic/2003-08/AttachmentsProfile-1.0.pdf"><cite>WS-I: Attachments
            Profile Version 1.0</cite></a>
          (See http://www.ws-i.org/Profiles/Basic/2003-08/AttachmentsProfile-1.0.pdf.)</dd></dl><dl><dt class="label"><a id="DVB" name="DVB"></a>DVB</dt><dd>
          <a href="http://www.dvb.org/"><cite>Digital Video Broadcasting</cite></a>
          (See http://www.dvb.org/.)</dd></dl><dl><dt class="label"><a id="TVAnytime" name="TVAnytime"></a>TV Anytime</dt><dd>
          <a href="http://tv-anytime.org/"><cite>TV Anytime</cite></a>
          (See http://tv-anytime.org/.)</dd></dl><dl><dt class="label"><a id="ARIB" name="ARIB"></a>ARIB</dt><dd>
          <a href="http://www.arib.or.jp/"><cite>Association of
            Radio Industries and Businesses</cite></a>
          (See http://www.arib.or.jp/.)</dd></dl><dl><dt class="label"><a id="MPEG-7" name="MPEG-7"></a>MPEG-7</dt><dd>
          <a href="http://www.iso.org/iso/en/prods-services/popstds/mpeg.html"><cite>MPEG-7</cite></a>
          (See http://www.iso.org/iso/en/prods-services/popstds/mpeg.html.)</dd></dl><dl><dt class="label"><a id="PDF" name="PDF"></a>PDF</dt><dd>
          <a href="http://partners.adobe.com/asn/acrobat/sdk/public/docs/PDFReference15_v6.pdf "><cite>PDF Reference,
            4th Ed.</cite></a>
          (See http://partners.adobe.com/asn/acrobat/sdk/public/docs/PDFReference15_v6.pdf .)</dd></dl><dl><dt class="label"><a id="SOAP-Trading" name="SOAP-Trading"></a>SOAP in Real-Time Trading Systems</dt><dd>
          <a href="http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html"><cite>Evaluating SOAP
            for High Performance Business Application: Real-Time Trading Systems.</cite></a>
          (See http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html.)</dd></dl><dl><dt class="label"><a id="MIME" name="MIME"></a>MIME</dt><dd>
          <a href="http://www.faqs.org/rfcs/rfc2387.html"><cite>The MIME
            Multipart/Related Content-type</cite></a>
          (See http://www.faqs.org/rfcs/rfc2387.html.)</dd></dl><dl><dt class="label"><a id="Mobile-SVG" name="Mobile-SVG"></a>Mobile SVG</dt><dd>
          <a href="http://www.w3.org/TR/SVGMobile/"><cite>Mobile SVG
            Profiles: SVG Tiny and SVG Basic</cite></a>
          (See http://www.w3.org/TR/SVGMobile/.)</dd></dl><dl><dt class="label"><a id="Mobile-XHTML" name="Mobile-XHTML"></a>Mobile XHTML</dt><dd>
          <a href="http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf"><cite>XHTML Mobile Profile</cite></a>
          (See http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf.)</dd></dl><dl><dt class="label"><a id="SMIL" name="SMIL"></a>SMIL</dt><dd>
          <a href="http://www.w3.org/TR/smil20/"><cite>Synchronized
            Multimedia Integration Language (SMIL 2.0)</cite></a>
          (See http://www.w3.org/TR/smil20/.)</dd></dl><dl><dt class="label"><a id="G-XML" name="G-XML"></a>G-XML</dt><dd>
          <a href="http://gisclh.dpc.or.jp/gxml/contents-e/"><cite>G-XML</cite></a>
          (See http://gisclh.dpc.or.jp/gxml/contents-e/.)</dd></dl><dl><dt class="label"><a id="MMS" name="MMS"></a>MMS</dt><dd>
          <a href="http://www.3gpp.org/ftp/Specs/html-info/26140.htm"><cite>Multimedia
            Messaging Services</cite></a>
          (See http://www.3gpp.org/ftp/Specs/html-info/26140.htm.)</dd></dl><dl><dt class="label"><a id="WAP-WBXML" name="WAP-WBXML"></a>WAP WBXML</dt><dd>
          <a href="http://www.openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-20010725-a.pdf"><cite>Binary XML
            Content Format Specification</cite></a>
          (See http://www.openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-20010725-a.pdf.)</dd></dl><dl><dt class="label"><a id="Comparing-SOAP-Performance" name="Comparing-SOAP-Performance"></a>Comparing SOAP Performance</dt><dd>
          <a href="http://www.cs.helsinki.fi/u/jkangash/soap-performance.pdf"><cite>Comparing SOAP
            Performance for Various Encodings, Protocols, and Connections</cite></a>
          (See http://www.cs.helsinki.fi/u/jkangash/soap-performance.pdf.)</dd></dl><dl><dt class="label"><a id="SOAP-Performance-Wireless-Networks" name="SOAP-Performance-Wireless-Networks"></a>SOAP Performance in Wireless Networks</dt><dd>
          <a href="http://conferences.computer.org/icws/2003/"><cite>Web Services in
            Wireless Networks - What Happened to the Performance?</cite></a>
          (See http://conferences.computer.org/icws/2003/.)</dd></dl><dl><dt class="label"><a id="WellLogML" name="WellLogML"></a>WellLogML</dt><dd>
          <a href="http://www.posc.org/ebiz/WellLogML/V1.0/index.html"><cite>POSC WellLogML Project</cite></a>
          (See http://www.posc.org/ebiz/WellLogML/V1.0/index.html.)</dd></dl><dl><dt class="label"><a id="POSC" name="POSC"></a>POSC</dt><dd>
          <a href="http://www.posc.org/"><cite>Petrotechnical
            Open Standards Consortium</cite></a>
          (See http://www.posc.org/.)</dd></dl><dl><dt class="label"><a id="ACORD" name="ACORD"></a>ACORD</dt><dd>
          <a href="http://www.acord.org"><cite>ACORD - Global
            Insurance Standards</cite></a>
          (See http://www.acord.org.)</dd></dl><dl><dt class="label"><a id="HL7" name="HL7"></a>HL7</dt><dd>
          <a href="http://www.hl7.org/"><cite>Health Level 7</cite></a>
          (See http://www.hl7.org/.)</dd></dl><dl><dt class="label"><a id="RosettaNet" name="RosettaNet"></a>RosettaNet</dt><dd>
          <a href="http://www.rosettanet.org/RosettaNet/Rooms/DisplayPages/LayoutInitial/"><cite>RosettaNet -
            ebusiness Standards for the Global Supply Chain</cite></a>
          (See http://www.rosettanet.org/RosettaNet/Rooms/DisplayPages/LayoutInitial/.)</dd></dl><dl><dt class="label"><a id="X3D-Markets" name="X3D-Markets"></a>X3D Markets</dt><dd>
          <a href="http://www.web3d.org/applications/"><cite>Application
            Markets for X3D-Based Open Standards</cite></a>
          (See http://www.web3d.org/applications/.)</dd></dl><dl><dt class="label"><a id="X3D-RFP" name="X3D-RFP"></a>X3D RFP</dt><dd>
          <a href="http://www.web3d.org/x3d/binary/X3dBinaryRFP.html"><cite>X3D Compressed
            Binary Encoding RFP</cite></a>
          (See http://www.web3d.org/x3d/binary/X3dBinaryRFP.html.)</dd></dl><dl><dt class="label"><a id="W3C-PP" name="W3C-PP"></a>W3C PP</dt><dd>
          <a href="http://www.w3.org/Consortium/Patent-Policy/"><cite>W3C Patent Policy</cite></a>
          (See http://www.w3.org/Consortium/Patent-Policy/.)</dd></dl><dl><dt class="label"><a id="RFC3920" name="RFC3920"></a>RFC 3920</dt><dd>
          <a href="http://www.rfc-archive.org/getrfc.php?rfc=3920"><cite>Extensible
            Messaging and Presence Protocol (XMPP): Core</cite></a>
          (See http://www.rfc-archive.org/getrfc.php?rfc=3920.)</dd></dl><dl><dt class="label"><a id="RFC3921" name="RFC3921"></a>RFC 3921</dt><dd>
          <a href="http://www.rfc-archive.org/getrfc.php?rfc=3921"><cite>Extensible
            Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</cite></a>
          (See http://www.rfc-archive.org/getrfc.php?rfc=3921.)</dd></dl><dl><dt class="label"><a id="RFC3922" name="RFC3922"></a>RFC 3922</dt><dd>
          <a href="http://www.rfc-archive.org/getrfc.php?rfc=3922"><cite>Mapping the
            Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant
            Messaging (CPIM)</cite></a>
          (See http://www.rfc-archive.org/getrfc.php?rfc=3922.)</dd></dl><dl><dt class="label"><a id="RFC3923" name="RFC3923"></a>RFC 3923</dt><dd>
          <a href="http://www.rfc-archive.org/getrfc.php?rfc=3923"><cite>End-to-End
            Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</cite></a>
          (See http://www.rfc-archive.org/getrfc.php?rfc=3923.)</dd></dl><dl><dt class="label"><a id="Jabber" name="Jabber"></a>Jabber</dt><dd>
          <a href="http://www.jabber.com/"><cite>Jabber</cite></a>
          (See http://www.jabber.com/.)</dd></dl><dl><dt class="label"><a id="Jabber-Enhancements" name="Jabber-Enhancements"></a>JEPs</dt><dd>
          <a href="http://www.jabber.org/jeps"><cite>Jabber: Jabber
            Enhancement Proposals (JEPs)</cite></a>
          (See http://www.jabber.org/jeps.)</dd></dl><dl><dt class="label"><a id="Jabber-Stream-Compression" name="Jabber-Stream-Compression"></a>Jabber Stream Compression</dt><dd>
          <a href="http://www.jabber.org/jeps/jep-0138.html"><cite>Jabber: Stream
            Compression JEP</cite></a>
          (See http://www.jabber.org/jeps/jep-0138.html.)</dd></dl><dl><dt class="label"><a id="WS-Addressing" name="WS-Addressing"></a>WS-Addressing</dt><dd>
          <a href="http://www.w3.org/Submission/ws-addressing/"><cite>Web Services Addressing</cite></a>
          (See http://www.w3.org/Submission/ws-addressing/.)</dd></dl><dl><dt class="label"><a id="WS-Routing-bib" name="WS-Routing-bib"></a>WS-Routing</dt><dd>
          <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp"><cite>Web Services
            Routing Protocol</cite></a>
          (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp.)</dd></dl><dl><dt class="label"><a id="WS-Eventing" name="WS-Eventing"></a>WS-Eventing</dt><dd>
          <a href="http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf"><cite>Web Services Eventing</cite></a>
          (See http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf.)</dd></dl><dl><dt class="label"><a id="OASIS-WS-BPEL" name="OASIS-WS-BPEL"></a>OASIS WS BPEL</dt><dd>
          <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel"><cite>OASIS Web
            Services Business Process Execution Language TC</cite></a>
          (See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel.)</dd></dl><dl><dt class="label"><a id="CVS" name="CVS"></a>CVS</dt><dd>
          <a href="http://www.cvshome.org"><cite>Concurrent
            Versions System</cite></a>
          (See http://www.cvshome.org.)</dd></dl><dl><dt class="label"><a id="SEGY" name="SEGY"></a>SEGY</dt><dd>
          <a href="http://www.seg.org/publications/tech-stand/"><cite>Society of
            Exploration Geophysicists</cite></a>
          (See http://www.seg.org/publications/tech-stand/.)</dd></dl><dl><dt class="label"><a id="XML-2002-Compression-Study" name="XML-2002-Compression-Study"></a>XML 2002 Compression Study</dt><dd>
          <a href="http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-02-04/06-02-04.html"><cite>M. Cokus and D. Winkowski. XML Sizing and Compression Study for Military Wireless Data. Proceedings of the XML 2002 Conference, December 2002</cite></a>
          (See http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-02-04/06-02-04.html.)</dd></dl><dl><dt class="label"><a id="USAF-Binary-XML" name="USAF-Binary-XML"></a>USAF Binary XML</dt><dd>
          <a href=" http://www.w3.org/2003/08/binary-interchange-workshop/25-MITRE-USAF-Binary-XML.htm"><cite>M. Cokus and Dr. S. Renner. The Need for Standard Schema-based and Hybrid Compression, Proceedings of the W3C Workshop on Binary Interchange of XML Information Sets, September 2003</cite></a>
          (See  http://www.w3.org/2003/08/binary-interchange-workshop/25-MITRE-USAF-Binary-XML.htm.)</dd></dl><dl><dt class="label"><a id="NCES" name="NCES"></a>NCES</dt><dd>
          <a href="http://www.disa.mil/main/nces.html"><cite>Defense Information Systems Agency (DISA), Net-Centric Enterprise Services (NCES) Program Office</cite></a>
          (See http://www.disa.mil/main/nces.html.)</dd></dl><dl><dt class="label"><a id="AF-CIO" name="AF-CIO"></a>AF CIO</dt><dd>
          <a href="http://www.mitre.org/news/events/xml4bin/pdf/gilligan_keynote.pdf"><cite>J. Gilligan. Why the Air Force Needs Binary XML, Proceedings of the XML for Binary Interchange 2004 Conference, September 2004</cite></a>
          (See http://www.mitre.org/news/events/xml4bin/pdf/gilligan_keynote.pdf.)</dd></dl><dl><dt class="label"><a id="GIG-ES" name="GIG-ES"></a>GIG-ES</dt><dd>
          <a href="http://ges.dod.mil"><cite>Global Information Grid Enterprise Services</cite></a>
          (See http://ges.dod.mil.)</dd></dl><dl><dt class="label"><a id="NATO-XML" name="NATO-XML"></a>NATO XML</dt><dd>
          <a href="http://www.gca.org/papers/xmleurope2000/papers/s16-03.html"><cite>Dr. K. Muller. NATO and XML. Proceedings of the XML Europe 2000 Conference, June 2000</cite></a>
          (See http://www.gca.org/papers/xmleurope2000/papers/s16-03.html.)</dd></dl><dl><dt class="label"><a id="Extending-XML" name="Extending-XML"></a>Extending XML</dt><dd>
          <a href="http://www.mitre.org/news/events/xml4bin/pdf/schneider_infosphere.pdf"><cite>J. Schneider. Extending XML to Mobile and Embedded Systems, Proceedings of the XML for Binary Interchange 2004 Conference, September 2004</cite></a>
          (See http://www.mitre.org/news/events/xml4bin/pdf/schneider_infosphere.pdf.)</dd></dl><dl><dt class="label"><a id="Efficient-XML" name="Efficient-XML"></a>Efficient XML</dt><dd>
          <a href=" http://www.w3.org/2003/08/binary-interchange-workshop/30-agiledelta-Efficient-updated.html"><cite>J. Schneider. Theory, Benefits and Requirements for Efficient Encoding of XML Documents. Proceedings of the W3C Workshop on Binary Interchange of XML Information Sets, September 2003</cite></a>
          (See  http://www.w3.org/2003/08/binary-interchange-workshop/30-agiledelta-Efficient-updated.html.)</dd></dl><dl><dt class="label"><a id="Airborne-Networking" name="Airborne-Networking"></a>Airborne Networking</dt><dd>
          <a href="http://www.mitre.org/news/events/xml4bin/pdf/stranc_airborne.pdf"><cite>K. Stranc. Airborne Networking, Proceedings of the XML for Binary Interchange 2004 Conference, September 2004</cite></a>
          (See http://www.mitre.org/news/events/xml4bin/pdf/stranc_airborne.pdf.)</dd></dl><dl><dt class="label"><a id="SensorML" name="SensorML"></a>SensorML</dt><dd>
          <a href="http://vast.uah.edu/SensorML/SensorML_04-019_1.0_beta.pdf"><cite>Sensor Model Language (SensorML) OGC 04-019r2</cite></a>
          (See http://vast.uah.edu/SensorML/SensorML_04-019_1.0_beta.pdf.)</dd></dl><dl><dt class="label"><a id="SensorsMag" name="SensorsMag"></a>SensorsMag</dt><dd>
          <a href="http://www.sensorsmag.com/articles/0403/30/main.shtml"><cite>M. Botts and L. McKee, A Sensor Model Language: Moving Sensor Data onto the Internet. Sensors Vol. 20 No 4, April 2003</cite></a>
          (See http://www.sensorsmag.com/articles/0403/30/main.shtml.)</dd></dl><dl><dt class="label"><a id="VMF" name="VMF"></a>VMF</dt><dd>
          <a href="http://jitc.fhu.disa.mil/brochure/vmf.pdf"><cite>Variable Message Format (MIL-STD-6017)</cite></a>
          (See http://jitc.fhu.disa.mil/brochure/vmf.pdf.)</dd></dl><dl><dt class="label"><a id="VMF-CCB" name="VMF-CCB"></a>VMF CCB</dt><dd>
          <a href="http://www.marcorsyscom.usmc.mil/sites/sei/JointStandards.asp"><cite>VMF Configuration Control Board</cite></a>
          (See http://www.marcorsyscom.usmc.mil/sites/sei/JointStandards.asp.)</dd></dl><dl><dt class="label"><a id="SyncML-Initiative" name="SyncML-Initiative"></a>SyncML Initiative</dt><dd>
          <a href="http://xml.coverpages.org/syncML.html"><cite>Cover Pages: The SynchML Initiative</cite></a>
          (See http://xml.coverpages.org/syncML.html.)</dd></dl><dl><dt class="label"><a id="OMA-SyncML" name="OMA-SyncML"></a>OMA-SyncML</dt><dd>
          <a href="http://www.openmobilealliance.org/release_program/ds_v12.html"><cite>OMA: SyncML Data Synchronization</cite></a>
          (See http://www.openmobilealliance.org/release_program/ds_v12.html.)</dd></dl><dl><dt class="label"><a id="NOKIA-SynchML" name="NOKIA-SynchML"></a>NOKIA-SynchML</dt><dd>
          <a href="http://www.nokia.co.uk/nokia/0,8764,18359,00.html"><cite>NOKIA: SynchML Technology</cite></a>
          (See http://www.nokia.co.uk/nokia/0,8764,18359,00.html.)</dd></dl><dl><dt class="label"><a id="HDF" name="HDF"></a>HDF</dt><dd>
          <a href="http://hdf.ncsa.uiuc.edu"><cite>Hierarchical Data Format (HDF)</cite></a>
          (See http://hdf.ncsa.uiuc.edu.)</dd></dl><dl><dt class="label"><a id="HDF-Software" name="HDF-Software"></a>HDF Software</dt><dd>
          <a href="http://hdf.ncsa.uiuc.edu/tools5.html"><cite>Software Supporting HDF5</cite></a>
          (See http://hdf.ncsa.uiuc.edu/tools5.html.)</dd></dl><dl><dt class="label"><a id="SZIP" name="SZIP"></a>SZIP</dt><dd>
          <a href="http://hdf.ncsa.uiuc.edu/doc_resource/SZIP"><cite>Szip Compression in HDF Products</cite></a>
          (See http://hdf.ncsa.uiuc.edu/doc_resource/SZIP.)</dd></dl><dl><dt class="label"><a id="MPI" name="MPI"></a>MPI</dt><dd>
          <a href="http://www-unix.mcs.anl.gov/mpi"><cite>The Message Passing Interface (MPI) Standard</cite></a>
          (See http://www-unix.mcs.anl.gov/mpi.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a id="N11E10" name="N11E10"></a>A Acknowledgments</h2><p>The Use Cases have been gathered by the XBC Working Group contributors:
Robin Berjon (Expway), Carine Bournez (W3C), Don Brutzman (Web3D), Mike Cokus (MITRE), Roger Cutler (ChevronTexaco), Ed Day (Objective Systems), Fabrice Desr&eacute; (France Telecom), Seamus Donohue (Cape Clear), Olivier Dubuisson (France Telecom), Oliver Goldman (Adobe), Peter Haggar (IBM), Takanari Hayama (KDDI), J&ouml;rg Heuer (Siemens), Misko Hevery (Adobe), Alan Hudson (Web3D), Takuki Kamiya (Fujitsu), Jaakko Kangasharju (University of Helsinki), Arei Kobayashi (KDDI), Eugene Kuznetsov (DataPower), Terence Lammers (Boeing), Kelvin Lawrence (IBM), Eric Lemoine (Tarari), Dmitry Lenkov (Oracle), Michael Leventhal (Tarari), Don McGregor (Web3D), Ravi Murthy (Oracle), Mark Nottingham (BEA), Santiago Pericas-Geertsen (Sun), Liam Quin (W3C), Kimmo Raatikainen (Nokia), Rich Salz (DataPower), Paul Sandoz (Sun), John Schneider (AgileDelta), Claude Seyrat (Expway), Paul Thorpe (OSS Nokalva), Alessandro Triglia (OSS Nokalva), Stephen D. Williams (Invited Expert).</p></div></div></body></html>