Re: Action Item 2004-07-01 Solution to 168/R114

Sanjiva Weerawarana wrote:

>Wouldn't this scenario be best solved by defining operation A
>(the one that's gone out to lunch) to be one that returns an
>element whose content model is a choice between Y and Z? That
>is, I don't think this is a good example to motivate leaving
>dispatching out of band.
>  
>
Well said.

>I'm +1 to leaving dispatching out of band on the basis that
>its the server's business to know how to dispatch and the WSDL
>is what the server has decided to tell *the client*. There's no
>need for the server to tell the client how *it* does its internal
>work.
>
A big -1. It is a problem for interop.

>
>The only case I've seen to justify including that is for "industry
>standard" WSDLs which are intended to be implemented by different
>service providers. That is, the WSDL there does not describe
>a single service offered by someone, but the structure of services
>to be offered  by others. In that case however I imagine the 95%
>scenario will be unique GEDs or some other form that is patently
>obvious to the service implementor.
>
Ok, lets take operation name from the addressing specs that are 
currently in out there, whether be WS-Addressing, WS-MD. This is 
obviously an indication of the need.

>
>My proposal supports both these to work happily. I'm not mandating
>that the SOAPAction based solution be used, but it does provide a
>mechanism to make "dispatching" clear when necessary. At the same
>time, we are not precluding other mechanisms (like the one Gudge
>mentioned) from doing what they want.
>
All my proposal says is that you need to engage an extension in WSDL and 
declare it. I don't understand why you guys find it so harmful to 
declare the full contract in WSDL although some of the contract is in an 
extension. Could you clarify that?

>
>Sanjiva.
>
--umit

>
>----- Original Message ----- 
>From: "Martin Gudgin" <mgudgin@microsoft.com>
>To: "David Booth" <dbooth@w3.org>; "Jeffrey Schlimmer"
><jeffsch@windows.microsoft.com>
>Cc: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>; "WS Description List"
><www-ws-desc@w3.org>
>Sent: Tuesday, July 13, 2004 4:00 PM
>Subject: RE: Action Item 2004-07-01 Solution to 168/R114
>
>
>  
>
>>Let's take an interface with operations B and C both of which have the
>>same input message, X. Operation B has an output message Y, while
>>operation C has a different output message Z. Both B and C use the
>>In-Out pattern.  Whether you get message Y or Z back depends on the
>>content of X. Let's for the sake of argument say that if a particular
>>value in X is over 1000 you get Z, otherwise you get Y.
>>
>>I believe that this is a coherent (if somewhat simplistic) example in
>>messaging systems. I also understand that it does not fit particularly
>>well into the RPC style. And that the WSDL does not describe the details
>>of how the server determines whether to send Y or Z. C'est la vie. There
>>is still enough information in the WSDL to construct messages that the
>>service will accept and to deconstruct messages the service will emit,
>>that is to interoperate with the service.
>>
>>Some of you are wondering what happened to operation A. But that's
>>another story...
>>
>>Gudge
>>
>>    
>>
>>>-----Original Message-----
>>>From: www-ws-desc-request@w3.org
>>>[mailto:www-ws-desc-request@w3.org] On Behalf Of David Booth
>>>Sent: 08 July 2004 17:40
>>>To: Jeffrey Schlimmer
>>>Cc: Umit Yalcinalp; WS Description List
>>>Subject: RE: Action Item 2004-07-01 Solution to 168/R114
>>>
>>>
>>>At 02:30 PM 7/7/2004 -0700, Jeffrey Schlimmer wrote:
>>>
>>>      
>>>
>>>>WSDL 2.0 should not require identifying the operation name
>>>>        
>>>>
>>>because doing
>>>      
>>>
>>>>so will unnecessarily limit the applicability of WSDL 2.0.
>>>>        
>>>>
>>>Can you give an example?
>>>
>>>      
>>>
>>>>R114 mandates that the WSD language define a way to uniquely
>>>>        
>>>>
>>>map, but it
>>>      
>>>
>>>>does not mandate that each WSDL document must uniquely map.
>>>>        
>>>>
>>>The current wording of R114 is indeed ambiguous ("R114: The
>>>description
>>>language MUST allow unambiguously mapping any on-the-wire
>>>Message to an
>>>Operation.").  It isn't clear whether the "MUST allow" verb
>>>applies to the
>>>_mapping_ or the _writer_of_a_WSDL_document_, i.e., whether
>>>it MUST allow
>>>any message to be mapped to an operation (this would be the stronger
>>>interpretation), or whether it MUST allow a WSDL document to
>>>be written
>>>such that any message can be mapped to an operation (this
>>>would be the
>>>weaker interpretation).  Also, the wording of this
>>>requirement somehow
>>>changed (weakened) after the WG agreed to it on 4 April 2002,
>>>though I
>>>can't find anything in the minutes to justify the change.
>>>(Here is the
>>>chronology that I found:
>>>http://lists.w3.org/Archives/Public/www-archive/2004Jul/0021.html )
>>>
>>>However, I think the precise wording of R114 is somewhat
>>>irrelevant.  The
>>>real question is what does the WG think we need.
>>>
>>>Jeffrey, are you suggesting that you think Scenario X (
>>>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html )
>>>is an acceptable situation and is not a interoperability
>>>problem that we
>>>need to solve?
>>>
>>>      
>>>
>>>>The RPC style (http://www.w3.org/2004/03/wsdl/style/rpc)
>>>>        
>>>>
>>>defines a way
>>>      
>>>
>>>>to uniquely map and therefore satisfies R114. Nothing else is needed.
>>>>        
>>>>
>>>Again, that depends on your interpretation of R114.  Unique GEDs also
>>>provide a way to uniquely map.  Personally, I think the weak
>>>interpretation
>>>of R114 would render R114 somewhat pointless, because the
>>>author of a WSD
>>>can always simply write the WSD to use unique GEDs -- nothing
>>>special is
>>>needed in the WSDL 2.0 spec to facilitate this.
>>>
>>>
>>>-- 
>>>David Booth
>>>W3C Fellow / Hewlett-Packard
>>>Telephone: +1.617.253.1273
>>>
>>>
>>>      
>>>
>
>
>  
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com