- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Tue, 13 Jul 2004 09:48:26 +0600
- To: <www-ws-desc@w3.org>
"David Orchard" <dorchard@bea.com> writes: > > As part of the "Web" services description language, I'd use the > semantics and the names of the HTTP verbs. I don't see much > need to be independent of the most widely deployed generic > protocol ever. I absolutely do .. otherwise we've spent a lot of energy keeping a separation that is not necessary. I'm sorry but I absolutely do not accept that any HTTP specific features belong at the interface level, in an abstract form. > Also, check out soap 1.2 adjuncts. It talks about the webMethod > feature being bound to protocols other than HTTP. That's why > it's a feature and not a new binding or mep. They could have > done the "webmethod" mep, but made it a feature. I believe MEPs are indeed features in SOAP. I have no idea what it would mean to make the Web method feature a MEP. > Good enough for soap, good enough for me. Good enough for SOAP isn't good enough for me because that would mean we can let the abstract part of WSDL become SOAP specific. That too is completely unacceptable to IBM, just like its unacceptable to let it become HTTP specific. > I'd say that if we used @webMethod (or how about @genericMethod), > then we could get rid of @safe. @safe is a special case that > applies to GET. I agree. So if we add whttp:webMethod (see my previous mail) then we can get rid of @safe. > Maybe if @webMethod="get" then the default wsoap:mep is soap-response. I'm sorry if I missed this but can you indicate the proposed value space of @webMethod please? Are we going to use "get" or "GET" or "Get" in the spec? We need to use something if we are going to talk about how that maps to wsoap:mep default values of course. Sanjiva.
Received on Tuesday, 13 July 2004 00:37:16 UTC