4.5 Messages and Types

R046

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

Commentary: Accept. Note that we rejected R064 which asked that we be able to express the Wire Format of messages. We stated this type of functionality was out of scope.

R051

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

Commentary: Accept. We should use existing type libraries as much as possible. Therefore I would suggest using the Array type defined by SOAP 1.2 and, if needed, extending it.

R047

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

Commentary: Reword and Reject. It seems backwards to state something as not being a requirement. How about stating the requirement, "Be able to describe the semantic content of messages." and reject is as out of scope for the current working group? That leaves the paper trail; we made the conscious decision that this wasn't in scope.

R085

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

Commentary: Reject. The goal of this requirement is to allow Messages to be composed from existing (and possibly) remote elements (reusability). I believe the intent is already covered by R071. I believe a 'strongly typed referent' could be treated as a portion of a WSDL description that exists in another file (the referred object).

This requirement comes from the following note from Paul Prescod: http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0047.html

R096

[?Reject?, 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. (Merged in R085.)

Commentary: Reject. As with R085, I believe this is covered by R071.

This requirement comes from the following note from Igor Sedukhin: http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0037.html

R055

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

Commentary: Reject. This is a restatement of R041: The language must allow describing sets of Operations that form a logical group.

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.

Commentary: Reject. While I like this idea, I think its beyond the scope of the Working Group. It presupposes the existance of a taxonomy of Web Service Operations. It might be a useful exercise in extensibility to show that the resulting WSDL specification is extensible and allows Messages to be annotated with this type of metadata.

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.

Commentary: Reject. Moved from Section 4.8, Reusability, in the April 5, 2002 Editor's Draft.

This requirement seems to be addressed to poor/incomplete implementations of namespaces. I believe the intent of this requirement is covered by R099.

This requirement comes from the following note from Igor Sedukhin: http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0037.html

R048

[?Reject?, Draft, Must, JS] Must be able to describe Messages using XML Schema simple and complex types.(Covered by R004.)

Commentary: Reject. As stated this requirement is already covered by R004 - Describe constructs using the XML Infoset model. Similar to the SOAP 1.2 specifiations, the WG specifrications will use the XML Infoset model. Note: R089 points to this requirement (in Section 4.3). We have also suggested rejecting that requirement.

R049

[?Reject?, Draft, Should, JS] Be able to describe Messages using other info sets. (Redundant with R100.)

Commentary: Reject. As stated this requirement is already covered by R100 - The WG specifications must support other type systems (besides XML Schema) via extensibility.

Moved to Interface Bindings in April 5, 2002 Editor's Draft:

R052

[?Reject?, Draft, Must, JS] Be able to describe Messages of other protocols besides SOAP 1.2. (Covered by R066.)

Commentary: Reject. As stated this requirement is already covered by R066 - The WG will ensure that Interfaces can be bound to transports other that HTTP/1.1.