index.html 47.6 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</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</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-characterization-20050331/">http://www.w3.org/TR/2005/NOTE-xbc-characterization-20050331/</a>
    </dd><dt>Latest version:</dt><dd>
     <a href="http://www.w3.org/TR/xbc-characterization">http://www.w3.org/TR/xbc-characterization</a>
    </dd><dt>Editors:</dt><dd>Oliver Goldman, Adobe Systems Inc.</dd><dd>Dmitry Lenkov, Oracle</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 the processes and results of the XML Binary Characterization
        Working Group in evaluating the need and feasibility of a "binary XML" recommendation.
        It includes an analysis of which properties such a format must possess.
        It recommends that the W3C produce a "binary XML" recommendation and enumerates
        the minimum requirements which this "binary XML" recommendation must meet.
      </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="#N10095">Background</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#N100A0">Definition of Binary XML</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#N100B7">Analysis Methodology</a><br>
3 <a href="#N100DD">W3C Requirements</a><br>
4 <a href="#N10105">Use Case Requirements</a><br>
5 <a href="#N101F4">Decision Tree Requirements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#N1020A">Property Decision Tree</a><br>
6 <a href="#N102EC">Minimum Binary XML Requirements</a><br>
7 <a href="#N103F4">Feasibility of Binary XML</a><br>
8 <a href="#N107D4">Conclusions</a><br>
9 <a href="#N107FF">References</a><br>
</p>
<h3><a id="appendices" name="appendices"></a>Appendix</h3><p class="toc">A <a href="#N108A5">Acknowledgments</a><br>
</p></div><hr><div class="body"><div class="div1">
<h2><a id="intro" name="intro"></a>1 Introduction</h2><p>
        The W3C XML Binary Characterizations Working Group (XBC WG) has evaluated a
        set of use cases across a variety of domains which establish the potential benefits of
        "binary XML". We recommend that the W3C proceed to produce
        such a recommendation.
      </p><p>
        We believe such a format will not be successful if it does not maintain
        interoperability with XML and the family of XML-related standards.
        In order to preserve XML interoperability producing a Binary XML
        recommendation must be a W3C activity.
      </p><p>
        The use cases have been analyzed to determine the minimum set of
        requirements which
        Binary XML must meet. This has been done by defining a single
        set of properties of formats and then stating
        use case requirements in terms of those properties. The properties
        can then be further understood in terms of the number of use cases
        which require them, their presence or absence in XML, and so forth.
      </p><p>
        Most of these required properties
        can be met by existing solutions. However, none of those solutions
        have been adopted in all or even most of the represented domains.
        At the same time, there
        are sufficiently many existing solutions to demonstrate the feasibility
        of creating a format which meets the majority of the requirements.
      </p><p>
        The remainder of this document contains a detailed analysis. Section 2
        provides background on the notion of "binary XML" and attempts a pragmatic
        definition of the term. It also describes our approach to the
        analysis.
      </p><p>
        Sections 3 through 7 form the core of the analysis. Section 3 enumerates
        required properties informed by W3C architectural principles.
        Section 4 enumerates required properties
        derived from the use cases. Section 5 analyzes all collected properties
        based on how they would affect interoperability with XML. Section 6
        consolidates the analysis of the previous three sections and contains
        the minimum required property list for "binary XML". Section 7 addresses
        the feasibility of a recommendation which might meet those requirements.
      </p><p>
        Section 8 concludes with a recommendation for proceeding with the
        development of "binary XML".
      </p></div><div class="div1">
<h2><a id="N10095" name="N10095"></a>2 Background</h2><p>
        The debate over "binary XML" has been common place since
	XML's inception. It arises because as a successful, widely adopted
	standard there are good reasons to adopt XML <a href="#XML10">[XML 1.0]</a>
	<a href="#XML11">[XML 1.1]</a> yet, at the same time,
	various properties of the format make it unsuitable for some uses.
	Some of those properties, such as a lack of terseness, are an
	intentional part of XML. The driving notion behind "binary XML"
	is generally that it would provide an equally interoperable format with a
	different set of properties. This would make it suitable to a different
	set of use cases which are not currently well-served by XML.
	The perception of what parts of XML
	a "binary XML" standard should keep or discard often varies.
      </p><div class="div2">
