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

Even if there had been some commonly used interface description format 
when HTTP was introduced I still believe HTTP should have defined its 
various run-time negotiation features. After all, static descriptions 
can change as new capabilities are added or removed and HTTP's 
negotiation features enable one to continue to function in the face of 
such changes.

In other words, HTTP's negotiation feature's usefulness would not have 
been negated even if a description format had been available when HTTP 
was developed.

Similarly the fact that HTTP has its negotiation features in no way 
negates the usefulness of pre-declaring capabilities in a description 
format now that one is available.

Allowing implementers to define in WSDL what HTTP features they support, 
e.g. GZIP, etc., enables a performance boost by allowing an on-line 
discovery step to be skipped. Given that the whole purpose of WSDL is 
effectively 'discovery', it seems reasonable to use a discovery 
mechanism to discover even more useful information.

	Yaron

Mark Baker wrote:
> 
> 
> On Thu, Apr 29, 2004 at 12:07:30PM -0700, Mark Nottingham wrote:
>  > However, there is no defined mechanism for the server to describe
>  > acceptable encodings in the request without an extra round trip, which,
>  > in POST-heavy uses of Web services, is important to many people.
> 
> Good point, and a good explanation of the issue, thanks.
> 
> But is that a valid use case for WSDL; to be used to fix problems with
> application protocols?  It doesn't sound like such a good idea to me.
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 

Received on Tuesday, 4 May 2004 14:29:38 UTC