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 Tuesday, 4 May 2004 15:04:29 UTC