| Date | Author | Description |
| 20010531 | MJH | Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation. |
Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
XMLP/SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. XMLP/SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use XMLP/SOAP in combination with HTTP and HTTP Extension Framework.
This is an editors' copy that has absolutely no standing.
This section describes the status of this document
at the time of its publication. Other documents may supersede this document.
The latest status of this document series is maintained at the
W3C.
The XMLP Protocol WG has, in keeping with its charter, produced a set of requirements and usage scenarios that have been published as a WD. To better evaluate SOAP 1.1 against these requirements and usage scenarios, the WG has produced an abstract model of SOAP 1.1 and a glossary of terms and concepts used by the WG. In addition, the WG has produced an issues list that describes issues and concerns raised by mapping its requirements against the SOAP 1.1 specification. A snapshot of this issues list is included in this document, along with a reference to the current version of the issues list.
This document is the result of merging the WG's glossary with the SOAP 1.1 specification. With few exceptions, no changes have yet been proposed to the syntax or the operation of SOAP 1.1 itself, although the WG may propose such changes in the future. As its work progresses, the WG intends to resolve differences in terminology between the glossary and SOAP/1.1 and to resolve outstanding issues. Currently, the WG expects many SOAP terms to be semantically similar to those in the glossary although differences in terminology may exist in this version.
Comments on this document should be sent to the W3C mailing list xmlp-comments@w3.org (public archives).
Discussion of this document takes place on the public
<xml-dist-app@w3.org> mailing
list (Archives) per the
email communication rules in
the XML Protocol Working Group Charter.
This is a public W3C Working Draft for review by W3C
members and other interested parties. It is a draft document and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference material or to cite them
as other than "work in progress". A list of
all W3C technical reports can be found at http://www.w3.org/TR/.
This Working Draft contains the XMLP/SOAP specification as currently stated. Appendix C contains updated XSD schemas. Appendix D contains a snapshot of the issues list that the WG maintains.
XMLP/SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. XMLP/SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows XMLP/SOAP to be used in a large variety of systems ranging from messaging systems to RPC.
XMLP/SOAP consists of three parts:
The XMLP/SOAP envelope (see section 4) construct defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory.
The XMLP/SOAP encoding rules (see section 5) defines a serialization mechanism that can be used to exchange instances of application-defined datatypes.
The XMLP/SOAP RPC representation (see section 7) defines a convention that can be used to represent remote procedure calls and responses.
Although these parts are described together as part of XMLP/SOAP, they are functionally orthogonal. In particular, the envelope and the encoding rules are defined in different namespaces in order to promote simplicity through modularity.
In addition to the XMLP/SOAP envelope, the XMLP/SOAP encoding rules and the XMLP/SOAP RPC conventions, this specification defines two protocol bindings that describe how a XMLP/SOAP message can be carried in HTTP [5] messages either with or without the HTTP Extension Framework [6].
A major design goal for XMLP/SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core XMLP/SOAP specification. Such features include
Distributed garbage collection
Boxcarring or batching of messages
Objects-by-reference (which requires distributed garbage collection)
Activation (which requires objects-by-reference)
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 [2].
The namespace prefixes "XS" and "XE" used in this document are associated with the XMLP/SOAP namespaces "http://schemas.xmlsoap.org/soap/envelope/" and "http://schemas.xmlsoap.org/soap/encoding/" respectively. Note that XML namespace prefixes are dynamically allocated and not semantically significant.
Throughout this document, the namespace prefix "xsi" is assumed to be associated with the URI "http://www.w3.org/1999/XMLSchema-instance" which is defined in the XML Schemas specification [11]. Similarly, the namespace prefix "xsd" is assumed to be associated with the URI "http://www.w3.org/1999/XMLSchema" which is defined in [10]. The namespace prefix "tns" is used to indicate whatever is the target namespace of the current document. All other namespace prefixes are samples only.
Namespace URIs of the general form "some-URI" represent some application-dependent or context-dependent URI [4].
This specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2616 [5] for certain constructs.
In this example, a GetLastTradePrice XMLP/SOAP request is sent to a StockQuote service. The request takes a string parameter, ticker symbol, and returns a float in the XMLP/SOAP response. The XMLP/SOAP Envelope element is the top element of the XML document representing the XMLP/SOAP message. XML namespaces are used to disambiguate XMLP/SOAP identifiers from application specific identifiers. The example illustrates the HTTP bindings defined in section 6. It is worth noting that the rules governing XML payload format in XMLP/SOAP are entirely independent of the fact that the payload is carried in HTTP.
More examples are available in Appendix A.
Example 1 XMLP/SOAP Message Embedded in HTTP Request
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
XMLP/SOAPAction: "Some-URI"
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</XS:Body>
</XS:Envelope>
Following is the response message containing the HTTP message with the XMLP/SOAP message as the payload:
Example 2 XMLP/SOAP Message Embedded in HTTP Response
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<XS:Envelope xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</XS:Body>
</XS:Envelope>
XMLP/SOAP messages are fundamentally one-way transmissions from a sender to a receiver, but as illustrated above, XMLP/SOAP messages are often combined to implement patterns such as request/response.
XMLP/SOAP implementations can be optimized to exploit the unique characteristics of particular network systems. For example, the HTTP binding described in section 6 provides for XMLP/SOAP response messages to be delivered as HTTP responses, using the same connection as the inbound request.
Regardless of the protocol to which XMLP/SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination.
A XMLP/SOAP application receiving a XMLP/SOAP message MUST process that message by performing the following actions in the order listed below:
Identify all blocks of the XMLP/SOAP message intended for that application (see section 4.2.2)
Verify that all mandatory blocks identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. If this is not the case then discard the message (see section 4.4). The processor MAY ignore optional blocks identified in step 1 without affecting the outcome of the processing.
If the XMLP/SOAP application is not the ultimate destination of the message then remove all blocks identified in step 1 before forwarding the message.
Processing a message or a part of a message requires that the XMLP/SOAP processor understands, among other things, the exchange pattern being used (one way, request/response, multicast, etc.), the role of the recipient in that pattern, the employment (if any) of RPC mechanisms such as the one documented in section 7, the representation or encoding of data, as well as other semantics necessary for correct processing.
While attributes such as the XMLP/SOAP encodingStyle attribute (see section 4.1.1) can be used to describe certain aspects of a message, this specification does not mandate a particular means by which the recipient makes such determinations in general. For example, certain applications will understand that a particular <getStockPrice> element signals an RPC request using the conventions of section 7, while another application may infer that all traffic directed to it is encoded as one way messages.
For a description of fundamental Web concepts including resources and resource manifestations, see the "Web Characterization Terminology & Definitions Sheet" W3C Working Draft.
XMLP/SOAP is a framework which can accommodate an open-ended set of XMLP/SOAP modules defining a large variety of functions and services. Typical functions and services defined by XMLP/SOAP modules can range from generic mechanisms for handling security, caching, routing, and eventing to specific functions like submitting a purchase order.
While XMLP/SOAP itself is intended to be as simple and lightweight as possible, XMLP/SOAP modules can be designed and composed to perform arbitrarily complex operations allowing the core protocol to remain simple.
XMLP/SOAP itself can be layered on top of a variety of underlying protocols that can help facilitate the transfer of XMLP/SOAP messages.
The formal set of conventions governing the format and processing rules of an XMLP/SOAP message and basic control of interaction among applications generating and accepting XMLP/SOAP messages for the purpose of exchanging information along an XMLP/SOAP message path.
A syntactic construct or structure used to delimit data that logically constitutes a single computational unit as seen by an XMLP/SOAP processor. A Block is identified by the fully qualified name of the outer element for the Block, which consists of the namespace URI and the local name.
The abstraction for the processing and/or logic defined by an XMLP module involving zero or more XMLP blocks.
An XMLP module is a basic unit for the definition of extensions to XMLP. An XMLP module encapsulates the definition of zero or more related XMLP/SOAP blocks and the associated processing rules. These processing rules are realized by an XMLP/SOAP handler.
The formal set of rules for carrying an XMLP/SOAP message within or on top of another protocol for the purpose of transmission. Typical XMLP/SOAP bindings include carrying an XMLP/SOAP message within an HTTP message, or on top of TCP.
The XMLP/SOAP layering model is illustrated on Figure 1.
Figure 1: XMLP/SOAP Layering Model
The XMLP/SOAP data encapsulation model describes how XMLP/SOAP blocks defined by XMLP/SOAP modules can be carried within an XMLP/SOAP message, which is the fundamental unit of communication in XMLP/SOAP. The following diagram illustrates how an XMLP/SOAP message is composed.
Figure 2: Encapsulation model illustrating the parts of an XMLP/SOAP message
An XMLP/SOAP message is composed of an XMLP/SOAP envelope which contains an XMLP/SOAP header and an XMLP/SOAP body each of which can contain zero, one or more XMLP/SOAP blocks.
An XMLP/SOAP message is the basic unit of communication between peer XMLP/SOAP processors.
An XMLP/SOAP Processor processes an XMLP/SOAP message according to the formal set of conventions defined by XMLP/SOAP. Parts of a an XMLP/SOAP message may be processed by handlers. The XMLP/SOAP processor is responsible for enforcing the rules that govern the exchange of XMLP/SOAP messages and accesses the services provided by the underlying protocols through XMLP/SOAP bindings.
Non-compliance with XMLP/SOAP conventions or failure in an XMLP/SOAP handler can cause an XMLP/SOAP processor to generate an XMLP/SOAP fault (see also XMLP/SOAP receiver and XMLP/SOAP sender).
The outermost syntactical construct or structure of an XMLP/SOAP message defined by XMLP/SOAP within which all other syntactical elements of the message are enclosed.
A collection or zero or more XMLP/SOAP blocks which may be targeted at any XMLP/SOAP receiver within the XMLP/SOAP message path
A collection or zero, or more XMLP/SOAP blocks targeted at the ultimate XMLP/SOAP receiver within the XMLP/SOAP message path.
A special XMLP/SOAP block which contains fault information generated by an XMLP/SOAP processor or handler.
The XMLP/SOAP message path model is defined in terms of XMLP/SOAP senders and XMLP/SOAP receivers who can generate and accept XMLP/SOAP messages respectively (see Figure 1). Behind each XMLP/SOAP receiver is an XMLP/SOAP processor that processes the message according to the rules of XMLP/SOAP.
An important part of the XMLP/SOAP message path model is the concept of XMLP/SOAP intermediaries. Intermediaries contain both an XMLP/SOAP receiver and an XMLP/SOAP sender which allows them to forward a message on behalf of the previous sender.
Note: In some interactions, more complicated message path models may be required to encapsulate the semantics of multi-party interactions like for example "fan-out" or "fan-in" models. Such models can be built using the basic XMLP/SOAP message path model provided that the semantics of message "split" and "merge" are provided by higher layer semantics.
An XMLP/SOAP node is an encapsulation of XMLP/SOAP handlers and their associated XMLP/SOAP processor.
An XMLP/SOAP sender is an XMLP/SOAP Node that transmits an XMLP/SOAP Message.
An XMLP/SOAP receiver is an XMLP/SOAP Node that accepts an XMLP/SOAP Message.
The set of XMLP/SOAP senders and XMLP/SOAP receivers through which a single XMLP/SOAP message passes. This includes the initial XMLP/SOAP sender, zero or more XMLP/SOAP intermediaries, and the ultimate XMLP/SOAP receiver.
The XMLP/SOAP sender that originates an XMLP/SOAP message as the starting point of an XMLP/SOAP message path.
An XMLP/SOAP intermediary is both an XMLP/SOAP receiver and an XMLP/SOAP sender, target-able from within an XMLP/SOAP message. It processes a defined set of blocks in an XMLP/SOAP message along an XMLP/SOAP message path. It acts in order to forward the XMLP/SOAP message towards the ultimate XMLP/SOAP receiver.
The XMLP/SOAP receiver that the initial sender specifies as the final destination of the XMLP/SOAP message within an XMLP/SOAP message path. An XMLP/SOAP message may not reach the ultimate recipient because of an XMLP/SOAP fault generated by an XMLP/SOAP processor or an XMLP/SOAP Handler along the XMLP/SOAP message path.
The relationship between an XMLP/SOAP sender and an XMLP/SOAP processor and an XMLP/SOAP receiver and an XMLP/SOAP processor respectively is illustrated in Figure 1.
A set of abstract constructs that can be used to describe common data types and link relationships in data defined by XMLP/SOAP modules.
The syntactic representation of data described by the XMLP/SOAP data model within one or more XMLP/SOAP blocks in an XMLP/SOAP message.
All XMLP/SOAP messages are encoded using XML (see [7] for more information on XML).
A XMLP/SOAP application SHOULD include the proper XMLP/SOAP namespace on all elements and attributes defined by XMLP/SOAP in messages that it generates. A XMLP/SOAP application MUST be able to process XMLP/SOAP namespaces in messages that it receives. It MUST discard messages that have incorrect namespaces (see section 4.4) and it MAY process XMLP/SOAP messages without XMLP/SOAP namespaces as though they had the correct XMLP/SOAP namespaces.
XMLP/SOAP defines two namespaces (see [8] for more information on XML namespaces):
The XMLP/SOAP envelope has the namespace identifier "http://schemas.xmlsoap.org/soap/envelope/"
The XMLP/SOAP serialization has the namespace identifier "http://schemas.xmlsoap.org/soap/encoding/"
A XMLP/SOAP message MUST NOT contain a Document Type Declaration. A XMLP/SOAP message MUST NOT contain Processing Instructions. [7]
XMLP/SOAP uses the local, unqualified "id" attribute of type "ID" to specify the unique identifier of an encoded element. XMLP/SOAP uses the local, unqualified attribute "href" of type "uri-reference" to specify a reference to that value, in a manner conforming to the XML Specification [7], XML Schema Specification [11], and XML Linking Language Specification [9].
With the exception of the XMLP/SOAP mustUnderstand attribute (see section 4.2.3) and the XMLP/SOAP actor attribute (see section 4.2.2), it is generally permissible to have attributes and their values appear in XML instances or alternatively in schemas, with equal effect. That is, declaration in a DTD or schema with a default or fixed value is semantically equivalent to appearance in an instance.
In this whole section, Body is used inconsistently, either to refer to the contents of the body section, or to the tag/element itself. This needs to be fixed. (The same applies to Header and, possibly, Envelope.)
The following paragraph introduces two terms, Header and Body, for which we have no definition. It is not yet clear whether the distinction between header blocks and body blocks will be kept in the final specification.
An XMLP/SOAP message is an XML document that consists of a mandatory XMLP/SOAP envelope, an optional XMLP/SOAP Header, and a mandatory XMLP/SOAP Body. This XML document is referred to as an XMLP/SOAP message for the rest of this specification. The namespace identifier for the elements and attributes defined in this section is "http://schemas.xmlsoap.org/soap/envelope/". An XMLP/SOAP message contains the following:
An XMLP/SOAP envelope. This is the top element of the XML document representing the XMLP/SOAP message.
An XMLP/SOAP Header. This is a generic mechanism for adding features to an XMLP/SOAP message in a decentralized manner without prior agreement between the communicating parties (an XMLP/SOAP sender, an XMLP/SOAP receiver, and possibly one or more XMLP/SOAP intermediaries). XMLP/SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory (see section 4.2)
An XMLP/SOAP Body. This is a container for mandatory information intended for the ultimate XMLP/SOAP receiver (see section 4.3). XMLP/SOAP defines an XMLP/SOAP fault for reporting errors.
The grammar rules are as follows:
XMLP/SOAP envelope
The element name is "Envelope".
The element MUST be present in an XMLP/SOAP message
The element MAY contain namespace declarations as well as additional attributes. If present, such additional attributes MUST be namespace-qualified. Similarly, the element MAY contain additional sub-elements. If present these sub-elements MUST be namespace-qualified and MUST come immediately after the XMLP/SOAP Body.
XMLP/SOAP Header (see section 4.2)
The element name is "Header".
The element MAY be present in an XMLP/SOAP message. If present, the element MUST be the first immediate child element of an XMLP/SOAP envelope.
The element MAY contain a set of XMLP/SOAP header blocks, each being an immediate child element of the XMLP/SOAP Header. All immediate child elements of the XMLP/SOAP Header MUST be namespace-qualified.
XMLP/SOAP Body (see section 4.3)
The element name is "Body".
The element MUST be present in an XMLP/SOAP message and MUST be an immediate child element of an XMLP/SOAP Envelope. It MUST come immediately after the XMLP/SOAP Header, if present. Otherwise, it MUST be the first immediate child element of the XMLP/SOAP envelope.
The element MAY contain a set of XMLP/SOAP body blocks, each being an immediate child element of the XMLP/SOAP Body. Immediate child elements of the XMLP/SOAP Body MAY be namespace-qualified. At most one child element MAY be an XMLP/SOAP fault. The XMLP/SOAP fault is used to indicate error messages (see section 4.4).
In the above sentence, replace "to indicate error messages" with "to carry error information"?
The XMLP/SOAP encodingStyle global attribute can be used to indicate the serialization rules used in an XMLP/SOAP message. This attribute MAY appear on any element, and is scoped to that element's contents and all child elements not themselves containing such an attribute, much as an XML namespace declaration is scoped. There is no default encoding defined for an XMLP/SOAP message.
The attribute value is an ordered list of one or more URIs identifying the serialization rule or rules that can be used to deserialize the XMLP/SOAP message indicated in the order of most specific to least specific. Examples of values are:
"http://schemas.xmlsoap.org/soap/encoding/" "http://my.host/encoding/restricted http://my.host/encoding/" ""
The serialization rules defined by XMLP/SOAP in section 5 are identified by the URI "http://schemas.xmlsoap.org/soap/encoding/". XMLP/SOAP messages using this particular serialization SHOULD indicate this using the XMLP/SOAP encodingStyle attribute. In addition, all URIs syntactically beginning with "http://schemas.xmlsoap.org/soap/encoding/" indicate conformance with the XMLP/SOAP encoding rules defined in section 5 (though with potentially tighter rules added).
A value of the zero-length URI ("") explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.
XMLP/SOAP does not define a traditional versioning model based on major and minor version numbers. An XMLP/SOAP message MUST contain an XMLP/SOAP enveloppe associated with the "http://schemas.xmlsoap.org/soap/envelope/" namespace. If an XMLP/SOAP message is received by an XMLP/SOAP node in which the XMLP/SOAP envelope is associated with a different namespace, the XMLP/SOAP node MUST treat this as a version error and discard the XMLP/SOAP message. If the XMLP/SOAP message is received through a request/response protocol such as HTTP, the XMLP/SOAP node MUST respond with an XMLP/SOAP VersionMismatch faultcode message (see section 4.4) using the XMLP/SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace.
XMLP/SOAP provides a flexible mechanism for extending an XMLP/SOAP message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as XMLP/SOAP header blocks are authentication, transaction management, payment, etc.
The XMLP/SOAP Header is encoded as the first immediate child element of the XMLP/SOAP envelope. All immediate child elements of the XMLP/SOAP Header are called XMLP/SOAP header blocks.
The encoding rules for XMLP/SOAP header blocks are as follows:
An XMLP/SOAP header block is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the XMLP/SOAP Header MUST be namespace-qualified.
The XMLP/SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the XMLP/SOAP header blocks (see section 4.1.1).
The XMLP/SOAP actor attribute (see section 4.2.2) and XMLP/SOAP mustUnderstand attribute (see section 4.2.3) MAY be used to indicate which XMLP/SOAP module will process the XMLP/SOAP header block, and how it will be processed (see section 4.2.1).
The XMLP/SOAP Header attributes defined in this section determine how an XMLP/SOAP receiver should process an incoming XMLP/SOAP message, as described in section 2. An XMLP/SOAP sender generating an XMLP/SOAP message SHOULD only use the XMLP/SOAP Header attributes on immediate child elements of the XMLP/SOAP Header. An XMLP/SOAP receiver MUST ignore all XMLP/SOAP Header attributes that are not applied to an immediate child element of the XMLP/SOAP Header.
An example is an XMLP/SOAP header block with an element identifier of "Transaction", a "mustUnderstand" value of "1", and a value of 5. This would be encoded as follows:
<XS:Header> <t:Transaction xmlns:t="some-URI" XS:mustUnderstand="1"> 5 </t:Transaction> </XS:Header>
An XMLP/SOAP message travels from an initial XMLP/SOAP sender to an ultimate XMLP/SOAP receiver, potentially passing through a set of XMLP/SOAP intermediaries along an XMLP/SOAP message path. Both intermediaries as well as the ultimate XMLP/SOAP receiver are identified by a URI.
The following paragraph required quite a bit of tuning, for getting the terminology straight.
Not all parts of an XMLP/SOAP message may be intended for the ultimate XMLP/SOAP receiver. They may be intended instead for one or more XMLP/SOAP intermediaries on the XMLP/SOAP message path. However, an XMLP intermediary MUST NOT forward further an XMLP/SOAP header block intended for it. This would be considered as a breach of contract, the contract being only between the XMLP/SOAP node which generated the XMLP/SOAP header block, and the XMLP/SOAP intermediary itself. However, the XMLP/SOAP intermediary MAY instead insert a similar XMLP/SOAP header block, which effectively sets up a new contract between that XMLP/SOAP intermediary and the XMLP/SOAP node at which the XMLP/SOAP header block is targeted.
The XMLP/SOAP actor global attribute can be used to indicate the XMLP/SOAP node at which a particular XMLP/SOAP header block is targeted. The value of the XMLP/SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next" indicates that the XMLP/SOAP header block is intended for the very first XMLP/SOAP node that processes the message. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP.
Omitting the XMLP/SOAP actor attribute indicates that the XMLP/SOAP header block is targeted at the ultimate XMLP/SOAP receiver.
This attribute MUST appear in the XMLP/SOAP message itself in order to be effective, and not in an eventual corresponding XML Schema (see section 3 and 4.2.1).
The XMLP/SOAP mustUnderstand global attribute can be used to indicate whether the processing of an XMLP/SOAP header block is mandatory or optional at the target XMLP/SOAP node. The target XMLP/SOAP node itself is defined by the XMLP/SOAP actor attribute (see section 4.2.2). The value of the XMLP/SOAP mustUnderstand attribute is either "1" or "0". The absence of this attribute is semantically equivalent to its presence with the value "0".
The following paragraph required quite a bit of tuning, for getting the terminology straight.
When an XMLP/SOAP header block is tagged with an XMLP/SOAP mustUnderstand attribute with a value of "1", the targeted XMLP/SOAP node MUST: either process the XMLP/SOAP block according to the semantics conveyed by the fully qualified name of the outer-most element of that block; or not process the XMLP/SOAP message at all, and fail (see section 4.4).
In the following paragraph, should we replace "element" by "XMLP/SOAP header block"?
The XMLP/SOAP mustUnderstand attribute allows for robust evolution. Elements tagged with the XMLP/SOAP mustUnderstand attribute with a value of "1" MUST be presumed to somehow modify the semantics of their parent or peer elements. Tagging elements in this manner assures that this change in semantics will not be silently (and, presumably, erroneously) ignored by those who may not fully understand it.
This attribute MUST appear in the XMLP/SOAP message itself in order to be effective, and not in an eventual corresponding XML Schema (see section 3 and 4.2.1).
The XMLP/SOAP Body element provides a simple mechanism for exchanging mandatory information intended for the ultimate XMLP/SOAP receiver of an XMLP/SOAP message. Typical uses of XMLP/SOAP Body include marshalling RPC calls and error reporting.
The XMLP/SOAP Body element is an immediate child element of an XMLP/SOAP envelope. If an XMLP/SOAP Header is present then the XMLP/SOAP Body MUST immediately follow the XMLP/SOAP Header, otherwise it MUST be the first immediate child element of the XMLP/SOAP envelope.
All immediate child elements of the XMLP/SOAP Body are called XMLP/SOAP body blocks, and each XMLP/SOAP body block is encoded as an independent element within the XMLP/SOAP Body.
The encoding rules for XMLP/SOAP body blocks are as follows:
An XMLP/SOAP body block is identified by its fully qualified element name, which consists of the namespace URI and the local name. Immediate child elements of the XMLP/SOAP Body element MAY be namespace-qualified.
The XMLP/SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the XMLP/SOAP body blocks (see section 4.1.1).
XMLP/SOAP defines one particular XMLP/SOAP body block, the XMLP/SOAP fault, which is used for reporting errors (see section 4.4).
While both XMLP/SOAP Header and XMLP/SOAP Body are defined as independent elements, they are in fact related. The relationship between an XMLP/SOAP body block and an XMLP/SOAP header block is as follows: an XMLP/SOAP body block is semantically equivalent to an XMLP/SOAP header block targeted at the default actor and with an XMLP/SOAP mustUnderstand attribute with a value of "1". The default actor is indicated by omitting the actor attribute (see section 4.2.2).
The XMLP/SOAP fault is used to carry error and/or status information within an XMLP/SOAP message. If present, the XMLP/SOAP fault MUST appear as an XMLP/SOAP body block and MUST NOT appear more than once within an XMLP/SOAP Body.
The XMLP/SOAP Fault defines the following four sub-elements:
The faultcode element is intended for use by software to provide an algorithmic mechanism for identifying the fault. The faultcode MUST be present in an XMLP/SOAP fault and the faultcode value MUST be a qualified name as defined in [8], section 3. XMLP/SOAP defines a small set of XMLP/SOAP fault codes covering basic XMLP/SOAP faults (see section 4.4.1)
The faultstring element is intended to provide a human readable explanation of the fault and is not intended for algorithmic processing. The faultstring element is similar to the 'Reason-Phrase' defined by HTTP (see [5], section 6.1). It MUST be present in an XMLP/SOAP fault and SHOULD provide at least some information explaining the nature of the fault.
The faultactor element is intended to provide information about which XMLP/SOAP node on the XMLP/SOAP message path caused the fault to happen (see section 2). It is similar to the XMLP/SOAP actor attribute (see section 4.2.2) but instead of indicating the target of an XMLP/SOAP header block, it indicates the source of the fault. The value of the faultactor attribute is a URI identifying the source. XMLP/SOAP nodes that do not act as the ultimate XMLP/SOAP receiver MUST include the faultactor element in the XMLP/SOAP fault. The ultimate XMLP/SOAP receiver MAY use the faultactor element to indicate explicitly that it generated the fault (see also the detail element below).
The detail element is intended for carrying application specific error information related to the XMLP/SOAP Body. It MUST be present when the contents of the XMLP/SOAP Body could not be processed successfully . It MUST NOT be used to carry error information about any XMLP/SOAP header blocks. Detailed error information for XMLP/SOAP header blocks MUST be carried within the XMLP/SOAP header blocks themselves.
The absence of the detail element in the XMLP/SOAP fault indicates that the fault is not related to the processing of the XMLP/SOAP Body. This can be used to find out whether the XMLP/SOAP Body was at least partially processed by the ultimate XMLP/SOAP receiver before the fault occurred, or not.
All immediate child elements of the detail element are called detail entries, and each detail entry is encoded as an independent element within the detail element.
The encoding rules for detail entries are as follows (see also example 10):
A detail entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. Immediate child elements of the detail element MAY be namespace-qualified.
The XMLP/SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the detail entries (see section 4.1.1).
Other XMLP/SOAP fault sub-elements MAY be present, provided they are namespace-qualified.
The XMLP/SOAP faultcode values defined in this section MUST be used in the XMLP/SOAP faultcode element when describing faults defined by this specification. The namespace identifier for these XMLP/SOAP faultcode values is "http://schemas.xmlsoap.org/soap/envelope/". Use of this space is recommended (but not required) in the specification of methods defined outside of the present specification.
The default XMLP/SOAP faultcode values are defined in an extensible manner that allows for new XMLP/SOAP faultcode values to be defined while maintaining backwards compatibility with existing XMLP/SOAP faultcode values. The mechanism used is very similar to the 1xx, 2xx, 3xx etc basic status classes classes defined in HTTP (see [5] section 10). However, instead of integers, they are defined as XML qualified names (see [8] section 3). The character "." (dot) is used as a separator of XMLP/SOAP faultcode values indicating that what is to the left of the dot is a more generic fault code value than the value to the right. Example:
Client.Authentication
The set of XMLP/SOAP faultcode values defined in this document is:
| Name | Meaning |
|---|---|
| VersionMismatch | The processing party found an invalid namespace for the XMLP/SOAP envelope element (see section 4.1.2) |
| MustUnderstand | An immediate child element of the XMLP/SOAP Header element that was either not understood or not obeyed by the processing party contained an XMLP/SOAP mustUnderstand attribute with a value of "1" (see section 4.2.3) |
| Client | Inconsistency: the glossary talks about a "sender", not a "client". The Client class of errors indicate that the message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change. See also section 4.4 for a description of the XMLP/SOAP Fault detail sub-element. |
| Server | Inconsistency: the glossary talks about a "receiver", not a "server". The Server class of errors indicate that the message could not be processed for reasons not directly attributable to the contents of the message itself but rather to the processing of the message. For example, processing could include communicating with a processor on an XMLP/SOAP node upstream, which did not respond. The message may succeed at a later point in time. See also section 4.4 for a description of the XMLP/SOAP Fault detail sub-element. |
The XMLP/SOAP encoding style is based on a simple type system that is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. A type either is a simple (scalar) type or is a compound type constructed as a composite of several parts, each with a type. This is described in more detail below. This section defines rules for serialization of a graph of typed objects. It operates on two levels. First, given a schema in any notation consistent with the type system described, a schema for an XML grammar may be constructed. Second, given a type-system schema and a particular graph of values conforming to that schema, an XML instance may be constructed. In reverse, given an XML instance produced in accordance with these rules, and given also the original schema, a copy of the original value graph may be constructed.
The namespace identifier for the elements and attributes defined in this section is "http://schemas.xmlsoap.org/soap/encoding/". The encoding samples shown assume all namespace declarations are at a higher element level.
Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with XMLP/SOAP (see section 4.1.1).
XML allows very flexible encoding of data. XMLP/SOAP defines a narrower set of rules for encoding. This section defines the encoding rules at a high level, and the next section describes the encoding rules for specific types when they require more detail. The encodings described in this section can be used in conjunction with the mapping of RPC calls and responses specified in Section 7.
To describe encoding, the following terminology is used:
A "value" is a string, the name of a measurement (number, date, enumeration, etc.) or a composite of several such primitive values. All values are of specific types.
A "simple value" is one without named parts. Examples of simple values are particular strings, integers, enumerated values etc.
A "compound value" is an aggregate of relations to other values. Examples of Compound Values are particular purchase orders, stock reports, street addresses, etc.
Within a compound value, each related value is potentially distinguished by a role name, ordinal or both. This is called its "accessor." Examples of compound values include particular Purchase Orders, Stock Reports etc. Arrays are also compound values. It is possible to have compound values with several accessors each named the same, as for example, RDF does.
An "array" is a compound value in which ordinal position serves as the only distinction among member values.
A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
A "simple type" is a class of simple values. Examples of simple types are the classes called "string," "integer," enumeration classes, etc.
A "compound type" is a class of compound values. An example of a compound type is the class of purchase order values sharing the same accessors (shipTo, totalCost, etc.) though with potentially different values (and perhaps further constrained by limits on certain values).
Within a compound type, if an accessor has a name that is distinct within that type but is not distinct with respect to other types, that is, the name plus the type together are needed to make a unique identification, the name is called "locally scoped." If however the name is based in part on a Uniform Resource Identifier, directly or indirectly, such that the name alone is sufficient to uniquely identify the accessor irrespective of the type within which it appears, the name is called "universally scoped."
Given the information in the schema relative to which a graph of values is serialized, it is possible to determine that some values can only be related by a single instance of an accessor. For others, it is not possible to make this determination. If only one accessor can reference it, a value is considered "single-reference". If referenced by more than one, actually or potentially, it is "multi-reference." Note that it is possible for a certain value to be considered "single-reference" relative to one schema and "multi-reference" relative to another.
Syntactically, an element may be "independent" or "embedded." An independent element is any element appearing at the top level of a serialization. All others are embedded elements.
Although it is possible to use the xsi:type attribute such that a graph of values is self-describing both in its structure and the types of its values, the serialization rules permit that the types of values MAY be determinate only by reference to a schema. Such schemas MAY be in the notation described by "XML Schema Part 1: Structures" [10] and "XML Schema Part 2: Datatypes" [11] or MAY be in any other notation. Note also that, while the serialization rules apply to compound types other than arrays and structs, many schemas will contain only struct and array types.
The rules for serialization are as follows:
All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element. A single-reference value SHOULD not be (but MAY be).
For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an xsi:type attribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted) XE:arrayType attribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.
A simple value is represented as character data, that is, without any subelements. Every simple value must have a type that is either listed in the XML Schemas Specification, part 2 [11] or whose source type is listed therein (see also section 5.2).
A Compound Value is encoded as a sequence of elements, each accessor represented by an embedded element whose name corresponds to the name of the accessor. Accessors whose names are local to their containing types have unqualified element names; all others have qualified names (see also section 5.4).
A multi-reference simple or compound value is encoded as an independent element containing a local, unqualified attribute named "id" and of type "ID" per the XML Specification [7]. Each accessor to this value is an empty element having a local, unqualified attribute named "href" and of type "uri-reference" per the XML Schema Specification [11], with a "href" attribute value of a URI fragment identifier referencing the corresponding independent element.
Strings and byte arrays are represented as multi-reference simple types, but special rules allow them to be represented efficiently for common cases (see also section 5.2.1 and 5.2.3). An accessor to a string or byte-array value MAY have an attribute named "id" and of type "ID" per the XML Specification [7]. If so, all other accessors to the same value are encoded as empty elements having a local, unqualified attribute named "href" and of type "uri-reference" per the XML Schema Specification [11], with a "href" attribute value of a URI fragment identifier referencing the single element containing the value.
It is permissible to encode several references to a value as though these were references to several distinct values, but only when from context it is known that the meaning of the XML instance is unaltered.
Arrays are compound values (see also section 5.4.2). XMLP/SOAP arrays are defined as having a type of "XE:Array" or a type derived there from.
XMLP/SOAP arrays have one or more dimensions (rank) whose members are distinguished by ordinal position. An array value is represented as a series of elements reflecting the array, with members appearing in ascending ordinal sequence. For multi-dimensional arrays the dimension on the right side varies most rapidly. Each member element is named as an independent element (see rule 2).
XMLP/SOAP arrays can be single-reference or multi-reference values, and consequently may be represented as the content of either an embedded or independent element.
XMLP/SOAP arrays MUST contain a "XE:arrayType" attribute whose value specifies the type of the contained elements as well as the dimension(s) of the array. The value of the "XE:arrayType" attribute is defined as follows:
arrayTypeValue = atype asize atype = QName *( rank ) rank = "[" *( "," ) "]" asize = "[" #length "]" length = 1*DIGIT
The "atype" construct is the type name of the contained elements expressed as a QName as would appear in the "type" attribute of an XML Schema element declaration and acts as a type constraint (meaning that all values of contained elements are asserted to conform to the indicated type; that is, the type cited in XE:arrayType must be the type or a supertype of every array member). In the case of arrays of arrays or "jagged arrays", the type component is encoded as the "innermost" type name followed by a rank construct for each level of nested arrays starting from 1. Multi-dimensional arrays are encoded using a comma for each dimension starting from 1.
The "asize" construct contains a comma separated list of zero, one, or more integers indicating the lengths of each dimension of the array. A value of zero integers indicates that no particular quantity is asserted but that the size may be determined by inspection of the actual members.
For example, an array with 5 members of type array of integers would have an arrayTypeValue value of "int[][5]" of which the atype value is "int[]" and the asize value is "[5]". Likewise, an array with 3 members of type two-dimensional arrays of integers would have an arrayTypeV<alue value of "int[,][3]" of which the atype value is "int[,]" and the asize value is "[3]".
An XMLP/SOAP array member MAY contain a "XE:offset" attribute indicating the offset position of that item in the enclosing array. This can be used to indicate the offset position of a partially represented array (see section 5.4.2.1). Likewise, an array member MAY contain a "XE:position" attribute indicating the position of that item in the enclosing array. This can be used to describe members of sparse arrays (see section 5.4.2.2). The value of the "XE:offset" and the "XE:position" attribute is defined as follows:
arrayPoint = "[" #length "]"
with offsets and positions based at 0.
A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:null with value '1' or possibly other application-dependent attributes and values.
Note that rule 2 allows independent elements and also elements representing the members of arrays to have names which are not identical to the type of the contained value.
For simple types, XMLP/SOAP adopts all the types found in the section "Built-in datatypes" of the "XML Schema Part 2: Datatypes" Specification [11], both the value and lexical spaces. Examples include:
| Type | Example |
|---|---|
| int | 58502 |
| float | 314159265358979E+1 |
| negativeInteger | -32768 |
| string | Louis "Satchmo" Armstrong |
The datatypes declared in the XML Schema specification may be used directly in element schemas. Types derived from these may also be used. An example of a schema fragment and corresponding instance data with elements of these types is:
<element name="age" type="int"/> <element name="height" type="float"/> <element name="displacement" type="negativeInteger"/> <element name="color"> <simpleType base="xsd:string"> <enumeration value="Green"/> <enumeration value="Blue"/> </simpleType> </element> <age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>Blue</color>
All simple values MUST be encoded as the content of elements whose type is either defined in "XML Schema Part 2: Datatypes" Specification [11], or is based on a type found there by using the mechanisms provided in the XML Schema specification.
If a simple value is encoded as an independent element or member of a heterogenous array it is convenient to have an element declaration corresponding to the datatype. Because the "XML Schema Part 2: Datatypes" Specification [11] includes type definitions but does not include corresponding element declarations, the XE schema and namespace declares an element for every simple datatype. These MAY be used.
<XE:int id="int1">45</XE:int>
The datatype "string" is defined in "XML Schema Part 2: Datatypes" Specification [11]. Note that this is not identical to the type called "string" in many database or programming languages, and in particular may forbid some characters those languages would permit. (Those values must be represented by using some datatype other than xsd:string.)
A string MAY be encoded as a single-reference or a multi-reference value.
The containing element of the string value MAY have an "id" attribute. Additional accessor elements MAY then have matching "href" attributes.
For example, two accessors to the same string could appear, as follows:
<greeting id="String-0">Hello</greeting> <salutation href="#String-0"/>
However, if the fact that both accessors reference the same instance of the string (or subtype of string) is immaterial, they may be encoded as two single-reference values as follows:
<greeting>Hello</greeting> <salutation>Hello</salutation>
Schema fragments for these examples could appear similar to the following:
<element name="greeting" type="XE:string"/> <element name="salutation" type="XE:string"/>
(In this example, the type XE:string is used as the element's type as a convenient way to declare an element whose datatype is "xsd:string" and which also allows an "id" and "href" attribute. See the XMLP/SOAP Encoding schema for the exact definition. Schemas MAY use these declarations from the XMLP/SOAP Encoding schema but are not required to.)
The "XML Schema Part 2: Datatypes" Specification [11] defines a mechanism called "enumeration." The XMLP/SOAP data model adopts this mechanism directly. However, because programming and other languages often define enumeration somewhat differently, we spell-out the concept in more detail here and describe how a value that is a member of an enumerated list of possible values is to be encoded. Specifically, it is encoded as the name of the value.
"Enumeration" as a concept indicates a set of distinct names. A specific enumeration is a specific list of distinct values appropriate to the base type. For example the set of color names ("Green", "Blue", "Brown") could be defined as an enumeration based on the string built-in type. The values ("1", "3", "5") are a possible enumeration based on integer, and so on. "XML Schema Part 2: Datatypes" [11] supports enumerations for all of the simple types except for boolean. The language of "XML Schema Part 1: Structures" Specification [10] can be used to define enumeration types. If a schema is generated from another notation in which no specific base type is applicable, use "string". In the following schema example "EyeColor" is defined as a string with the possible values of "Green", "Blue", or "Brown" enumerated, and instance data is shown accordingly.
<element name="EyeColor" type="tns:EyeColor"/> <simpleType name="EyeColor" base="xsd:string"> <enumeration value="Green"/> <enumeration value="Blue"/> <enumeration value="Brown"/> </simpleType>
<Person> <Name>Henry Ford</Name> <Age>32</Age> <EyeColor>Brown</EyeColor> </Person>
An array of bytes MAY be encoded as a single-reference or a multi-reference value. The rules for an array of bytes are similar to those for a string.
In particular, the containing element of the array of bytes value MAY have an "id" attribute. Additional accessor elements MAY then have matching "href" attributes.
The recommended representation of an opaque array of bytes is the 'base64' encoding defined in XML Schemas [10][11], which uses the base64 encoding algorithm defined in 2045 [13]. However, the line length restrictions that normally apply to base64 data in MIME do not apply in XMLP/SOAP. A "XE:base64" subtype is supplied for use with XMLP/SOAP.
<picture xsi:type="XE:base64"> aG93IG5vDyBicm73biBjb3cNCg== </picture>
Many languages allow accessors that can polymorphically access values of several types, each type being available at run time. A polymorphic accessor instance MUST contain an "xsi:type" attribute that describes the type of the actual value.
For example, a polymorphic accessor named "cost" with a value of type "xsd:float" would be encoded as follows:
<cost xsi:type="xsd:float">29.95</cost>
as contrasted with a cost accessor whose value's type is invariant, as follows:
<cost>29.95</cost>
XMLP/SOAP defines types corresponding to the following structural patterns often found in programming languages:
A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
An "array" is a compound value in which ordinal position serves as the only distinction among member values.
XMLP/SOAP also permits serialization of data that is neither a Struct nor an Array, for example data such as is found in a Directed-Labeled-Graph Data Model in which a single node has many distinct accessors, some of which occur more than once. XMLP/SOAP serialization does not require that the underlying data model make an ordering distinction among accessors, but if such an order exists, the accessors MUST be encoded in that sequence.
The members of a Compound Value are encoded as accessor elements. When accessors are distinguished by their name (as for example in a struct), the accessor name is used as the element name. Accessors whose names are local to their containing types have unqualified element names; all others have qualified names.
The following is an example of a struct of type "Book":
<e:Book> <author>Henry Ford</author> <preface>Prefatory text</preface> <intro>This is a book.</intro> </e:Book>
And this is a schema fragment describing the above structure:
<element name="Book"> <complexType> <element name="author" type="xsd:string"/> <element name="preface" type="xsd:string"/> <element name="intro" type="xsd:string"/> </complexType> </e:Book>
Below is an example of a type with both simple and complex members. It shows two levels of referencing. Note that the "href" attribute of the "Author" accessor element is a reference to the value whose "id" attribute matches. A similar construction appears for the "Address".
<e:Book> <title>My Life and Work</title> <author href="#Person-1"/> </e:Book> <e:Person id="Person-1"> <name>Henry Ford</name> <address href="#Address-2"/> </e:Person> <e:Address id="Address-2"> <email>mailto:henryford@hotmail.com</email> <web>http://www.henryford.com</web> </e:Address>
The form above is appropriate when the "Person" value and the "Address" value are multi-reference. If these were instead both single-reference, they SHOULD be embedded, as follows:
<e:Book> <title>My Life and Work</title> <author> <name>Henry Ford</name> <address> <email>mailto:henryford@hotmail.com</email> <web>http://www.henryford.com</web> </address> </author> </e:Book>
If instead there existed a restriction that no two persons can have the same address in a given instance and that an address can be either a Street-address or an Electronic-address, a Book with two authors would be encoded as follows:
<e:Book> <title>My Life and Work</title> <firstauthor href="#Person-1"/> <secondauthor href="#Person-2"/> </e:Book> <e:Person id="Person-1"> <name>Henry Ford</name> <address xsi:type="m:Electronic-address"> <email>mailto:henryford@hotmail.com</email> <web>http://www.henryford.com</web> </address> </e:Person> <e:Person id="Person-2"> <name>Samuel Crowther</name> <address xsi:type="n:Street-address"> <street>Martin Luther King Rd</street> <city>Raleigh</city> <state>North Carolina</state> </address> </e:Person>
Serializations can contain references to values not in the same resource:
<e:Book> <title>Paradise Lost</title> <firstauthor href="http://www.dartmouth.edu/~milton/"/> </e:Book>
And this is a schema fragment describing the above structures:
<element name="Book" type="tns:Book"/> <complexType name="Book"> <!-- Either the following group must occur or else the href attribute must appear, but not both. --> <sequence minOccurs="0" maxOccurs="1"> <element name="title" type="xsd:string"/> <element name="firstauthor" type="tns:Person"/> <element name="secondauthor" type="tns:Person"/> </sequence> <attribute name="href" type="uriReference"/> <attribute name="id" type="ID"/> <anyAttribute namespace="##other"/> </complexType> <element name="Person" base="tns:Person"/> <complexType name="Person"> <!-- Either the following group must occur or else the href attribute must appear, but not both. --> <sequence minOccurs="0" maxOccurs="1"> <element name="name" type="xsd:string"/> <element name="address" type="tns:Address"/> </sequence> <attribute name="href" type="uriReference"/> <attribute name="id" type="ID"/> <anyAttribute namespace="##other"/> </complexType> <element name="Address" base="tns:Address"/> <complexType name="Address"> <!-- Either the following group must occur or else the href attribute must appear, but not both. --> <sequence minOccurs="0" maxOccurs="1"> <element name="street" type="xsd:string"/> <element name="city" type="xsd:string"/> <element name="state" type="xsd:string"/> </sequence> <attribute name="href" type="uriReference"/> <attribute name="id" type="ID"/> <anyAttribute namespace="##other"/> </complexType>
XMLP/SOAP arrays are defined as having a type of "XE:Array" or a type derived there from (see also rule 8). Arrays are represented as element values, with no specific constraint on the name of the containing element (just as values generally do not constrain the name of their containing element).
Arrays can contain elements which themselves can be of any type, including nested arrays. New types formed by restrictions of XE:Array can also be created to represent, for example, arrays limited to integers or arrays of some user-defined enumeration.
The representation of the value of an array is an ordered sequence of elements constituting the items of the array. Within an array value, element names are not significant for distinguishing accessors. Elements may have any name. In practice, elements will frequently be named so that their declaration in a schema suggests or determines their type. As with compound types generally, if the value of an item in the array is a single-reference value, the item contains its value. Otherwise, the item references its value via an "href" attribute.
The following example is a schema fragment and an array containing integer array members.
<element name="myFavoriteNumbers" type="XE:Array"/> <myFavoriteNumbers XE:arrayType="xsd:int[2]"> <number>3</number> <number>4</number> </myFavoriteNumbers>
In that example, the array "myFavoriteNumbers" contains several members each of which is a value of type XE:int. This can be determined by inspection of the XE:arrayType attribute. Note that the XE:Array type allows unqualified element names without restriction. These convey no type information, so when used they must either have an xsi:type attribute or the containing element must have a XE:arrayType attribute. Naturally, types derived from XE:Array may declare local elements, with type information.
As previously noted, the XE schema contains declarations of elements with names corresponding to each simple type in the "XML Schema Part 2: Datatypes" Specification [11]. It also contains a declaration for "Array". Using these, we might write
<XE:Array XE:arrayType="xsd:int[2]"> <XE:int>3</XE:int> <XE:int>4</XE:int> </XE:Array>
Arrays can contain instances of any subtype of the specified arrayType. That is, the members may be of any type that is substitutable for the type specified in the arrayType attribute, according to whatever substitutability rules are expressed in the schema. So, for example, an array of integers can contain any type derived from integer (for example "int" or any user-defined derivation of integer). Similarly, an array of "address" might contain a restricted or extended type such as "internationalAddress". Because the supplied XE:Array type admits members of any type, arbitrary mixtures of types can be contained unless specifically limited by use of the arrayType attribute.
Types of member elements can be specified using the xsi:type attribute in the instance, or by declarations in the schema of the member elements, as the following two arrays demonstrate respectively.
<XE:Array XE:arrayType="xsd:ur-type[4]"> <thing xsi:type="xsd:int">12345</thing> <thing xsi:type="xsd:decimal">6.789</thing> <thing xsi:type="xsd:string"> Of Mans First Disobedience, and the Fruit Of that Forbidden Tree, whose mortal tast Brought Death into the World, and all our woe, </thing> <thing xsi:type="xsd:uriReference"> http://www.dartmouth.edu/~milton/reading_room/ </thing> </XE:Array>
<XE:Array XE:arrayType="xsd:ur-type[4]"> <XE:int>12345</XE:int> <XE:decimal>6.789</XE:decimal> <xsd:string> Of Mans First Disobedience, and the Fruit Of that Forbidden Tree, whose mortal tast Brought Death into the World, and all our woe, </xsd:string> <XE:uriReference> http://www.dartmouth.edu/~milton/reading_room/ </XE:uriReference > </XE:Array>
Array values may be structs or other compound values. For example an array of "xyz:Order" structs :
<XE:Array XE:arrayType="xyz:Order[2]"> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </XE:Array>
Arrays may have other arrays as member values. The following is an example of an array of two arrays, each of which is an array of strings.
<XE:Array XE:arrayType="xsd:string[][2]"> <item href="#array-1"/> <item href="#array-2"/> </XE:Array> <XE:Array id="array-1" XE:arrayType="xsd:string[2]"> <item>r1c1</item> <item>r1c2</item> <item>r1c3</item> </XE:Array> <XE:Array id="array-2" XE:arrayType="xsd:string[2]"> <item>r2c1</item> <item>r2c2</item> </XE:Array>
The element containing an array value does not need to be named "XE:Array". It may have any name, provided that the type of the element is either XE:Array or is derived from XE:Array by restriction. For example, the following is a fragment of a schema and a conforming instance array.
<simpleType name="phoneNumber" base="string"/> <element name="ArrayOfPhoneNumbers"> <complexType base="XE:Array"> <element name="phoneNumber" type="tns:phoneNumber" maxOccurs="unbounded"/> </complexType> <anyAttribute/> </element>
<xyz:ArrayOfPhoneNumbers XE:arrayType="xyz:phoneNumber[2]"> <phoneNumber>206-555-1212</phoneNumber> <phoneNumber>1-888-123-4567</phoneNumber> </xyz:ArrayOfPhoneNumbers>
Arrays may be multi-dimensional. In this case, more than one size will appear within the asize part of the arrayType attribute:
<XE:Array XE:arrayType="xsd:string[2,3]"> <item>r1c1</item> <item>r1c2</item> <item>r1c3</item> <item>r2c1</item> <item>r2c2</item> <item>r2c3</item> </XE:Array>
While the examples above have shown arrays encoded as independent elements, array values MAY also appear embedded and SHOULD do so when they are known to be single reference.
The following is an example of a schema fragment and an array of phone numbers embedded in a struct of type "Person" and accessed through the accessor "phone-numbers":
<simpleType name="phoneNumber" base="string"/> <element name="ArrayOfPhoneNumbers"> <complexType base="XE:Array"> <element name="phoneNumber" type="tns:phoneNumber" maxOccurs="unbounded"/> </complexType> <anyAttribute/> </element> <element name="Person"> <complexType> <element name="name" type="string"/> <element name="phoneNumbers" type="tns:ArrayOfPhoneNumbers"/> </complexType> </element>
<xyz:Person> <name>John Hancock</name> <phoneNumbers XE:arrayType="xyz:phoneNumber[2]"> <phoneNumber>206-555-1212</phoneNumber> <phoneNumber>1-888-123-4567</phoneNumber> </phoneNumbers> </xyz:Person>
Here is another example of a single-reference array value encoded as an embedded element whose containing element name is the accessor name:
<xyz:PurchaseOrder> <CustomerName>Henry Ford</CustomerName> <ShipTo> <Street>5th Ave</Street> <City>New York</City> <State>NY</State> <Zip>10010</Zip> </ShipTo> <PurchaseLineItems XE:arrayType="Order[2]"> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </PurchaseLineItems> </xyz:PurchaseOrder>
XMLP/SOAP provides support for partially transmitted arrays, known as "varying" arrays in some contexts [12]. A partially transmitted array indicates in an "XE:offset" attribute the zero-origin offset of the first element transmitted. If omitted, the offset is taken as zero.
The following is an example of an array of size five that transmits only the third and fourth element counting from zero:
<XE:Array XE:arrayType="xsd:string[5]" XE:offset="[2]"> <item>The third element</item> <item>The fourth element</item> </XE:Array>
XMLP/SOAP provides support for sparse arrays. Each element representing a member value contains a "XE:position" attribute that indicates its position within the array. The following is an example of a sparse array of two-dimensional arrays of strings. The size is 4 but only position 2 is used:
<XE:Array XE:arrayType="xsd:string[,][4]"> <XE:Array href="#array-1" XE:position="[2]"/> </XE:Array> <XE:Array id="array-1" XE:arrayType="xsd:string[10,10]"> <item XE:position="[2,2]">Third row, third col</item> <item XE:position="[7,2]">Eighth row, third col</item> </XE:Array>
If the only reference to array-1 occurs in the enclosing array, this example could also have been encoded as follows:
<XE:Array XE:arrayType="xsd:string[,][4]"> <XE:Array XE:position="[2]" XE:arrayType="xsd:string[10,10]> <item XE:position="[2,2]">Third row, third col</item> <item XE:position="[7,2]">Eighth row, third col</item> </XE:Array> </XE:Array>
The encoding rules just cited are not limited to those cases where the accessor names are known in advance. If accessor names are known only by inspection of the immediate values to be encoded, the same rules apply, namely that the accessor is encoded as an element whose name matches the name of the accessor, and the accessor either contains or references its value. Accessors containing values whose types cannot be determined in advance MUST always contain an appropriate xsi:type attribute giving the type of the value.
Similarly, the rules cited are sufficient to allow serialization of compound types having a mixture of accessors distinguished by name and accessors distinguished by both name and ordinal position. (That is, having some accessors repeated.) This does not require that any schema actually contain such types, but rather says that if a type-model schema does have such types, a corresponding XML syntactic schema and instance may be generated.
<xyz:PurchaseOrder> <CustomerName>Henry Ford</CustomerName> <ShipTo> <Street>5th Ave</Street> <City>New York</City> <State>NY</State> <Zip>10010</Zip> </ShipTo> <PurchaseLineItems> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </PurchaseLineItems> </xyz:PurchaseOrder>
Similarly, it is valid to serialize a compound value that structurally resembles an arrray but is not of type (or subtype) XE:Array. For example:
<PurchaseLineItems> <Order> <Product>Apple</Product> <Price>1.56</Price> </Order> <Order> <Product>Peach</Product> <Price>1.48</Price> </Order> </PurchaseLineItems>
An omitted accessor element implies either a default value or that no value is known. The specifics depend on the accessor, method, and its context. For example, an omitted accessor typically implies a Null value for polymorphic accessors (with the exact meaning of Null accessor-dependent). Likewise, an omitted Boolean accessor typically implies either a False value or that no value is known, and an omitted numeric accessor typically implies either that the value is zero or that no value is known.
The XMLP/SOAP root attribute can be used to label serialization roots that are not true roots of an object graph so that the object graph can be deserialized. The attribute can have one of two values, either "1" or "0". True roots of an object graph have the implied attribute value of "1". Serialization roots that are not true roots can be labeled as serialization roots with an attribute value of "1" An element can explicitly be labeled as not being a serialization root with a value of "0".
The XMLP/SOAP root attribute MAY appear on any subelement within the XMLP/SOAP Header and XMLP/SOAP Body elements. The attribute does not have a default value.
This section describes how to use XMLP/SOAP within HTTP with or without using the HTTP Extension Framework. Binding XMLP/SOAP to HTTP provides the advantage of being able to use the formalism and decentralized flexibility of XMLP/SOAP with the rich feature set of HTTP. Carrying XMLP/SOAP in HTTP does not mean that XMLP/SOAP overrides existing semantics of HTTP but rather that XMLP/SOAP over HTTP inherits HTTP semantics.
XMLP/SOAP naturally follows the HTTP request/response message model by providing an XMLP/SOAP request message in a HTTP request and XMLP/SOAP response message in a HTTP response. Note, however, that XMLP/SOAP intermediaries are NOT the same as HTTP intermediaries. That is, an HTTP intermediary addressed with the HTTP Connection header field cannot be expected to inspect or process the XMLP/SOAP entity body carried in the HTTP request.
HTTP applications MUST use the media type "text/xml" according to RFC 2376 [3] when including XMLP/SOAP messages in HTTP exchanges.
Although XMLP/SOAP might be used in combination with a variety of HTTP request methods, this binding only defines XMLP/SOAP within HTTP POST requests (see section 7 for how to use XMLP/SOAP for RPC and section 6.3 for how to use the HTTP Extension Framework).
The SOAPAction HTTP request header field can be used to indicate the intent of the XMLP/SOAP HTTP request. The value is a URI identifying the intent. XMLP/SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a XMLP/SOAP HTTP Request.
soapaction = "SOAPAction" ":" [ <"> URI-reference <"> ] URI-reference = <as defined in RFC 2396 [4]>
The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter XMLP/SOAP request messages in HTTP. The header field value of empty string ("") means that the intent of the XMLP/SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.
Examples:
SOAPAction: "http://electrocommerce.org/abc#MyMessage" SOAPAction: "myapp.sdl" SOAPAction: "" SOAPAction:
XMLP/SOAP over HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the XMLP/SOAP component was successfully received, understood, and accepted etc.
If an error occurs while processing the request, the XMLP/SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a XMLP/SOAP message in the response containing a XMLP/SOAP fault (see section 4.4) indicating the XMLP/SOAP processing error.
A XMLP/SOAP message MAY be used together with the HTTP Extension Framework [6] in order to identify the presence and intent of a XMLP/SOAP HTTP request.
Whether to use the Extension Framework or plain HTTP is a question of policy and capability of the communicating parties. Clients can force the use of the HTTP Extension Framework by using a mandatory extension declaration and the "M-" HTTP method name prefix. Servers can force the use of the HTTP Extension Framework by using the 510 "Not Extended" HTTP status code. That is, using one extra round trip, either party can detect the policy of the other party and act accordingly.
The extension identifier used to identify XMLP/SOAP using the Extension Framework is
http://schemas.xmlsoap.org/soap/envelope/
Example 3 XMLP/SOAP HTTP Using POST
POST /StockQuote HTTP/1.1 Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://electrocommerce.org/abc#MyMessage" <XS:Envelope... HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <XS:Envelope...
Example 4 XMLP/SOAP Using HTTP Extension Framework
M-POST /StockQuote HTTP/1.1 Man: "http://schemas.xmlsoap.org/soap/envelope/"; ns=NNNN Content-Type: text/xml; charset="utf-8" Content-Length: nnnn NNNN-SOAPAction: "http://electrocommerce.org/abc#MyMessage" <XS:Envelope... HTTP/1.1 200 OK Ext: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <XS:Envelope...
One of the design goals of XMLP/SOAP is to encapsulate remote procedure call functionality using the extensibility and flexibility of XML. This section defines a uniform representation of RPC invocations and responses.
Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in section 5, other representations are possible. The XMLP/SOAP encodingStyle attribute (see section 4.3.2) can be used to indicate the encoding style of the RPC invocation and/or the response using the representation described in this section.
Using XMLP/SOAP for RPC is orthogonal to the XMLP/SOAP protocol binding (see section 6). In the case of using HTTP as the protocol binding, an RPC invocation maps naturally to an HTTP request and an RPC response maps to an HTTP response. However, using XMLP/SOAP for RPC is not limited to the HTTP protocol binding.
To invoke an RPC, the following information is needed:
The URI of the target XMLP/SOAP processor
A procedure or method name
An optional procedure or method signature
The parameters to the procedure or method
Optional header data
XMLP/SOAP relies on the protocol binding to provide a mechanism for carrying the URI. For example, for HTTP the request URI indicates the resource that the invocation is being made against. Other than it be a valid URI, XMLP/SOAP places no restriction on the form of an address (see [4] for more information on URIs).
RPC invocations and responses are both carried in the XMLP/SOAP Body element (see section 4.3) using the following representation:
An RPC invocation is modelled as a struct.
The invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the procedure or method name.
Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter. These appear in the same order as in the procedure or method signature.
An RPC response is modelled as a struct.
The response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The first accessor is the return value followed by the parameters in the same order as in the procedure or method signature.
Each parameter accessor has a name corresponding to the name of the parameter and type corresponding to the type of the parameter. The name of the return value accessor is not significant. Likewise, the name of the struct is not significant. However, a convention is to name it after the procedure or method name with the string "Response" appended.
An invocation fault is encoded using an XMLP/SOAP fault (see section 4.4). If a protocol binding adds additional rules for fault expression, those MUST also be followed.
As noted above, RPC invocation and response structs can be encoded according to the rules in section 5, or other encodings can be specified using the encodingStyle attribute (see section 4.1.1).
Applications MAY process invocations with missing parameters but also MAY return a fault.
Because a result indicates success and a fault indicates failure, it is an error for an RPC response to contain both a result and a fault.
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in the RPC encoding. If so, it MUST be expressed as a header block.
An example of the use of a header block is the passing of a transaction ID along with a message. Since the transaction ID is not part of the signature and is typically held in an infrastructure component rather than application code, there is no direct way to pass the necessary information with the invocation. By adding a header entry with a fixed name, the transaction manager on the receiving side can extract the transaction ID and use it without affecting the coding of remote procedure calls.
Not described in this document are methods for integrity and privacy protection. Such issues will be addressed more fully in a future version(s) of this document.
[1] S. Bradner, "The Internet Standards Process -- Revision 3", RFC2026, Harvard University, October 1996
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997
[3] E. Whitehead, M. Murata, "XML Media Types", RFC2376, UC Irvine, Fuji Xerox Info. Systems, July 1998
[4] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.
[5] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, U.C. Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
[6] H. Nielsen, P. Leach, S. Lawrence, "An HTTP Extension Framework", RFC 2774, Microsoft, Microsoft, Agranat Systems
[7] W3C Recommendation "The XML Specification"
[8] W3C Recommendation "Namespaces in XML"
[9] W3C Proposed Recommendation "XML Linking Language"
[10] W3C Proposed Recommendation "XML Schema Part 1: Structures"
[11] W3C Proposed Recommendation "XML Schema Part 2: Datatypes"
[12] Transfer Syntax NDR, in "DCE 1.1: Remote Procedure Call"
[13] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, Innosoft, First Virtual, November 1996
Example 5 Similar to Example 1 but with a Mandatory Header
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
XMLP/SOAPAction: "Some-URI"
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Header>
<t:Transaction
xmlns:t="some-URI"
XS:mustUnderstand="1">
5
</t:Transaction>
</XS:Header>
<XS:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<m:symbol>DEF</m:symbol>
</m:GetLastTradePrice>
</XS:Body>
</XS:Envelope>
Example 6 Similar to Example 1 but with multiple request parameters
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
XMLP/SOAPAction: "Some-URI"
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Body>
<m:GetLastTradePriceDetailed
xmlns:m="Some-URI">
<Symbol>DEF</Symbol>
<Company>DEF Corp</Company>
<Price>34.1</Price>
</m:GetLastTradePriceDetailed>
</XS:Body>
</XS:Envelope>
Example 7 Similar to Example 2 but with a Mandatory Header
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Header>
<t:Transaction
xmlns:t="some-URI"
xsi:type="xsd:int" mustUnderstand="1">
5
</t:Transaction>
</XS:Header>
<XS:Body>
<m:GetLastTradePriceResponse
xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</XS:Body>
</XS:Envelope>
Example 8 Similar to Example 2 but with a Struct
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/"
XS:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<XS:Body>
<m:GetLastTradePriceResponse
xmlns:m="Some-URI">
<PriceAndVolume>
<LastTradePrice>
34.5
</LastTradePrice>
<DayVolume>
10000
</DayVolume>
</PriceAndVolume>
</m:GetLastTradePriceResponse>
</XS:Body>
</XS:Envelope>
Example 9 Similar to Example 2 but Failing to honor Mandatory Header
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/">
<XS:Body>
<XS:Fault>
<faultcode>XS:MustUnderstand</faultcode>
<faultstring>XMLP/SOAP Must Understand Error</faultstring>
</XS:Fault>
</XS:Body>
</XS:Envelope>
Example 10 Similar to Example 2 but Failing to handle Body
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<XS:Envelope
xmlns:XS="http://schemas.xmlsoap.org/soap/envelope/">
<XS:Body>
<XS:Fault>
<faultcode>XS:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
<e:myfaultdetails xmlns:e="Some-URI">
<message>
My application didn't work
</message>
<errorcode>
1001
</errorcode>
</e:myfaultdetails>
</detail>
</XS:Fault>
</XS:Body>
</XS:Envelope>
@@@ This is a tentative acknowledgement section. The structure and contents may change.
This document is based on the SOAP 1.1 specification whose authors are:
Don Box (DevelopMentor)
David Ehnebuske (IBM)
Gopal Kakivaya (Microsoft)
Andrew Layman (Microsoft)
Noah Mendelsohn (Lotus Development Corp.)
Henrik Frystyk Nielsen (Microsoft)
Satish Thatte (Microsoft)
Dave Winer (UserLand Software, Inc.)
@@@ describe process here @@@
This document is the work of the W3C XML Protocol Working Group:
@@@ List WG members here@@@
The contributions of the following people to this specification are gratefully acknowledged:
@@@ List members from the public here
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
targetNamespace="http://schemas.xmlsoap.org/soap/envelope/" >
<!-- XMLP/SOAP envelope, header and body -->
<xs:element name="Envelope" type="tns:Envelope" />
<xs:complexType name="Envelope" >
<xs:sequence>
<xs:element ref="tns:Header" minOccurs="0" />
<xs:element ref="tns:Body" />
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="Header" type="tns:Header" />
<xs:complexType name="Header" >
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="Body" type="tns:Body" />
<xs:complexType name="Body" >
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<!-- Global Attributes. The following attributes are intended
to be usable via qualified attribute names on any complex type
referencing them. -->
<xs:attribute name="mustUnderstand" default="0" >
<xs:simpleType>
<xs:restriction base="xs:boolean" >
<xs:pattern value="0|1" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="actor" type="xs:anyURI" />
<!-- 'encodingStyle' indicates any canonicalization conventions followed
in the contents of the containing element. For example, the value
'http://schemas.xmlsoap.org/soap/encoding/' indicates
the pattern described in XMLP/SOAP specification. -->
<xs:simpleType name="encodingStyle" >
<xs:list itemType="xs:anyURI" />
</xs:simpleType>
<xs:attributeGroup name="encodingStyle" >
<xs:attribute name="encodingStyle" type="tns:encodingStyle" />
</xs:attributeGroup>
<!-- XMLP/SOAP fault reporting structure -->
<xs:complexType name="Fault" final="extension" >
<xs:sequence>
<xs:element name="faultcode" type="xs:QName" />
<xs:element name="faultstring" type="xs:string" />
<xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
<xs:element name="detail" type="tns:detail" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="detail">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
<xs:anyAttribute processContents='lax' />
</xs:complexType>
</xs:schema>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"
targetNamespace="http://schemas.xmlsoap.org/soap/encoding/" >
<!-- 'root' can be used to distinguish serialization roots from other
elements that are present in a serialization but are not roots of
a serialized value graph. -->
<xs:attribute name="root" default="0" >
<xs:simpleType>
<xs:restriction base="xs:boolean" >
<xs:pattern value="0|1" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<!-- Attributes common to all elements that function as accessors or
represent independent (multi-ref) values. The href attribute is
intended to be used in a manner like CONREF. That is, the element
content should be empty iff the href attribute appears. -->
<xs:attributeGroup name="commonAttributes" >
<xs:attribute name="id" type="xs:ID" />
<xs:attribute name="href" type="xs:anyURI" />
<xs:anyAttribute namespace="##other" processContents='lax' />
</xs:attributeGroup>
<!-- Global Attributes. The following attributes are intended
to be usable via qualified attribute names on any complex type
referencing them. -->
<!-- Array attributes. Needed to give the type and dimensions of an array's
contents, and the offset for partially-transmitted arrays. -->
<xs:simpleType name="arrayCoordinate" >
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:attribute name="arrayType" type="xs:string" />
<xs:attribute name="offset" type="tns:arrayCoordinate" />
<xs:attributeGroup name="arrayAttributes" >
<xs:attribute ref="tns:arrayType" />
<xs:attribute ref="tns:offset" />
</xs:attributeGroup>
<xs:attribute name="position" type="tns:arrayCoordinate" />
<xs:attributeGroup name="arrayMemberAttributes" >
<xs:attribute ref="tns:position" />
</xs:attributeGroup>
<!-- 'Array' is a complex type for accessors identified by position.
-->
<xs:element name="Array" type="tns:Array" />
<xs:group name="Array" >
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
</xs:group>
<xs:complexType name="Array" >
<xs:group ref="tns:Array" minOccurs="0" />
<xs:attributeGroup ref="tns:arrayAttributes" />
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:complexType>
<!-- 'Struct' is a complex type for accessors identified by name.
Constraint: No element may be have the same name as any other,
nor may any element have a maxOccurs > 1. -->
<xs:element name="Struct" type="tns:Struct" />
<xs:group name="Struct" >
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents='lax' />
</xs:sequence>
</xs:group>
<xs:complexType name="Struct" >
<xs:group ref="tns:Struct" minOccurs="0" />
<xs:attributeGroup ref="tns:commonAttributes"/>
</xs:complexType>
<!-- 'Base64' can be used to serialize binary data using base64 encoding
as defined in RFC2045 but without the MIME line length limitation. -->
<xs:simpleType name="base64" >
<xs:restriction base="xs:base64Binary" />
</xs:simpleType>
<!-- Element declarations corresponding to each of the simple types in the
XML Schemas Specification. -->
<xs:element name="duration" type="tns:duration" />
<xs:complexType name="duration" >
<xs:simpleContent>
<xs:extension base="xs:duration" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="dateTime" type="tns:dateTime" />
<xs:complexType name="dateTime" >
<xs:simpleContent>
<xs:extension base="xs:dateTime" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="time" type="tns:time" />
<xs:complexType name="time" >
<xs:simpleContent>
<xs:extension base="xs:time" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="date" type="tns:date" />
<xs:complexType name="date" >
<xs:simpleContent>
<xs:extension base="xs:date" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gYearMonth" type="tns:gYearMonth" />
<xs:complexType name="gYearMonth" >
<xs:simpleContent>
<xs:extension base="xs:gYearMonth" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gYear" type="tns:gYear" />
<xs:complexType name="gYear" >
<xs:simpleContent>
<xs:extension base="xs:gYear" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gMonthDay" type="tns:gMonthDay" />
<xs:complexType name="gMonthDay" >
<xs:simpleContent>
<xs:extension base="xs:gMonthDay" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gDay" type="tns:gDay" />
<xs:complexType name="gDay" >
<xs:simpleContent>
<xs:extension base="xs:gDay" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gMonth" type="tns:gMonth" />
<xs:complexType name="gMonth" >
<xs:simpleContent>
<xs:extension base="xs:gMonth" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="boolean" type="tns:boolean" />
<xs:complexType name="boolean" >
<xs:simpleContent>
<xs:extension base="xs:boolean" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="base64Binary" type="tns:base64Binary" />
<xs:complexType name="base64Binary" >
<xs:simpleContent>
<xs:extension base="xs:base64Binary" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="hexBinary" type="tns:hexBinary" />
<xs:complexType name="hexBinary" >
<xs:simpleContent>
<xs:extension base="xs:hexBinary" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="float" type="tns:float" />
<xs:complexType name="float" >
<xs:simpleContent>
<xs:extension base="xs:float" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="double" type="tns:double" />
<xs:complexType name="double" >
<xs:simpleContent>
<xs:extension base="xs:double" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="anyURI" type="tns:anyURI" />
<xs:complexType name="anyURI" >
<xs:simpleContent>
<xs:extension base="xs:anyURI" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="QName" type="tns:QName" />
<xs:complexType name="QName" >
<xs:simpleContent>
<xs:extension base="xs:QName" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attribute name="NOTATION" type="tns:NOTATION" />
<xs:complexType name="NOTATION" >
<xs:simpleContent>
<xs:extension base="xs:NOTATION" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="string" type="tns:string" />
<xs:complexType name="string" >
<xs:simpleContent>
<xs:extension base="xs:string" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="normalizedString" type="tns:normalizedString" />
<xs:complexType name="normalizedString" >
<xs:simpleContent>
<xs:extension base="xs:normalizedString" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="token" type="tns:token" />
<xs:complexType name="token" >
<xs:simpleContent>
<xs:extension base="xs:token" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="language" type="tns:language" />
<xs:complexType name="language" >
<xs:simpleContent>
<xs:extension base="xs:language" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Name" type="tns:Name" />
<xs:complexType name="Name" >
<xs:simpleContent>
<xs:extension base="xs:Name" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NMTOKEN" type="tns:NMTOKEN" />
<xs:complexType name="NMTOKEN" >
<xs:simpleContent>
<xs:extension base="xs:NMTOKEN" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NCName" type="tns:NCName" />
<xs:complexType name="NCName" >
<xs:simpleContent>
<xs:extension base="xs:NCName" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NMTOKENS" type="tns:NMTOKENS" />
<xs:complexType name="NMTOKENS" >
<xs:simpleContent>
<xs:extension base="xs:NMTOKENS" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ID" type="tns:ID" />
<xs:complexType name="ID" >
<xs:simpleContent>
<xs:extension base="xs:ID" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="IDREF" type="tns:IDREF" />
<xs:complexType name="IDREF" >
<xs:simpleContent>
<xs:extension base="xs:IDREF" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ENTITY" type="tns:ENTITY" />
<xs:complexType name="ENTITY" >
<xs:simpleContent>
<xs:extension base="xs:ENTITY" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="IDREFS" type="tns:IDREFS" />
<xs:complexType name="IDREFS" >
<xs:simpleContent>
<xs:extension base="xs:IDREFS" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ENTITIES" type="tns:ENTITIES" />
<xs:complexType name="ENTITIES" >
<xs:simpleContent>
<xs:extension base="xs:ENTITIES" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="decimal" type="tns:decimal" />
<xs:complexType name="decimal" >
<xs:simpleContent>
<xs:extension base="xs:decimal" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="integer" type="tns:integer" />
<xs:complexType name="integer" >
<xs:simpleContent>
<xs:extension base="xs:integer" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="nonPositiveInteger" type="tns:nonPositiveInteger" />
<xs:complexType name="nonPositiveInteger" >
<xs:simpleContent>
<xs:extension base="xs:nonPositiveInteger" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="negativeInteger" type="tns:negativeInteger" />
<xs:complexType name="negativeInteger" >
<xs:simpleContent>
<xs:extension base="xs:negativeInteger" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="long" type="tns:long" />
<xs:complexType name="long" >
<xs:simpleContent>
<xs:extension base="xs:long" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="int" type="tns:int" />
<xs:complexType name="int" >
<xs:simpleContent>
<xs:extension base="xs:int" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="short" type="tns:short" />
<xs:complexType name="short" >
<xs:simpleContent>
<xs:extension base="xs:short" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="byte" type="tns:byte" />
<xs:complexType name="byte" >
<xs:simpleContent>
<xs:extension base="xs:byte" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="nonNegativeInteger" type="tns:nonNegativeInteger" />
<xs:complexType name="nonNegativeInteger" >
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedLong" type="tns:unsignedLong" />
<xs:complexType name="unsignedLong" >
<xs:simpleContent>
<xs:extension base="xs:unsignedLong" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedInt" type="tns:unsignedInt" />
<xs:complexType name="unsignedInt" >
<xs:simpleContent>
<xs:extension base="xs:unsignedInt" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedShort" type="tns:unsignedShort" />
<xs:complexType name="unsignedShort" >
<xs:simpleContent>
<xs:extension base="xs:unsignedShort" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedByte" type="tns:unsignedByte" />
<xs:complexType name="unsignedByte" >
<xs:simpleContent>
<xs:extension base="xs:unsignedByte" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="positiveInteger" type="tns:positiveInteger" />
<xs:complexType name="positiveInteger" >
<xs:simpleContent>
<xs:extension base="xs:positiveInteger" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="anyType" />
</xs:schema>
This is a snapshot of the issues list that the WG maintains and which contains the latest status.
| id | Spec | Req | Class | Status | Raised By | Owner |
|---|---|---|---|---|---|---|
| 42 | XMLP Spec | 200 | Editorial | Unassigned | vidur@netscape.com | |
| Description: [ref] [RPC2] The SOAP 1.1 spec uses words like "object" and "method" to refer to the end-points of an RPC operation. More generic words (or better qualification of these terms) that do not bias the reader towards expectations of full-fledged object systems on both sides are necessary. | ||||||
| Resolution: It will be covered in a glossary description | ||||||
| 41 | XMLP Spec | 200 | Design | Open | vidur@netscape.com | Noah_Mendelsohn@lotus.com |
| Description: [ref] [RPC1] The target (program, service or object) URI (TBD) is not mentioned in any normative way in the SOAP envelope. While this does not conflict with the requirements, I believe it's an important (and possibly debatable) decision. This decision precludes sending an RPC invocation through an intermediary that uses different protocol bindings for sending and receiving XP messages. | ||||||
| Resolution: | ||||||
| 44 | XMLP Spec | 200 | Design | Open | vidur@netscape.com | jkay@ENGENIA.COM |
| Description: [ref]
[RPC4] Regarding "2.Enable support for matching response messages
to request messages for cases in which matching is not provided by the
underlying protocol binding.
Section 7.2 states that a correlation ID is an example of the use of a SOAP header element. This does not seem to be a normative part of the specification and no rules are placed on the form of such a transaction ID. "3.The ability to specify the parameters to a call in a request message and the results of a call in a reply messages." Section 7.1 describes how elements in the body of a SOAP envelope can be used to represent parameters in an invocation and return values (and out parameters) in a response. "4.Provisions for specifying errors in a reply message (see also 703a and 703b)" Section 7.1 states that a "method fault is encoded using the SOAP Fault element". |
||||||
| Resolution: This was first listed as a transaction ID but the group has recast it as a correlation ID as this seems to be what is meant. | ||||||
| 45 | XMLP Spec | 200 | Design | Open | vidur@netscape.com | rayw@netscape.com |
| Description: [ref] [RPC5] Should there be a predefined set of fault codes that apply specifically to RPC? Examples would include errors for missing parameters, out of range values, etc. | ||||||
| Resolution: We will create a sub-group that will discuss this issue. Deadline is March 7 | ||||||
| 46 | XMLP Spec | 200 | Design | Closed | vidur@netscape.com | fallside@us.ibm.com |
| Description: [ref]
[RPC6] "Where possible, an attempt will be made to leverage any
related work done by the IETF."
The SOAP 1.1. spec does not directly reference the IETF work on RPC [2]. Is the quoted RFC out-of-date? Should more attention have been paid to IETF activity? |
||||||
| Resolution:
The working group is chartered with taking the SOAP 1.1. specification as its base. The charter also allows the working group to modify that specification to meet its requirements where the existing specification falls short. In cases where such modifications are necessary, the working group may make use of and/or reference IETF technology. To date, the working group has not made any such modifications. However, we are conscious of keeping in touch with the IETF if such modifications are necessary. In particular, we have at least one person on the working group who is aware of relevant IETF work, we invited a presentation on IETF technology at our f2f meeting, and our W3C staff contacts provide an additional link via a regular W3C/IETF co-ordination call. David Fallside, for the XML Protocol Working Group |
||||||
| 43 | XMLP Spec | 200 | Design | Closed | vidur@netscape.com | vidur@netscape.com |
| Description: [ref] [RPC3] The requirements state that the "procedure or method to be called" should also be represented using URI syntax. I believe this is an error in our document - the requirements should place no restrictions on the form of a procedure or method name. | ||||||
| Resolution: As the initiater and owner of on our XMLP Issues List, I'd like to suggest that we close it. R200 in the XMLP Requirements document states that a procedure or method name in a RPC call must be represented "using URI syntax". The SOAP 1.1 spec states that procedure or method name is represented as a qualified name. While a qualified name is not syntactically equivalent to a URI, it does contain a namespace URI and does, as such, share the same properties with respect to uniqueness. | ||||||
| 47 | XMLP Spec | 201 | Design | Open | vidur@netscape.com | David_E3@Verifone.com |
| Description: [ref] [RPC7] SOAP 1.1 describes its notion of a "data model" in a section describing an encoding system. The notion of a data model should probably be separated from the actual physical representation. | ||||||
| Resolution: SOAP defines in section 5 a datamodel that contains constructs like "struct", "array", "multi-struct", and simple types. The RPC convention in section 7 is cast in terms of the data model and not in terms of a specific representation within the SOAP message. That is, it is possible in SOAP to use another actual representation while still using the SOAP data model as well as using some other data model entirely. We (the WG) makes a note that we should ensure the destinction is made in the XML Protocol spec. We leave it to later to actually decide how we might best tackle this in the design phase. Discussion will take place in email. | ||||||
| 48 | XMLP Spec | 202 | Design | Unassigned | vidur@netscape.com | |
| Description: [ref] The SOAP encodingStyle attribute [5] can be used to used to indicate arbitrary serialization rules within a SOAP message. Section 5 [3] of the specification also states that "use of the data model and encoding style described in [the section describing the default SOAP encoding] is encouraged but not required; other data models and encodings can be used in conjunction with SOAP." | ||||||
| Resolution: | ||||||
| 34 | XMLP Spec | 300 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref]
In SOAP1.1, "1. Introduction", SOAP specifically declines to define an
architecture, abstract or otherwise: "SOAP does not itself define any
application semantics... or implementation semantics...; rather it
defines ... a modular packaging model and encoding mechanisms...".
The semantics mentioned are some of the key elements in the abstract models which are being introduced. Clearly, SOAP1.1 doesn't satisfy XML Protocol requirements in this regard. Please note that these semantics are also the focal point of the ongoing "usage scenario" work being done by the WG. Also note that "application" semantics are clearly out of scope (as they are for SOAP1.1), whereas "operational" semantics of a messaging system are in scope. |
||||||
| Resolution: | ||||||
| 35 | XMLP Spec | 301 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] SOAP1.1 conforms | ||||||
| Resolution: | ||||||
| 36 | XMLP Spec | 301a | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] Since SOAP1.1 defines only a "modular packaging model" and "encoding mechanisms", conformance with SOAP1.1 can be viewed as "validation" conformance (as in DTD or Schema validation). "XML Protocol requirements" is suggesting a more rigorous conformance test which includes semantics defined in in-scope usage scenarios, i.e. certain types of behavior. | ||||||
| Resolution: | ||||||
| 37 | XMLP Spec | 302 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] SOAP1.1 defines a vocabulary with certain types of extensibility. XML Protocol requirements declare a need for extensibility which supports "decentralized extensibility without prior agreement". It's not clear whether the types of extensiblity in SOAP are adequate for this requirement. | ||||||
| Resolution: | ||||||
| 38 | XMLP Spec | 304 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] A central point of R304 is really that the WG will define certain usage scenarios as in-scope. It is not yet certain whether SOAP1.1 will be adequate for these scenarios. SOAP1.1 does appear to support the RPC flavor of exchange. Other scenarios are not so clear. (See comments in R307). | ||||||
| Resolution: | ||||||
| 39 | XMLP Spec | 306 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] SOAP1.1 does not directly address deployment issues; but may indeed satisfy this requirement, with the qualification that it does not address a "full spectrum" of deployment environments. Rather, it addresses the HTTP common web-server/web-browser situation. | ||||||
| Resolution: | ||||||
| 32 | XMLP Spec | 307 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref]
It cannot be proven that SOAP1.1 would not address this requirement;
however, the requirement calls out usage scenarios as tools to prove
suitability. Since the usage requirements themselves are under
consideration, we can only suggest that the XML Protocol R307 will
help outline requirements which are more widely "suitable" than those
used in the design of SOAP1.1, and further suggest that SOAP1.1 might
fall short of fulfilling these requirements.
More specifically, SOAP1.1 has only limited usage scenarios, and as such falls short of R307. |
||||||
| Resolution: | ||||||
| 33 | XMLP Spec | 308 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] The SOAP1.1 specification succeeded to some extent in supporting modularity, especially modularity in terms of unforeseen architectural components which can be supported through constructs such as the "Header" and "Body" elements, or in SOAP encoding rules. However, this modularity seems weaker than that specified in the XML Protocol requirements. Further, SOAP1.1 doesn't appear to have much support for "layering". Such support arguably requires a clear architecture, promised in XML Protocol requirements (R300) but missing in SOAP1.1. | ||||||
| Resolution: | ||||||
| 40 | XMLP Spec | 309 | Design | Unassigned | David_E3@Verifone.Com | |
| Description: [ref] While SOAP1.1 may indeed be adequate for some simple exchanges usable on small systems, hopefully XML Protocol will do a better job of addressing these needs explicitly. | ||||||
| Resolution: | ||||||
| 26 | XMLP Spec | 400 | Design | Unassigned | pcotton@microsoft.com | |
| Description: [ref]
SOAP/1.1 provides a data model and a proposed serialization of that
model using the encoding provided in section 5 [1]. Both the data
model and the data serialization is orthogonal to the data
encapsulation (the SOAP envelope [2]). In [1] it is stated
that the two are orthogonal:
Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see section 4.1.1). The SOAP envelope provides a mechanism in form of the "encodingStyle" envelope attribute [3] that allows other data models and data serialization mechanisms to be used, |
||||||
| Resolution: SOAP/1.1 covers this requiremen | ||||||
| 28 | XMLP Spec | 401 | Design | Unassigned | pcotton@microsoft.com | |
| Description: [ref]
SOAP/1.1 adopts all simple types defined by XML Schema as described in
[4]:
For simple types, SOAP adopts all the types found in the section "Built-in datatypes" of the "XML Schema Part 2: Datatypes" Specification, both the value and lexical spaces. The SOAP/1.1 data model supports the use of XML schema complex types although it does not support the use of attributes for carrying instance values. The reason is that the SOAP/1.1 serialization mechanism reserves attributes for book keeping of the serialization and does not allows the application to otherwise use attributes. Therefore, XML instances using attributes for carrying instance data do not follow the SOAP serialization. There are two ways around this: generate a schema as described in the comment of R402 or not to use the SOAP serialization model. As one of the goals of the SOAP serialization is to limit the ways instance data can be encoded, the limitation of attributes is not considered as a disadvantage. |
||||||
| Resolution: SOAP/1.1 supports simple types and support complex types with the exception of attributes which are reserved for the SOAP serialization. The perceived benefit of this limitation is that it provides a simpler mapping to common programming language constructs. It is therefore judged that this requirement is met given the stated limitation. | ||||||
| 29 | XMLP Spec | 402 | Design | Unassigned | pcotton@microsoft.com | |
| Description: [ref] SOAP/1.1 states that given any data model that can be expressed using the SOAP/1.1 data model consisting of simple types, complex types, and references, it is possible to create an XML schema representing that model. Next, given a particular instance of values (for example a graph) expressed using that XML schema, it is possible to create an XML instance representing those values. This XML instance is what is being transferred within a SOAP message. The recipient of a SOAP message can given the XML schema and the XML instance recreate the original value (for example a graph) | ||||||
| Resolution: The current SOAP/1.1 model seems to be capable of representing directed graphs as well as object graphs and enable a recipient to deserialize an XML instance to recreate those graphs. It is not clear whether there are other data models that potentially are interesting to serialize but not representable within the SOAP data model. | ||||||
| 30 | XMLP Spec | 403 | Design | Unassigned | pcotton@microsoft.com | |
| Description: [ref] The SOAP/1.1 encoding uses the "id" and "href" attributes to name and refer to resources or sub-parts of resources. The format of the href attribute is of type "uri-reference" as defined by XML schema. The "id" attribute is of type "ID" as defined by XML/1.0. There are no restrictions on the value of a URI used as value in a href attribute. | ||||||
| Resolution: SOAP/1.1 covers this requirement although it is not explicitly stated that URIs can in fact point to anything. | ||||||
| 31 | XMLP Spec | 404 | Design | Unassigned | pcotton@microsoft.com | |
| Description: [ref]
Comment: The SOAP/1.1 data model defines an array type [5]:
SOAP arrays are defined as having a type of "SOAP-ENC:Array" or a type derived there from (see also rule 8). Arrays are represented as element values, with no specific constraint on the name of the containing element (just as values generally do not constrain the name of their containing element). as well as the encoding mechanism defines a serialization of that array type: The representation of the value of an array is an ordered sequence of elements constituting the items of the array. Within an array value, element names are not significant for distinguishing accessors. Elements may have any name. and can be nested: Arrays can contain elements which themselves can be of any type, including nested arrays. |
||||||
| Resolution: SOAP/1.1 covers this requirement | ||||||
| 49 | XMLP Spec | 500 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The introduction to the SOAP specification states that: SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC. Therefore the SOAP 1.1 specification mainly supports R500. Issue: There is a common belief that SOAP is intended for, and only supports the RPC programming model. The XP WG should emphasise the neutrality of its specification to programming models and illustrate its applicability to them via a wide range of use cases. | ||||||
| Resolution: | ||||||
| 50 | XMLP Spec | 501 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The SOAP 1.1 specification defines a binding to HTTP only. Therefore it only partially supports requirement R501. | ||||||
| Resolution: | ||||||
| 51 | XMLP Spec | 502 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The SOAP 1.1 specification partially supports requirement R502. There are no explicit examples in the SOAP 1.1 specification to support this requirement. The XP specification must provide a broader set of patterns and scenarios. | ||||||
| Resolution: | ||||||
| 52 | XMLP Spec | 503 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] Requirement R503 is a procedural requirement placed on the XP WG and is not influenced by the SOAP 1.1 specification. | ||||||
| Resolution: | ||||||
| 53 | XMLP Spec | 504 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The SOAP 1.1 specification provides a lightweight framework with extensibility via namespace defined header elements. The SOAP Body provides a mechanism for exchanging mandatory information (Section 4.3). This provides only part of the extensibility requirements implied by R504. Therefore the SOAP 1.1 specification partly fulfils R504. | ||||||
| Resolution: | ||||||
| 54 | XMLP Spec | 505 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The SOAP 1.1 specification does not support this requirement. At the minimum, there has to be an implicit assumption that the communicating parties will understand the SOAP protocol. The protocol does not provide a mechanism for submitting a SOAP request to a generic HTTP (or other protocol) server. | ||||||
| Resolution: | ||||||
| 55 | XMLP Spec | 506 | Design | Unassigned | john_ibbotson@uk.ibm.com | |
| Description: [ref] The SOAP 1.1 specification partially fulfils this requirement. It provides one mechanism for encapsulation and encoding of data with limited examples of extensibility. The XP specification must broaden these mechanisms via use cases. | ||||||
| Resolution: | ||||||
| 56 | XMLP Spec | 600 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] SOAP 1.1 has an implicit dependency on a synchronous request/response transport protocol to achieve correlation. It has a further implicit dependency on SOAP processor endpoint information being transport protocol endpoint information. | ||||||
| Resolution: | ||||||
| 57 | XMLP Spec | 604 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Not relevant to SOAP 1.1, so not addressed. | ||||||
| Resolution: | ||||||
| 58 | XMLP Spec | 608 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Not specifically addressed by SOAP 1.1, although limited extension facilities may be used to help achieve this goal. | ||||||
| Resolution: | ||||||
| 59 | XMLP Spec | 609 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Not specifically addressed. | ||||||
| Resolution: | ||||||
| 60 | XMLP Spec | 612 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] A binding to a synchronous request/response protocol is implicit in the SOAP 1.1 specification, so a normative binding to HTTP is not addressed. | ||||||
| Resolution: | ||||||
| 61 | XMLP Spec | 700a | Design | Unassigned | ohurley@iona.com | |
| Description: [ref]
This requirement is partially addressed by SOAP 1.1, which provides a
SOAP:Header extension element that may be used to add arbitrary XML to
a SOAP:Envelope.
SOAP 1.1 does not include defined mechanisms to carry and reference payloads outside the SOAP:Envelope, nor does it address carrying non-XML formatted information. |
||||||
| Resolution: | ||||||
| 62 | XMLP Spec | 700b | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] The SOAP 1.1 mustUnderstand attribute scheme satisfies this requirement for the SOAP:header extension mechanism only. XML Protocol specific extension mechanisms will require a similar attribution to satisfy this requirement. | ||||||
| Resolution: | ||||||
| 63 | XMLP Spec | 700c | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Partially addressed by the simple semantics of SOAP:fault categories | ||||||
| Resolution: | ||||||
| 64 | XMLP Spec | 701a | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] The SOAP 1.1 Enveloping scheme satisfies this requirement if taken in isolation. Given the context of other XML Protocol requirements and the context of binary content discussions, the SOAP 1.1 scheme may only partially satisfy this requirement. | ||||||
| Resolution: | ||||||
| 65 | XMLP Spec | 701b | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Is only slightly addressed by the concept and categorisation of faults and so is not satisfied by the SOAP 1.1 specification. | ||||||
| Resolution: | ||||||
| 66 | XMLP Spec | 702 | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] SOAP 1.1 provides simple envelope versioning through the use of XML namespaces and provides a specific faultcode for a failure in this area. As such it may be said to satisfy this requirement, but in a very unsophisticated manner. | ||||||
| Resolution: | ||||||
| 67 | XMLP Spec | 703a | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] SOAP 1.1 provides a fault entity, but also has an implicit dependence on HTTP for delivery, so it partially satisfies this requirement. Again, it is in a fairly unsophisticated manner as the faultcode semantics are limited. | ||||||
| Resolution: | ||||||
| 68 | XMLP Spec | 703b | Design | Unassigned | ohurley@iona.com | |
| Description: [ref] Not satisfied in SOAP 1.1 | ||||||
| Resolution: | ||||||
| 73 | XMLP Spec | 802 | Design | Unassigned | mnot@akamai.com | |
| Description: [ref] SOAP does not explicitly address this requirement, but it should be addressed by the 'actor' attribute, in that XP Blocks which were not targetted could be skipped over, depending on the processor implementation. | ||||||
| Resolution: | ||||||
| 69 | XMLP Spec | 803 | Design | Unassigned | mnot@akamai.com | |
| Description: [ref] The relationship between the transport binding and message is implied in "Using SOAP in HTTP" SOAP doesn't have a firm conception of a protocol binding or the requirments placed upon it - HTTP is assumed. | ||||||
| Resolution: | ||||||
| 71 | XMLP Spec | 806 | Design | Unassigned | mnot@akamai.com | |
| Description: [ref]
SOAP allows targeting through the "actor" attribute.
The value of the attribute may be underspecified; currently, there is no standard way to refer to intermediaries with a URI. Additionally, it may be desireable to target an XP Block by means other than direct reference or 'hop-by-hop', as described. Also, SOAP's processing model does not dictate the order in which multiple headers should be processed, if targetted at the same processor. |
||||||
| Resolution: | ||||||
| 72 | XMLP Spec | 808 | Design | Unassigned | mnot@akamai.com | |
| Description: [ref]
SOAP provides error and status reporting through SOAP Faults
The 'faultactor' subelement satisfies this requirement. See notes in R806 regarding the value of this element. Also, it should be noted that the mechanism for communicating a SOAP Fault is necessarily transport binding-dependent. |
||||||
| Resolution: | ||||||
| 70 | XMLP Spec | 811 | Design | Unassigned | mnot@akamai.com | |
| Description: [ref] SOAP accommodates processing intermediaries, but does not define them. See also R806 and R808. | ||||||
| Resolution: | ||||||
| 23 | XMLP Spec | n/a | Design | Unassigned | ||
| Description: Be more specific when and when not PIs and the like is allowed | ||||||
| Resolution: | ||||||
| 8 | XMLP Spec | n/a | Design | Unassigned | mnot@akamai.com | |
| Description: Lack of clarity in SOAP processing model. | ||||||
| Resolution: | ||||||
| 10 | XMLP Spec | n/a | Design | Unassigned | Tim.Sawyer@PANCREDIT.COM | |
| Description: Lack of clarity of when to use XML Version info. | ||||||
| Resolution: | ||||||
| 11 | XMLP Spec | n/a | Design | Unassigned | LMM@acm.org | |
| Description: Lack of clarity and design choice in SOAP protocol binding to HTTP, for example, use of port 80, HTTP status codes, and use of MUST/SHOULD/MAY is inconsistent. | ||||||
| Resolution: | ||||||
| 12 | XMLP Spec | n/a | Design | Unassigned | LMM@acm.org | |
| Description: SOAP and HTTP status codes (200 vs. 500 etc.). | ||||||
| Resolution: | ||||||
| 13 | XMLP Spec | n/a | Design | Unassigned | cfm@COGIT.COM | |
| Description: SOAP and HTTP on port 80. | ||||||
| Resolution: | ||||||
| 4 | XMLP Spec | n/a | Design | Unassigned | LMM@acm.org | |
| Description: Lack of clarity and design choices in SOAP's HTTP protocol binding. | ||||||
| Resolution: | ||||||
| 14 | XMLP Spec | n/a | Design | Unassigned | LMM@acm.org | |
| Description: SOAP versioning model. | ||||||
| Resolution: | ||||||
| 21 | XMLP Spec | n/a | Design | Unassigned | jlapp@WEBMETHODS.COM | |
| Description: Related issues regarding the SOAP messaging model and how it works with packaging | ||||||
| Resolution: | ||||||
| 18 | XMLP Spec | n/a | Design | Unassigned | frystyk@microsoft.com | |
| Description: Should multiref be top level or inline? | ||||||
| Resolution: | ||||||
| 19 | XMLP Spec | n/a | Design | Unassigned | bryan_murray@HP.COM | |
| Description: The SOAP spec currently does not require any namespace for the children elements of the Fault element; namely, faultcode, faultstring, detail, and faultactor. These elements are therefore in the default namespace. | ||||||
| Resolution: | ||||||
| 20 | XMLP Spec | n/a | Design | Unassigned | sjm@APTEST.COM | |
| Description: Propose to have 'xsd:string' as the default type for the standard encoding style and how schemas are to be used | ||||||
| Resolution: | ||||||
| 25 | XMLP Spec | n/a | Design | Unassigned | ylafon@w3.org | |
| Description: What is the status of footers/trailers? The SOAP/1.1 spec is somewhat ambiguous on the matter as it allows "other stuff" after the body but doesn't say what to use it for or what the processing model is. | ||||||
| Resolution: | ||||||
| 17 | XMLP Spec | n/a | Editorial | Unassigned | bryan_murray@HP.COM | |
| Description: Discussion needed as to when and why to use the section 5 encoding. | ||||||
| Resolution: | ||||||
| 15 | XMLP Spec | n/a | Editorial | Unassigned | LMM@acm.org | |
| Description: Some protocol requirements labeled as 'MUST' in the SOAP 1.1 spec seem to require implementation etails that have no explicit interoperability requirements. What is the fallback for encodingStyle and confusion about SOAPAction. | ||||||
| Resolution: | ||||||
| 24 | XMLP Spec | n/a | Editorial | Unassigned | erikc@microsoft.com | |
| Description: It should be allowed to have multiple headers using the same namespace (multiple signatures for example) in a single SOAP message. The current SOAP envelope schema doesn't allow this | ||||||
| Resolution: | ||||||
| 22 | XMLP Spec | n/a | Editorial | Unassigned | frystyk@microsoft.com | |
| Description: There is nothing that says what to do in the HTTP protcol binding if there is a SOAPAction header field but no SOAP in the HTTP request entity body | ||||||
| Resolution: | ||||||
| 1 | XMLP Spec | n/a | Editorial | Unassigned | EricSmith@WINDSOR.COM | |
| Description: Need description of how to escape properties with illegal characters for XML in SOAP. | ||||||
| Resolution: | ||||||
| 7 | XMLP Spec | n/a | Editorial | Unassigned | bernhard.dorninger@SCCH.AT | |
| Description: Need to update with respect to to latest XML schema spec. | ||||||
| Resolution: | ||||||
| 6 | XMLP Spec | n/a | Editorial | Unassigned | marek@ICSD.MOT.COM | |
| Description: Bugs in examples and question of consistency between text and schema. | ||||||
| Resolution: | ||||||
| 5 | XMLP Spec | n/a | Editorial | Unassigned | lars@LARS.COM | |
| Description: Problem in some examples. | ||||||
| Resolution: | ||||||
| 16 | XMLP Spec | n/a | Editorial | Unassigned | bryan_murray@HP.COM | |
| Description: The RPC mapping is not clear on how a method with a void return type and no out arguments should be mapped onto the SOAP protocol. | ||||||
| Resolution: | ||||||
| 3 | XMLP Spec | n/a | Editorial | Unassigned | davec@progress.com | |
| Description: Update syntax of "*" to "unbounded" in SOAP schema according to latest Schema language syntax. | ||||||
| Resolution: | ||||||
| 9 | XMLP Spec | n/a | Editorial | Unassigned | marek@ICSD.MOT.COM | |
| Description: Bug in example - need declarations of xsd and xsi namespaces | ||||||
| Resolution: | ||||||
| 2 | XMLP Spec | n/a | Editorial | Closed | bryan_murray@HP.COM | |
| Description: Follow-up: Whats wrong with attributes? | ||||||
| Resolution: Dup of issue 1 | ||||||