WS-I Profile SupportWS-I Profiles specify important new standards for building and using web services. The Web Services Package tries to follow the recommendations of the WS-I Profile. However, there are some recommendations that are not supported or required by the Web Services Package. This section documents the level of conformity by the Web Services Package to the WS-I Profile guidelines.
3. Profile Conformance
3.1 Conformance of Artifacts * MESSAGE--protocol elements that are exchanged, usually over a network, to effect a web service (e.g., SOAP/HTTP messages)
* DESCRIPTION--descriptions of types, messages, interfaces, and their concrete protocol and data format bindings, and the network access points associated with web services (e.g., WSDL descriptions)
* REGDATA--registry elements that are involved in the registration and discovery of web services (e.g. UDDI tModels) 3.2 Conformance of Services, Consumers and Registries * INSTANCE--software that implements a wsdl:port or a uddi:bindingTemplate
* CONSUMER--software that invokes an INSTANCE
* REGISTRY--a UDDI registry, capable of managing REGDATA * SENDER--software that generates a message according to the protocol(s) associated with it
* RECEIVER--software that consumes a message according to the protocol(s) associated with it (e.g., SOAP processors) R0001 An INSTANCE MUST be described by a WSDL 1.1 service description, by a UDDI binding template, or both.
Not applicable.
3.3 Conformance Annotation in Descriptions
R0002 A DESCRIPTION MAY contain conformance claims regarding instances, as specified in the conformance claim schema.
Not supported. R0003 A DESCRIPTION's conformance claims MUST be children of the wsdl:documentation element of each of the elements: wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation (as a child element of wsdl:portType but not of wsdl:binding) and wsdl:message.
Not supported. 3.4 Conformance Annotation in Messages R0004 A MESSAGE MAY contain conformance claims, as specified in the conformance claim schema.
Not supported. R0005 A MESSAGE's conformance claims MUST be carried as SOAP header blocks.
Not supported. R0006 A MESSAGE MAY contain conformance claims for more than one profile.
Not supported. R0007 A SENDER MUST NOT use the soap:mustUnderstand attribute when sending a SOAP header block containing a conformance claim.
Not supported. 3.5 Conformance Annotation in Registry Data R3020 REGDATA of type uddi:tModel claiming conformance with a profile MUST be categorized using the ws-i-org:conformsTo:2002_12 taxonomy.
Not supported. R3030 REGDATA of type uddi:tModel claiming conformance with a profile MUST use the ws-i-org:conformsTo:2002_12 categorization value corresponding to the conformance claim URI for that profile.
Not supported. R3021 A REGISTRY MUST support the WS-I conformance category system by adding the ws-i-org:conformsTo:2002_12 tModel definition to its registry content.
Not supported. R3005 REGDATA other than uddi:tModel elements representing conformant web service types MUST NOT be categorized using the ws-i-org:conformsTo:2002_12 taxonomy and a categorization of "http://ws-i.org/profiles/basic/1.0".
Not supported. R3004 REGDATA of type uddi:tModel MUST be constructed so that the conformance claim it makes is consistent with the conformance claim made by the wsdl:binding to which it refers.
Not supported.
4. Messaging
4.1 XML Representation of SOAP Messages
4.1.1 SOAP Messages and the Unicode BOM
R4001 A RECEIVER MUST accept messages that include the Unicode Byte Order Mark (BOM).
Not directly supported by the Mathematica client, but may be supported by Axis.
4.1.2 SOAP Fault Syntax
R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor, and detail.
SOAP faults are handled by Axis. This should be documented in the Axis documentation.
4.1.3 SOAP Faults and Namespaces
R1001 When a MESSAGE contains a soap:Fault element, its element children MUST be unqualified.
SOAP faults are handled by Axis. This should be documented in the Axis documentation.
4.1.4 SOAP Fault Extensibility
R1002 A RECEIVER MUST accept fault messages that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified.
SOAP faults are handled by Axis. This should be documented in the Axis documentation. R1003 A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than "http://schemas.xmlsoap.org/soap/envelope/".
SOAP faults are handled by Axis. This should be documented in the Axis documentation.
4.1.5 SOAP Fault Language
R1016 A RECEIVER MUST accept fault messages that carry an xml:lang attribute on the faultstring element.
SOAP faults are handled by Axis. This should be documented in the Axis documentation.
4.1.6 SOAP Custom Fault Codes
R1004 When a MESSAGE contains a faultcode element, the content of that element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace qualified fault code.
SOAP faults are handled by Axis. This should be documented in the Axis documentation. R1031 When a MESSAGE contains a faultcode element, the content of that element SHOULD NOT use the SOAP 1.1 "dot" notation to refine the meaning of the fault.
SOAP faults are handled by Axis. This should be documented in the Axis documentation.
4.1.7 SOAP encodingStyle Attribute
R1005 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/envelope/".
Not supported. This is not supported as the Web Services Package supports rpc/encoded web services. This is required to be encoded. R1006 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.
Not supported. This is not supported as the Web Services Package supports rpc/encoded web services. This is required to be encoded. R1007 A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements that are grandchildren of soap:Body.
Supported.
4.1.8 SOAP's use of XML
R1008 A MESSAGE MUST NOT contain a Document Type Declaration (DTD).
Supported. R1009 A MESSAGE MUST NOT contain processing instructions.
Supported.
4.1.9 SOAP and XML Declarations
R1010 A RECEIVER MUST accept messages that contain an XML declaration.
Supported.
4.1.10 SOAP Trailers
R1011 A MESSAGE MUST NOT have any element children of soap:Envelope following the soap:Body element.
Supported.
4.1.11 Acceptable SOAP Character Encodings
R1012 A MESSAGE MUST be serialized as either UTF-8 or UTF-16.
Supported. R1018 The media type of a MESSAGE's envelope MUST indicate the correct character encoding, using the charset parameter.
Not directly supported by the Mathematica client, but may be supported by Axis.
4.1.12 SOAP mustUnderstand Attribute
R1013 A MESSAGE containing a soap:mustUnderstand attribute MUST only use the lexical forms "0" and "1".
Supported.
4.1.13 SOAP Body and Namespaces
R1014 The children of the soap:Body element in a MESSAGE MUST be namespace qualified.
Supported.
4.1.14 SOAP Envelope Namespace
R1015 A RECEIVER MUST generate a fault if they encounter a message whose document element has a local name of "Envelope" but a namespace name that is not "http://schemas.xmlsoap.org/soap/envelope/".
Not directly supported by the Mathematica client, but may be supported by Axis.
4.1.15 Use of xsi:type Attributes
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).
Supported.
4.2 SOAP Processing Model
4.2.1 Mandatory Headers
R1025 A RECEIVER MUST handle messages in such a way that it appears that all checking of mandatory header blocks is performed before any actual processing. SOAP12
Not supported. The client does not support processing headers.
4.2.2 Generating mustUnderstand Faults
R1027 A RECEIVER MUST generate a "soap:MustUnderstand" fault when a message contains a mandatory header block (i.e., one that has a soap:mustUnderstand attribute with the value "1") targeted at the receiver (via soap:actor) that the receiver does not understand.
Not supported. The client does not support processing headers.
4.2.3 SOAP Fault Processing
R1028 When a fault is generated by a RECEIVER, further processing SHOULD NOT be performed on the SOAP message aside from that which is necessary to rollback, or compensate for, any effects of processing the message prior to the generation of the fault.
Not supported. The client does not support processing headers. R1029 Where the normal outcome of processing a SOAP message would have resulted in the transmission of a SOAP response, but rather a SOAP fault is generated instead, a RECEIVER MUST transmit a SOAP fault message in place of the response.
Supported. R1030 A RECEIVER that generates a SOAP fault SHOULD notify the end user that a SOAP fault has been generated when practical, by whatever means is deemed appropriate to the circumstance.
Not supported. The client does not do this by default.
4.3 Use of SOAP in HTTP
4.3.1 HTTP Versions
R1140 A MESSAGE SHOULD be sent using HTTP/1.1.
Supported. R1141 A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0.
Supported.
4.3.2 Identifying SOAP Faults
R1107 A RECEIVER MUST interpret SOAP messages containing only a soap:Fault element as a fault.
Not directly supported by the Mathematica client, but may be supported by Axis.
4.3.3 HTTP Methods and Extensions
R1132 A HTTP request MESSAGE MUST use the HTTP POST method.
Supported. R1108 A MESSAGE MUST NOT use the HTTP Extension Framework (RFC2774).
Supported.
4.3.4 SOAPAction Header Syntax
R1109 The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.
Not directly supported by the Mathematica client, but may be supported by Axis. R1119 A RECEIVER MAY respond with a fault if the value of the SOAPAction HTTP header field is not quoted.
Not supported. The client does not support SOAPAction headers.
4.3.5 HTTP and TCP Ports
R1110 An INSTANCE MAY accept connections on TCP port 80 (HTTP).
Not applicable.
4.3.6 HTTP Success Status Codes
R1124 An INSTANCE MUST use a 2xx HTTP status code for responses that indicate a successful outcome of a request.
Not applicable. R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code for responses that contain a SOAP message that is not a SOAP fault.
Not applicable. R1112 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.
Not applicable.
4.3.7 HTTP Redirect Status Codes
R1130 An INSTANCE MUST use HTTP status code "307 Temporary Redirect" when redirecting a request to a different endpoint.
Not applicable. R1131 A CONSUMER MAY automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response.
Supported.
4.3.8 HTTP Client Error Status Codes
R1125 An INSTANCE MUST use a 4xx HTTP status code for responses that indicate a problem with the format of the request.
Not applicable. R1113 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.
Not applicable. R1114 An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST".
Not applicable. R1115 An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if the Content-Type HTTP request header did not have a value consistent with the value specified for the corresponding binding of the input message.
Not applicable.
4.3.9 HTTP Server Error Status Codes
R1126 An INSTANCE MUST use a "500 Internal Server Error" HTTP status code if the response message is a SOAP fault.
Not applicable.
4.3.10 HTTP Cookies
R1120 An INSTANCE MAY use the HTTP state mechanism ("cookies").
Not applicable. R1122 An INSTANCE using cookies SHOULD conform to RFC2965.
Not applicable. R1121 An INSTANCE SHOULD NOT require consumer support for cookies in order to function correctly.
Not applicable. R1123 The value of the cookie MUST be considered to be opaque by the CONSUMER.
Not applicable.
5. Service Description
5.1 Document Structure
5.1.1 WSDL Schema Definitions
R2028 A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this profile) MUST be valid according to the XML Schema found at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd.
Required. 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://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd.
Required.
5.1.2 WSDL and Schema Import
R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description.
Required. R2002 To import XML Schema definitions, a DESCRIPTION MUST use the XML Schema "import" statement.
Required. R2003 A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section.
Required. 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".
Required. R2009 An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode BOM.
Not directly supported by the Mathematica client, but may be supported by Axis. R2010 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.
Required. R2011 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.
Required.
5.1.3 WSDL Import location Attribute Syntax
R2007 A DESCRIPTION MUST specify a non-empty location attribute on the wsdl:import element.
Required.
5.1.4 WSDL Import location Attribute Semantics
R2008 In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint.
Not supported.
5.1.5 Placement of WSDL import Elements
R2022 When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements from the WSDL namespace except wsdl:documentation.
Not directly supported by the Mathematica client, but may be supported by Axis. R2023 When they appear in a DESCRIPTION, wsdl:types elements MUST precede all other elements from the WSDL namespace except wsdl:documentation and wsdl:import.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.1.6 XML Version Requirements
R4004 A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.
Required.
5.1.7 WSDL and the Unicode BOM
R4002 A DESCRIPTION MAY include the Unicode BOM.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.1.8 Acceptable WSDL Character Encodings
R4003 A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.
Required.
5.1.9 Namespace Coercion
R2005 The targetNamespace attribute on the wsdl:definitions element of a description that is being imported MUST have same the value as the namespace attribute on the wsdl:import element in the importing DESCRIPTION.
Required.
5.1.10 WSDL documentation Element
R2020 The wsdl:documentation element MAY occur as a child of the wsdl:import element in a DESCRIPTION.
Supported, but this will be ignored by the client. R2021 The wsdl:documentation element MAY occur as a child of the wsdl:part element in a DESCRIPTION.
Supported, but this will be ignored by the client. R2024 The wsdl:documentation element MAY occur as a first child of the wsdl:definitions element in a DESCRIPTION.
Supported, but this will be ignored by the client.
5.1.11 WSDL Extensions
R2025 A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the profile.
Not supported. R2026 A DESCRIPTION SHOULD NOT include extension elements with a wsdl:required attribute value of "true" on any WSDL construct (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types or wsdl:import) that claims conformance to the profile.
Not supported. R2027 If during the processing of an element in the WSDL namespace in a description a consumer encounters a WSDL extension element amongst its element children 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 of that element in the WSDL namespace.
Not supported.
5.2 Types
5.2.1 QName References
R2101 A DESCRIPTION MUST NOT use QName references to elements in namespaces that have been neither imported nor defined in the referring WSDL document.
Required. R2102 A QName reference to a schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element.
Required.
5.2.2 Schema targetNamespace Syntax
R2105 All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).
Required.
5.2.3 soapenc:Array
R2110 In a DESCRIPTION array declarations MUST NOT extend or restrict the soapenc:Array type.
Not required. R2111 In a DESCRIPTION array declarations MUST NOT use wsdl:arrayType attribute in the type declaration.
Not required. R2112 In a DESCRIPTION array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX.
Not supported. R2113 A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute.
Not required.
5.2.4 WSDL and Schema Definition Target Namespaces
R2114 The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same.
Supported.
5.3 Messages
5.3.1 Bindings and Parts
R2201 A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body elements, have at most one part listed in the parts attribute, if the parts attribute is specified.
Required. R2210 If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl:part elements(s).
Required. R2202 A wsdl:binding in a DESCRIPTION MAY contain soapbind:body elements that specify that zero parts form the soap:Body.
Supported. R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its soapbind:body element(s), only to wsdl:part elements that have been defined using the type attribute.
Required. R2211 A MESSAGE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of "1" or "true" on the part accessors.
Supported. R2207 A wsdl:message in a DESCRIPTION MAY contain wsdl:parts that use the elements attribute, provided those wsdl:parts are not referred to by a soapbind:body in an rpc-literal binding.
Supported. R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.
Required. R2208 A binding in a DESCRIPTION MAY contain soapbind:header element(s) that refer to wsdl:part element(s) in the same wsdl:message that are referred to by its soapbind:body element(s).
Not directly supported by the Mathematica client, but may be supported by Axis.
5.3.2 Bindings and Faults
R2205 A wsdl:binding in a DESCRIPTION MUST refer, in each of its soapbind:header, soapbind:headerfault, and soapbind:fault elements, only to wsdl:part element(s) that have been defined using the element attribute.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.3.3 Unbound portType Element Contents
R2209 A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault, or soapbind:headerfault.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.3.4 Declaration of part Elements
R2206 A wsdl:message in a DESCRIPTION containing a wsdl:part that uses the element attribute MUST refer, in that attribute, to a global element declaration.
Required.
5.4 Port Types
5.4.1 Ordering of part Elements
R2301 The order of the elements in the soap:body of a MESSAGE MUST be the same as that of the wsdl:part element(s) in the wsdl:message that describes it.
Supported.
5.4.2 Allowed Operations
R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.
Required.
5.4.3 Distinctive Operations
R2304 A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes.
Not required, but recommended.
5.4.4 parameterOrder Attribute Construction
R2305 A wsdl:portType in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most one wsdl:part from the output message.
Not required. The parameterOrder attribute is not used in the client.
5.4.5 Exclusivity of type and element Attributes
R2306 A wsdl:message in a DESCRIPTION MUST NOT specify both type and element attributes on the same wsdl:part.
Required.
5.5 Bindings
5.5.1 Use of SOAP Binding
R2401 A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.
Required.
5.6 SOAP Binding
5.6.1 Specifying the transport Attribute
R2701 The wsdl:binding element in a DESCRIPTION MUST be constructed so that its soapbind:binding child element specifies the transport attribute.
Not required.
5.6.2 HTTP Transport
R2702 A wsdl:binding element in a DESCRIPTION MUST specify the HTTP transport protocol with SOAP binding. Specifically, the transport attribute of its soapbind:binding child MUST have the value "http://schemas.xmlsoap.org/soap/http".
Required.
5.6.3 Consistency of style Attribute
R2705 A wsdl:binding in a DESCRIPTION MUST use either a rpc-literal binding or a document-literal binding.
Not required. The rpc-encoded binding is supported as well.
5.6.4 Encodings and the use Attribute
R2706 A wsdl:binding in a DESCRIPTION MUST use the value of "literal" for the use attribute in all soapbind:body, soapbind:fault, soapbind:header, and soapbind:headerfault elements.
Not required. The value "encoded" is valid as well.
5.6.5 Default for use Attribute
R2707 A wsdl:binding in a DESCRIPTION that contains one or more soapbind:body, soapbind:fault, soapbind:header, or soapbind:headerfault elements that do not specify the use attribute MUST be interpreted as though the value "literal" had been specified in each case.
Supported.
5.6.6 Multiple Bindings for portType Elements
R2709 A wsdl:portType in a DESCRIPTION MAY have zero or more wsdl:binding elements that refer to it, defined in the same or other WSDL documents.
Supported.
5.6.7 Wire Signatures for Operations
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another.
Required.
5.6.8 Multiple Ports on an Endpoint
R2711 A DESCRIPTION SHOULD NOT have more than one wsdl:port with the same value for the location attribute of the soapbind:address element.
Not required, but recommended.
5.6.9 Child Element for Document-Literal Bindings
R2712 A document-literal binding MUST be represented on the wire as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part.
Required.
5.6.10 One-Way Operations
R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains a SOAP envelope. Specifically, the HTTP response entity-body must be empty.
Not applicable. R2750 A CONSUMER MUST ignore a SOAP response carried in a response from a one-way operation.
One-way operations are not supported. R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it.
One-way operations are not supported.
5.6.11 Namespaces for soapbind Elements
R2716 A document-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained soapbind:body, soapbind:header, soapbind:headerfault, and soapbind:fault elements.
Not required.
5.6.12 Consistency of portType and binding Elements
R2718 A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operation elements as the wsdl:portType to which it refers.
Required.
5.6.13 Describing headerfault Elements
R2719 A wsdl:binding in a DESCRIPTION MAY contain no soapbind:headerfault elements if there are no known header faults.
Supported.
5.6.14 Enumeration of Faults
R2740 A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:fault describing each known fault.
Supported. R2741 A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:headerfault describing each known header fault.
Supported. R2742 A MESSAGE MAY contain a fault detail entry in a SOAP fault that is not described by a wsdl:fault element in the corresponding WSDL description.
Supported. R2743 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.
Supported.
5.6.15 Type and Name of SOAP Binding Elements
R2720 A wsdl:binding in a DESCRIPTION MUST use the attribute named part with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements.
Required. R2749 A wsdl:binding in a DESCRIPTION MUST NOT use the attribute named parts on contained soapbind:header and soapbind:headerfault elements.
Required.
5.6.16 name Attribute on Faults
R2721 A wsdl:binding in a DESCRIPTION MUST have the name attribute specified on all contained soapbind:fault elements.
Not required. R2754 In a DESCRIPTION, the value of the name attribute on a soapbind:fault element MUST match the value of the name attribute on its parent wsdl:fault element.
Not required.
5.6.17 Omission of the use Attribute
R2722 A wsdl:binding in a DESCRIPTION MAY specify the use attribute on contained soapbind:fault elements.
Not supported. R2723 If in a wsdl:binding in a DESCRIPTION the use attribute on a contained soapbind:fault element is present, its value MUST be "literal".
Not supported. R2728 A wsdl:binding in a DESCRIPTION that omits the use attribute on a contained soapbind:fault element MUST be interpreted as though use="literal" had been specified.
Not supported.
5.6.18 Consistency of Messages with Descriptions
R2724 If an INSTANCE receives a message that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of "Client", unless a "MustUnderstand" or "VersionMismatch" fault is generated.
Not directly supported by the Mathematica client, but may be supported by Axis. R2725 If an INSTANCE receives a message that is inconsistent with its WSDL description, it MUST check for "VersionMismatch", "MustUnderstand", and "Client" fault conditions in that order.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.6.19 Response Wrappers
R2729 A MESSAGE described with an rpc-literal binding that is a response message MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string "Response".
Not required.
5.6.20 Namespace for Part Accessors
R2735 A MESSAGE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace.
Supported.
5.6.21 Namespaces for Children of Part Accessors
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.
Supported.
5.6.22 Required Headers
R2738 A MESSAGE MUST include all soapbind:header elements specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it.
Supported.
5.6.23 Allowing Undescribed Headers
R2739 A MESSAGE MAY contain SOAP header blocks that are not described in the wsdl:binding that describes it.
Not supported. There is no way to add additional headers to a message unless you work directly with the message. If the client receives a message with headers that are not described in the definition, they will not be processed. R2753 A MESSAGE containing SOAP header blocks that are not described in the appropriate wsdl:binding MAY have the mustUnderstand attribute on such SOAP header blocks set to "1".
Not supported. There is no way to add additional headers to a message unless you work directly with the message. If the client receives a message with headers that are not described in the definition, they will not be processed.
5.6.24 Ordering Headers
R2751 The order of soapbind:header elements in soapbind:binding sections of a DESCRIPTION MUST be considered independent of the order of SOAP header blocks in the message.
The client does not support processing headers. The headers will be placed in order when building a message on the client. R2752 A MESSAGE MAY contain more than one instance of each SOAP header block for each soapbind:header element in the appropriate child of soapbind:binding in the corresponding description.
The client does not support processing headers.
5.6.25 Describing SOAPAction
R2744 A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description.
Supported. R2745 A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted empty string value, if in the corresponding WSDL description, the soapAction of soapbind:operation is either not present or present with an empty string as its value.
Not directly supported by the Mathematica client, but may be supported by Axis.
5.6.26 SOAP Binding Extensions
R2747 A CONSUMER MUST understand and process all WSDL 1.1 SOAP binding extension elements, irrespective of the presence or absence of the wsdl:required attribute on an extension element and irrespective of the value of the wsdl:required attribute when present.
Extensions are not supported. R2748 A CONSUMER MUST NOT interpret the presence of the wsdl:required attribute on a soapbind extension element with a value of "false" to mean the extension element is optional in the messages generated from the WSDL description.
Extensions are not supported.
5.7 Use of XML Schema
R2800 A DESCRIPTION MAY use any construct from XML Schema 1.0.
Not supported. R2801 A DESCRIPTION MUST use XML Schema 1.0 recommendation as the basis of user-defined datatypes and structures.
Required.
6. Service Publication and Discovery
6.1 bindingTemplates
R3100 REGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element.
Registry functionality is not supported.
6.2 tModels
R3002 REGDATA of type uddi:tModel representing a conformant web service type MUST use WSDL as the description language.
Registry functionality is not supported. R3003 REGDATA of type uddi:tModel representing a conformant web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec".
Registry functionality is not supported. R3010 REGDATA of type uddi:tModel representing a conformant web service type MUST follow V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry.
Registry functionality is not supported. R3011 The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST itself conform to the profile.
Registry functionality is not supported.
7. Security
7.1 Use of HTTPS
R5000 An INSTANCE MAY require the use of HTTPS.
Not applicable. R5001 If an INSTANCE requires the use of HTTPS, the location attribute of the soapbind:address element in its wsdl:port description MUST be a URI whose scheme is "https"; otherwise it MUST be a URI whose scheme is "http".
Required. R5010 An INSTANCE MAY require the use of HTTPS with mutual authentication.
Not applicable.
| 