<h3><a id="N100A0" name="N100A0"></a>2.1 Definition of Binary XML</h3><p>
          To discuss "binary XML" requires at least a pragmatic definition
          of the term. For purposes of this document we define <b>Binary XML</b>
          as a format which does not conform to the XML specification
          yet maintains a well-defined, useful relationship with XML.
          By "useful" we mean that practical systems may take advantage of this
          relationship with little additional effort. For example, it may be
          useful to convert a file from XML to Binary XML.
        </p><p>
          For the remainder
          of this document we use the term Binary XML (without quotation)
          to refer to this definition. Later we further examine the relationship
          of Binary XML to XML.
        </p><p>
          One of the most important questions concerning Binary XML is
 	  whether a single solution can operate efficiently on a vast
 	  and uneven set of requirements, from full-fledged GUI applications
 	  using document-oriented vocabularies such as SVG on mobile devices,
 	  to high-performance data-intensive SOAP messages sent between powerful
	  servers over broadband LANs (to take slightly caricatural examples).
	  Indeed, the domains in which XML is or could be used cover so much
	  ground, and the situations into which its adopters wish to bring
	  as much of its value as possible are so diverse, that the variety
	  of the requirements being expressed with regards to Binary XML is
	  larger than most expect. To this effect, the XBC WG has documented
	  a cross-section of these possible requirements in its Use Cases
	  document.
        </p><p>
          Other important considerations include whether the introduction of a Binary
	  XML format into the core set of XML specifications defined by the
	  W3C would be harmful to the XML ecosystem; whether leaving the definition
	  of such a solution to other, more domain-specific, organizations
	  would be better or worse; and whether standardizing a single Binary
	  XML format would be more or less valuable than not doing so.
        </p><p>
          The goals of this document are therefore to answer the following questions:
        </p><ul><li><p>
              Do the use case requirements justify either the development or adoption of a Binary XML recommendation?
              There is a cost to developing Binary XML. Justifying this cost means
              that the requirements would have to suggest a format substantially different
              from XML.
            </p></li><li><p>
              Is it possible to create a recommendation which reasonably addresses these requirements?
              It will be of little value to suggest working on something which is not feasible
              or something so complex so as to be unusable.
            </p></li></ul></div><div class="div2">
<h3><a id="N100B7" name="N100B7"></a>2.2 Analysis Methodology</h3><p>
          The efforts of the working group proceeded roughly as follows.
        </p><p>
              We began by documenting a set of use cases <a href="#use-cases">[XBC Use Cases]</a>
              which might benefit from the use of a
              widely standardized format. In most of these use cases XML has either
              been considered or adopted but not found satisfactory. Many of these
              use cases are themselves aggregations of many more distinct applications
              within their own domains. We ultimately concluded that a Binary XML standard
              should address all of the use cases we identified.
            </p><p>
              We then analyzed the requirements of each use case and,
              by comparing these requirements across use cases, created a set of
              <b>properties</b> <a href="#properties">[XBC Properties]</a>.
              These properties are either a property a
              format may possess (e.g., a format may be compact) or a property of
              software implementations which process the format (e.g., a format may permit
              implementations with a small code footprint).
            </p><p>
	  We next used these as input to answer the first question put to the
	  group, that is, do the requirements justify the development of a Binary XML standard?
	  In other words, would the properties which this format would have to possess
	  differ significantly from XML yet justify the cost of developing such a standard?
	  We derived these properties by:
	</p><ul><li><p>
	      Determining what properties the format would, by virtue of being a W3C
	      standard, need to possess.
	    </p></li><li><p>
	      Determining which properties the use case requirements suggested a Binary XML
	      standard should support.
	    </p></li><li><p>
	      Determining which properties would or would not permit Binary XML to
	      maintain a well-defined, useful relationship with XML.
	    </p></li></ul><p>
          Beginning in Section 3 we use the keywords MUST, MUST NOT, SHOULD,
          and SHOULD NOT when stating requirements on Binary XML. When these
          words appear in this document they are to be interpreted as
          described in <a href="#rfc2119">[RFC 2119]</a>.
        </p><p>
          Finally, we addressed the feasibility of the resulting set of requirements
          by looking at existing implementations and the expertise of the members of the XBC WG.
        </p></div></div><div class="div1">
