Basic Profile Version 1.1 Errata

Board Approval Draft

Revision: 1.8

Date: 2005/10/25

This version:

http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2005-10-25.html

Latest version:

http://www.ws-i.org/Profiles/BasicProfile-1.1-errata.html

Editors:

Anish Karmarkar, Oracle Corp.

Administrative contact:

secretary@ws-i.org

Abstract

This document contains the set of published errata against the WS-I BasicProfile-1.1.

Status of this Document

This document is a Board Approval Draft; it has been approved for publication by the Working Group, and is submitted for consideration by the Board of Directors, and for public comment. It is a work in progress, and should not be considered as final; other documents may supersede this document.

Notice

The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this material or WS-I. The material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Feedback

The Web Services-Interoperability Organization (WS-I) would like to receive input, suggestions and other feedback ("Feedback") on this work from a wide variety of industry participants to improve its quality over time.

By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an individual, and your company if you are providing Feedback on behalf of the company) will be deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner whatsoever the Feedback you provide regarding the work. You acknowledge that you have no expectation of confidentiality with respect to any Feedback you provide. You represent and warrant that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you represent and warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all of your Feedback in a future version of the work, it may, but is not obligated to include your name (or, if you are identified as acting on behalf of your company, the name of your company) on a list of contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf you are acting, please do not provide any Feedback.

Feedback on this document should be directed to wsbasic_comment@ws-i.org.

er001 Composability issue with AP 1.0 -- R2301

Description
The order of the elements in soap:Body are not necessarily the same as that of the wsdl:part in the wsdl:message that describes it, but the wordings of R2301 require it to be the same. This results in a composability problem with AP 1.0, since AP 1.0 does not require that all the wsdl:parts be bound to soap:Body.
Resolution: 2004-12-14

Amend R2301 by appending the phrase:

"for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element"

R2301 now reads as follows:

R2301 The order of the elements in the soap:Body of an ENVELOPE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element.

er002 Section 4.7.21 WSDL example has extraneous message attribute and a trailing "/" in the value of the transport attribute

Description
The WSDL example in Section 4.7.21 has an extra message attribute on the input element which is the grandchild of the binding element. The same example has an incorrect value for the transport attribute of the soapbind:binding element.
Resolution: 2004-12-14

Amend example in Section 4.7.21 by removing the message attribute on the input element which is the grandchild of the binding element and by removing the trailing "/" in the value of the transport attribute of the soapbind:binding element.

The WSDL in the example is now as follows:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bar="http://example.org/bar/" targetNamespace="http://example.org/bar/" xmlns:foo="http://example.org/foo/"> <types> <xsd:schema targetNamespace="http://example.org/foo/" xmlns:tns="http://example.org/foo/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:complexType name="fooType"> <xsd:sequence> <xsd:element ref="tns:bar"/> <xsd:element ref="tns:baf"/> </xsd:sequence> </xsd:complexType> <xsd:element name="bar" type="xsd:string"/> <xsd:element name="baf" type="xsd:integer"/> </xsd:schema> </types> <message name="BarMsg"> <part name="BarAccessor" type="foo:fooType"/> </message> <portType name="BarPortType"> <operation name="BarOperation"> <input message="bar:BarMsg"/> </operation> </portType> <binding name="BarSOAPBinding" type="bar:BarPortType"> <soapbind:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> <operation name="BarOperation"> <input> <soapbind:body use="literal" namespace="http://example.org/bar/"/> </input> </operation> </binding> <service name="serviceName"> <port name="BarSOAPPort" binding="bar:BarSOAPBinding"> <soapbind:address location="http://example.org/myBarSOAPPort"/> </port> </service> </definitions>

er003 Messages encoded in both UTF-8 and UTF-16 and UDDI

Description
Section 5 of Basic Profile 1.0 says that -- "Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages encoded in both UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) " This should really say that the message is encoded in either UTF-8 or UTF-16 and refer to Profile 1.1 not Profile 1.0.
Resolution: 2005-09-06

Replace the following sentence in Section 5:

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages encoded in both UTF-8 and UTF-16 as required by the Profile.

