W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

eliminating <message>: a few additional thoughts

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Mon, 21 Jul 2003 21:49:11 +0600
Message-ID: <02c301c34f9f$a32ff790$02c8a8c0@lankabook2>
To: <www-ws-desc@w3.org>

Further to my note on July 6th (in my timezone at least!) about
$subject, the final proposal was something like this:

> One additional syntactic shortcut one can do is to overload the
> two usages into one attribute:
> <operation name="ncname">
>     <input body="qname" [headers="list-of-qnames"]/>
>     <output body="qname" [headers="list-of-qnames"]/> 
> </operation>
> Now depending on whether @body refers to a type or an element,
> we get the two previous cases.

Arthur pointed out to me that a single attribute won't work
because its legit in XSD to name both an element and a type
x:foo. Oops. OK, so back to the two attribute version:

(Going further back in my original note)

> Basically that means we drop the nested anonymous complexType
> inclusion capability. The syntax would then be:
> <operation name="ncname">
>     <input (element|body)="qname" [headers="list-of-qnames"]/>
>     <output (element|body)="qname" [headers="list-of-qnames"]/>
> </operation>
> If @element is used then only that element will appear in the
> body. If @body is used then that's the type representing all
> of body content, i.e., the type of soap:Body in the case of SOAP.

I like this approach, but I'm am a bit concerned that the subtlety
of @element vs. @body may not be clear to most. Note that I didn't
use @type for @body for a reason: doing so would give the casual
reader the feeling that we've retained the part/@type vs. part/@element
distinction and of course that's complete wrong!

To reiterate: In the SOAP case, @element refers to a SINGLE
element inside <soap:Body>. That is what I believe the 80-20
case for SOAP: the body only contains one and only one element.
In the non-SOAP case, one can bind the single element or 
the multiple things inside the complex type any way they

    BEFORE SOMEONE JUMPS ON ME: This is not new functionality:
    WSDL 1.1 could describe all this stuff and people did describe
    this kind of stuff but without agreement on a single way of
    doing it. This proposal basically is an attempt to get 
    convergence on the one true way. ;-).

In the SOAP case, @type refers defines a NEW type for <soap:Body>
and NOT for the stuff that's inside it. When you think about it
you'll see that that's the only way to allow users to describe
>=1 elements inside <soap:Body> with the full power of XSD.

My personal preference would be to restrict to only dealing
with a single element and forget about the whole complex type
thing. Can die-hard SOAPers live with WSDL not being able
to describe everything possible in SOAP 1.2? JJM? Gudge? Glen?
Anyone else? 

If someone will die for it (hmm, maybe I should ask who first!),
then we'll have to keep both. I would like to simplify that 
case a bit too, but I feel as if I'm talking to myself about
this topic. If no one really cares about how we eliminate 
<message> that's cool with me; we'll just do it my way ;-).

Received on Monday, 21 July 2003 11:49:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:32 UTC