Re: eliminating <message>: a few additional thoughts

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.

Yep. 

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.

Sanjiva.

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