Basic Profile Version 1.0 Errata

Delete the second sentence in Section 4.1.15 which reads:

The xsi:type attribute is only needed where no such schema exists, that is where both sides are assuming that all exchanged items are "xsd:anyType".

Section 4.1.15 now reads as follows:

In many cases, senders and receivers will share some form of type information related to the messages being exchanged.

R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in messages except as required in order to indicate a derived type (see XML Schema Part 1: Structures, Section 2.6.1).

Change R2737 from:

R2737 A MESSAGE described with an rpc-literal binding MUST namespace qualify the children of part accessor elements for the parameters and the return value with the targetNamespace in which their types are defined.

to:

R2737 A MESSAGE described with an rpc-literal binding MUST namespace qualify the descendents of part accessor elements for the parameters and the return value, as defined by the schema in which the part accessor types are defined.

Change R2101 from:

R2101 A DESCRIPTION MUST NOT use QName references to elements in namespaces that have been neither imported, nor defined in the referring WSDL document.

to:

R2101 A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document.

Change R2705 from:

R2705 A wsdl:binding in a DESCRIPTION MUST use either be a rpc-literal binding or a document-literal binding.

to:

R2705 A wsdl:binding in a DESCRIPTION MUST either be an rpc-literal binding or a document-literal binding.

The schemaLocation attribute of the xsd:import element is optional, R2004 does not prevent importation of schemas using the namespace attribute alone. This allows, for example, a schema within a wsdl:types section to import another schema defined within the same wsdl:types section using xsd:import with just the namespace attribute.

Change R2004 from:

R2004 A DESCRIPTION MUST NOT use the XML Schema "import" statement to import a Schema from any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema".

to:

R2004 In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema".

Remove the use of the word "array" in R2110, R2111, R2112, and R2113

• Change R2110 from:

  R2110 In a DESCRIPTION, array declarations MUST NOT extend or restrict the soapenc:Array type.

  to:

  R2110 In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array type.

• Change R2111 from:

  R2111 In a DESCRIPTION, array declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

  to:

  R2111 In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

• Change R2112 from:

  R2112 In a DESCRIPTION, array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX.

  to:

  R2112 In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX.

• Change R2113 from:

  R2113 A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute.

  to:

  R2113 A MESSAGE MUST NOT include the soapenc:arrayType attribute.

Change the fifth paragraph of Section 5.3 from:

An "rpc-literal operation" is a wsdl:operation child element of wsdl:binding each of whose soapbind:body descendant elements specifies the use attribute with the value "literal" and each of which either:

1. Specifies the style attribute with the value "rpc"; or
2. Is the child of a soapbind:binding element which specifies the style attribute with the value "rpc", and does not itself have the style attribute specified.

to:

An "rpc-literal operation" is a wsdl:operation child element of wsdl:binding whose soapbind:body descendant elements specify the use attribute with the value "literal", and either:

1. The style attribute with the value "rpc" is specified on the child soapbind:operation element; or
2. The style attribute is not present on the child soapbind:operation element, and the soapbind:binding element in the enclosing wsdl:binding specifies the style attribute with the value "rpc"

Change the seventh paragraph of Section 5.3 from:

A "document-literal operation" is a wsdl:operation child element of wsdl:binding each of whose soapbind:body descendent elements specifies the use attribute with the value "literal" and each of which either:

1. Specifies the style attribute with the value "document"; or
2. Is the child of a soapbind:binding element which specifies the style attribute with the value "document", and does not itself have the style attribute specified; or
3. Is the child of a soapbind:binding element which does not have the style attribute specified, and does not itself have the style attribute specified.

to:

A "document-literal operation" is a wsdl:operation child element of wsdl:binding whose soapbind:body descendent elements specifies the use attribute with the value "literal" and, either:

1. The style attribute with the value "document" is specified on the child soapbind:operation element; or
2. The style attribute is not present on the child soapbind:operation element, and the soapbind:binding element in the enclosing wsdl:binding specifies the style attribute with the value "document"; or
3. The style attribute is not present on both the child soapbind:operation element and the soapbind:binding element in the enclosing wsdl:binding.

Change the first paragraph of Section 5.5.1 from:

The Profile limits the choice of bindings to the well defined and most commonly used SOAP binding. MIME and HTTP GET/POST bindings are not permitted by the Profile.

to:

The Profile limits the choice of bindings to the well defined and most commonly used SOAP binding. HTTP GET/POST bindings, MIME or any other attachments technology, are not permitted by the Profile.

