index.html 12.5 KB
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>XOP Inclusion Mechanism - Frequently Asked Questions</title>
    <style type="text/css">
      .issue {
      background-color:#dfd;
      border: thin solid black;
      color:black;
      }

      .designSketch {
      background-color:#fdf;
      border: thin solid black; 
      color:black;
      }

      .illustration {
      margin-left:auto;
      margin-right:auto;
      text-align:center; 
      }

      .example {
      margin-left:auto;
      margin-right:auto;
      padding-top:0.5em;
      padding-bottom:0.5em;
      width:70%;
      border-top:thin dashed black;
      border-bottom:thin dashed black;
      }
    </style>
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" />
  </head>

  <body xml:lang="en-US" lang="en-US">
    <div class="head">
<a href="http://www.w3.org/"><img alt="W3C" src="http://www.w3.org/Icons/w3c_home" height="48" width="72" /></a>

     <h1>XOP Inclusion Mechanism - Frequently Asked Questions</h1>

      <h2>W3C Working Group Note 8 June 2004</h2>

	<dl> 
	  <dt>This Version:</dt>
	  <dd><a href="http://www.w3.org/TR/2004/NOTE-xopinc-FAQ-20040608/">http://www.w3.org/TR/2004/NOTE-xopinc-FAQ-20040608/</a></dd>
	  <dt>Latest Version:</dt>
	  <dd><a href="http://www.w3.org/TR/xopinc-FAQ/">http://www.w3.org/TR/xopinc-FAQ/</a></dd>
	  <dt>Authors:</dt>
	  <dd>Michael Mahan, Nokia</dd> 
	</dl>

	<p class="copyright"><a
	    href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
	  &#169; 2004 <a href="http://www.w3.org/"><acronym
	      title="World Wide Web Consortium">W3C</acronym></a><sup>&#174;</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> and <a
	    href="http://www.w3.org/Consortium/Legal/copyright-software">software
	    licensing</a> rules apply.</p>
      </div>
      <hr />

      <h2>Abstract</h2>

      <p>This document lists and provides answers to some frequently asked
	questions about the design decisions behind the choice of include
	mechanism by the <a href="http://www.w3.org/2000/xp/Group/">XML
	  Protocol Working Group</a> during construction of <a href="http://www.w3.org/TR/xop10/">XML-binary
	  Optimized Packaging</a> (XOP). For more information about <a href="http://www.w3.org/TR/xop10/">XOP</a>,
	see the <a href="http://www.w3.org/2000/xp/Group/">Working Group Home
	  Page.</a></p>

      <div>
	<h2>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 the <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#q74">First
	Working Group Note</a> of the Frequently Asked Questions document about the
<a href="http://www.w3.org/TR/xop10/">XOP</a> Inclusion Mechanism. It has been produced by the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a> (WG),
	which is part of the <a href="http://www.w3.org/2002/ws/Activity"> Web Services
	  Activity</a>. The WG has produced this document to answer questions that have commonly and recently been asked about <a href="http://www.w3.org/TR/xop10/">XOP</a>, it does not intend to update the document.

      </p>

      <p>
	Comments should be sent to the <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a> mailing
	list <a href="http://lists.w3.org/Archives/Public/xmlp-comments/">(public
	  archive)</a>.</p>

      <p>This document has been produced under the 
