W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

Re: Static vs. dynamic aspects of a service description (was Re: HTTP properties

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Thu, 29 Apr 2004 12:23:55 -0400
To: www-ws-desc@w3.org
Message-ID: <OF53291A85.3DE10F36-ON85256E85.0059514F-85256E85.005A146D@ca.ibm.com>


I think HTTP has a great mechanism for negotiating transport details, like 

compression, at runtime. The less we put in WSDL the better. 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063
intranet: http://w3.torolab.ibm.com/DRY6/

Mark Baker <distobj@acm.org> 
Sent by: www-ws-desc-request@w3.org
04/29/2004 10:44 AM

David Orchard <dorchard@bea.com>
Static vs. dynamic aspects of a service description (was Re: HTTP 

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

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



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.

Received on Thursday, 29 April 2004 12:24:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC