Basic Profile Version 1.0 Errata

Editors:

• Chris Ferris, IBM
• Anish Karmarkar, Oracle Corp.
• Mark Nottingham, BEA Systems

Administrative contact:

secretary@ws-i.org

Copyright © 2002-2004 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. All Rights Reserved.

Abstract

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

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	Use of xsi:type
	Description R1017 does not give clear guidance regarding the use of xsi:type. For instance, if a part is defined using an XSD data type (e.g. xsd:string or xsd:int) and it is used in a rpc-literal binding, should the part accessor in the message have an xsi:type attribute? Resolution: 2003-09-16 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).
er002	NS qualification of children of part accessors for rpc-lit binding and R2737
	Description R2737 is incorrect as it always requires the children of part accessors (for rpc-literal binding) to be NS qualified with the targetNamespace in which the part types are defined. Resolution: 2003-09-23 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.
er003	R2101 is ambiguous as to whether it applies to Schema or WSDL components
	Description Does R2101 apply only to schema OR to WSDL components? Resolution: 2003-09-16 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.
er005	R2705 wordings are awkward
	Description R2705 wording are awkward/incorrect Resolution: 2003-09-16 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.
er006	Intent of R2004
	Description Was it the intention of BP 1.0 to prevent multiple inlined schemas in the same WSDL document to refer to each other (using xsd:import) Resolution: 2003-11-13 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".
er007	Incorrect use of the word 'array' in R2110, R2111, R2112, and R2113
	Description R2110, R2111, R2112, and R2113 restricts array descriptions. This is confusing and untestable as the concept of "array" is alien to XML Schema Resolution: 2003-10-21 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.
er008	Incorrect definition of "rpc-literal" and "document-literal" operations
	Description Section 5.3 is confusing as it does not clearly specify where the style attribute can occur. Resolution: 2003-11-13 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: Specifies the style attribute with the value "rpc"; or 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: The style attribute with the value "rpc" is specified on the child soapbind:operation element; or 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: Specifies the style attribute with the value "document"; or 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 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: The style attribute with the value "document" is specified on the child soapbind:operation element; or 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 The style attribute is not present on both the child soapbind:operation element and the soapbind:binding element in the enclosing wsdl:binding.
er009	Intent of R2401
	Description What is the intent of R2401? Does is disallow other binding or binding extensions? Resolution: 2003-11-18 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 requirement R2491 In a DESCRIPTION the WSDL MIME and HTTP GET/POST and DIME binding extensions MUST NOT appear in the SOAP binding
er010	What is the meaning of "on the wire"?
	Description What is the meaning of "on the wire"? Resolution: 2004-02-10 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 paragraph 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 paragraph 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."
er011	SOAP version 1.2 is no longer in development
	Description Section 1.2, says that SOAP 1.2 is "currently under development." This is no longer the case. Resolution: 2004-01-13 Remove 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.
er012	Incorrect reference to media type in R1018
	Description R1018 should refer to a Content-Type header, not a media type (media types do not contain parameters) Resolution: 2004-02-03 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]
er013	Extraneous "do" in R1112
	Description Extraneous "do" in R1112 Resolution: 2004-01-13 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.
er014	Misplaced space in R1113
	Description R1113 has a misplaced space Resolution: 2004-02-01 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.
er015	Placement of WSDL extensibility elements in WSDL
	Description WSDL schema and the specification contradict each other with respect to the placement of WSDL extensibility elements as children of wsdl:definitions. Resolution: 2005-08-16 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 allow element extensibility at the end of the sequence in the tDefinitions type: <xs:complexType name="tDefinitions"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:sequence minOccurs="0"> <xs:group ref="wsdl:anyTopLevelOptionalElement"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:group ref="wsdl:anyTopLevelOptionalElement"/> <xs:any namespace="##other" processContents="lax"/> <xs:choice> <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> As a convenience, WS-I has posted a version of the revised WSDL schema at: http://ws-i.org/profiles/basic/1.0/wsdl-2005-03-09.xsd
er016	Extraneous "are required" in Section 4.1.11
	Description Extraneous "are required" in Section 4.1.11 Resolution: 2004-02-01 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.
er017	Section 5.4.4 incorrectly indicates that the parameterOrder attribute is on the wsdl:portType element
	Description Section 5.4.4 and R2305 talk about the usage of the parameterOrder attribute, but it incorrectly indicates that this attribute is on the wsdl:portType element. It is actually on the wsdl:operation element. Resolution: 2004-01-13 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.
er018	Incorrect namespace prefix for the headerfault element in R2743
	Description In Section 5.6.14, requirement R2743 makes a reference to a wsdl:headerfault element. This element does not exist in the WSDL namespace Resolution: 2004-01-13 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.
er019	Inconsistency between the spec and the schema for WSDL extensibility
	Description Section 5.1.11 extensibility list is different from the extensibility in the schema file located at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd Resolution: 2004-02-03 Remove the phrase "as well as attributes" from the BP1.0 text in section 5.1.11
er020	Incorrect URL for SOAP 1.1
	Description The URL http://www.w3.org/TR/SOAP/ is intended to reference the most recent version of the SOAP specification, which is currently SOAP Version 1.2. The correct URL for SOAP 1.1 is http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ Resolution: 2004-01-20 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/
er021	Is the RECEIVER required to accept UTF-8 message that don't have a BOM?
	Description R4001 requires the RECEIVER to accept messages that do have a BOM, but there is no mention of messages that do not have a BOM (which is allowed by UTF-8) Resolution: 2004-01-20 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.
er022	Is the RECEIVER required to accept a message that does not have the XML declaration?
	Description R1010 requires the RECEIVER to accept messages that that have an XML declaration, but there is no mention of messages that do not have an XML declaration Resolution: 2004-01-20 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.
