Re: HTTP binding options

This is the big issue with option 5.
If we use the RPC style, we somehow define abstract parameters in the 
GED and the GED in that case seems (at least to me) to be some kind of a 
collection of parameters. In that particular case, I think I feel ok 
with only some of  the parameters (i.e. only a part of the GED) to be 
serialized in the message body.
    Youenn


Jeffrey Schlimmer wrote:

> Youenn, how do you feel about having only part of the GED indicated by 
> /definitions/interface/operation/{input,output}/@message be serialized 
> in /Envelope/Body/* ?
>
>  
>
> --Jeff
>
>  
>
> ------------------------------------------------------------------------
>
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
> On Behalf Of FABLET Youenn
> Sent: Monday, November 10, 2003 5:37 AM
> To: Philippe Le Hegaret
> Cc: Sanjiva Weerawarana; Web Services Description
> Subject: Re: HTTP binding options
>
>  
>
> I do not remember that there was a "pretty strong sentiment against 
> doing 5", i.e. URL replacement.
> Maybe I do not recall the entire discussion. Anyway, I would also 
> favor option 5, which seems to be equivalent to today's http binding 
> functionnality.
>
> Personly, I would even go beyond and ask to generalize the access 
> mechanism (used by the url replacement) to work not only with the http 
> binding but also with the soap binding, for instance to directly set 
> property values with abstract data.
>
>     Youenn
>
> Philippe Le Hegaret wrote:
>
>On Thu, 2003-11-06 at 11:57, Sanjiva Weerawarana wrote:
>
>  
>
>>The "HTTP binding table" at the post-meeting lunch came up
>>
>>with the following possible options for the HTTP binding:
>>
>> 
>>
>>option 1:
>>
>>    drop HTTP binding completely
>>
>> 
>>
>>option 2:
>>
>>    define a POST binding only with the natural binding possible:
>>
>>    input becomes POST body and output must be POST response
>>
>> 
>>
>>option 3:
>>
>>    define option 2 +
>>
>>    define GET binding for operations with MEP=in-out and with no
>>
>>    input body (i.e., GET goes to http:address <http://address> URL) and the output
>>
>>    must be the GET response
>>
>> 
>>
>>option 4:
>>
>>    define option 3 + 
>>
>>    define GET binding for operations with MEP=in-out and @style=rpc
>>
>>    ala the WSDL 1.1 binding, but with rules to move all parameters 
>>
>>    into query parameters. (That is, no URL rewriting ala WSDL 1.1.)
>>
>> 
>>
>>option 5:
>>
>>    define option 4 +
>>
>>    add URL replacement to allow different parts to go in the URL
>>
>>    itself vs. as query params
>>
>> 
>>
>>There was pretty strong sentiment against doing (5). (4) has the
>>
>>negative that the value of operation/@style is bleeding into the
>>
>>binding - which would be unfortunate. (3) is interesting and can
>>
>>be generalized a bit for other MEPs if needed. An interesting twist
>>
>>on (3) could be to allow appending a relative URL to the adresss
>>
>>on a per-operation  basis. That's not without price (inconsistent
>>
>>use of xml:base for relative URLs for one).
>>
>> 
>>
>>My current preference is that we do option (2).
>>
>>    
>>
> 
>
>I currently favor option 5. SOAP 1.2 includes a SOAP response-only MEP
>
>and we ought to support it reasonably, which not the case of option 1,
>
>2, and 3. It is also a matter of enabling Web applications to take
>
>advantage of Web Services, without requiring a SOAP stack. True enough,
>
>this has to be done with limitations, because of the limitations of HTTP
>
>itself. Option (4) can require to use the RPC style at the interface
>
>level if necessary. Regarding option 5, the idea of not being able to
>
>expose a database of images where each image has its own uri, without
>
>using parameters, is simply absurd. HTTP is out there and we better take
>
>advantage of it. Finally, I would note that enabling option 5 does
>
>affect at all our abstract model. It does affect the way applications
>
>can define interfaces since the RPC style must be required in the case
>
>of HTTP GET.
>
> 
>
>Philippe
>
> 
>
> 
>
>  
>