Analysis of WSDL 2.0 CR versus Requirements

Jonathan Marsh, 29 Nov 2005

Items of interest highlighted in yellow, items needing to be completed highlighted in orange.

4.1 General
R001	The description language MUST allow any programming model, transport, or protocol for communication between peers. (From the Charter. Last revised 23 Apr 2002.)	Fulfilled to the best of our knowledge.
R004	The WG specification(s) MUST describe constructs using the [XML Information Set] model (similar to the SOAP 1.2 specifications [SOAP 1.2 Part 1]). (From JS. Last revised 21 Feb 2002.)	Fulfilled, e.g. http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Description_XMLRep
R099	Processors of the description language MUST support XML Schema (http://www.w3.org/2001/XMLSchema). See also [XML Schema Part 1]. (From WG discussion. Last discussed 21 Feb 2002.)	Fulfilled. XML Schema support is baked into the component model, but our conformance section allows one to use parts of a WSDL document that it doesn't understand, and this may apply to parts that use XML Schema. See http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#xsd-types. WSDL Document conformance is assessed including references to XML Schema, so conformance checkers MUST check that XML Schema is referenced correctly. See http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#markup.
R100	The description language MUST allow other type systems besides XML Schema (http://www.w3.org/2001/XMLSchema) via extensibility. (From WG discussion. Last discussed 21 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#other-types, and the WG Note sketching some initial thoughts of how extensions for RDF and RelaxNG might be specified (http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/).
R098	The WG specification(s) schema and examples MUST be written in XML Schema and SHOULD be written in the latest public W3C XML Schema Recommendation. (From WG discussion. Last revised 28 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#basics-greath-scenario.
R005	The WG specification(s) MUST correct errors/inconsistencies in [WSDL 1.1]. (From KL. Last revised 10 Apr 2002.)	Fulfilled, to the best of our knowledge. We processed all issues identified by the community, including those from the WS-I BP.
R007	The WG specification(s) MUST provide detailed examples, including on-the-wire messages. (From KL. Last revised 10 Apr 2002.)	Fulfilled with many examples in the Primer, although examples of on-the-wire messages are limited to http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#adv-MTOM.
R003	The WG specification(s) SHOULD use available XML technologies. (From JS. Last revised 10 Apr 2002.)	Fulfilled by the use of XML, Namespaces, Infoset, XML Schema and XML Schema datatypes, XPointer framework, IRIs, etc. Supports bindings of SOAP 1.2 and HTTP.
R105	The WG specification(s) SHOULD support Web Services that operate on resource constrained devices. (From YF. Last discussed 10 Apr 2002.)	Fulfilled to the best of our ability. No comments otherwise have been received.
R010	The WG specification(s) SHOULD use consistent terminology across all sections of the specification(s). (From KL. Last revised 10 Apr 2002.)	Fulfilled to the best of our ability.
R124	The WG MUST register a MIME type for WSDL (perhaps application/wsdl+xml). (From WG discussion. Last revised 27 Jun 2002.)	In progress, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#ietf-draft.
4.2 Simplicity
R013	The WG specification(s) MUST be simple to understand and implement correctly. The description language MUST be simple to use. (From the Charter. Last discussed 7 Mar 2002.)	Fulfilled to the best of our ability. Simplicity is always in the eye of the beholder.
R014	The WG specification(s) SHOULD be compatible with existing Web infrastructure. (From the Charter. Last discussed 7 Mar 2002.)	Fulfilled. WG is not aware of any conflicts with existing Web infrastructure.
4.3 Interface Description
R021	The description language MUST describe the Messages accepted and generated by the Web Service. (From the Charter. Last revised 21 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#InterfaceOperation.
R022	The description language MUST allow describing application-level error Messages (AKA faults) generated by the Web Service. (From the Charter. Last revised 28 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#InterfaceFault.
R054	The description language MUST describe Messages independent from their use in message exchange patterns and/or InterfaceBindings. (From YF. Last revised 17 Oct 2002.)	Fulfilled, though note that we rely on XML Schema (or some other type system) to define the structure of the message, and use the Interface Operation component (http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#InterfaceOperation.) to associate these structures with a message exchange pattern. The WSDL 1.1 Message construct has been removed in favor of directly using the facilities of the schema language for this purpose.
R041	The description language MUST allow describing sets of Operations that form a logical group. (From JS. Last revised 28 Feb 2002.)	Fulfilled. Operations are grouped into Interfaces, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Interface.
R116	The description language MUST allow describing abstract policies required or offered by Services. (From GD. Last revised 11 Apr 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Feature, although Features and Properties are marked at risk. Some feel the ability to extend WSDL with policy languages such as WS-Policy is sufficient to meet this requirement.
R083	The description language MUST separate design-time from run-time information. (From JS. Last discussed 11 Apr 2002.)	Fulfilled. Interfaces are separate from bindings
R026	The description language MUST provide human-readable comment capabilities. (From the Charter. Last discussed 28 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#eii-documentation.
R123	The content model for human-readable comment capabilities MUST be open. (From RD. Last discussed 11 June 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#eii-documentation.
R042	The description language SHOULD allow deriving one Interface from another by extension of the logical group of Messages. (From JS. Last discussed 11 June 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Interface_details.
R117	The description language SHOULD allow specifying QoS-like policies and mechanisms of a Web Service. For instance, an indication of how long it is going to take a Web Service to process the request. (From WG discussion. Last discussed 12 April 2002.)	Not supported natively. We rely on extension mechanisms (open content model, features & properties framework) to describe QoS capabilities of the service - WSDL components don't support a built-in set of interesting QoS parameters.
4.4 Description of Interactions with a Service
R036	The description language MUST allow describing the functionality associated with one-way messages (to and from the service described), request-response, solicit-response, and faults. (From the Charter. Last revised 28 Feb 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#patterns, although many of these patterns are marked at risk.
R044	The description language SHOULD allow describing both application data and context data of a Service. (From PF. Last discussed 12 April 2002.)	Partially fulfilled. Both SOAP and HTTP bindings allow specification of header information that can be used to carry contextual information, but there are no specific facilities at the abstract level for distinguishing between contextual information and any other application data. See http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#soap-headers-decl and http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#http-headers-decl.
R097	The description language SHOULD allow describing asynchronous message exchange patterns. (From IS. Last discussed 11 April 2002.)	Not supported natively. WSDL message exchange patterns are not constrained to synchronous or asynchronous use. Interface operations are neutral about whether they should be manifested through synchronous or asynchronous programming paradigms. Our SOAP/HTTP binding describes synchronous use (HTTP back-channel), though extensions such as WS-A modify that to offer greater s descriptive capability over asynchrony.
R110	The description language SHOULD allow indicating how long a Web Service is going to take to process the request. This is just a hint to the Client, and the Web Service would not be obligated to respect what it advertised. (From WV. Special case of R117.)	Not supported natively.
R094	The description language MAY allow describing events and output-oriented Operations. The description language MAY be very specific about events, defining a special type of a Message or even a separate definition entity. (From IS. Last discussed 12 April 2002.)	Not supported natively. We describe output-oriented message exchange patterns, but don't provide conventions for event-like operations.
4.5 Messages and Types
R046	The description language MUST describe Messages independent from transfer encodings. (From JS. Last discussed 17 Oct 2002.)	Fulfilled. Messages are described using schema language constructs, and can be bound to a variety of transfer encodings. See for instance the ability to transform XML elements into HTTP parameters in the HTTP binding (http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#_http_location_template).
R085	The description language SHOULD allow describing Messages that include references (URIs) to typed referents, both values and Services. (From PP. Last discussed 11 April, 2002.)	Fulfilled; the Primer illustrates the description of references (URIs) used to refer to a service of a particular type. See http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#adv-service-references.
4.6 Service Types
R118	The description language SHOULD group Interfaces into a Service type. (From JS. Last discussed 12 April 2002.)	Not fulfilled: All endpoints in a service must use the same interface, and represent alternative ways to invoke that single interface. We don't provide a mechanism for relating different interfaces together into a single service, beyond Interface inheritance mechanisms.
R058	The description language SHOULD allow deriving one Service type from another by extension of the logical group of InterfaceBindings. (From JS. Last discussed 12 April 2002.)	Not fulfilled. We support interface inheritance, but not service type inheritance, since we don't have service types.
4.7 InterfaceBindings
R081	The description language MUST describe EndPoint location using URIs. (From JS.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Endpoint_address_attribute.
R114	The description language MUST allow unambiguously mapping any on-the-wire Message to an Operation. (From WG discussion. Last revised 4 Apr 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#adv-message-dispatch for examples of how to enable unambiguous mapping. WS-Addressing's [action] property also provides a mechanism that may be used for mapping messages to an operation. There is however no requirement that each message signature be unique, or the operation name be included in each message, to ensure the disambiguation mechanism is universally understood.
R060	The description language MUST allow specifying an association between an Interface and one or more concrete protocols and/or data formats. (From the Charter. Last revised 12 Apr 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Binding.
R068	The description language MUST allow binding of transport characteristics independently of data marshalling characteristics. (From PF. Last discussed 12 April 2002.)	Fulfilled, we support both bindingless interfaces (see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Description), and interfaceless bindings (see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Binding).
R052	The description language MUST allow describing InterfaceBindings to other protocols besides those described in the specification. (From JS. Last revised 11 April 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Binding_extension_elements. Our bindings are formulated as extensions too.
R111	The WG MUST provide a normative description of the InterfaceBinding for HTTP/1.1 [IETF RFC 2616] GET and POST. (From the Charter. Last revised 28 Mar 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#_http_binding_default_rule_method.
R066	The description language MUST allow binding Interfaces to transports other than HTTP/1.1 [IETF RFC 2616]. (From JS. Last discussed 12 April 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#soap-protocol.
R028	The description language MUST allow describing the structure of incoming and outgoing SOAP 1.2 messages [SOAP 1.2 Part 1], including the contents, encoding, target, and optionality of SOAP 1.2 Header and Body blocks, SOAP RPC blocks, and SOAP Faults. (From JJM. Last revised 12 Apr 2002.)	Partially fulfilled. We allow the description of the Body, headers, fault codes, etc. We don't natively support the specification of the targets for headers (this is a client responsibility), nor make any special consideration for RPC encoding, nor do we recommend description of SOAP-level faults.
R113	The description language MUST allow describing which SOAP features are offered by or required by an Operation or a Service. (From GD. Last revised 4 Apr 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#soap-module-decl.
R065	The WG MUST provide a normative description of the InterfaceBinding for SOAP 1.2 over HTTP/1.1. (From JS. Last revised 28 Mar 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#soap-binding
R062	The WG specification(s) MUST ensure that the SOAP 1.2 InterfaceBinding is capable of describing transports other than HTTP. (From the Charter. Last revised 28 Mar 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#soap-protocol.
R125	The normative description of the InterfaceBinding for SOAP 1.2 MUST support the SOAP 1.2 MEP for HTTP GET in and HTTP SOAP out. (From TAG. Last discussed 26 Sep 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-adjuncts-20051215/#id2294956.
R031	The WG specification(s) SHOULD support SOAP 1.2 intermediaries. (From JJM. Last discussed 11 April 2002.)	No native facilities describe capabilities of intermediaries. Each intermediary is either transparent, or can have its own WSDL describing its capabilities.
4.8 Reusability
R071	The description language MUST allow partitioning a description across multiple files. (From JS.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#modularize.
R072	The description language MUST allow using a description fragment in more than one description. (From JS. Last discussed 12 April 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#modularize.
4.9 Extensibility
R012	The description language MUST support the kind of extensibility actually seen on the Web: disparity of document formats and protocols used to communicate, mixing of XML vocabularies using XML namespaces, development of solutions in a distributed environment without a central authority, etc. In particular, the description language MUST support distributed extensibility. (From the Charter. Last discussed 12 April 2002.)	Fulfilled. We support element extensibility, and the features and properties framework, with a “required” attribute that allows a processor to determine whether it understands, and can successfully process, any particular part of the WSDL document. Extensibility is supported through XML namespaces and URIs, which allow distributed extensibility. See http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#language-extensibility and http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#Feature.
R067	The description language MUST allow for extension in description language components, including at least message, port type, binding, and service. (From WG discussion. Last discussed 17 Oct 2002.)	Fulfilled, all WSDL components are extensible, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#language-extensibility.
4.10 Versioning
R075	The description language MUST allow identifying versions of Services. (From PF. Last discussed 12 April 2002.)	No native support for a service version identifier. Versioning strategies are illustrated at http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#adv-versioning. Mechanisms for identifying versions can be added through extensibility points.
R119	The description language MUST allow identifying versions of descriptions. (From PF. Last discussed 12 April 2002.)	No native support for a description version identifier (other than the targetNamespace). Versioning strategies are illustrated at http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-primer-20051215/#adv-versioning. Mechanisms for identifying versions can be added through extensibility points.
4.11 Security
R115	The WG specification(s) SHOULD define an equivalence relation on Service descriptions. (From SW. Last discussed 17 Oct 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#compequiv.
4.12 Mapping to the Semantic Web
R070	The WG specification(s) MUST allow providing a mapping from the description language to [RDF]. (From the Charter. Last revised 11 April, 2002.)	Separate deliverable, see http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-rdf.html.
R120	The description language MUST ensure that all conceptual elements in the description of Messages are addressable by a URI reference [IETF RFC 2396]. (From the Semantic Web. Last discussed 11 June 2002.)	Fulfilled, see http://www.w3.org/2002/ws/desc/5/11/cr/CR-wsdl20-20051215/#wsdl-iri-references.