er023	The profile does not say how the 'encoding' pseudo-attribute of the XML declaration is treated.
	Description R1018 requires that the HTTP Content-Type header must specify the 'charset' parameter, but does not say how the 'encoding' pseudo-attribute of the XML declaration of the SOAP is treated. Resolution: 2004-01-20 Add a new requirement R1019 in Section 4.1.11: R1019 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.
er024	Clarify the meaning of generating a fault and explain the difference between generating a fault and transmitting a fault
	Description The profile has requirements regarding genaration of a fault (e.g., R1027), but does not describe the meaning of generating a fault. The profile also does not specify the distinction between generating and transmitting a fault. Resolution: 2004-02-03 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."
er025	Change the 'MUST' to 'SHOULD' in R1029
	Description R1029 requires that the service transmit a fault in case of an error. This means that a service will always have to send a fault, even when it is facing a DoS attack. Resolution: 2004-02-03 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."
er026	SOAP 1.1 schema located at http://schemas.xmlsoap.org/soap/envelope/ does not allow xml:lang attribute on the faultstring element
	Description R1016 requires that receiver must accept fault messages that carry xml:lang attribute on the faultstring element, but the SOAP 1.1 schema at http://schemas.xmlsoap.org/soap/envelope/ does not allow this attribute. Resolution: 2004-02-10 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'.
er027	Clarify that wsdl:operation applies to both binding and portType
	Description Clarify that wsdl:operation applies to child of either wsdl:portType or wsdl:binding. Resolution: 2004-02-03 Amend wsdl:operation bullet item in the list in Section 5.1.11 to append "(in portType or binding)"
er028	clarify R1107
	Description clarify R1107 Resolution: 2004-02-03 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."
er029	Should the schemas for WSDL and SOAP should be posted at a WS-I URI
	Description The URIs for the normative WSDL and WSDL SOAP schemas should be ws-i.org URIs. Resolution: 2004-10-25 Modify section 5.1.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".
er030	clarification of soap:actor extensibility point description
	Description Does http://schemas.xmlsoap.org/soap/actor/next count as an extensibility point? Resolution: 2004-02-24 Amend the text for the soap:actor extensibility point in Appendix II 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.
er032	xmlns:xml issue
	Description Confusion as to whether it is acceptable to have messages and/or descriptions use the xmlns:xml namespace declaration. Resolution: 2004-03-09 Add XML 1.0 reference to BP 1.0 Section 5 list of profiled specs. 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. Add Namespaces in XML 1.0 to BP 1.0 Section 4 list of profiled specs, just below XML 1.0. Add Namespaces in XML 1.0 to BP 1.0 Section 5 list of profiled specs, just below XML 1.0. Add Namespaces in XML 1.0 to BP 1.0 Appendix I, just below XML 1.0. Add the following two requirements after BP 1.0 Section 4.1.8: R1033: An ENVELOPE SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". [c] R1034: 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.
er033	R1000 contains an ambiguous term/target 'Message contains a soap:Fault'
	Description R1000 talks about a 'MESSAGE contains a soap:Fault' and not about SOAP Envelopes that are Faults. Resolution: 2004-03-17 Replace R1000 with the following: R1000 When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have element children other than faultcode, faultstring, faultactor and detail.
er034	R2027 is hard to understand
	Description R2027 is hard to understand. Resolution: 2004-03-18 Amend R2027 to read as follows: R2027 If during the processing of a description, a consumer encounters a WSDL extension element that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing.
er035	Part accessors local name of rpc-literal binding
	Description Section 5.6.20 does not specify the value of the part accessors local names. Resolution: 2004-03-18 Change the section title for Section 5.6.20 to "Part Accessors". Add the following requirement to Section 5.6.20: R2755 The part accessor elements in a MESSAGE described with an rpc-literal binding MUST have a local name of the same value as the name attribute of the corresponding wsdl:part element.
er036	Incorrect namespace prefixes in R2742 and R2743
	Description Incorrect namespace prefixes in R2742 and R2743. Resolution: 2004-03-18 In R2742, change wsdl:fault to soapbind:fault. In R2743, change wsdl:headerfault to soapbind:headerfault.
er037	Section 4.1.3
	Description Section 4.1.3 -- 'contain a fault' vs. 'is a fault' Resolution: 2004-03-17 Replace R1001 with the following: R1001 When an ENVELOPE is a Fault, the element children of the soap:Fault element MUST be unqualified.
er038	Messages encoded in both UTF-8 and UTF-16 and UDDI
	Description Section 6 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. Resolution: 2005-09-06 Replace the following sentence in Section 6: 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 1.0 because they do not accept messages encoded in either UTF-8 or UTF-16 as required by the Profile.
er039	WSDL SOAP binding schema does not allow parts attribute on the soapbind:body element to be empty
	Description The WSDL SOAP binding schema represented by the soapbind namespace prefix does not allows the parts attribute of the soapbind:body element to be empty. I.e., <soapbind:body parts=""/> Such an empty attribute is required to indicate that none of the message parts are bound to soap:Body. Resolution: 2005-10-25 Modify the schema to for soapbind namespace as follows: Add a new type: <xs:simpleType name="tParts"> <xs:list itemType="xs:NMTOKEN"/> <xs:simpleType> Change the type of the 'parts' attribute of complexType tBody to tParts as follows: <xs:complexType name="tBody" > <xs:complexContent> <xs:extension base="wsdl:tExtensibilityElement" > <xs:attribute name="parts" type="soapbind:tParts" use="optional" /> <xs:attributeGroup ref = "soapbind:tBodyAttributes" /> <xs:extension> <xs:complexContent> <xs:complexType>