<h2><a id="N100DD" name="N100DD"></a>3 W3C Requirements</h2><p>
          As a chartered activity of the W3C, we thought it essential that our
          recommendation conform with architectural principles and best practices
          laid down by the W3C <a href="#webarch">[WWWArch]</a>. As such, Binary XML
          MUST support the properties required for this conformance. The properties in this category are:
        </p><ul><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/#human-language-neutral">Human Language Neutral</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/#platform-neutrality">Platform Neutrality</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/#integratable-into-xml-stack">Integratable into XML Stack</a></p></li></ul></div><div class="div1">
<h2><a id="N10105" name="N10105"></a>4 Use Case Requirements</h2><p>
          We reviewed each property in the context of each use case and assigned it to one
          of four categories:
        </p><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 <em>must have</em> property would not simply
          make a format undesirable but actually unusable.
        </p><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 <em>should have</em>
          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><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 <em>should have</em> or
          <em>must have</em> properties for that use case.
        </p><p>
          Irrelevant: The property is generally irrelevant to the use case. However, if the inclusion
          of the property
          in the format prohibits a <em>must have</em>, <em>should have</em>, or
          <em>nice to have</em> property then it is undesirable.
        </p><p>
          The XBC Use Cases document provides a description,
          for each use case,
          of its must, should, and nice to have properties. Irrelevant properties are omitted
          from the descriptions and must be determined by their absence.
        </p><p>
          It is helpful to view the results of this exercise using the following chart.
          This chart shows, for each property, the number of use cases which
          rank it <em>must have</em> , <em>should have</em>, or <em>nice to have</em>.
          The number of use cases ranking a property as irrelevant is not explicitly indicated.
        </p><img src="PropertyDemand.png" alt="Bar chart showing the number of use cases requiring each property"><p>
	<p><a href="PropertyDemand.svg">(SVG version)</a></p>
	<p>
         The chart is sorted first by the number of use cases for which a property
         is a <em>must have</em>, then by the number of use cases for which a
         property is a <em>should have</em>, and finally by the number of use cases
         for which a property is a <em>nice to have</em>.
       </p><p>
         We began the analysis by including all properties designed as
         <em>must have</em> for at least one use case. This was the minimum
         bar which still permitted all use cases to be addressed. While we were
         prepared to eliminate use cases and thereby eliminate additional requirements
         if necessary, further analysis showed this was not the case. In part,
         this is because some requirements listed here were eliminated by the
         decision tree applied in Section 5, below. This list, therefore, continues
         to include each property which is a <em>must have</em> for at least
         one use case.
       </p><ul><li><p><a href="http://www.w3.org/TR/xbc-properties/#directly-readable-writable">Directly Readable and Writable</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/#processing-efficiency">Processing Efficiency</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/#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/#royalty-free">Royalty Free</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/#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/#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/#space-efficiency">Space Efficiency</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/#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/#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/#format-version-identification">Format Version Identification</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/#explicit-typing">Explicit Typing</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/#robustness">Robustness</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/#forward-compatibility">Forward Compatibility</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/#implementation-cost">Implementation Cost</a></p></li><li><p><a href="http://www.w3.org/TR/xbc-properties/#extension-points">Extension Points</a></p></li></ul></div><div class="div1">
<h2><a id="N101F4" name="N101F4"></a>5 Decision Tree Requirements</h2><p>
          We believe Binary XML must have a well-defined and useful relationship with
          XML. The inclusion of the property Integratable into XML Stack to 16 of the 18
          use cases supports this belief. This position can also be seen as enhancing
          interoperability not only within the Binary XML community and XML community but between
          them as well.
        </p><p>
          Some proposals for Binary XML, such as the use of GZIP <a href="#gzip">[GZIP]</a>,
          operate directly on XML, thus preserving it byte-for-byte. (The use of
          GZIP as a content encoding or transfer encoding applicable to various types
          of content including XML is standardized by HTTP 1.1 <a href="#http">[HTTP 1.1]</a>.)
          However, the importance of Directly Readable and Writable, Compactness,
          and Processing Efficiency suggest that any viable candidate must support
          all three. These three properties cannot be achieved with any approach such as GZIP which requires
          creating an XML representation as an intermediate step in creating Binary XML.
          The places an upper bound on how tightly XML and Binary XML can be coupled.
        </p><p>
          The working group observed that, of the set of properties indicated in the
          previous section, some had to be "intrinsic" properties of a new format
          but others could be obtained via other means. For example, if a Binary XML
          format is Integratable into XML Stack then it could be signable by virtue
          of integration with the XML Signatures <a href="#xml-dsig">[XMLDSig]</a> recommendation and without defining
          a new signature mechanism specific to Binary XML.
        </p><p>
          The working group addressed this issue in a systematic way for each
          property by applying the following decision tree to determine whether a property should
          be made a part of Binary XML or addressed in some other fashion.
        </p><p>
          The use of this decision tree should not be taken as a recommendation to
          either change or not change other recommendations in the XML stack. Rather,
          it recommends parity between XML and Binary XML. Subsequent recommendations in the
          XML stack, whether new or revised, should address both XML and Binary XML equally.
          For example, a revision to XML Signatures should define a canonicalization algorithm
          which does not require a conversion to XML and thus negates many benefits of Binary
          XML in some use cases.
        </p><div class="div2">
