The WS-I Validator can be used to check your WSDL definitions against the Basic Profile.
You can use the WS-I Validator to check your WSDL definitions against the Basic Profile; see WS-I Basic Profile Version 1.1.
- Manually against a specific
.wsdlresource in the workbench.
This option enables you to investigate and fix WS-I compliance problems; all validation issues are displayed as task list errors and warnings.
- Automatically, when WSDL is imported or generated.
You can import WSDL definitions by using the Message Model wizard.
- Select .
- Click Service Policies, and expand Profile Compliance.
- Select one of the following profiles:
- WS-I AP compliance level (WS-I Attachments Profile 1.0)
- WS-I SSBP compliance level (WS-I Simple SOAP Binding Profile 1.0)
- Select a compliance level:
- Select Suggest compliance to run the validator with errors treated as unrecoverable, but warnings only notified. This is the default setting.
- Select Require compliance to run the validator with errors and warnings treated as unrecoverable.
- Select Ignore compliance if you do not want to run the validator.
The AP selection applies automatically to the SSBP field, therefore Ignore is not explicitly selectable unless the AP selection is set to Ignore.
document-literalmeans the combination
rpc-literalmeans the combination
rpc-encodedmeans the combination
- Your WSDL is rpc-encoded
- WSDL with
use="encoded"is not WS-I compliant and can lead to operational problems because products of different vendors can make different assumptions about the expected SOAP payload.
WS-I: (BP2406) The use attribute of a
soapbind:headerfaultdoes not have the value of "literal".
- Your WSDL is document-literal, but one or more WSDL part definitions refer to XML Schema types.
document-literalWSDL, the SOAP body payload is the XML Schema element that is referred to by the appropriate WSDL part.
If a type is specified instead of an element, the SOAP payload is potentially ambiguous (the payload name is not defined) and interoperability problems are likely.
WS-I: (BP2012) A
soapbind:bodyelements that refer to message part elements that do not have the element attribute.
- Your WSDL is rpc-literal or rpc-encoded, but one or more WSDL part definitions refer to XML Schema elements.
- In rpc-style WSDL, the SOAP body payload is the WSDL operation
name, and its children are the WSDL parts that are specified for that
If an element is specified instead of a type, the SOAP message payload is potentially ambiguous (the payload name might be the WSDL part name or the XML Schema element name), and interoperability problems are likely.
WS-I: (BP2013) An rpc-literal binding contains
soapbind:bodyelements that refer to message part elements that do not have the type attribute.
- Your WSDL includes SOAP header, headerfault or fault definitions that refer to XML Schema types.
- In rpc-style WSDL, the SOAP body is correctly defined through
XML Schema types as described above.
SOAP headers and faults, however, do not correspond to an rpc function call in the same way as the body.
In particular, there is no concept of 'parameters' to a header or fault, and a header or fault must always be defined in terms of XML Schema elements to avoid potential ambiguity. Effectively, header and fault definitions in WSDL are always
WS-I: (BP2113) The
soapbind:faultelements refer to
wsd:partelements that are not defined using only the "element" attribute.
- Your WSDL is rpc-literal or rpc-encoded, but no namespace was specified for an operation.
- In rpc-style WSDL, the SOAP message payload is the WSDL operation
name, qualified by a namespace that is specified as part of the WSDL
If no namespace is specified then the SOAP message payload is potentially ambiguous (the payload name might be in no namespace, or might default to use a different namespace, such as the target namespace of the WSDL definition) and interoperability problems are likely.
WS-I: (BP2020) An rpc-literal binding contains
soapbind:bodyelements that either do not have a namespace attribute, or have a namespace attribute value that is not an absolute URI.
- Your WSDL includes a SOAP/JMS binding.
- If your WSDL uses a SOAP/JMS transport URI it is not WS-I compliant. An error is shown if strict WS-I validation is enabled. To disable strict WS-I validation, click WS-I BP 1.1: Allow SOAP/JMS as transport URI. By default strict WS-I validation is disabled. and select the
- Use document-style WSDL whenever possible.
- Use literal encoding, if rpc-style WSDL is necessary.
- Ensure that the WSDL operation definitions are qualified by a valid namespace attribute, if rpc-encoded WSDL must be used.