Six new or updated specifications related to binary content have been released by members of the W3C XML Protocol Working Group and Web Services Description Working Group. Both Working Groups are part of the W3C Web Services Activity.

XML-binary Optimized Packaging and SOAP Message Transmission Optimization Mechanism are now Last Call Working Drafts which enhance SOAP Version 1.2 performance. Feedback on these WDs may be sent to the XML Protocol Working Group through 2004-06-29.

The XML-binary Optimized Packaging (XOP) convention provides a means of more efficiently serializing XML Infosets that have certain types of content. A concrete implementation of the XOP format designed for carrying SOAP messages is defined in the SOAP Message Transmission Optimization Mechanism Working Draft; it describes both an abstract feature and a concrete implementation of XOP for optimizing the transmission and/or wire format of SOAP messages.

A new W3C Note written by Michael Mahan (Nokia) answers questions about design decisions in the choice of the include mechanism selected by the XML Protocol Working Group during construction of XML-binary Optimized Packaging (XOP). XOP Inclusion Mechanism: Frequently Asked Questions explains the use of xop:Include as a "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."

The SOAP 1.2 Attachment Feature Note "defines a SOAP feature that represents an abstract model for SOAP attachments. It provides the basis for the creation of SOAP bindings that transmit such attachments along with a SOAP envelope, and provides for reference of those attachments from the envelope. SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message part and zero or more related documents parts known as attachments."

An updated SOAP Optimized Serialization Use Cases and Requirements Working Draft document "serves to motivate and constrain the scope of the XML Protocol WG's work on a SOAP Message Transmission Optimization Mechanism.

A new Assigning Media Types to Binary Data in XML Working Draft "addresses the need to indicate the media type associated with binary element content in an XML document and the need to specify, in XML Schema, the expected media types associated with binary element content. It is expected that the additional information about the media type will be used for optimizing the handling of binary data that is part of a Web services message."

Bibliographic Information and Overview

• XML-binary Optimized Packaging. Edited by Noah Mendelsohn (IBM), Mark Nottingham (BEA), and Hervé Ruellan (Canon). W3C Working Draft. 08-June-2004. Version URL: http://www.w3.org/TR/2004/WD-xop10-20040608/. Latest version URL: http://www.w3.org/TR/xop10/. Previous version URL: http://www.w3.org/TR/2004/WD-xop10-20040209/.

  "This document defines the XML-binary Optimized Packaging (XOP) convention, a means of more efficiently serializing XML Infosets that have certain types of content...

  A XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Related, see RFC 2387). Then, selected portions of its content that are base64-encoded binary data are re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.

  In a number of important XOP applications, binary data need never be encoded in base64 form. If the data to be included is already available as a binary octet stream, then either an application or other software acting on its behalf can directly copy that data into a XOP package, at the same time preparing suitable linking elements for use in the root part; when parsing a XOP package, the binary data can be made available directly to applications, or, if appropriate, the base64 binary character representation can be computed from the binary data.

  However, at the conceptual level, this binary data can be thought of as being base64-encoded in the XML Document. As this conceptual form might be needed during some processing of the XML Document (e.g., for signing the XML document), it is necessary to have a one to one correspondence between XML Infosets and XOP Packages. Therefore, the conceptual representation of such binary data is as if it were base64-encoded, using the canonical lexical form of XML Schema base64Binary datatype (see XML Schema Part 2, 3.2.16 base64Binary). In the reverse direction, XOP is capable of optimizing only base64-encoded Infoset data that is in the canonical lexical form.

  As a result, only element content can be optimized; attributes, non-base64-compatible character data, and data not in the canonical representation of the base64Binary datatype cannot be successfully optimized by XOP..."

