WSDL20 validation

The WSDL-20 Primer makes some assertions about the valididty of a WSDL document

http://www.w3.org/TR/wsdl20-primer

I scanned the primer for MUST and came up with the following list:

2.2 Defining a WSDL Target Namespace

001) The WSDL target namespace MUST be an absolute URI

2.3 Defining Message Types

002) All normal and fault message types must be defined as single elements at the topmost level

2.4 Defining an Interface

003) Each operation specifies the types of messages that the service can send or receive as part of that operation.

004) Each interface must be given a name that is unique within the set of interfaces defined in this WSDL target namespace.

005) Fault names must unique within an interface.

006) Operation names must also be unique within an interface.

007) Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the messageLabel attribute.

008) Faults are declared a little differently than normal messages. The ref attribute refers to the name of a previously defined fault in this interface – not a message schema type directly.

009) The fault messageLabel is used to indicate the desired point for this particular fault.

2.5 Defining a Binding

010) A binding specifies concrete message format and transmission protocol details for an interface, and must supply such details for every operation and fault in the interface.

011) The name attribute defines a name for this binding. Each name must be unique among all bindings in this WSDL target namespace

012) wsoap:mep specifies the SOAP message exchange pattern that will be used to implement the abstract WSDL 2.0 message exchange pattern

2.6 Defining a Service

013) A WSDL 2.0 service specifies a single interface that the service will support, and a list of endpoint locations where that service can be accessed.

014) Each endpoint must also reference a previously defined binding in order to indicate the binding details that are to be used at that endpoint.

015) defines a name for this service, which must be unique among service names in the WSDL target namespace.

016) interface specifies the name of the previously defined interface that these service endpoints will support.

017) endpoint defines an endpoint for the service, and a name for this endpoint, which must be unique within this service.

018) binding specifies the name of the previously defined binding to be used by this endpoint.

019) address specifies the physical address at which this service can be accessed using the binding specified by the binding attribute.

3.1 Defining Messages Using XML Schema

020) A WSDL description MUST NOT refer to XML Schema components in a given namespace unless an xs:import and/or xs:schema statement for that namespace is present.

3.1.1 Importing XML Schema

021) components that the schema imports via xs:import are NOT available to WSDL.

022) the referenced schema MUST contain an XML Schema targetNamespace attribute on its xs:schema element and the values of these two attributes MUST be identical.

3.1.2 Embedding XML Schema

023) components defined in an embedded XML schema are NOT automatically made available to a WSDL description that imported (using wsdl:import ) the description that embeds the schema

4.1.1 Interface Inheritance

024) recursive extension of interfaces is prohibited.

025) within the same namespace, two or more interface operations end up having the same name. In such cases, WSDL 2.0 requires that the component models of those Interface Operation components MUST be equivalent

4.1.3 Interface Operations

026) Note that the style attribute MAY not be present, but if it is present, then the rules implied by that value MUST be followed or it is an error. For example, WSDL 2.0 defines a set of rules for constructing so called RPC style messages

027) The messageLabel attribute is used to identify the role this message plays in the MEP. Its value must match the name of the MEP place holder message.

028) the direction implied by the input, and output must also match the direction of the placeholder message identified by messageLabel .

5. More on Bindings

029) If a binding specifies any operation-specific binding details or any fault binding details, then it MUST specify an interface the binding information applies to

030) A binding tied to a particular interface MUST define bindings for all the operations of that interface.

031) Constructs for defining binding details are defined within their own namespaces which must be different from the WSDL namespace.

5.1.1 Binding Faults

032) the value of ref attribute of all the faults under a binding MUST be unique. That is, one cannot define multiple bindings for the same interface fault within a given binding.

5.1.2 Binding Operations

033) the required ref attribute of binding operation . For each operation within a binding , the value of ref attribute MUST be unique. That is, one cannot define multiple bindings for the same interface operation within a given binding .

6. More on Service Endpoints

034) Each service within a same namespace must be named uniquely. A service can only implement one single interface, and it must specify the single interface it implements via the interface attribute.

035) All endpoints within a service must be named uniquely via the name attribute. The required binding attribute refers to, via Qname, a binding definition. Note that if the refered binding specifies a particular interface, that interface MUST be the same as the one implmented by the parent service .

Please implement these checks and add others from the spec if appropriate.