W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

Re: issue: optional parts in <message>?

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Sat, 4 May 2002 07:15:00 +0600
Message-ID: <03b901c1f309$1ea72410$17aa7cca@lankabook2>
To: <www-ws-desc@w3.org>
"Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >The idea of parts was to recognize that while the operation takes
> >a single message, it is actually taking a collection of things. 
> >Each thing (a part) represents a first-class thing it takes. So
> >for example, if an ordering operation takes a purchase order
> >document and a vcard document giving it information about where to
> >send the stuff to, then that operation takes 2 things. In your model,
> >I would be forced to model those two as a single document, which 
> >they are just not!
> Are we suggesting that the various "parts" are a single document within
> the computing environment of the client or server? Mais non. However,

I'm not sure I grok what you are saying .. can u please clarify? I'm
saying that forcing one to define one type in WSDL is not natural.
WSDL is the service's view that the client sees ... so the client/server
question confuses me.

> they are part of a single "document" on the wire. Whether to describe
> representational types with a WSDL-specific EII or to re-use XML Schema
> is an engineering decision not a modeling issue.

It is for RPC style bindings. Take SOAP RPC: the "document" sent 
looks like the following:
        <arg1 ../>
        <arg2 ../>
        <argn ../>
Forcing me to describe this as one "type" would mean I have to write 
a type definition for the methodName element. That is not a first
class model of the underlying RPC. 

Historically, the precise reason for the existence of <message> was
to provide a unified mechanism for first-class description of both
RPC style operations and document style operations.

> (Such healthy discussion! It's so much nicer than mere administrivia.)

Yes!! Finally ...

Received on Friday, 3 May 2002 21:18:09 UTC

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