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

On Thu, May 06, 2004 at 10:56:42AM -0700, Mark Nottingham wrote:
> On May 4, 2004, at 12:03 PM, Mark Baker wrote:
> >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.
> 
> I wonder at how useful that would be; predicting the stability of 
> metadata (or entire representations, for that matter) is a tricky 
> business.

For sure.  Perhaps I haven't been clear; I don't currently see a heck
of a lot of value to doing that (though I remain open to there being
some there); I'm just doing this because it seems this is where the WG
wants to go, and I want it to work as well as it can with the Web.

> It would be more useful to see such descriptions as hints; i.e., the 
> dynamic negotiation mechanisms still need to be honoured, but the 
> static hints allow you to make informed decisions before you get the 
> feedback (e.g., the error message that says "I don't support 
> compression in requests").

I agree that this would be a much better interpretation of this kind of
information, but that wasn't what I understood folks to be saying.
What I was hearing was that they wanted to use this information as they
would a declaration of an operation, or a schema.

I'm certainly in favour of making WSDL more forms-like though, so I
would welcome any attempt to, for example, allow an agent to learn
via the *dynamic* discovery of a new WSDL document, that submitting a
document to some processor required (or desired) a particular content
coding, as well as media type, and anything else which describes the
follow-on interaction.

> I do agree that there's an issue regarding description and metadata 
> lifecycles, but don't think they're specific to this particular aspect.

Right.

> This also highlights some areas of HTTP that are lacking, in terms of 
> error reporting; e.g., AFAIK there's no machine-readable way to say "I 
> don't support compressed requests".  I'd much rather define these in a 
> HTTP-specific way than in a SOAP-specific way; perhaps the HTTP 
> errata-in-progress is a place to introduce such a mechanism.

Sounds good, but it also sounds like a new feature request rather than
an errata.  Should be easy enough to write up and deploy though, seeing
as ignore-semantics would work.

 [1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0089.html

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 10 May 2004 12:40:02 UTC