SOAP Attachment Feature Requirements
W3C @@@ Draft @@
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark,document use and software licensing rules apply.
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark,document use and software licensing rules apply.
This document is a first cut at a set of SOAP Attachment Feature requirements. It is NOT to be considered a W3C Working Draft.
[Ednote: the title of this document and the internal characterization of i as a set of SOAP Attachment Feature requirements may need to be revised to be less oriented toward the notion of attachments.]
Discussion of this document takes place on the public <xml-dist-app@w3.org> mailing list (Archives [4]) per the email communication rules in the XML Protocol Working Group Charter [3].
The terminology and processing reflected in these requirements supercede and are not necessarily consistent with the SOAP 1.2 Abstract Feature specification [http://www.w3.org/TR/2002/WD-soap12-af-20020814/]. For example, the term part does not necessarily indicate attachment data that is logically outside the SOAP envelope infoset. It may also cover data in alternative serializations that is logically contained in the SOAP envelope infoset.
There are general, high-level considerations in choosing a design for a SOAP Attachment Feature which should be taken as input in addition to the specific requirements listed in the following section.
There also may be additional features which can be implemented using the extensibility mechanisms in SOAP Headers and and the attachment representation, but which have broad enough applicability to warrant a normative specification. A message manifest is a potential example of such functionality. The working group encourages members interested in pursuing the collection of use cases and detailed requirements for such a specification to do so as an adjunct to the attachments specification.
The requirements below are coarsely categorized as applying to the SOAP/WSDL processing environment (general issues, abstract features and properties, WSDL compatibility, etc.) or arising primarily at the concrete wire format level (serialization, representation, metadata, etc.).
The specification must describe its points of extensibility.
The specification should be conveniently describable by languages such as WSDL. [WSDL should have enough extensibility to handle reasonable new attachment specifications include ours. Our spec should be reasonably describable by languages such as WSDL.]
The specification should include sample changes to WSDL 1.2 and/or extensions to WSDL.
The specification must work with the SOAP 1.2 HTTP binding and shouldn't unnecessarily preclude working with other bindings.
The specification must be specified using the mechanisms of SOAP 1.2. These may include features, binding specifications, headers, relaying of information through intermediaries, etc. All processing must be specified in terms of the SOAP processing model, as augmented by any new features introduced. Where practical, the optional mechanisms of SOAP 1.2 (such as A Convention for Describing Features and Binding and Bindings) should be used in the description of the attachments specification.
[Ednote: May need to be reworded to clarify. R8 is now merged with R32.]
The specification must define a mapping between the attachment representation and a standalone SOAP message. For example, this may aid down-level receivers that do not understand this specification.
The specification should support securing of messages and message parts, such as use of encryption and signatures, in a simple manner. If practical, WS-Security should be supported.
[Ednote: This requirement is very tied to the PASWA/MTOM scheme.]
The specification must define a means to carry multiple data parts.
The specification must define a means for parts to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments).
The specification should support efficient implementation of:
The specification should use a reasonably space-efficient representation.
The representation should efficiently support the addition and deletion of parts by intermediaries.
The specification must provide support for arbitrarily large parts.
The specification should support streaming of parts, i.e. chunked encoding.
We recognize use cases in which streaming, interleaving, chunking, etc. are important. Assuming that physical part order is significant and controllable, various packaging mechanisms would permit application-level solutions. The WG needs to decide whether to provide a more universal solution; if so, we need to collect enough use cases to properly design such a scheme.
The specification should conveniently provide for the existence and extension of metadata to be carried with a message.
The specification should conveniently provide for the existence and extension of metadata associated with individual parts.
The specification must provide a means by which any or all parts may be labeled with associated media types. (I.e. applications sending a message are not obligated to label parts with media types, but the specification must provide for carrying the media type if provided.)
The specification must provide a facility for specifying length information that is appropriate to meet likely buffering requirements of receivers. The use of this facility is optional.
Each part must be named by an absolute URI. The normal mechanisms of URI references may be employed to refer either to parts or to fragments.
The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc.
The specification should not specify a particular physical ordering of parts.
In particular, this requirement was motivated by a use case in which the primary (SOAP) part was not required to be the first part.
Physical order is significant, and there are cases in which control over physical order is important (for example, see R26). The issue here is whether the specification should be as rigid as SwA in insisting, for example, that the primary SOAP part be the first part.
The primary (SOAP) message part should be readily locatable/identifiable.
The editor thanks the members of the attachment requirements task force for their contribution to this document: David Fallside, Martin Gudgin, Marc Hadley, Mark Jones, Anish Karmarkar, Noah Mendelsohn, Hervé Ruellan, Jeffrey Schlimmer, Mark Nottingham, and Tony Graham.
The WG thanks all participants of the xml-dist-app@w3.org mailing list (Archives [4]) for directly and indirectly contributing to this document.