XOP Inclusion Mechanism - Frequently Asked Questions

Status of this Document

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 W3C technical reports index at http://www.w3.org/TR/.

This is the First Working Group Note of the Frequently Asked Questions document about the XOP Inclusion Mechanism. It has been produced by the XML Protocol Working Group (WG), which is part of the Web Services Activity. The WG has produced this document to answer questions that have commonly and recently been asked about XOP, it does not intend to update the document.

Comments should be sent to the [email protected] mailing list (public archive).

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. 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 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

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.

1. Why does XMLP need an include mechanism for its work?

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.

2. What is XInclude?

XML Core WG developed XInclude, a processing model and syntax for general purpose inclusion for XML documents in order to facilitate document modularity.

3. So XOP uses XInclude, right?

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.

4. What include mechanism did XML Core and XMLP agree was most appropriate for XOP and what is the prime rationale?

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 – the optimized processing of binary data.

5. What is xop:Include?

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.

6. What were the technical arguments why XOP SHOULD NOT use XInclude?

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:

Nested includes
Namespace fix-ups
Use of XPointer/XPath
Extra media-type support, i.e. Text

Other technical reasons are:

xop:Include implementation would be simpler and smaller compared to XInclude implementation. This is especially relevant for constrained processors.
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.
Differentiating XIncludes used by XOP and by application layer.
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.
Cost of managing cross-references between multiple specs is high relative to the small functional overlap between XInclude and XOP.

7. What were the technical arguments why XOP SHOULD use XInclude?

Having XML with binary attachments can be solved with some existing, but underutilized, features of MIME plus a small extension to XInclude – the addition of a ‘parse=base64’ 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.
Implementation benefit: XOP can use the ‘standard’ XML inclusion technology. This would enable simpler merging of XOP with generic XInclude software.
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.
Documentation benefit: Documentation reuse enables generalized reuse of tools and applications.

8. What are other non-technical issues?

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.

9. Can this decision be revisited?

Yes. XMLP will reopen this issue should XMLP find they have to make use of more XInclude functionality.