<h3><a id="N1020A" name="N1020A"></a>5.1 Property Decision Tree</h3><p>
          Does XML support the property directly?
        </p><ol class="enumar"><li><p>Yes. The Binary XML format should directly support the property.</p></li><li><p>No. Does XML support this property when combined with other recommendations in the XML stack?</p><ol class="enumla"><li><p>Yes. Binary XML should work with the other recommendations in the XML stack.</p></li><li><p>No. Is it feasible for XML to support this property? </p><ol class="enumlr"><li><p>
                      Yes. The property should be addressed by a general approach (e.g., new
                      recommendation) that works for both XML and Binary XML.
                    </p></li><li><p>
                      No. The property should be directly supported by Binary XML.
                    </p></li></ol></li></ol></li></ol></div><p>
        The decision tree divides properties into a number of categories. The following
        properties are those which the decision tree suggests Binary XML MUST support:
      </p><ul><li><p><a href="http://www.w3.org/TR/xbc-properties/#directly-readable-writable">Directly Readable and Writable</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/#processing-efficiency">Processing Efficiency</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/#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/#royalty-free">Royalty Free</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/#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/#roundtrip-support">Roundtrip Support</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/#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/#format-version-identification">Format Version Identification</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/#self-contained">Self Contained</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/#implementation-cost">Implementation Cost</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/#no-arbitrary-limits">No Arbitrary Limits</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/#localized-changes">Localized Changes</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/#single-conformance-class">Single Conformance Class</a></p></li></ul><p>
          Based on the decision tree we determined that the following properties should be
          addressed by separate
          technologies designed to work with both XML and Binary XML. Some of these
          technologies, such as for signatures and encryption, already exist. These
          properties therefore
          fall into the category of properties which Binary XML SHOULD NOT support but
          which Binary XML also SHOULD NOT prevent separate technologies from addressing:
        </p><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/#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/#signable">Signable</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/#efficient-update">Efficient Update</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/#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/#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></ul></div><div class="div1">
<h2><a id="N102EC" name="N102EC"></a>6 Minimum Binary XML Requirements</h2><p>
          The results of the analysis in the three preceding sections were
          combined to determine the minimum requirements on Binary XML.
          A property appears in the minimal requirements because either:
        </p><ol class="enumar"><li><p>It is included in order to conform with architectural principles and best practices laid down by the W3C
	  or</p></li><li><p>
            It is a <em>must have</em> property for at least one use case
            <em>and</em> should, per the decision tree, be supported directly
            by Binary XML.
          </p></li></ol><p>
          All properties met the second test. Those which also
          met the first have been annotated as such in the table.
        </p><p>
          Six of these properties are either algorithmic properties or
          additional considerations related primarily to a Binary XML
          processor implementation. Binary XML
          MUST NOT prevent an implementation from achieving
          these properties. However, an implementation might reasonably choose
          not to attain one of these properties even for a format which
          permits it. For example, an implementation may elect to trade off
          achieving Small Footprint for further improvements in Processing
          Efficiency. These properties are therefore stated
          as MUST NOT Prevent requirements intead of MUST Support requirements.
        </p><table rules="all" border="1"><tbody><tr><th>Property</th><th>W3C</th></tr><tr><th colspan="2" align="center">MUST Support</th></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#directly-readable-writable">Directly Readable and Writable</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#transport-independence">Transport Independence</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#compactness">Compactness</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#human-language-neutral">Human Language Neutral</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#platform-neutrality">Platform Neutrality</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#integratable-into-xml-stack">Integratable into XML Stack</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#royalty-free">Royalty Free</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#fragmentable">Fragmentable</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#streamable">Streamable</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#roundtrip-support">Roundtrip Support</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#generality">Generality</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#schema-extensions-deviations">Schema Extensions and Deviations</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#format-version-identification">Format Version Identifier</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#content-type-management">Content Type Management</a></td><td>W3C</td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#self-contained">Self Contained</a></td><td></td></tr><tr><th colspan="2" align="center">MUST NOT Prevent</th></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#processing-efficiency">Processing Efficiency</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#small-footprint">Small Footprint</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#widespread-adoption">Widespread Adoption</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#space-efficiency">Space Efficiency</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#implementation-cost">Implementation Cost</a></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/xbc-properties/#forward-compatibility">Forward Compatibility</a></td><td></td></tr></tbody></table></div><div class="div1">