Change R2401 from:

R2401 A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

to:

R2401 A wsdl:binding element in a DESCRIPTION MUST only use the WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

Add a new requirement:

R2490 In a DESCRIPTION WSDL binding extension elements and attributes which cause messages on the wire to be non-conformant to BP 1.0 MUST NOT be used.

Add a new requirment

R2491 In a DESCRIPTION the WSDL MIME and HTTP GET/POST and DIME binding extensions MUST NOT appear in the SOAP binding

• Section 1.1 Guiding Principles - no change; this is not normative, and the phrase is used colloquially.
• Section 5.3 Messages - change "specific wire format" to "specific message serialization."
• Section 5.3.1 Bindings and Parts - change "the wire representation of that part" to "the serialization of that part in a message"
• Section 5.4.1 Ordering of part Elements - change "method signatures and messages on the wire" to "methods' signatures and their serializations."
• Section 5.6.7 Wire Signatures for Operations - change section title to "Operation Signatures." Change the first paragrah to read: An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique operation signature.
• Section 5.6.7 Wire Signatures for Operations - Change the second paragrah to read: The profile defines the operation signature to be the fully qualified name of the child element of SOAP body of the SOAP input message described by an operation in a WSDL binding.
• R2710 - change "wire signature" to "operation signature"
• Section 5.6.8 - change "on the wire" to "when serialized."
• R2712 - change "represented on the wire" to "serialized."

Remove the the phrase "currently under development" from Section 1.2.

This changes the sixth paragraph of Section 1.2 from:

Some statements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "SOAP12" for SOAP Version 1.2, currently under development). Note that because such work is not complete, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

to:

Some statements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "SOAP12" for SOAP Version 1.2). Note that because such work is not complete, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

Replace R1018 text with the following:

R1018 The Content-Type HTTP header field value of a MESSAGE MUST indicate the correct character encoding, using the charset parameter. [C]

Remove the extraneous "do" from R1112.

Change R1112 from:

An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response that does do not contain a SOAP message but indicates successful HTTP outcome of a request.

to:

An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response that does not contain a SOAP message but indicates successful HTTP outcome of a request.

Remove the extra space character between 'Request' and '"' and add a space character between '"' and 'HTTP status code' in R1113.

This changes R1113 from:

An INSTANCE SHOULD use a "400 Bad Request "HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

to:

An INSTANCE SHOULD use a "400 Bad Request" HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

The WS-I WSDL schema published at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd is inconsistent with the WSDL1.1 specification text with regards to the correct placement of top-level extensibility element content.

The WS-I WSDL schema published at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd is therefore amended to add an xs:any after the "anyTopLevelOptionalElement" group in the tDefintions type:

  <xs:complexType name="tDefinitions">
    <xs:complexContent>
      <xs:extension base="wsdl:tExtensibleDocumented">
        <xs:sequence>
          <xs:group ref="wsdl:anyTopLevelOptionalElement" minOccurs="0" 
maxOccurs="unbounded"/>
==>         <xs:any namespace="#other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="targetNamespace" type="xs:anyURI" use=
"optional"/>
        <xs:attribute name="name" type="xs:NCName" use="optional"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

Replace "are required" with "to" in the first line of Section 4.1.11.

This changes Section 4.1.11 from:

The Profile requires all XML processors are required support the "UTF-8" and "UTF-16" character encodings, in order to aid interoperability.

to:

The Profile requires all XML processors to support the "UTF-8" and "UTF-16" character encodings, in order to aid interoperability.

Change the first paragraph in Section 5.4.4 from:

WSDL 1.1 does not clearly state how the parameterOrder attribute of the wsdl:portType should be constructed.

to:

WSDL 1.1 does not clearly state how the parameterOrder attribute of the wsdl:operation element (which is the child of the wsdl:portType element) should be constructed.

Change R2305 from:

A wsdl:portType in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message.

to:

A wsdl:operation element child of a wsdl:portType element in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message.

Change R2743 from:

A MESSAGE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a wsdl:headerfault element in the corresponding WSDL description.

to:

A MESSAGE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a soapbind:headerfault element in the corresponding WSDL description.

Remove the phrase "as well as attributes" from the BP1.0 text in section 5.1.11

Change the hyperlink in the first bullet in Section 4, around the text "Simple Object Access Protocol (SOAP) 1.1" from:

http://www.w3.org/TR/SOAP/

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Change the hyperlink in the first bullet in Section 4.1, around the text "SOAP 1.1, Section 4" from:

http://www.w3.org/TR/SOAP/#_Toc478383494

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383494

Change the hyperlink in the first bullet in Section 4.2, around the text "SOAP 1.1, Section 2" from:

http://www.w3.org/TR/SOAP/#_Toc478383491

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383491

Change the hyperlink in the first bullet in Section 4.3, around the text "SOAP 1.1, Section 6" from:

http://www.w3.org/TR/SOAP/#_Toc478383526

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383526

Change the hyperlink in the first bullet in Appendix I, around the text "Simple Object Access Protocol (SOAP) 1.1" from:

http://www.w3.org/TR/SOAP/

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Change the hyperlink in the third paragraph in Appendix II, around the text "Simple Object Access Protocol (SOAP) 1.1:" from:

http://www.w3.org/TR/SOAP/

to:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Change R4001 from:

A RECEIVER MUST accept messages that include the Unicode Byte Order Mark (BOM).

to

A RECEIVER MUST accept messages with envelopes that include the Unicode Byte Order Mark (BOM), in addition to accepting UTF-8 encoded envelops that do not include a BOM.

Change R1010 from:

A RECEIVER MUST accept messages that contain an XML Declaration.

to

A RECEIVER MUST accept messages with envelopes that contain an XML Declaration, in addition to those that omit the declaration.

Add a new requirement Rxxxx Section 4.1.11:

A RECEIVER MUST ignore the encoding pseudo-attribute of the envelope's XML declaration in a message.

Add the following sentence at the end of the second paragraph in Section 4.1.11:

The charset parameter of Content-Type HTTP header field must be used to determine the correct character encoding of the message, in absence of a charset parameter, the default value for charset (which is "us-ascii") must be used.

In section 4.2.3, add the following explanation text:

"Both SOAP and this Profile use the term 'generate' to denote the creation of a SOAP Fault. It is important to realize that generation of a Fault is distinct from its transmission, which in some cases is not required."

Add the following to conformance section 3, following the third paragraph:

"None of the requirements of this profile, regardless of their strength, are to be considered as limiting the ability of an otherwise conforming instance to apply security countermeasures in response to a real or perceived threat. E.g. a requirement that states that an instance MUST send a message in response to a request need not be observed in the face of a DOS."

Add a Note following R1016 that reads: Note that this requirement conflicts with the schema for SOAP appearing at its namespace URL. A schema without conflicts can be found at 'http://schemas.xmlsoap.org/soap/envelope/2004-01-21.xsd'.

Amend wsdl:operation bullet item in the list in section 5.1.11 to append "(in portType or binding)"

Amend R1107 to read: "A RECEIVER MUST interpret a SOAP message as a Fault when the soap:Body of the message has a single soap:Fault child."

Amend the text for the soap:actor extensibility point to read: “Values of the soap:actor attribute, other than the special uri “http://schemas.xmlsoap.org/soap/actor/next” , represent a private agreement between parties of the web service.”

1)  Add XML 1.0 reference to BP 1.0 Section 5 list of profiled specs.
2)       Add “Namespaces in XML 1.0 <http://www.w3.org/TR/1999/REC-xml-names-19990114/>” to the list of specs profiled by BP 1.0.
3) Add Namespaces in XML 1.0 to BP 1.0 Section 4 list of profiled specs, just below XML 1.0
4) Add Namespaces in XML 1.0 to BP 1.0 Section 5 list of profiled specs, just below XML 1.0.
5) Add Namespaces in XML 1.0 to BP 1.1 Appendix I, just below XML 1.0.
6) Add Namespaces in XML 1.0 to BP 1.1 Section 4 list of profiled specs, just below XML 1.0.
7) Add Namespaces in XML 1.0 to BP 1.0 Appendix I, just below XML 1.0.
8) Add the following two requirements after BP 1.0 section 4.1.8:

RXXXX: An ENVELOPE SHOULD NOT contain the namespace declaration xmlns:xml=”http://www.w3.org/XML/1998/namespace”. [c]
RYYYY: A DESCRIPTION SHOULD NOT contain the namespace declaration xmlns:xml=”http://www.w3.org/XML/1998/namespace”. [c]
 
Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata) allows this namespace declaration to appear, some older processors considered such a declaration to be an error.  These requirements ensure that conformant artifacts have the broadest interoperability possible.