Web Service Description Requirements

2.1 Non-normative definitions

Web Service

A Web Service is a software application or component identified by a URI, whose Interfaces and InterfaceBindings: (a) are capable of being described by standard XML vocabularies, and (b) support direct interactions with other software applications or components through the exchange of information that is expressed in terms of an XML Infoset via Internet-based protocols.

Client

Software that makes use of a Web Service, acting as its 'user' or 'customer'.

2.2 Normative definitions

Message

The basic unit of communication between a Web Service and a Client; data to be communicated to or from a Web Service as a single logical transmission.

Operation

A set of Messages related to a single Web Service action.

Interface (AKA Port Type)

A logical grouping of operations. An Interface represents an abstract Web Service type, independent of transmission protocol and data format.

InterfaceBinding

An association between an Interface, a concrete protocol and/or a data format. An InterfaceBinding specifies the protocol and/or data format to be used in transmitting Messages defined by the associated Interface.

EndPoint (AKA Port)

An association between a fully-specified InterfaceBinding and a network address, specified by a URI, that may be used to communicate with an instance of a Web Service. An EndPoint indicates a specific location for accessing a Web Service using a specific protocol and data format.

Service

A collection of EndPoints.

4.1 General

R001

[Accepted, Must Not, 1.2, Charter] The language developed by the WG must not preclude any programming model, nor assume any transport or protocol for communication between peers. (Last revised 21 Feb 2002.)

R004

[Accepted, Must, 1.2, JS] Describe constructs using the XML Infoset model. Similar to the SOAP 1.2 specifications, the WG specifications will use the XML Infoset model. (Last revised 21 Feb 2002.)

R099

