- From: Mark Baker <distobj@acm.org>
- Date: Thu, 29 Apr 2004 10:44:10 -0400
- To: David Orchard <dorchard@bea.com>
- Cc: www-ws-desc@w3.org
I'd like to understand the use case for this (and the recent suggestions to describe HTTPS and chunked transfer encoding). It was my understanding that a WSDL document described the static aspects of a Web service, as it allowed code to be generated which could assume those static things. So what's the value in, for example, allowing a WSDL document to declare "This service accepts gzip encoded documents", when HTTP already does that? Is the idea that declaring it in a WSDL means that it's static for all time? If not, then what's the value add, since if I didn't declare that in the WSDL, I could use gzip as long as I wanted, then change later? And if so, why would you want to do that? Why isn't just writing your code to the HTTP specification sufficient? And how do you deal with inconsistencies, since that information is now available in two places? It seems to me that a WSDL document should stick to describing aspects of a service that aren't expected to change, so that the generated code - which may been deployed long ago - won't need to be upgraded because the WSDL was changed in a way that code wasn't expecting. But I'm not saying that this can't be done - clearly, some guidelines about what it means for underlying protocol features to be described in WSDL would make it possible. I'm just trying to understand the motivation. Cheers, Mark. On Thu, Apr 29, 2004 at 02:55:45AM -0700, David Orchard wrote: > > This message contains a list of HTTP properties that may be of interest to WSDL description. I have provided some starter comments on the relative utility of being described by WSDL. The categories that I used are: described by WSDL 2.0, probably useful, probably not useful, not useful or applicable (n/a). In summary, I found roughly: 4 properties that are described by WSDL 2.0, 9 probably useful categories, 2 probably not useful, and 8 not useful/application. [snip]
Received on Thursday, 29 April 2004 10:53:26 UTC