with:

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile because they do not accept messages encoded in either UTF-8 or UTF-16 as required by the Profile.

er004 E0013 excludes extension attributes

Description
E0013 - WSDL extensions - mentions extension elements but not extention attributes
Resolution: 2004-12-14

Amend E0013 by adding:

"and attributes"

after:

"extension elements"

E0013 now reads as follows:

E0013 - WSDL extensions - WSDL allows extension elements and attributes in certain places; use of such extensions requires out-of-band negotiation.

er005 Is SOAP fault allowed with HTTP Client Error Status Codes?

Description
BP1.1 Section 3.4.6 specifies the use of a few HTTP Client Error Status Codes. However it does not specify the content of HTTP body and it's not clear whether a soap fault is allowed.
Resolution: 2004-07-26

Append Section 3.4.6 HTTP Client Error Status Codes with the following text:

Also note that SOAP 1.1, Section 6.2 requires that SOAP Fault can only be returned with HTTP 500 "Internal Server Error" code. This profile doesn't change that requirement. When HTTP 4xx error status code is used, the response message should not contain a SOAP Fault.

er006 Child elements of the soap:Body

Description
While the combination of R2201 and R2210 clearly imply that theremay be at most one child element of the soap:Body, there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion.
Resolution: 2005-10-25

Add a new requirement to Section 3.1.1 SOAP Envelope Structure as follows:

While the combination of R2201 and R2210 (below) clearly imply that there may be at most one child element of the soap:Body, there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion.

R9981 An ENVELOPE MUST have exactly zero or one child elements of the soap:Body element.

er007 URIs for normative WSDL and WSDL SOAP schema conforming to the Profile

Description
The URIs listed for the normative schemas for the WSDL and WSDL SOAP binding schemas are incorrect.
Resolution: 2005-10-25

Amend the content of 4.2.1 WSDL Schema Definitions to read as follows:

The normative schemas for WSDL appearing in Appendix 4 of the WSDL 1.1 specification have inconsistencies with the normative text of the specification. The Profile references new schema documents that have incorporated fixes for known errors.

R2028 A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd".

R2029 A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at "http://ws-i.org/profiles/basic/1.1/wsdlsoap-2004-08-24.xsd".

er008 Location of SOAP envelope schema consistent with the Profile

Description
As a convenience, the schema for the SOAP envelope consistent with the profile should be hosted from the WS-I.org site.
Resolution: 2005-10-25

Replace the URI in Section 3.3.5 SOAP Fault Language with the following:

"http://ws-i.org/profiles/basic/1.1/soap-envelope-2004-01-21.xsd"

er001	Composability issue with AP 1.0 -- R2301
	Description The order of the elements in `soap:Body` are not necessarily the same as that of the `wsdl:part` in the `wsdl:message` that describes it, but the wordings of R2301 require it to be the same. This results in a composability problem with AP 1.0, since AP 1.0 does not require that all the `wsdl:parts` be bound to `soap:Body`. Resolution: 2004-12-14 Amend R2301 by appending the phrase: "for each of the `wsdl:part` elements bound to the envelope's corresponding `soapbind:body` element" R2301 now reads as follows: R2301 The order of the elements in the `soap:Body` of an ENVELOPE MUST be the same as that of the `wsdl:parts` in the `wsdl:message` that describes it for each of the `wsdl:part` elements bound to the envelope's corresponding `soapbind:body` element.