<h2><a id="N103F4" name="N103F4"></a>7 Feasibility of Binary XML</h2><p>
        For Binary XML to be a widely accepted standard it should successfully
        address a wide and varied range of problems that may involve different,
        and occasionally, conflicting requirements. This quality has been
        captured by the Generality property which is a property Binary XML
        MUST support. As the Use Cases document shows, XML does
        not achieve the desired degree of generality, i.e. it is not compact
        enough for some applications, it does prevent certain degrees of
        efficiency for others, it lacks certain features for yet others, etc.
      </p><p>
        However, it would be of little value to recommend the creation of
        Binary XML if it is not feasible to balance these many constraints.
        In evaluating the feasibility of a single standard Binary XML format
        the working group relied on the following two factors:
	</p><ul><li><p>
            Numerous candidate algorithms and implementations already exist which
            demonstrate sufficient support for different combinations of the
            required properties identified in this document.
          </p></li><li><p>
            There is a consensus  in the Working Group, based on significant collective
            experience of participants and organizations they represent, that such
            format is feasible.
          </p></li></ul><p>
        The table below provides the characterization of existing formats in regard
        to the list of required properties identified in Section 5 of this document.

        The Working Group has not done any measurements on submitted formats. Their
        placement in the table is no way an endorsement of any
        of these formats as being appropriate for a standardization activity.
      </p><table border="1"><tbody><tr><th>Format</th><th>XML</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th></tr><tr><th colspan="11" align="center">MUST Support</th></tr><tr><td>Directly Readable &amp; Writable</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Transport Independence</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Compactness</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td></tr><tr><td>Human Language Neutral</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Platform Neutrality</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Integratable into XML Stack</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Royalty Free</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>Fragmentable</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Streamable</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Roundtrip Support</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>Generality</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Schema Extensions and Deviations</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Format Version Identifier</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Content Type Management</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Self-Contained</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td></tr><tr><th colspan="11" align="center">MUST NOT Prevent</th></tr><tr><td>Processing Efficiency</td><td>Prevents</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr><tr><td>Small Footprint</td><td>Prevents</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr><tr><td>Widespread Adoption</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr><tr><td>Space Efficiency</td><td>Prevents</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr><tr><td>Implementation Cost</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr><tr><td>Forward Compatibility</td><td>Prevents</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td><td>Does Not Prevent</td></tr></tbody></table><p>Notes:</p><ul><li>
