RE: HTTP binding options

Is it feasible to have a URL re-writing syntax that also covers other URLs such as FTP or SMTP ?

I guess i'm wondering about option 5 but not limited to the http-binding and not just for rewriting query_string parameters.

Paul

 -----Original Message----- 
 From: David Orchard [mailto:dorchard@bea.com] 
 Sent: Wed 12/11/2003 17:56 
 To: www-ws-desc@w3.org 
 Cc: 
 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 17:53:04 UTC