XML-binary Optimized Packaging

1.1 Terminology

The following terms are used in this specification:

• Original Data Model - An XML Data Model to be optimized
• Original XML Infoset - An XML Infoset to be optimized.
• Extracted Content - Optimized content which has been removed from the Data Model.
• XOP Data Model - The Original Data Model with any Extracted Content removed and replaced by xop:Include elements.
• XOP Document - A serialization of the XOP Data Model using XML 1.0.
• XOP Package - A package containing the XOP Document and any Extracted Content. As a whole, the XOP Package is an alternate serialization of the Original Data Model.
• Reconstituted Data Model - An XML Data Model that has been constructed from the parts of a XOP Package.
• Reconstituted XML Infoset - An XML Infoset that has been constructed from the parts of a XOP Package.

Figure 1: Architecture of the XOP framework

1.2 Example

Example 1 shows an XML Infoset prior to XOP processing. Example 2 shows the same Infoset, serialized using the XOP format in a MIME Multipart/Related package. The base64-encoded content of the m:photo and m:sig elements have been replaced by a xop:Include element, while the binary octets have been serialized in separate MIME parts.

<soap:Envelope
    xmlns:soap='https://www.w3.org/2003/05/soap-envelope' 
    xmlns:xop='https://www.w3.org/2003/12/xop/include' 
    xmlns:xop-mime='https://www.w3.org/2003/12/xop/mime'>
  <soap:Body>
    <m:data xmlns:m='https://example.org/stuff'>
      <m:photo xop-mime:content-type='image/png'>
        /aWKKapGGyQ=
      </m:photo>
      <m:sig xop-mime:content-type='application/pkcs7-signature'>
        Faa7vROi2VQ=
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
	      type=text/xml;start="<mymessage.xml@example.org>"
Content-Description: An XML document with my picture and signature in it
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope
    xmlns:soap='https://www.w3.org/2003/05/soap-envelope'
    xmlns:xop='https://www.w3.org/2003/12/xop/include'
    xmlns:xop-mime='https://www.w3.org/2003/12/xop/mime'>
  <soap:Body>
    <m:data xmlns:m='https://example.org/stuff'>
      <m:photo xop-mime:content-type='image/png'>
        <xop:Include href='cid:https://example.org/me.png'/>
      </m:photo>
      <m:sig xop-mime:content-type='application/pkcs7-signature'>
        <xbinc:Include href='cid:https://example.org/my.hsh'/>
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <https://example.org/me.png>
// binary octets for png
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <https://example.org/my.hsh>
// binary octets for signature
--MIME_boundary--

1.3 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].

This specification uses a number of namespace prefixes throughout; they are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

2.1 MIME Multipart/Related XOP Packages

This section describes how MIME Multipart/Related packaging (as specified in [RFC 2387]) is used with XOP.

The root MIME part is the root part of the package, and MUST be an XML 1.0 serialization [XML 1.0] of the XOP Data Model, as defined below, and MUST be identified with the [ TBD ] media type.

Except for purposes of determining the root MIME part, as specified by [RFC 2387], ordering of MIME parts MUST NOT be considered significant to XOP processing or to the construction of the XOP Data Model.

Part metadata is reflected in MIME header fields. Specifically, if the URI used in the value of a xop:Include element's href attribute has a 'cid' scheme, the corresponding MIME part's Content-ID header field MUST have a corresponding field-value. Otherwise, the MIME part's Content-Location header field MUST have a field-value identical to the URI in the value of the href attribute.

