RE: What WSDL defines - the diagram!

+1 to Gudge! I find a lot of people confused about this. How to make it clear to the spec readers?
Attached is one simplified attemt to formally define some of the WSDL components and their relationships in UML.


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Martin Gudgin
Sent: Friday, November 07, 2003 5:12 AM
To: David Booth; Anne Thomas Manes; Mark Baker; Glen Daniels
Cc: www-ws-desc@w3.org; paul.downey@bt.com
Subject: RE: What WSDL defines - the diagram!


It's not about a 'document'. It's about a set of WSDL components. You can't tell by looking at a single document whether it violates the unique definitions rule. You have to follow imports to do that, which is something only a WSDL processor can do ( whether that processor is implemented in wetware, XSLT, Java or whatever ).

So, I disagree that our job is only to state what it means to be a WSDL document. We do need to state that. But we also need to state what it mean to be a valid set of WSDL components. Note that the distinction here is EXACTLY the same as that between a schema document and a schema.

Gudge

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: 07 November 2003 08:57
> To: Martin Gudgin; Anne Thomas Manes; Mark Baker; Glen Daniels
> Cc: www-ws-desc@w3.org; paul.downey@bt.com
> Subject: RE: What WSDL defines - the diagram!
> 
> No, whether or not there are duplicate definitions is a property of 
> the WSDL document -- not a question of what a WSDL processor does with 
> it.  The
> *document* is erroneous (or non-conformant) if it contains duplicate 
> definitions.
> 
> WSDL processors might do many things.  We cannot make assumptions 
> about what they may wish to do, nor should we try to restrict what 
> they might do.  That's their business, not ours.  Our business is to 
> define: (a) what constitutes a conformant WSDL document; and (b) what 
> that document means.
> 
> At 10:38 AM 11/6/2003 -0800, Martin Gudgin wrote:
> >I think the WSDL 2.0 spec does define certain things that a WSDL 
> >processor MUST do. For example, check that no duplicate definitions 
> >exist.
> >
> >Gudge
> >
> > > -----Original Message-----
> > > From: www-ws-desc-request@w3.org
> > > [mailto:www-ws-desc-request@w3.org] On Behalf Of David Booth
> > > Sent: 06 November 2003 06:51
> > > To: Anne Thomas Manes; Mark Baker
> > > Cc: www-ws-desc@w3.org; paul.downey@bt.com
> > > Subject: Re: What WSDL defines - the diagram!
> > >
> > >
> > > P.S. The greater significance of the diagram is not so
> much in what
> > > it includes but what it omits.  In particular, it says
> nothing about
> > > what a WSDL *processor* must or must not do.
> > >
> > > There are different types of interoperability that we could 
> > > potentially strive to obtain with the WSDL 2.0 spec, which I'll 
> > > arbitrarily call:
> > >
> > > Type 1: Web Service & Client interop.  This type of interop is to 
> > > ensure that the WS and client agree on the mechanics of their 
> > > interaction -- the message formats, data types,
> transport, MEP, etc.  
> > > (Of course, they still need to use other means to ensure
> that they
> > > agree on the semantics and other higher-level details of the 
> > > interaction -- beyond what WSDL covers.)
> > >
> > > Type 2: WSDL Processor interop.  This type of interop
> would ensure
> > > that different WSDL processors would have the same behavior when 
> > > presented with a given WSD.
> > >
> > > WSDL 2.0 pursues type 1: Web Service & Client interop.  
> It does not
> > > define what a WSDL processor must or must not do with a
> given WSD.  
> > > (And rightly so, in my opinion: what a processor *does*
> with a given
> > > WSD is its own business -- not ours.)
> > >
> > >
> > > At 01:10 PM 11/5/2003 -0500, David Booth wrote:
> > >
> > > >Mark & Anne,
> > > >
> > > >Certainly, a WSDL document does not *fully* define client or 
> > > >service behavior, but it does *partially* define their behavior.
> > > That's what
> > > >MEPs are all about.  When a WSDL document specifies a
> > > message exchange
> > > >pattern, that pattern partially defines the behavior of the
> > > interacting
> > > >parties -- not their internal behavior, but their externally
> > > observable
> > > >behavior, i.e., what messages they send and receive and in
> > > what sequence.
> > > >
> > > >The labels on the diagram were somewhat abbreviated, and omitted 
> > > >the word "partially".  A clearer diagram is at 
> > > >http://lists.w3.org/Archives/Public/www-archive/2003Nov/0002.html
> > > >
> > > >
> > > >At 01:34 PM 11/4/2003 -0500, Anne Thomas Manes wrote:
> > > >
> > > >>+1.
> > > >>
> > > >>WSDL explicitly does not define client or service behaviour. It 
> > > >>describes syntax of messages and protocols used to exchange
> > > those messages.
> > > >>
> > > >>Anne
> > > >>
> > > >>At 10:41 AM 11/4/2003, Mark Baker wrote:
> > > >>
> > > >>>Cool, thanks for tackling that at the f2f.
> > > >>>
> > > >>>But I disagree with the diagram.  As it was explained to
> > > me, a WSDL
> > > >>>2.0 document could be said to "describe the syntax" of
> client and
> > > >>>service ("schema in, schema out"), rather than "define the 
> > > >>>behaviour", which would require defining what in/out means in 
> > > >>>relation to any requested semantics (aka the protocol).
> > > >>>
> > > >>>WSDL 1.1 describes the protocol in that it suggests that a
> > > successful
> > > >>>response to a message means that the requested
> operation in the
> > > >>>message was successfully invoked.  WSDL 2.0 is ambiguous.
> > > >>>
> > > >>>Mark.
> > > >>>--
> > > >>>Mark Baker.   Ottawa, Ontario, CANADA.
> > > http://www.markbaker.ca
> > > >
> > > >--
> > > >David Booth
> > > >W3C Fellow / Hewlett-Packard
> > > >Telephone: +1.617.253.1273
> > >
> > > --
> > > David Booth
> > > W3C Fellow / Hewlett-Packard
> > > Telephone: +1.617.253.1273
> > >
> > >
> 
> --
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
> 
>