er002	Section 4.7.21 WSDL example has extraneous message attribute and a trailing "/" in the value of the transport attribute
	Description The WSDL example in Section 4.7.21 has an extra `message` attribute on the `input` element which is the grandchild of the `binding` element. The same example has an incorrect value for the `transport` attribute of the `soapbind:binding` element. Resolution: 2004-12-14 Amend example in Section 4.7.21 by removing the `message` attribute on the `input` element which is the grandchild of the `binding` element and by removing the trailing "/" in the value of the `transport` attribute of the `soapbind:binding` element. The WSDL in the example is now as follows: <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bar="http://example.org/bar/" targetNamespace="http://example.org/bar/" xmlns:foo="http://example.org/foo/"> <types> <xsd:schema targetNamespace="http://example.org/foo/" xmlns:tns="http://example.org/foo/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:complexType name="fooType"> <xsd:sequence> <xsd:element ref="tns:bar"/> <xsd:element ref="tns:baf"/> </xsd:sequence> </xsd:complexType> <xsd:element name="bar" type="xsd:string"/> <xsd:element name="baf" type="xsd:integer"/> </xsd:schema> </types> <message name="BarMsg"> <part name="BarAccessor" type="foo:fooType"/> </message> <portType name="BarPortType"> <operation name="BarOperation"> <input message="bar:BarMsg"/> </operation> </portType> <binding name="BarSOAPBinding" type="bar:BarPortType"> <soapbind:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> <operation name="BarOperation"> <input> <soapbind:body use="literal" namespace="http://example.org/bar/"/> </input> </operation> </binding> <service name="serviceName"> <port name="BarSOAPPort" binding="bar:BarSOAPBinding"> <soapbind:address location="http://example.org/myBarSOAPPort"/> </port> </service> </definitions>
er003	Messages encoded in both UTF-8 and UTF-16 and UDDI
	Description Section 5 of Basic Profile 1.0 says that -- "Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages encoded in both UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) " This should really say that the message is encoded in either UTF-8 or UTF-16 and refer to Profile 1.1 not Profile 1.0. Resolution: 2005-09-06 Replace the following sentence in Section 5: Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages encoded in both UTF-8 and UTF-16 as required by the Profile. with: Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile because they do not accept messages encoded in either UTF-8 or UTF-16 as required by the Profile.
er004	E0013 excludes extension attributes
	Description E0013 - WSDL extensions - mentions extension elements but not extention attributes Resolution: 2004-12-14 Amend E0013 by adding: "and attributes" after: "extension elements" E0013 now reads as follows: E0013 - WSDL extensions - WSDL allows extension elements and attributes in certain places; use of such extensions requires out-of-band negotiation.
er005	Is SOAP fault allowed with HTTP Client Error Status Codes?
	Description BP1.1 Section 3.4.6 specifies the use of a few HTTP Client Error Status Codes. However it does not specify the content of HTTP body and it's not clear whether a soap fault is allowed. Resolution: 2004-07-26 Append Section 3.4.6 HTTP Client Error Status Codes with the following text: Also note that SOAP 1.1, Section 6.2 requires that SOAP Fault can only be returned with HTTP 500 "Internal Server Error" code. This profile doesn't change that requirement. When HTTP 4xx error status code is used, the response message should not contain a SOAP Fault.
er006	Child elements of the soap:Body
	Description While the combination of R2201 and R2210 clearly imply that theremay be at most one child element of the `soap:Body`, there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion. Resolution: 2005-10-25 Add a new requirement to Section 3.1.1 SOAP Envelope Structure as follows: While the combination of R2201 and R2210 (below) clearly imply that there may be at most one child element of the `soap:Body`, there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion. R9981 An ENVELOPE MUST have exactly zero or one child elements of the `soap:Body` element.
er007	URIs for normative WSDL and WSDL SOAP schema conforming to the Profile
	Description The URIs listed for the normative schemas for the WSDL and WSDL SOAP binding schemas are incorrect. Resolution: 2005-10-25 Amend the content of 4.2.1 WSDL Schema Definitions to read as follows: The normative schemas for WSDL appearing in Appendix 4 of the WSDL 1.1 specification have inconsistencies with the normative text of the specification. The Profile references new schema documents that have incorporated fixes for known errors. R2028 A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd". R2029 A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at "http://ws-i.org/profiles/basic/1.1/wsdlsoap-2004-08-24.xsd".
er008	Location of SOAP envelope schema consistent with the Profile
	Description As a convenience, the schema for the SOAP envelope consistent with the profile should be hosted from the WS-I.org site. Resolution: 2005-10-25 Replace the URI in Section 3.3.5 SOAP Fault Language with the following: "http://ws-i.org/profiles/basic/1.1/soap-envelope-2004-01-21.xsd"