On removing messages

In order to kickstart an orderly discussion on removing wsdl:message,
I thought I would list some of the dimensions/tradeoffs that we have
identified while exploring this space.

1. Similarity to WSDL 1.1

The wsdl:message construct is familiar to developers who've used WSDL 1.1.
If we were to adopt a radically different proposal, we'd need to provide
guidance to ease migration.

2. Readability/Writeability for WSDL Authors

Aside from the similarity to WSDL 1.1 listed above, other aspects may affect
authors of WSDL 1.2. In general, users of WSDL will value things like a 
simple
(readable and writeable) syntax, the lack of redundant information, guidance
on which construct to use when several are possible, etc. If it makes 
sense in this
case, we may consider having a simplified syntax for the 80% case and a more
complex one for the remaining 20%. At the same time, not all simplifications
are equally good. For instance, we received feedback that the xsd:group
construct that was proposed as a replacement for wsdl:message is not 
familiar
to WSDL users, even though they used it implicitly all the time in their
type definitions! But, naturally enough, the same developers find it 
puzzling
that they sometimes need to use xsd:element and sometimes xsd:type, and even
more that they need to switch from one to the other if they decide to modify
the style of binding they're using (caveat: this feedback is based on WSDL
1.1 use only).

3. Simplicity/Consistency for Advanced Users

Advanced" here means spec/extension authors (including authors of specs
which build on WSDL 1.2) and implementors in general. One way to
analyze this aspect is to look at the component model itself, with metrics
such as "number of components required".

4. Binding Implications

Binding authors need to take into account all aspects of an operation before
they can fully specify how to bind it to a particular protocol. When 
multiple,
different constructs or type systems are used as part of the same operation
definition, the work of a binding author instantly becomes a lot harder.
Even for XML-based protocols, such as SOAP, we need to see how the type
information provided at the abstract level relates to the infoset of the
messages sent on the wire. For instance, an issue that came up at the last
face-to-face was that of the validation of a soap:Body element that is
allowed to contain more than one element.

5. Expressiveness

A key motivation for removing wsdl:message was to replace it with a more
powerful construct. In our proposal ([1]), we identified several 
shortcomings
of wsdl:message, specifically its lack of support for extensibility 
relationships
between messages, optionality of parts, cardinality of parts, sharing of 
message
parts, naming parts by QNames, extensibility a la xsd:any. It's quite 
possible
that not all those shortcomings are equally important, so we may want to
prune that list and keep only critical ones. On the other hand, doing so
forces us to take a guess at how WSDL 1.2 will be used in the real world,
and we may not always be right (really!).

6. Multiple Parts in a Message

In a sense, this seems to be the crux of the matter: do messages have 
multiple
parts even when there are no attachments involved? If not, how should 
rpc-style
operations be represented? When multiple type systems are used, at what
granularity can they be applied? Also, are attachments on the same logical
footing as the other parameters of an operation?

7. Completeness

Any notion of "completeness" for WSDL 1.2 should include the ability to
describe any SOAP 1.2 message. This aspect directly clashes with some of
the ones described above. For instance, the rpc/document distinction in
WSDL 1.1 could be justified with the need to allow SOAP 1.1 messages
with an arbitrary number of body blocks to be described, all while providing
a first-class description for rpc-style operations.

8. Attachments

In WSDL 1.1, attachments are represented via message parts. 
Interestingly enough,
their type is given twice: first, in the portType definition, as an XML type
(e.g. <part name="logo" type="tns:ArrayOfBinary"/>), then in the MIME 
binding
using MIME content type strings (e.g. <mime:content part="logo" 
type="image/gif"/>).
On top of that, the MIME binding itself contains a mini-type system for MIME
that allows union types to be expressed, as in the following example which
allows for GIF-or-JPEG images:
    <mime:part>
            <mime:content part="logo" type="image/gif"/>
                <mime:content part="logo" type="image/jpeg"/>
        </mime:part>

Our proposal ([1]) hinted in the direction of specifying the MIME type 
as part
of the abstract definition, by annotating XML schema with an extensibility
attribute, e.g.
    <xsd:element name="logo" type="xsd:base64Binary" mime:type="image/gif"/>
Another proposal ([2]) used only the MIME type systems and described 
attachments
as additional <wsdl:input>s to an operation, e.g. (my example)
    <wsdl:operation name="foo">
        <wsdl:input type="fooRequest"/>
        <wsdl:input mime:type="image/gif"/>
    </wsdl:operation>
If we follow this approach, we need to reconcile it with the recent 
discussion
on interactions/MEPs. (This approach has recently been extended in [3].)

9. Multiple Type Systems

Although WSDL 1.2 requires support for XML Schema, it allows other XML type
systems (grammars) to be used, e.g. Relax NG, DTD, etc. Similarly to the 
case
of attachments above, we need to consider how multiple type systems would
interact when used together as part of the definition of an operation. This
aspect is actually quite central to the discussion on removing message,
because wsdl:message itself is a sort of type-agnostic container and as
such it can be seen as defining its own restricted type system.


References
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0035.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0040.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0042.html

--

Roberto Chinnici
Web Technologies and Standards
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Monday, 20 January 2003 11:52:27 UTC