W3C home > Mailing lists > Public > public-ws-desc-meps@w3.org > June 2003

Re: SOAP pattenrs vs. WSDL patterns (was: Minutes from MEP Task Force 23 June 2003)

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Wed, 25 Jun 2003 09:25:10 -0700
Message-ID: <3EF9CCE6.7060905@oracle.com>
To: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
CC: David Booth <dbooth@w3.org>, public-ws-desc-meps@w3.org, FABLET Youenn <youenn.fablet@crf.canon.fr>



Jean-Jacques Moreau wrote:

>
> From the minutes, I am not entirely sure what conclusion you reached. 
> Would it be fair to summarize the TF's position as follows? (I 
> apologize in advance if my summary misrepresent the TF's position.)
>
> 1) At the interface level, we will use WSDL patterns.
>
> 2) At the binding level, we will use SOAP MEPs.
>
> 3) We will not indicate the relationship between the two.
>
> I'm fine with 1) and 2); I feel we will need to be a little more 
> explicit about 3). For example, does the choice of a WSDL pattern 
> restrict the set of possible SOAP MEPs?
>
> Again, apologies if my characterization of the TF's position was not 
> accurate. 

I don't think that we reached a conclusion or a specific stand on (3). 
Personally, my gut feeling is that the SOAP MEPs will be specific 
instances of a particular WSDL pattern and that is how we can establish 
the relationships between the two. That is what I tried to convey during 
the concall (but perhaps failed :-)).

--umit

>
>
> Jean-Jacques.
>
> David Booth wrote:
>
>>       SOAP patterns vs. WSDL patterns.
>>
>> <*dbooth*> See Youenn's message: 
>> http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jun/0024.html 
>>
>>
>> *David:* Any wisdom to share?
>>
>> *Amy:* In Scottsdale we decided to make WSDL patterns operate at a 
>> more fundamental conceptual level than SOAP MEPS.
>> ... Some discussion whether we should ask SOAP to define their 
>> patterns in terms of ours.
>> ... Decided "no". They weren't going to change.
>> ... Doesn't change the fact that SOAP patterns are more explicit than 
>> ours.
>> ... No attempt to discriminate on our part between HTTP 
>> request-response, an HTTP get followed by a SOAP response, and a SOAP 
>> request-response.
>> ... XMLP has defined two of these.
>> ... In WSDL we also are dealing with pure HTTP request-response.
>> ... I don't see that we have a significant win in distinguishing 
>> those cases.
>> ... Do we need to identify SOAP categories of request-response?
>> ... Can we leave this totally to the binding?
>>
>> *Scribe:* David, Umit: Leave to binding.
>>
>> *Amy:* There's a certain amount of SOAP r-r that we won't model 
>> outside the binding.
>>
>> *Umit:* Does it matter to the client? No.
>>
>> *Amy:* We don't need to make as many distinctions as SOAP r-r 
>> patterns, right?
>>
>> *Scribe:* David, Umit: Sounds like the case.
>>
>> *David:* Still useful to show correspondence between our patterns and 
>> XMLPs.
>>
>> *Amy:* Yes, at some point we end up with a pattern (p3) which maps to 
>> both SOAP MEPs.
>>
>> *Umit:* Equivalencies.
>>
>> *David:* Specializations.
>>
>> *Umit:* If they map to p3 doesn't that mean two equivalent 
>> implementations of the pattern?
>> ... Actually a concretization of the pattern in three different ways.
>> ... When we have a leaf node in our lattice, there may be a specific 
>> binding that describes that pattern.
>>
>> *David:* Specific binding is not an actual sequence of messages. A 
>> sequence of messages conforms to the binding, or not.
>> ... If it conforms to the binding, it conforms to the pattern.
>>
>> *Amy:* Can we say we might need some specialized terminology and move 
>> on?
>>
>> *Scribe:* (scribe missing some chunks here)
>>
>> *Umit:* As long as the client has a specific pattern it adheres to, 
>> how it relates to XMLP work doesn't matter.
>>
>> *David:* We will need to identify the link between our specific 
>> patterns and SOAP's.
>>
>> <*dbooth*> JM: It would be good of people writing new SOAP specs 
>> would reference our MEPs.
>
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Wednesday, 25 June 2003 12:27:31 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:39 GMT