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

Re: eliminating <message>: a few additional thoughts

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Tue, 22 Jul 2003 00:03:12 +0600
Message-ID: <030601c34fb2$5b547320$02c8a8c0@lankabook2>
To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>, <www-ws-desc@w3.org>

Hi Savas,

> Wouldn't it be better if you kept @body instead of @element and
> introduced the additional restriction of @body only referring to a
> complexType? That way you could capture both cases... One could define a
> complexType with only one element (most SOAP cases, as you suggested) or
> one could define a complexTypes with multiple elements (the first
> example in the SOAP 1.2 has two elements in the body). Keeping @element
> restricts what people can do, which is going to be more confusing to
> people who read the SOAP spec (why can't I have multiple elements in the
> SOAP body you say? Surely, not because I couldn't describe it at the
> interface level.)

True. However, that's make the simple, what I believe to the 80-20
case harder. (See near the top of my original proposal and you'll
see what it looks like.)

> Of course, now, you always have to define global complexTypes that are
> used for @body but, IMHO, that's fine.


These are clearly subjective calls ;-).

> Also, as I suggested in one of my responses to your original message, I
> believe that the use of @body should be optional. One may want to define
> a protocol where only headers are used. In your original syntax you had
> that but through the simplifications it got lost. 
> <operation name="ncname">
>    <input [body="qname"] [headers="list-of-qnames"]/>
>    <output [body="qname"] [headers="list-of-qnames"]/>
> </operation>
> Where the qname in @body MUST refer to a complexType.

I'm still debating about how to do @body, but the optionality
is ok with me. I seem to recall that SOAP requires a non-empty
body, but I have seen specs which don't seem to follow that.

Received on Monday, 21 July 2003 14:03:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:43 UTC