Re: HTTP binding options

On Mon, 2003-11-10 at 11:31, Sanjiva Weerawarana wrote:
> "Philippe Le Hegaret" <plh@w3.org> writes:
> > > The problem with doing (5) is that it bleeds the value of @style to
> > > bindings. I think that's pretty bad.
> > 
> > Not at all. (5) requires the use of @style in the interface, but does
> > not move it or redefine it in the bindings.
> 
> However, (5) does require different binding rules for @style=rpc
> vs not. That's what I meant by @style bleeding into the bindings.

correct, since I'd like to add a condition on top of the rpc style to
restrict the content of the children elements to be simple types.

> > My concern here has nothing to do with REST, but with HTTP. We should
> > take advantage of its functionalities.
> 
> Fair enough. However, in general one could then argue that you should
> be able to use XPath (for example) to look inside the input message
> and form the URL. Again, its all a matter of how far we want to 
> go and where we believe 80-20 lies. 

Arthur and myself did explore the XPath solution in the past and
rejected it for our first HTTP binding proposal, and no one objected to
it. Doing the serialization using XPath would be easy but the
deserialization can lead to conflicts. Extending the RPC rules is easier
imho.

Philippe

Received on Monday, 10 November 2003 13:29:43 UTC