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

We have a number of issues which are roughly in the area of providing greater description of what will be going in the actual HTTP deployment.  Some of these are 56, 164, 165.  The chair suggested that it might be useful to exhaustively list the "things/properties/features/constructs/stuff" that comprise HTTP messages that might be candidates for WSDL description, and then systematically analyze the list of "things" to determine whether WSDL should describe any/some/all of these "things".  

In the case of dynamic versus static description, I think there is an evaluation to be made about whether it is useful to describe in WSDL what is dynamic in HTTP.  In the case of gzip versus non-gzipped, it seems that having the knowledge upfront about what a service accepts can reduce the network traffic.  Writing to the HTTP specification is sufficient, but perhaps not optimal for network efficiency.  I've heard lots of talk lately about wanting to improve Web service performance to things like mobile devices, and one approach to improving performance is to reduce network traffic.

We will end up having the debate about whether this network traffic reduction is useful, both in theory and in reality.  And we'll also end up looking at other aspects of HTTP.  

I have no problem with either: we found a bunch of things that are interesting to describe because a variety of benefits ensue that are worth the cost, or the converse.  I'm simply doing what work I can in order to help the group make forward progress and get to LC.  

Cheers,
Dave

> -----Original Message-----
> From: Mark Baker [mailto:mbaker@markbaker.ca]On Behalf Of Mark Baker
> Sent: Thursday, April 29, 2004 9:44 AM
> To: David Orchard
> Cc: www-ws-desc@w3.org
> Subject: Static vs. dynamic aspects of a service description (was Re:
> HTTP properties
> 
> 
> 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 13:46:28 UTC