[Accepted, Must, 1.2, WG] WSDL 1.2 processors must support XML Schema (http://www.w3.org/2001/XMLSchema*). (Last discussed 21 Feb 2002.)

R100

[Accepted, Must, Extension, WG] The WG specifications must support other type systems (besides XML Schema http://www.w3.org/2001/XMLSchema*) via extensibility. (Last discussed 21 Feb 2002.)

R098

[Accepted, Must, 1.2, WG] The schema and examples for the WG specifications must be written in XML Schema and should be written in the latest public XML Schema recommendation. (Last revised 28 Feb 2002.)

R003

[Draft, Should, JS] Use available XML technologies wherever possible.

R005

[Draft, Should, KL] Correct errors/inconsistencies in WSDL1.1

R006

[Draft, Should, KL] Provide better specification for document name and linking. WSDL1.1 section 2.1.1 is over simple. More detailed specification should be provided to define how the import mechanism works, especially how it's related to the import and include mechanism defined in the XML Schema specification.

R007

[Draft, Should, KL] Provide detailed examples including on-the-wire Messages. (Was Best Practices and Conformance Test. Although a few examples are given in WSDL 1.1 specification, the examples are not sufficiently explained in the text, and no corresponding wired Message examples are available for different InterfaceBinding definitions. To help clearer interpretation of the specification, more consistent and detailed examples should be provided. In addition, a technical report associated with the WSDL specification should be dedicated to provide: Use cases which illustrate typical usage scenarios of WSDL, Best practices, Conformance test suite.)

R009

[Draft, Should, KL] Enable easy Interaction with Upper layers in the Web Services stack. Additional technologies will be required in the future to complete the Web Services architecture. As one of the fundamental layers of the Web Services stack, though WSDL should not depend on any other layers, one of the design goals of WSDL should be easy interaction with upper layers, such as Services composition layers.

R010

[Draft, Should, KL] Editorial Improvements. Consistent terminology should be used across all the sections of the specification. As one example, the usage of the terms 'port' and 'endpoint' is confusing to many readers. Though it states that 'port' is 'a single endpoint defined as a combination of a binding and a network address', the specification uses 'port' and 'endpoint' interchangeably in many places. Some diagrams that explain the structure of core WSDL elements and their relationship will help reduce misinterpretations.

R103

[Draft, Should, YF] WSDL specifications should be clear and easy to understand. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material.

R105

[Draft, Should, YF] The WSD specification should make reasonable efforts to support applications that operate on resource constrained devices. Even though any practical device is resource constrained in any number of dimensions including but not limited to bandwidth, computational power and storage, the term 'resource constrained device' often refers to hand-portable devices. This document does not attempt to define the term 'resource constrained' nor what the constraints are for the available resources.

R008

[Rejected, KL] Support up-to-date XML Schema. In all WSDL 1.1 examples, the October 2000 version of the XML schema is used: http://www.w3.org/2000/10/XMLSchema. We understand that the 10/2000 schema was the most up-to-dated schema available at the time WSDL1.1 was released. However, in future versions of WSDL specification, the W3C recommendation version of the XML schema should be used. The recommendation was released in May 2001: http://www.w3.org/2001/XMLSchema. (Last discussed 21 Feb 2002. Replaced with R098, R099, and R100.)

4.2 Simplicity

R013

[Accepted, Must, 1.2, Charter] The WG specifications must be simple to understand and implement correctly. The language defined by the WG specifications must be simple to use. (Last discussed 7 Mar 2002.)

R014

[Accepted, Should, 1.2, Charter] The WG specifications must be compatible with the existing Web infrastructure. (Last discussed 7 Mar 2002.)

R011

[Rejected, Charter] Focus must be put on simplicity, modularity and decentralization. (Last discussed 21 Feb 2002. Replaced with R013, R102, R027.)

R016

[Rejected, JS] Be simple to understand and implement correctly; comparable to other widespread Web solutions. (Last discussed 21 Feb 2002. Replaced with R013.)

R017

[Rejected, JS] Specification shall be as lightweight as possible, keeping parts that are mandatory to a minimum. (Last discussed 7 Mar 2002. Redundant with R013.)

R018

[Rejected, JS] Optional parts of the specification should be orthogonal to each other allowing non-conflicting configurations to be implemented. (Last discussed 7 Mar 2002. Good goal, but unnecessary as a specific requirement.)

R019

[Rejected, YF] Facilitate the creation of simple applications (fast and easy writing for simple apps). (Last discussed 7 Mar 2002. Merged in R013.)

R020

[Rejected, YF] Be possible to compare easily two WSDL Web Services. (Last discussed 7 Mar 2002. May raise intractable semantic issues.)

R102

[Rejected, YF] Since WSDL is intended to be a foundation service description language, its definition should remain simple and stable over time. Explicit use of modularity and layering in the resulting design will help assure longevity. Such a framework will allow subsequent extension of the design while leaving the foundation of the design intact. (Last discussed 7 Mar 2002. Adequately covered by 'simple' in R013.)

R104

[Rejected, YF] The WSDL specification must clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested (see also the W3C Conformance requirements (W3C members only)). (Last discussed 7 Mar 2002. Adequately covered by 'correct' in R013.)

4.3 Interface Description

R021

[Accepted, Must, 1.2, Charter] The description language must describe the messages accepted and generated by the Web Service. (Last revised 21 Feb 2002.)

R026

[Accepted, Must, 1.2/Extension, Charter] The description language designed will be used both by applications, in order to automatically communicate between each other, as well as by programmers developing Web Services themselves. The language should therefore provide, in addition to the raw XML definition of the interface, human-readable comment capabilities to allow both applications and developers to make use of them. (Last discussed 28 Feb 2002.)

R022

[Accepted, Must, 1.2, Charter] The language must allow describing application-level error Messages (AKA faults) generated by the Web Service. (Last revised 28 Feb 2002.)

R041

[Accepted, Must, 1.2, JS] The language must allow describing sets of Operations that form a logical group. (Last revised 28 Feb 2002.)

R027

[Draft, Should, Charter] Developers are likely to want to extend the functionality of an existing Web Service. The WG will look into extending interface descriptions in a decentralized fashion, i.e. without priori agreement with the original interface designers.

R032

[Draft, Should, WS] In a lot of cases, it is important for the server to expose some service-wide properties/attributes. These properties/attributes have the service-level scope and could be used to describe either some QoS parameters or some application specific characteristics. As an example, a service may want to expose an attribute which describes the version number of the service. Hence, WSDL should be able to model service level attributes/properties.

R035

[Draft, Should, KL] Distinction between interface definition and implementation definition. A description of a Web Service can be logically divided into three parts: Data type definition, Service Interface definition and Service Implementation definition. The data type definition can be viewed as part of the Service Interface Definition. Analogous to defining an abstract interface in a programming language and having many concrete implementations, a service interface definition can be instantiated and referenced by multiple service implementers. WSDL 1.1 specification implies such a division by providing the mechanism for dividing a service definition into multiple WSDL documents. WSDL1.1 Section 2.1.2, Authoring Style, shows an example of separating a complete service definition into three documents: data type definition, abstract definitions and specific service bindings. However, this distinction is not clear and reference to each unit is very difficult. To facilitate easier allocation of responsibilities among different organizations (such as standard bodies and service providers) or among different teams within an organization (such as teams related to the different stages of a service's lifecycle: design time/development time, configuration time and run time), a better distinction between Interface definition and Implementation definition should be made in the specification. Elements such as message, portType, operation are abstract interface definitions, and are usually defined at design time. Elements such as binding and services usually get their value at configuration/deployment/run time. Mixing all these elements together is at least confusing to many people.

R090

[?Reject?, Draft, Must, KB] Group logically related Operations together into abstract Interface types. (Redundant with R041.)

R023

[Rejected, Charter] The data exchanged is usually typed and structured. This increases interoperability by having applications agreeing on semantics and also provides some level of error detection. It is expected that developers will want to use different mechanisms for describing data types and structures, depending on the purpose of the Web service. The WG should allow different mechanisms, and must define one based on XML Schema. (Last discussed 21 Feb 2002. Redundant with R021, R090, R100.)

R033

[Rejected, YF] Support abstract interfaces. (Last discussed 28 Feb 2002. Replaced by R109.)

R034

[Rejected, YF] Support interfaces derived from abstract interfaces. (Last discussed 28 Feb 2002. Replaced by R109.)

R101

[Rejected, KL] The final WSDL specification should be divided into two parts: the first part only focuses on the core interface definition language, and the second part addresses the binding extensions. This requirement concurs with the Charter's requirement for two separate deliverables. (Last discussed 28 Feb 2002. Concern that this over constrains the specification process.)

R109

[Rejected, JS] The language must describe interfaces separate from their concrete protocol, transport, data format or wire format deployment. (See also R046.) (Last discussed 7 Mar 2002. Redundant with R071.)

4.4 Description of Interactions with a Service

R036

[Accepted, Must, 1.2, Charter] The language will allow a Web Service to describe the functionality associated with one-way messages (to and from the service described), request-response, solicit-response, and faults. (Last revised 28 Feb 2002.)

R042

[Draft, Must, JS] Be able to derive an Interface from another by extension of the logical group of Messages.

R043

[Draft, Must, JS] Be able to extend Interfaces using mechanisms not explicitly identified in the spec.

R040

[Draft, Must Not, JS] (Not a requirement to describe arbitrary Message exchanges.)

R094

[Draft, Should, IS] Able to define events. WSDL should be very specific about events, defining a special type of a Message or even a separate definition entity. Currently it is missing in WSDL 1.1.

R097

[Draft, Should, IS] Define Operations that can be carried out synchronously (i.e., have a short expected reply cycle) and those Messages that require asynchronous notification (i.e., have long expected reply cycle). Ability to differentiate such Operations is a requirement of the Web Service definition rather than application architecture. For the async Operations, providing a reference to an event definition or status inquiry Operation should be required.

R044

[Draft, Should, PF] Context. Web Services requests often have an associated context -- such as the identity of the caller. This context has a logical component - typically a set of name-value pairs - and a binding into the particular format or transport. So for example, a userid and password may be bound into the HTTP transport using Basic Auth, or may be encoded in the SOAP header, and the Service implementation may be expecting that. Furthermore, there are some context items that the service may require, and there are others that are not required but may be understood. It is also possible that there are context items that are not required or understood, but the service may have a policy of passing on non-understood context items to other service it calls, or returning them to the client -- which may use them for correlation.

R045

[Draft, Should, PF] WSDL is typically used to capture the Web Server requirements on the Client. For example, the Web Server will expect to see certain SOAP headers. When WSDL is used in higher protocols, such as an orchestration language, each side of the exchange may wish to publish their requirements, and the Client may have a requirement on the Web Server. For example, the Client may require the Web Server to set a particular header on the response. In WSDL today, there is an option to try to map this into the 'out-in' or 'out' interactions, by treating them as the 'conjugates' of the corresponding 'in-out' or 'in-only' Operations. However, this is unsatisfactory, as these interactions are not well defined, and there is no way to specify that an out-in is actually the conjugate of an in-out, or simply another Operation that has the same messages in the opposite order. It would be more satisfactory if the concept of 'conjugates' was exposed directly so that the Client side of an interaction could publish their requirements. This could be used by proposal such as flow or orchestration languages.

R095

[Draft, Should, IS] Extensible meta definitions. Be able to include typed metadata attributes for any definition element: Message, Operation, Interface, InterfaceBinding, EndPoint, Service. The attributes may also be hierarchical (i.e., defined in another namespace).

R054

[?Reject?, Draft, Must, YF] Clearly separate the description of the operations (messages?) from the message exchange pattern and protocol binding. (Redundant with definition of Interface.)

R110

[?Reject?, Draft, Should, WV] Provide a way (optional) for the Web Service to give an indication of how long it is going to take to process the request. This is just a hint to the client and the service is not obligated to respect what it advertised. (Special case of R097.)

R037

[Rejected, JJM] Must describe SOAP 1.2 MEP (Message Exchange Pattern) (charter says: "must [...] describe [...] one-way Messages, [...] request-response") (Last discussed 28 Feb 2002. Redundant with R036.)

R038

[Rejected, JS] Must be able to describe simple one-way Messages, i.e., either incoming or outgoing (event) Messages. (Last discussed 28 Feb 2002. Redundant with R036.)

R039

[Rejected, JS] Must be able to describe simple request-response-fault Message exchange. (Last discussed 28 Feb 2002. Redundant with R036.)

4.5 Messages and Types

R046

[Draft, Must, JS] Must be able to describe Messages independent of specific wire format.

R048

[Draft, Must, JS] Must be able to describe Messages using XML Schema simple and complex types.

R050

[Draft, Must, JS] Be able to extend Message descriptions using mechanisms not explicitly identified in the spec.

R051

[Draft, Must, JS] Be able to describe Messages that include arrays and nested arrays.

R052

[Draft, Must, JS] Be able to describe Messages of other protocols besides SOAP 1.2.

R047

[Draft, Must Not, JS] (No requirement to describe semantic content of Messages.)

R049

[Draft, Should, JS] Be able to describe Messages using other info sets.

R085

[Draft, Should, PP] Be able to describe Messages that include references (URIs) to strongly-typed referents.

R096

[Draft, Should, IS] Be able to describe references to other Web Services (remote) or other Interfaces (EndPoints, local to this WSDL doc) that can be used as parts in Message definitions. Currently (as of WSDL 1.1) Message parts refer to data types (described in one or the other schema). The part must also be able to refer to a remote Web Service (WSDL URL/Service/Port) or a local Web Service/EndPoint qualified names. This has to be made clear as part of the standard for WS Clients and Web Service providers.

R055

[Draft, Should, YF] Support grouping functionalities (Operations) that share the same Message-exchange pattern and transport InterfaceBinding.

R053

[Draft, Should, JR] Be able to classify/categorize [individual] Operations. With the usage of XML schema in the ELEMENT attribute of the PART element (current WSDL spec), it is possible to use a type system as a kind of taxonomy for a semantically enriched description of parameters. To automatically search a suitable Web Service respectively Operation from a set of Web Service descriptions, it is not enough only to consider the parameters but also a kind of Operation "type" (something like a taxonomy on Operations). So I would suggest a kind of ELEMENT or TYPE attribute for Operations.

R089

[?Reject?, Draft, Must, KB] Describe Web Services Operations in an abstract format using the XML type system. (Redundant with R048.)

4.6 Service Types

R056

[Draft, Must, JS] Be able to describe a logical group of fully-specified InterfaceBindings without specifying a network address that may be used to communicate with the instance of the InterfaceBinding. That is, be able to describe a Service type.

R058

[Draft, Must, JS] Be able to derive one Service type from another by extension of the logical group of InterfaceBindings.

R059

[Draft, Must, JS] Be able to extend Service descriptions using mechanisms not explicitly identified in the spec.

R057

[Draft, Should, JS] Be able to name an instance of a EndPoint.

R082

[?Reject?, Draft, Must, JS] Be able to describe the address for specific EndPoint instances within a Service. (Redundant with R057.)

R106

[?Reject?, Draft, Must, PM] Ability to bind network address to the operation at runtime. For example, it is possible to have a service that supports operations like "Register" and "Notify" where a user will provide an email address that a Web Service can send notifications to when the user registers with the service. So the binding network address for the "Notify" operation needs to be dynamically populated at runtime. To achieve this it becomes necessary to allow a placeholder for dynamic bindings within the description of the Web Service. (Redundant with R056.)

4.7 InterfaceBindings

R028

[Draft, Must, JJM] Describe SOAP 1.2 Messages, including Header, Body, encoding, fault, RPC, actor. (Charter says: "must describe Messages available via Interface", "must describe error Messages", and "make sure SOAP 1.2 extensibility mechanism can be expressed".)

R065

[Draft, Must, JS] The WG will provide a normative description of the InterfaceBinding for SOAP 1.2 over HTTP/1.1.

R062

[?Modify? Draft, Must, Charter] The WG will ensure that SOAP 1.2 InterfaceBindings ?to transports other than HTTP? can be described.

R067

[Draft, Must, JS] Be able to extend InterfaceBindings using mechanisms not explicitly identified in the spec.

R031

[Draft, Should, JJM] Support SOAP 1.2 intermediaries. (Charter says: "make sure SOAP 1.2 extensibility mechanism can be expressed".)

R111

[Draft, Should, Charter] The WG should provide a normative InterfaceBinding for HTTP/1.1 GET and POST.

R086

[Draft, Should, PP] Support all HTTP methods (verbs), including WebDAV and allow the use of non-standard HTTP methods.

R068

[?Modify?, Draft, Should, PF] ?The description language will allow describing an Interface that is incompletely bound to the protocol or data format.? A clearer separation of transport and binding in the spec. The current spec builds bindings that are tied to the transport, and therefore a hard link between the port and binding information. There are obviously cases where formatting information is specific to the transport, so it would be good to see the ability to define multiple bindings and to define bindings that are independent of transport, and also perhaps independent of the exact port type. So an example would be --- define a port type, then a binding for "soap-encoded rpc style", then a binding for SOAP/HTTP, then a port for HTTP, which points to both bindings.

R107

[Draft, Should, JJ] Based on the XML Protocol Usage Scenario (2.14 S21 Incremental parsing/processing of SOAP messages) and other requirements (a SOAP processor returning a large amount of data as attachment or message) there is a need for a SOAP processor and the SOAP client proxies to be constructed with the notion of data streaming in mind so that applications can scale well. (Especially in the case of dynamic proxy and stub creation scenarios.) This requirement for the SOAP processors imposed a requirement on the WSDL to be descriptive enough (like MIME binding or some kind of extension) to describe so that the Service Provider will do incremental parsing and processing of data (input) and the client can process the return message or attachment the same way. Without this description most of the toolkits will find it difficult to use this SOAP processor advantages for scalability and/or fail in interoperability.

R112

[Draft, Should, SK] A Web Service description should be able to define extensible mechanisms for capturing meta-information associated with a message. A WS description allows it to publish the message interactions it is capable of handling. However, this description alone does not capture any meta-information associated with the message interaction definitions. The message interactions are meaningful in a given business domain, or more precisely, as defined as part of W3C work on ontology [2]. Some of the examples of the meta-information are:

1. Some messages of a WS may require authentication information.

2. Some messages of a WS may deal with in a particular Business Domain. For instance, submitPO, may be an overloaded message where one such message primarily deals with RosettaNet.

3. QoS parameters

R029

[?Reject?, Draft, Must, JJM] Describe SOAP 1.2 Header and Body's content type. (Charter says: "must define [a mechanism for describing data types and structures] based on XML Schema" and "take into account ending work going on in XML Protocol".) (Covered adequately by R028.)

R030

[?Reject?, Draft, Should, JJM] Describe SOAP 1.2 RPC parameters types (ibid.). (Redundant with R065.)

R060

[?Reject?, Draft, Must, Charter] The information exchanged to and from a Web Service can be carried in a large number of different ways. The action of carrying some XML-based communication in an underlying protocol is called, in the XML Protocol [SOAP 1.2] jargon, a binding. The description language defined should therefore describe how to reach the Web Service in a form which is orthogonal to its Message exchange patterns and its Messages. (Redundant with R028.)

R061

[?Reject?, Draft, Must/Should, Charter] It is expected that in the near-term future, Web Services will be accessed largely through SOAP Version 1.2 (the XML-based protocol produced by the XML Protocol Working Group) carried over HTTP/1.1, or by means of simple HTTP/1.1 GET and POST requests.

1. [?Reject?, Draft, Must, Charter] The WG will provide a normative InterfaceBinding for SOAP Version 1.2 over HTTP. (Redundant with R065.)

2. [?Reject?, Draft, Should, Charter] The WG should provide a normative InterfaceBinding for HTTP/1.1 GET and POST requests. (Called out as a separate requirement R111.)

R063

[?Reject?, Draft, Must, JJM] Ensure that SOAP 1.2 bindings to SMTP or BEEP (for example) can be described (charter says: "ensure that other SOAP bindings can be described"). (Adequately covered by R062.)

R064

[?Reject?, Draft, Must, JS] Be able to describe the wire format of Messages, including, but not limited to, XML, ASCII, binary, or some combination. (Redundant with R065, R111, and R067.)

R066

[?Reject?, Draft, Must, JS] Be able to describe bindings to transports other than HTTP. (Merged in R062.)

R069

[?Reject?, Draft, Must, KL] Better Specification for InterfaceBinding Extensions. In addition to the core service definition framework, WSDL1.1 introduces specific InterfaceBinding extensions for SOAP 1.1, HTTP GET/POST, and MIME, and nothing precludes the use of other InterfaceBinding extensions. To keep the core service definition framework simple, a separate and more detailed specification or technical report should be dedicated for various InterfaceBindings. (Concern that this over constrains the specification process like NR101 does.)

R077

[?Reject?, Draft, Must, JS] Be able to describe SOAP 1.2 Messages. (Redundant with R028.)

R078

[?Reject?, Draft, Must, JS] The WG will provide a normative description of SOAP 1.2 Messages. (Redundant with R065.)

R079

[?Reject?, Draft, Must, JS] Be able to describe SOAP 1.2 Header elements and Body elements. (Redundant with R028.)

R080

[?Reject?, Draft, Must, JS] Be able to describe SOAP 1.2 Faults. (Redundant with R028.)

R081

[?Reject?, Draft, Must, JS] Be able to describe EndPoint location using URIs. (Redundant with definition of EndPoint.)

R083

[?Reject?, Draft, Must, JS] Be able to separate design-time from run-time information. (Imprecisely worded; generally redundant with definition of Interface versus EndPoint.)

R087

[?Reject?, Draft, Should, FC] WSDL 1.1 defines services and operations and their bindings to various protocols. However, the details of how an operation is identified (either generally or specifically in particular bindings) is, shall we say, rather vague. As a result, some implementations use the namespace & element of the first child of Body (in SOAP RPC), others use SOAPAction header (in SOAP over HTTP), others use only the namespace, others the element name, others attempt to match the message type, etc. As a result, interoperability suffers.

It seems like a normative model (at least) for operation determination is necessary for interoperability between clients and servers from different vendors. This may be a requirement to define such a requirement for all defined bindings, as opposed to something that can be completely specified in the description. But I believe that such a requirement exists. (Redundant with R065.)

R091

[?Reject?, Draft, Must, KB] Apply specific wire-format serializations (InterfaceBindings) for Service types. (Redundant with R065, R111, and R067.)

R092

[?Reject?, Draft, Must, KB] Apply in an orthogonal manner specific transport(s) for an InterfaceBinding. (Unclear. A requirement for partial InterfaceBindings?)

R108

[?Reject?, Draft, Must, MW] Must be able to describe messages that include binary data, where the binary data is transmitted efficiently. (Redundant with R065, R111, and R067.)

4.8 Reusability

R071

[Accepted, Must, 1.2, JS] Be able to partition a description across multiple files.

R072

[Draft, Must, JS] Be able to use a description fragment in more than one description.

R073

[Draft, Must, YF] Support reusability of WSDL documents or parts of documents.

R093

[Draft, Should, IS] Be able to accommodate namespace clusters with data types (schemas) and Interface definitions (Message/EndPoint/InterfaceBinding). I.e., Service may have several namespaces with types and several other namespaces with Message/EndPoint definitions. That is pretty important for expressing proper OO model of a Service. Very few framework implementations pay attention to this. (In many cases namespaces are flattened out which results in name conflicts.) I guess it is so because namespaces of various type definitions and Message/EndPoint/InterfaceBinding definitions have never been emphasized as a requirement really.

4.9 Extensibility

R012

[Draft, Must, Charter] The language proposed 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, it must support distributed extensibility.

R015

[Draft, Must, JJM] Must support an open content model. (Charter says: "must support distributed extensibility" and "will look into extending Interface descriptions in a decentralized fashion".)

R025

[Draft, Must, Charter] The WG will make sure that SOAP 1.2 extensibility mechanism can be expressed.

R074

[Draft, Should, JS] Define a set of constructions to indicate which extensions are optional versus mandatory.

4.10 Versioning

R075

[Draft, Must, PF] Have a simple versioning tag to identify versions of WSDL documents or Services.

R076

[Draft, Should, FC] It would be good to allow for versioning of something smaller than a WSDL document.  I suspect that tools vendors will "compose" these documents, and they may sometimes contain information about a number of unrelated services (or, more correctly, services that are related in ways other than application semantics (tool vendor, server location,  etc)).  It would be good if Web Services themselves were versioned, the Web Services being the semantic "unit" being defined.

4.11 Security

R084

[Draft, Must Not, JS] Compliance must not preclude building implementations that are resistant to attacks.

R088

[Draft, Should, DM] Should define best practice for signing descriptions using XML signatures, including canonicalization, transforms, XPath selectors, etc. I would probably be willing to leave this function out of the "core" functionality, because some client configuration WSDL driven tools might not care about issues of trusting WSDL input.

4.12 Mapping to the Semantic Web

R070

[Draft, Must, Charter] The WG will provide a mapping to RDF so that the information described can be easily merged with that of other applications. This mapping will be developed with the help of the RDF Interest Group.

5.1 XML Protocol

5.2 XForms

5.3 RDF

5.4 P3P