This document records known errors in the SOAP Version 1.2 Specification for which there are approved fixes.
The errata are separated into 5 sections, corresponding to the 4 documents of the specification, and the associated XML schemas:
Errata for each part are numbered separately. Errata for Primer are numbered with a prefix beginning with "E0-", errata for Messaging Framework are identified by "E1-", errata for Adjuncts are numbered with "E2-", errata for Test Collection are identified by "ET-", and errata for Schemas are numbered with "ES-". The errata within each section are classified as Error, Editorial or Clarification and listed in reverse chronological order of their date of publication. Three kinds of changes are highlighted: ↑new, added text↑, ↑changed text↑, and ↓deleted text↓.
Missing double quote
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
Editorial
In section 2.1:
"The choices of what data is placed in a header block and what goes in the SOAP body are decisions made at the time of application design."
In section 2.2.1:
"The message exchanges in Examples 1 and 2 are cases where XML-based contents conforming to some application-defined schema are exchanged via SOAP messages."
Editorial (change link)
In section 1.1:
Section 6 of this document describes the changes from SOAP Version 1.1 [SOAP 1.1]
In section 7: [SOAP 1.1] W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box et al., 8 May, 2000 (See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)
Editorial
In example 14:
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
In example 15:
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
In example 16:
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
Editorial
Copyright ©2003 W3C®(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Editorial
It is the responsibility of each such features to define any combined processing.
Reference to Part2 points to the right URI but mentions "Proposed Recommendation"
[SOAP Part 2]
W3C Proposed Recommendation "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley,
Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003
(See http://www.w3.org/TR/2003/REC-soap12-part2-20030624.)
Text over green background due to old diff markup
Remove diff markup from the source:
<p diff="add">In this case,
Editorial (change link)
[SOAP 1.1]
W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)
Editorial
After 2nd paragraph:
SOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 [SOAP 1.1]
Editorial
The scope of the encodingStyle attribute information item is its [owner element]
and that element information item's descendants, excluding the scope
of any inner encodingStyle attribute information item.
Editorial
To SOAP, a URI is simply a formatted string that identifies a web resource
via its name, location, or any other characteristics.
Editorial
[...] character information item children whose character code is. The character code of each such character information item MUST be amongst the white space characters as defined by XML 1.0
Editorial
The semantics of one or more SOAP header blocks in a SOAP message, or the SOAP
MEP used, MAY require [...]
Editorial (3 occurences, subsections 5.2.2, 5.2.3, 5.2.4)
SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept, the SOAP [...] attribute information item [...]
Editorial - typographic rules (several instances)
e.g., [...] i.e., [...] [...] items [...] SHOULD have [...]; that is, the name of the element SHOULD [...] in sections 5.2.1, 5.3.1, 5.4.5.1 (first bullet) [...] namespace-qualified [...] [...] human-readable explanation [...] in sections 5.4.2, 5.4.2.1 [...] SOAP-related security problems [...] in section 7.2 [...] SOAP-based authentication mechanism [...] in section 7.3 SOAP intermediaries are by definition men-in-the-middle [...] in section 7.2
Editorial
After table 3, added caption:
Table 3 summarizes the forwarding behavior of a SOAP node for a given
header block. Each row contains a different combination of the value of
the header block's role attribute information item, whether the SOAP
node is acting in that role and whether the header block has been
understood and processed, and shows whether the header block will be
forwarded or removed.
Clarification / Restriction
In the first paragraph: A SOAP message is specified as an XML infoset that whose comment, element, attribute, namespace and character information items are able to be serialized as XML 1.0. Note, requiring that the specified information items in SOAP message infosets be serializable as XML 1.0 does NOT require that they be serialized using XML 1.0. A SOAP message Infoset consists of a document information item with exactly one member in its [children] property, which MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope). This element information item is also the value of the [document element] property. The [notations] and [unparsed entities] properties are both empty. The [base URI], [character encoding scheme] and [version] properties can have any legal value. The [standalone] property either has a value of "yes" or has no value. The Infoset Recommendation [XML Infoset] allows for content not directly serializable using XML; for example, the character #x0 is not prohibited in the Infoset, but is disallowed in XML. The XML Infoset of a SOAP Message MUST correspond to an XML 1.0 serialization [XML 1.0].
As described in 5. SOAP Message Construct, each SOAP message is specified as an XML infoset that consists of a document information item with exactly one child: the SOAP Envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP message infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol. 5. SOAP Message Construct provides that all SOAP envelopes are serializable using an XML 1.0 serialization, so XML 1.0 or later versions of XML MAY be used by bindings as the "on the wire" representation of the XML Infoset. However, the binding framework does not require that every binding use an XML serialization for transmission; compressed, encrypted, fragmented representations and so on can be used if appropriate. A binding, if using an XML serialization of the XML infoset, MAY mandate that a particular character encoding or set of encodings be used. A binding, if using a XML serialization, must list the versions of XML used to serialize the infoset, or if it delegates this to other means (like media type description). To preserve interoperability, the list of supported XML versions should be exhaustive.
Clarification
In the second paragraph after the numbered list: Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message processing MAY result in the generation of at most one SOAP fault.; more than one SOAP fault MUST NOT be generated when processing a SOAP message.
Editorial (Capital letter)
Note: Other SOAP Version 1.2 bindings to HTTP may permit other combinations of http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName and http://www.w3.org/2003/05/soap/features/web-method/Method.
Editorial
Copyright ©2003 W3C®(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Reference to Part1 points to the right URI but mentions "Proposed Recommendation"
[SOAP Part 1]
W3C Proposed Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley,
Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003
(See http://www.w3.org/TR/2003/REC-soap12-part1-20030624.)
Clarification
Tables 4 and 5, Column "Notes", in each line:
A relative URI whose base URI is the value of the Property named ...
Editorial
After 2nd paragraph:
SOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 [SOAP 1.1]
Editorial - wording + adjust table width
In third column (Notes), each line changed:
A relative URI that will be resolved against [...]
Editorial
One of the design goals of SOAP is to facilitate the exchange of messages that
map conveniently to definitions and invocations of methods and procedures
in commonly used programming languages.
Editorial
Accordingly, when mapping to or from a programming language method or procedure
call,
any arguments that serve to identify resources (such as the part number above)
should when practical be represented in the URI to which the SOAP message is
addressed.
Editorial - typographic rules (several instances)
[...] on an application- or procedure-specific basis [...] [...] the binding-specific expression [...] [...] application-defined data [...] [...] the application-defined name [...] [...] is entirely platform-independent [...] are implementation-defined [...] i.e., [...]
Editorial
The struct is named identically to the procedure or method name and the conventions [...] [...] The values of properties in Environment Context may depend upon local circumstances (as depicted by the external arrow from Environment Context in the figure above) [...]
Editorial
As shown in the figure below, we make the distinction between per-message-exchange properties and more widely scoped properties by assigning them [...]
Editorial - Terms used in Figure 1.
In the top box: SOAP node In the left cloud and upper text: Environment Context In the right cloud: Transport Message Exchange Context
Editorial
The media type of the request entity body, if present; otherwise...
Editorial
The response message follows in the HTTP response [...]
Editorial
It is recommended that such behavior be disabled.
Editorial
[...] it is strongly RECOMMENDED that the security implications of a context
within which the SOAP message is used be fully
understood.
Editorial
SOAP places no restrictions on the specificity of the URI, and does not guarantee that it is resolvable."
Editorial
Although W3C XML Schemas are conventionally exchanged in the form of schema documents (...),
the schema recommendation is built on an abstract definition of schemas [...]
Clarification
In first paragraph, add:
The SOAP Action feature defines a single property, which is described in Table 14.
The value of this property MUST be an absolute URI [RFC 2396] and MUST NOT be empty.
Editorial
In the "401" row: Indicates that the HTTP request requires authorization. If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then tThe message exchange is regarded as having completed unsuccessfully.
Clarification
The array's dimensions are represented by each item in the list of sizes (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list. The default value of the arraySize attribute information item is "*", that is by default arrays are considered to have a single dimension of unspecified size. The arraySize attribute conveys a suggested mapping of a SOAP array to a multi-dimensional program data structure. The cardinality of the arraySize list represents the number of dimensions, with individual values providing the extents of the respective dimensions. When SOAP encoding multidimensional arrays, nodes are selected such that the last subscript (I.e. the subscript corresponding to the last specified dimension) varies most rapidly, and so on with the first varying most slowly. An asterisk MAY be used only in place of the first size to indicate a dimension of unspecified extent; asterisks MUST NOT appear in other positions in the list. The default value of the arraySize attribute information item is "*", I.e. a single dimension of unspecified extent.
Inside <env:Header>, <test:echoOk> is incorrectly matched with </test:unknown>
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<test:echoOk xmlns:test="http://example.org/ts-tests"
env:role="http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver"
env:mustUnderstand="wrong">
foo
</test:echoOK>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
Inside <env:Body> of Node A's message, <test:DoesNotExist> is incorrectly matched with </test:doesNotExist>
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<test:DoesNotExist xmlns:test="http://example.org/ts-tests">
</test:DoesNotExist>
</env:Body>
</env:Envelope>
Missing XML declaration
Message sent from Node A
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
End tag does not match start tag
Message sent from Node A
<test:Ignore xmlns:test="http://example.org/ts-tests"
env:role="http://example.org/ts-tests/B">
foo
</test:Ignore>
Typo double-quote in Node C's message
<return xsi:type="ns1:SOAPStruct"
xmlns:ns1="http://example.org/ts-tests/xsd">
Missing slash in Node C's message
<return xsi:type="xsd:string">
hello world
</return>
End tag does not match start tag in message sent from Node A
</inputIntegerArray>
</test:echoIntegerArray>
Missing "=" in node A's message
<item enc:id="data" xsi:type="xsd:string" enc:ref="#data">hello</item>
NOTATION is declared out of a doctype declaration
<!DOCTYPE foo [
<!NOTATION application_xml SYSTEM 'http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml'>
]>
ELEMENT is declared out of a doctype declaration
<!DOCTYPE foo [
<!ELEMENT Envelope (Body) >
<!ELEMENT Body (echoOk) >
<!ELEMENT echoOk (#PCDATA) >
]>
undeclared namespace prefix "xsi" in node C's message
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
Typo in an end tag in node C's message
</test:responseResolvedRef>
Missing slash
in 3rd Message sent from Node A
</inputString>
in 3rd Message sent from Node C
</return>
Missing namespace declaration for prefix "test", missing prefix env: for encodingStyle, typo in closing tag
Message sent from Node A
<test:echoOk env:encodingStyle="http://example.org/PoisonEncoding"
xmlns:test="http://example.org/ts-tests">
Message sent from Node C
<env:Value>env:DataEncodingUnknown</env:Value>
Missing ? in XML decl of some messages
Same fix for all concerned messages:
<?xml version="1.0"?>
Typo double-quote instead of colon
<return xsi:type="ns1:SOAPStruct"
xmlns:ns1="http://soapinterop.org/xsd">
Missing " in XML decl
Same fix for all concerned messages:
<?xml version="1.0"?>
End tag does not match start tag
</sb:getTimeResponse>
Missing "
<env:Body
env:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/">
Typo in end tag
Message sent from Node C
<env:Value>env:DataEncodingUnknown</env:Value>
Editorial
In point 2:
MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics using a SOAP/1.1 binding to the underlying protocol (see [soap11]).
Typo in end tag
<rpc:result>return</rpc:result>
End tag does not match start tag, node C's message
</test:echoStringResponse>
End tag does not match start tag
<inputString ...> ... </inputString>
Editorial
<sb:echoStringArrayResponse xmlns:sb="http://soapinterop.org/"
Editorial - tags
In node A's message: <inputInteger xsi:type="xsd:int">123</inputInteger> In node C's message: </sb:echoIntegerResponse>
End tag does not match start tag (4 occurences)
</h:echoMeUnknown>
End tag does not match start tag
</h:echoMeUnknown>
End tag does not match start tag, node C's message
<inputInteger xsi:type="xsd:int">abc</inputInteger>
Wrong namespace prefix (several occurences)
<sb:Unknown env:role="http://www.w3.org/2003/05/soap-envelope/role/..."
Editorial
In [SOAP Part1]
W3C Working DraftRecommendation "SOAP Version 1.2 Part 1: Messaging Framework"
In [SOAP Part2]
W3C Working DraftRecommendation "SOAP Version 1.2 Part 2: Adjuncts"
Wrong detail element in fault
In Test: T27
<env:Detail>
Array element declared as array of integersstring contains elements
with wrong content.
</env:Detail>
Missing RPC namespace in node C's response
In Test: T33 Message sent from Node C: <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"> <env:Header>
Wrong description
In Test: T61 Description: Node A sends to Node C a message specifying an array with bound specified by an asterisk.containing an array with a list of dimensions consisting of an integer followed by an asterisk. Node C responds with the count of items that appeared in the input array.a fault stating that the asterisk can occur only in the first position in the dimension list.
Wrong encoding
In Test: T66
Message sent from Node A
<?xml version='1.0' encoding='UTF-8'?>
Wrong reference
In Test: T56
Message sent from Node A
<test:echoString xmlns:test="http://example.org/ts-tests"
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<inputString enc:ref="#data-2" xsi:type="xsd:string" />
</test:echoString>
In Test: T57
Message sent from Node A
<test:echoString xmlns:test="http://example.org/ts-tests"
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<test:inputString enc:ref="#data" xsi:type="xsd:string" />
</test:echoString>
In Test: T59
Message sent from Node A
<inputStringArray enc:itemType="xsd:string"
xmlns:enc="http://www.w3.org/2003/05/soap-encoding">
<item enc:id="data" xsi:type"xsd:string" enc:ref="#data">hello</item>
<item>world</item>
</inputStringArray>
Wrong type definition
In Test:SBR2-echoBoolean
Message sent from Node A
<sb:echoBoolean xmlns:sb="http://soapinterop.org/"
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<inputBoolean xsi:type="xsd:decimalboolean">1</inputBoolean>
</sb:echoBoolean>
Wrong namespace
In Test:SBR2-echoNestedStruct
Message sent from Node C
<varFloat xsi:type="xsd:float">0.005</varFloat>
<varString xsi:type="xsd:string">hello world</varString>
<varStruct xsi:type="ns1:SOAPStructStruct">
<varInt xsi:type="xsd:int">99</varInt>
<varFloat xsi:type="xsd:float">4.0699e-12</varFloat>
<varString xsi:type="xsd:string">nested struct</varString>
</varStruct>
Missing RPC namespace in node C's response
In Test:XMLP-12 Message sent from Node C <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"> <env:Body>
Error in description
In Test:XMLP-18 Description: The test is similar to XMLP-15. Node A sends the echoString request along with an optional SOAP header block targeted at "http://www.w3.org/2003/05/soap-envelope/role/next" and a rolerelay attribute with a value of "true".
Wrong value for type
In Test:T53
Message sent from Node A
<test:echoDate xmlns:test="http://example.org/ts-tests"
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<inputDate xsi:type="xsd:date">1956-10-18T22:20:00-07:00</inputDate>
</test:echoDate>
In Test:T53
Message sent from Node C
<rpc:result>return</rpc:result>
<return xsi:type="xsd:date">1956-10-18T15:20:00Z</return>
</test:echoDateResponse>
Wrong type for value
In Test:SBR1-echoDate
Message sent from Node A
<sb:echoDate xmlns:test="http://soapinterop.org/"
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<inputDate xsi:type="xsd:dateTime">1956-10-18T22:20:00-07:00</inputDate>
</sb:echoDate>
In Test:SBR1-echoDate
Message sent from Node C
<rpc:result>return</rpc:result>
<return xsi:type="xsd:dateTime">1956-10-18T159T05:20:00Z</return>
</sb:echoDateResponse>
Addition of schemaLocation for xml:
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
Declaration of the type of the element 'result' to be consistent with section 4.2.2 of part 2.
<xs:element name='result' type='xs:QName'/>
<!-- Schema defined in the SOAP Version 1.2 Part 1 specification
Proposed Recommendation: at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
http://www.w3.org/TR/2003/PR-soap12-part1-20030507/
<!-- Schema defined in the SOAP Version 1.2 Part 1 specification
Proposed Recommendation: at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
http://www.w3.org/TR/2003/PR-soap12-part1-20030507/