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

RE: proposal for eliminating <message>

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Tue, 8 Jul 2003 21:44:05 -0400
To: www-ws-desc@w3.org
Message-ID: <OFEDD57A44.C7ED6D8A-ON85256D5E.00086368-85256D5E.00098705@us.ibm.com>

Savas Parastadis wrote on 07/08/2003 04:46:51 PM:

> 
> Sanjiva,
> 
> Apologies for not replying sooner to your proposal. Needed some time to
> think about it...
> 
> I really like it. I am sure you have already thought how this affects
> (future) specs like BPEL, etc. but of course this shouldn't be of
> (great) concern to this group.

With all due respect, I think it should be of concern for this group!
These specs cannot be developed in a vacuum, oblivious of one another.
I will grant that there shouldn't be excessive concern, but as with
sister WGs within the W3C, we should be making every effort to understand
what others are thinking of doing, building upon WSDL as a foundation
as does BPEL, as well as ensuring that the WSDL spec is consistent with
work that has gone before it...

> 
> Building on your proposal, something else to consider...
> 
> <operation name="ncname">
>     <input body="list-of-qnames" [headers="list-of-qnames"]/>
>     <output body="list-of-qnames" [headers="list-of-qnames"]/>
> <!-- need a story about faults -->
> </operation>
> 
> In this, instead of having to specify the complexType of the body and go
> into the potential problems of two types for the same element, you
> specify the QNames of all the elements that are going to appear inside a
> SOAP body, as you do with headers.
> 
> Another problem you avoid with this approach is ordering. If I was to
> define a complexType for the body like this:
> 
> <xs:complexType name="foo">
>   <xs:sequence>
>     <xs:element name="arg1" type="xs:string"/>
>     <xs:element name="arg2" type="xs:int"/>
>   </xs:sequence>
> </xs:complexType>
> 
> Then, if you wanted to define an operation where the arguments appeared
> in reverse order, you'd have to define a new complexType. However, if
> you had something like this:
> 
> <xs:element name="arg1" type="xs:string"/>
> <xs:element name="arg2" type="xs:int"/>
> 
> Then you could define operations like this:
> 
> <operation name="foo1">
>   <input body="tns:arg1 tns:arg2"/>
> </operation>
> 
> <operation name="foo2">
>   <input body="tns:arg2 tns:arg1"/>
> </operation>
> 
> What do you think?

What's wrong with using XSD to describe this?

        <xs:complexType name="foo">
                <xs:all>
                        <xs:element name="arg1" type="xs:string"/>
                        <xs:element name="arg2" type="xs:int"/>
                </xs:all>
        </xs:complexType>

> --
> Savas Parastatidis 
> http://savas.parastatidis.name
> 
> 
<snip/>
Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
Received on Tuesday, 8 July 2003 21:44:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:25 GMT