1-- Compactness: No (neither and (maybe) schema) - Generality: No (13/20)
</li><li>
2-- Compactness: Yes (both schema and compression) - Royalty Free: No (likely but not at this point) - Round Trip Support: Yes (Lossless Equivalence) - Generality: No (13/20)
</li><li>
3-- Compactness: Yes (all categories) - Generality: Yes (19/20)
</li><li>
4-- Compactness: No (Yes for Schema + Neither) - Generality: No (11/20)
</li><li>
6-- Compactness: Yes (all categories) - Generality: No (13/20)
</li></ul><p>References:</p><ul><li>Efficient XML</li><li>esXML</li><li>Fast Infoset</li><li>Fujitsu binary</li><li>MPEG-7 BiM</li><li>X.694 with BER </li><li>X.694 with PER </li><li>Xebu</li></ul></div><div class="div1">
<h2><a id="N107D4" name="N107D4"></a>8 Conclusions</h2><p>
        The XBC WG developed 18 extensive use cases and documented 38 different
        format properties and considerations which those use cases might require.
        The sheer number of requirements has suggested to some that either Binary
        XML is not achievable or, in attempt to satisfy too many requirements,
        is destined to collapse under its own weight.
      </p><p>
        After conducting our analysis the consensus in the WG is confident that creation and adoption
        of Binary XML can be reasonably achieved. After a thorough analysis, 17
        of the properties (nearly half) did not make the minimum requirements list. From those that remain, 6 of those that remain are derived from W3C architectural principles and
        would presumably be required of any W3C Recommendation.
      </p><p>
        Using the decision tree-based analysis suggests another 11 properties
        which, if addressed, should be addressed in the XML stack and <em>not</em>
        as part of Binary XML itself. While a complete set of requirements for
        Binary XML is outside the scope of this document it is clear that
        development of a Binary XML recommendation would not need to satisfy all
        38 properties to achieve success.
      </p><p>
        This achievable minimum requirements list will address the <em>must have</em>
        requirements of all use cases. While excluding certain use cases might have made
        Binary XML yet more achievable, it would also have made it less widely applicable.
      </p><p>
        In conclusion:
      </p><p>
        <em>Binary XML is needed.</em> Working Group domain experts have
        collected and examined a comprehensive set
        of use cases which establish this need for Binary XML.
        The use cases lay out the properties Binary XML must possess
        in order to be successful. Formats which possess these properties are
        being adopted now within the represented domains.
      </p><p>
        <em>Binary XML is feasible.</em> The number of required properties determined to be
        <em>must haves</em> for adoption by the use cases is less than half of the nearly
        forty properties identified. Evaluation of existing approaches has shown that there is
        at least one format capable of implementing all the required properties.
      </p><p>
        <em>The W3C must produce Binary XML.</em> Many of the represented
        domains are already adopting Binary XML formats. In order to preserve XML
        interoperability and to prevent the establishment of multiple, incompatible binary
        formats, producing a standard Binary XML must be a W3C activity.
      </p><p>
        <em>Binary XML must integrate with XML.</em> The required properties make it clear
        that Binary XML must integrate with the existing XML stack and not require
        changes to XML itself. Binary XML
        will significantly widen the domains to which XML expertise and software
        will apply.
      </p></div><div class="div1">
<h2><a id="N107FF" name="N107FF"></a>9 References</h2><dl><dt class="label"><a id="use-cases" name="use-cases"></a>XBC Use Cases</dt><dd>
          <a href="http://www.w3.org/TR/xbc-use-cases/"><cite>XML Binary Characterization Use Cases</cite></a>
          (See http://www.w3.org/TR/xbc-use-cases/.)</dd><dt class="label"><a id="properties" name="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><dt class="label"><a id="meas" name="meas"></a>XBC Measurement Methodologies</dt><dd>
          <a href="http://www.w3.org/TR/xbc-measurement/"><cite>XML Binary Characterization Measurement Methodologies</cite></a>
          (See http://www.w3.org/TR/xbc-measurement/.)</dd><dt class="label"><a id="XML10" name="XML10"></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><dt class="label"><a id="XML11" name="XML11"></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><dt class="label"><a id="xml-dsig" name="xml-dsig"></a>XMLDSig</dt><dd>
          <a href="http://www.w3.org/TR/xmldsig-core/"><cite>XML-Signature Syntax and Processing</cite></a>
          (See http://www.w3.org/TR/xmldsig-core/.)</dd><dt class="label"><a id="webarch" name="webarch"></a>WWWArch</dt><dd>
          <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>
          (See http://www.w3.org/TR/webarch/.)</dd><dt class="label"><a id="gzip" name="gzip"></a>GZIP</dt><dd>
          <a href="http://www.ietf.org/rfc/rfc1952.txt"><cite>GZIP file format specification version 4.3</cite></a>
          (See http://www.ietf.org/rfc/rfc1952.txt.)</dd><dt class="label"><a id="http" name="http"></a>HTTP 1.1</dt><dd>
          <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol -- HTTP/1.1</cite></a>
          (See http://www.ietf.org/rfc/rfc2616.txt.)</dd><dt class="label"><a id="rfc2119" name="rfc2119"></a>RFC 2119</dt><dd>
          <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>
          (See http://www.ietf.org/rfc/rfc2119.txt.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a id="N108A5" name="N108A5"></a>A Acknowledgments</h2><p>
        The editors would like to thank the many contributors from the working group:
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>