• SOAP Message Transmission Optimization Mechanism. Edited by Noah Mendelsohn (IBM), Mark Nottingham (BEA), and Hervé Ruellan (Canon). W3C Working Draft. 08-June-2004. Version URL: http://www.w3.org/TR/2004/WD-soap12-mtom-20040608/. Latest version URL: http://www.w3.org/TR/soap12-mtom/. Previous version URL: http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/.

  "This document describes an abstract feature and a concrete implementation of it for optimizing the transmission and/or wire format of SOAP messages. The concrete implementation relies on the XML-Binary Optimized Packaging (XOP) format for carrying SOAP messages.

  The first part of this document describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message (SOAP Part 1) by selectively encoding portions of the message, while still presenting an XML Infoset to the SOAP application.

  The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no mandatory convention for optimization of SOAP transmission through intermediaries. The feature does provide optional means by which binding implementations MAY choose to facilitate the efficient pass-through of optimized data contained within headers or bodies relayed by an intermediary (see 2.3.4 Binding Optimizations at Intermediaries). Additional specifications might also be written to provide for other optimized multi-hop capabilities, perhaps building on the mechanisms provided herein.

  The second part describes an Optimized MIME Multipart/Related Serialization of SOAP Messages implementing the Abstract Transmission Optimization Feature in a binding independent way. This implementation relies on the XOP format.

  The third part uses this Optimized MIME Multipart/Related Serialization of SOAP Messages for describing an implementation of the Abstract Transmission Optimization Feature for the SOAP 1.2 HTTP binding (see SOAP Part 2 7. SOAP HTTP Binding)..."

• XOP Inclusion Mechanism: Frequently Asked Questions. By Michael Mahan (Nokia). W3C Working Group Note. 08-June-2004. Version URL: http://www.w3.org/TR/2004/NOTE-xopinc-FAQ-20040608/. Latest Version URL: http://www.w3.org/TR/xopinc-FAQ/.

  "This document lists and provides answers to some frequently asked questions about the design decisions behind the choice of include mechanism by the XML Protocol Working Group during construction of XML-binary Optimized Packaging (XOP)...

  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...

  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..."

• SOAP 1.2 Attachment Feature. Edited by Henrik Frystyk Nielsen (Microsoft) and Hervé Ruellan (Canon). W3C Working Group Note. 08-June-2004. Version URL: http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/. Latest version URL: http://www.w3.org/TR/soap12-af/. Previous version URL: http://www.w3.org/TR/2002/WD-soap12-af-20020924/.

  "This document defines a SOAP feature that represents an abstract model for SOAP attachments. It provides the basis for the creation of SOAP bindings that transmit such attachments along with a SOAP envelope, and provides for reference of those attachments from the envelope. SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message part and zero or more related documents parts known as attachments."

• SOAP Optimized Serialization Use Cases and Requirements. Edited by Tony Graham (Sun Microsystems), Anish Karmarkar (Oracle Corp), and Mark Jones (AT&T). W3C Working Draft. 08-June-2004. Version URL: http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/. Latest version URL: http://www.w3.org/TR/soap12-os-ucr/. Previous version URL: http://www.w3.org/TR/2003/WD-soap12-os-ucr-20031112/.

  "This document records the use cases and specifies the requirements for optimizing the processing and serialization of SOAP messages."

• Assigning Media Types to Binary Data in XML. Edited by Anish Karmarkar (Oracle Corporation) and Ümit Yalçinalp (Oracle Corporation). W3C Working Draft. 8-June-2004. Version URL: http://www.w3.org/TR/2004/WD-xml-media-types-20040608. Latest version URL: http://www.w3.org/TR/xml-media-types.

  "This document addresses the need to indicate the media type associated with binary element content in an XML document and the need to specify, in XML Schema, the expected media types associated with binary element content. It is expected that the additional information about the media type will be used for optimizing the handling of binary data that is part of a Web services message.

  Data sent and received over the Web typically uses the the MIME media type defined by IETF RFC 2046, as the type system. For example, 'image/jpeg', 'application/pdf'. As Web services get widely deployed, there is a need to indicate the media type of the XML element content in the messages sent and received by Web services. There is also a need to express the media type information using XML Schema: Datatypes, which is the type system used by WSDL 2.0 Part 1 to describe Web services. This would allow Web services to utilize the widely deployed and supported MIME media type infrastructure.

  XOP and MTOM (SOAP Message Transmission Optimization Mechanism) enables one to serialize binary content (element content that is in a canonical lexical representation of the xs:base64Binary type) in an optimized way using MIME packaging. There is a desire to specify the media type information of such binary element content in a standard way in the [XML Information Set] and not just in the optimized serialization of that Infoset.

  This document specifies: (1) a mechanism to indicate the media type of an XML element content whose type is xs:base64Binary; (2) a mechanism to indicate in XML Schema the expected media type(s) for an element content whose type is xs:base64Binary..."