<a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended 
by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>. 
An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s)
 with respect to this specification should disclose the information in accordance with section 6 of the 
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">W3C Patent Policy</a>.
	Patent disclosures relevant to this specification may be found on the
	Working Group's <a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent
	  disclosure page</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>
	<h2 id="toc">Contents</h2>
	<ol>
	  <li><a href="#q1">Why does XMLP need an include mechanism for its work?</a> </li>
	  <li><a href="#q2">What is XInclude?</a></li>
	  <li><a href="#q3">So XOP uses XInclude, right?</a></li>
	  <li><a href="#q4">What include mechanism did XML Core and XMLP agree was most appropriate for XOP and what is prime rationale?</a></li>
	  <li><a href="#q5">What is xop:Include?</a></li>
	  <li><a href="#q6">What are the technical arguments why XOP SHOULD NOT use XInclude?</a></li>
	  <li><a href="#q7">What are the technical arguments why XOP SHOULD use XInclude?</a></li>
	  <li><a href="#q8">What are other non-technical issues?</a></li>
	  <li><a href="#q9">Can this design decision be revisited?</a></li>
	</ol>
      </div>

      <div>
	<h2><a id="q1" name="q1"></a><span class="gen">1.</span> Why does XMLP need an include mechanism for its work?</h2>
	<p>The XMLP working group has created a specification called XOP
	  (XML-binary Optimized Packaging) that defines an efficient
	  convention for serializing XML Infosets for
	  binary content. XOP defines a mechanism to take selected binary data
	  from a source Infoset and place them in the
	  XOP package. The location of the selected binary data must be marked
	  in the serialized XML using some include mechanism. This include
	  mechanism provides the link to the packaged binary data using URIs.
	</p>

	<h2><a id="q2" name="q2"></a><span class="gen">2.</span> What is XInclude?</h2>
	<p>XML Core WG developed <a href="http://www.w3.org/TR/xinclude/">XInclude</a>,
	  a processing model and syntax for general purpose inclusion for XML
	  documents in order to facilitate document modularity.</p>

	<h2><a id="q3" name="q3"></a><span class="gen">3.</span> So XOP uses XInclude, right?</h2>
	<p>The XMLP WG decided that XOP will not reuse XInclude. Instead XMLP
	  WG created a new element, xop:Include, whose semantics
	  are tailored to the use case which XMLP is targeted to solve. XML
	  Core raised an objection to this design choice. A series of emails
	  between the working groups culminated in a joint face to face meeting
	  on Feb 28, 2004 in Cannes, France to resolve the issue.</p>

	<h2><a id="q4" name="q4"></a><span class="gen">4.</span> What include mechanism did XML Core and XMLP agree was most appropriate for XOP and what is the prime rationale?</h2>
	<p>The agreed resolution is for XMLP XOP to continue with its include
	  mechanism, xop:Include. The overriding rationale was that XInclude
	  contains many features and facilities that XOP does not require.
	  Hence, XOP usage of XInclude could result in abuse and interop
	  problems, thus creating a more risky than beneficial solution.
	  Supporting full XInclude processing, without receiving the benefits
	  of XInclude features, runs counter to one the principal XOP
	  requirements &ndash; the optimized processing of binary data.</p>


	<h2><a id="q5" name="q5"></a><span class="gen">5.</span> What is xop:Include?</h2>
	<p>It is a minimal include element that defines one mandatory href
	  attribute information item for the URI link to the related MIME part
	  in a XOP package. Additionally, xop:Include has available from its
	  owner element the content-type of the binary data of the same MIME
	  part.</p>

	<h2><a id="q6" name="q6"></a><span class="gen">6.</span> What were the technical arguments why XOP SHOULD NOT use XInclude?</h2>
	<p>The overriding reason is that the benefit of XInclude reuse does
	  not override the cost of added complexity. This is because reuse of
	  XInclude features is low relative to XMLP attachment requirements. In
	  particular, XInclude's features for general
	  inclusion not required or desired by XOP are:</p>
	<ul>
	  <li>Nested includes</li>
	  <li>Namespace fix-ups</li>
	  <li>Use of XPointer/XPath</li>
	  <li>Extra media-type support, i.e. Text</li>
	</ul>
	<p>Other technical reasons are:</p>
	<ul>
	  <li>xop:Include implementation would
	      be simpler and smaller compared to
	      XInclude implementation. This is especially relevant for 
	    constrained processors.</li>
	  <li>XInclude would apparently need a
	      new base64Binary parse type to allow binary data to be merged into
	      an Infoset. The CIIs of this parse type need study to determine
	      whether they should be in canonical form or not.</li>
	  <li>Differentiating XIncludes
	      used by XOP and by application layer.</li>
	  <li>Security: in general, security and
	      correctness issues dictate that the only legal target of an
	      xop:Include be a part within the same multipart
	      related. Any generalized implementation of XInclude that failed to
	      check this would introduce security errors. On the other hand, if
	      one had to provide special code in SOAP to parse the link target and
	      check it before calling an include resolver, then some of the
	      advantage of a generalized implementation is lost, and there is
	      potential duplicate overhead in dealing with the same attribute
	      twice.</li>
	  <li>Cost of managing cross-references between multiple specs is
	      high relative to the small functional overlap between XInclude and
	      XOP.</li>
	</ul>

	<h2><a id="q7" name="q7"></a><span class="gen">7.</span> What were the technical arguments why XOP SHOULD use XInclude?</h2>
	<ul>
	  <li>Having XML with binary attachments
	      can be solved with some existing, but underutilized, features of
	      MIME plus a small extension to XInclude &ndash; the addition of a
	      &lsquo;parse=base64&rsquo; to causes the resource to be treated as a
	      sequence of octets and then included as the character information
	      items resulting from base64 encoding of those octets. Hence, a
	      minor change to XInclude can then handle the XMLP attachment
	      requirement. 
	    </li>
	  <li>Implementation benefit: XOP can
	      use the &lsquo;standard&rsquo; XML
	      inclusion technology. This would enable simpler
	      merging of XOP with generic XInclude software. 
	    </li>
	  <li>Specification benefit: XOP would
	      be used to qualify and profile XInclude. Reuse of syntax is highly
	      desirable. Point made that reuse of small
	      portion of XInclude is not such a big deal and there is precedence
	      for this. 
	    </li>
	  <li>Documentation benefit: Documentation reuse enables
	      generalized reuse of tools and applications. 
	    </li>
	</ul>

	<h2><a id="q8" name="q8"></a><span class="gen">8.</span> What are other non-technical issues?</h2>
	<p>It is highly desirable that only one XML
	  inclusion mechanism is supported by the W3C and its membership. This
	  is a goal the W3C working groups and coordination group strive to
	  receive. If W3C supports multiple technologies that covers a specific
	  area, we may be sending out a confusing message. However, in this
	  case, the requirements are sufficiently disjoint to justify two
	  inclusion mechanisms.</p>

	<h2><a id="q9" name="q9"></a><span class="gen">9.</span> Can this decision be revisited?</h2>
	<p>Yes. XMLP will reopen this issue should XMLP find they have to
	  make use of more XInclude functionality.</p>
      </div>
    </body>
</html>