RE: HTTP binding options

Yes

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of David Orchard
> Sent: Wednesday, November 12, 2003 10:25 AM
> To: www-ws-desc@w3.org
> Subject: RE: HTTP binding options
> 
> I think I am saying that is a feature not a bug.  In the case of a
banking
> customer I was talking to, they want the transaction # in the URL.
> 
> Does this mess things up in the "infoset uber alles" approach?
> 
> Dave
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Jeffrey Schlimmer
> > Sent: Wednesday, November 12, 2003 10:17 AM
> > To: David Orchard; www-ws-desc@w3.org
> > Subject: RE: HTTP binding options
> >
> >
> >
> > David, 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
> >
> > > -----Original Message-----
> > > From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org]
> > On
> > > Behalf Of David Orchard
> > > Sent: Wednesday, November 12, 2003 9:57 AM
> > > To: www-ws-desc@w3.org
> > > Subject: RE: HTTP binding options
> > >
> > >
> > > I'm strongly in favour of option 5.  I really don't see how we
could
> > > seriously call this a "Web" service description language if
> > there's no
> > > support for describing URLs.  We see a significant number
> > of customers
> > > wanting to have better integration between URL parts and
> > message parts
> > in
> > > WSDL.  Y'all know how much I have argued against certain
> > zealotry so I
> > > don't
> > > say this from that pov.
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> > [mailto:www-ws-desc-request@w3.org]On
> > > > Behalf Of Sanjiva Weerawarana
> > > > Sent: Thursday, November 06, 2003 8:57 AM
> > > > To: www-ws-desc@w3.org
> > > > Subject: HTTP binding options
> > > >
> > > >
> > > >
> > > > 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 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).
> > > >
> > > > Sanjiva.
> > > >
> > > >
> >
> >

Received on Wednesday, 12 November 2003 14:06:06 UTC