Furthermore, if a xop-mime:content-type header is found (as described in 4. XOP's Processing Model), it SHOULD be reflected in the MIME Content-Type header's field-value.

3.1 xop:Include Element Node

The xop:Include Element Node property values are as follows:

• node-name MUST be {https://www.w3.org/2003/12/xop/include;Include} .
• type MUST be {https://www.w3.org/2003/12/xop/include;Include} .
• children MUST NOT contain any Element Node.
• There MAY be more than one Attribute Nodes comprising attributes. Among these MUST be the following:
  • href Attribute Node (see 3.2 href Attribute Node).
• nilled MUST be false.
• Other properties such as base-uri, parent nad namepsaces MUST be set according to the context.

3.2 href Attribute Node

The href Attribute Node has the following Data Model property values:

• node-name MUST be {;href} .
• string-value MUST be a representation of a URI referencing the part of the package containing the data logically included by the parent Element Node (i.e., the xop:Include Element Node).
• parent MUST be the xop:Include Element Node which is parent of the Attribute Node.
• type MUST be {https://www.w3.org/2001/XMLSchema;anyURI} .

3.3 xop-mime:content-type Attribute Node

The xop-mime:content-type Attribute Node has the following Data Model property values:

• node-name MUST be {https://www.w3.org/2003/12/xop/mime;content-type} .
• string-value MUST be the content-type of the binary data represented as base64 encoded data in the Element Node parent of this Attribute Node.
• parent MUST be set according to the context.
• type MUST be {https://www.w3.org/2003/12/xop/mime;content-type} .

4.1 Creating XOP Packages

To create a XOP Package from an Original XML Infoset or an Original Data Model:

1. If starting with an Original XML Infoset, create an Original Data Model as described in A.1 XOP Infoset to Data Model Mapping; otherwise, proceed using the supplied Original Data Model.
2. Ensure that the Original Data Model contains no Element Node with a node-name of {https://www.w3.org/2003/12/xop/include;Include} . As discussed in 3. XOP Data Models Constructs, Data Models with such Element Node cannot be represented using XOP.
3. Create an empty package.
4. Identify within the Original Data Model the Element Nodes to be optimized. Such Nodes MUST have type equal to xs:base64Binary , and the return value of the dm:string-value accessor of such Nodes must be in the canonical lexical representation of that type as described in Errata in XML Schema, E2-54.
5. Create a XOP Data Model which is a copy of the Original Data Model, but with the children of each Element Node identified in the previous step replaced by a xop:Include Element Node (see 3.1 xop:Include Element Node) constructed as follows:
   1. Transform the replaced characters into binary data by processing them as base64-encoded data.
   2. Serialize the binary data into a new part of the package, with appropriate metadata corresponding to the string-value of the href Attribute Node of the xop:Include Element Node (see 3.2 href Attribute Node).
   3. If the Node being optimized (i.e., the parent of the newly inserted xop:Include Element Node) has a xop-mime:content-type Attribute Node, its value SHOULD be reflected appropriately in the part's metadata.
6. Serialize the resulting XOP Data Model into the package as XML 1.0 and identify it as the root part according to the packaging mechanism's convention.

Additional parts MAY be added to the package to satisfy application specific requirements. Other content-specific metadata MAY be reflected in the packaging metadata as appropriate.

If content cannot be successfully encoded into the XOP Data Model, implementations SHOULD behave as if that portion of the Original Data Model was not nominated for optimization.

4.2 Interpreting XOP Packages

To create a Reconstituted Data Model or a Reconstituted XML Infoset from a XOP Package:

1. Parse the root part of the package as an XML 1.0 document to construct an XML Infoset (see [XML InfoSet]). From that, construct a Data Model using the Infoset to Data Model mapping described in [XML Query Data Model] Construction from an Infoset.
2. Using that Data Model, for each Element Node which has as its children a xop:Include Element Node (as defined in 3.1 xop:Include Element Node):
   1. Locate the part of the package corresponding to the URI in the xop:Include 's href Attribute Node (i.e., corresponding to the URI encoded in the Attribute Node's string-value).
   2. Replace the Element Node's children with a Text Node containing the canonical base64 encoding of the entity body of the identified package part (i.e., effectively replace the xop:Include Element Node with the data reconstructed from the package part).
3. If a reconstructed XML Infoset is needed, use the mapping described in A.2 XOP Data Model to Infoset Mapping to create the required Reconstructed XML Infoset from the Reconstructed Data Model.