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

Mark

I agree that there is a useful distinction to be made here
between stuff that can be burned into a 'client' and stuff
that is just a useful runtime default but still maybe negotiated.

I guess this is one of the distinctions Dave is asking us to consider 
when looking at his enumeration of HTTP features:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0083.html

One way of flagging this distinction could be to move the given 
property from the binding to the endpoint - but this would leave me 
feeling uncomfortable too as i prefer to keep my WSDLs as a description 
of an interface and have the runtime parameters separate. This saves 
having to edit WSDL, turn a handle just to point a client at a different
server when moving from development to test to live.

I am happy, however, to describe a binding as using Basic 
Authentication or gzip, since these are features likely to be 
supported across all endpoints implementing an interface. Worst
comes to worst and they'll be ignored / renegotiated.

In my mind urlReplacement is more business as usual for WSDL
i.e. it's how interface values are serialised/deserialised in a 
particular binding.

Paul

-- 
Paul Sumner Downey
Web Services Integration
BT Exact



-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Mark Baker
Sent: 04 May 2004 20:04
To: Yaron Y. Goland
Cc: www-ws-desc@w3.org
Subject: Re: Static vs. dynamic aspects of a service description (was
Re: HTTP properties



On Tue, May 04, 2004 at 11:29:23AM -0700, Yaron Y. Goland wrote:
> 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.

I guess this boils down to use-cases for WSDL.

The only way I've seen WSDL used in practice, is as a design-time tool
which declares the static aspects of a service.  This is in line with
its (pervasive) use in code generation.

But that's a very different use than you're describing there, which is
to use WSDL as a runtime tool (which, FWIW, I've been promoting by
trying to add some forms-like capabilities to WSDL, viz a viz
"urlReplacement").  And though I agree that there's a lot of value in
that approach, I'm concerned that it's being done without due
consideration to the problems it will create for those using it for
code generation.

I wonder if an extension couldn't be defined to allow a WSDL document
to declare whether what its asserting is intended to be true for all
time, versus just true at this moment in time, at a very fine level of
granularity (per feature)?  That would permit code generators to ignore
the "at this moment in time" assertions, thereby preventing them from
generating code which could break when that thing changes.

Thoughts?

Mark.

Received on Wednesday, 5 May 2004 11:31:12 UTC