- From: Amelia A Lewis <alewis@tibco.com>
- Date: Mon, 26 Jul 2004 14:39:46 -0400
- To: Glen Daniels <gdaniels@sonicsoftware.com>
- Cc: www-ws-desc@w3.org
On Mon, 26 Jul 2004 12:39:25 -0400 Glen Daniels <gdaniels@sonicsoftware.com> wrote: > Unfortunately, I still think that allowing the "widening" of potential > values (i.e. feature requiredness and property values/constraints) is a > dangerous place to go. Imagine this situation: I define a standard As I recall, this was discussed at the face to face, where it was resolved in favor of a single scoping rule, rather than scope-modified-by-requisite. An issue fell out of that resolution, that it should be *possible* to express 'requisite, cannot be made optional', and a proposal was submitted. In that discussion, many people expressed antipathy to the idea (and the proposal's author was, in fact, convinced by these arguments). I think that, in general, we get in trouble when we try to head down the path of *prescribing* behavior, rather than *describing* it. I would so characterize the decision made that requires some wsdl:required meaningless-feature for dispatch. Granting that there are best current practices, ruling out other practices is [several seconds of inventive appalachian obscenity in a form that translates to a single adjective meaning 'extremely'] bad practice on our part. We MUST provide a language for service description. We MAY mention best practices, but we MUST NOT gut the language in order to prevent something considered stylistically abusive (even if it's dressed up in missile-launch terminology, for better scare value). SO. I object to reopening this issue, as the scenario offered was also presented at the face to face, and after, in the discussion of the 'final' bit. Lacking new information, new proposals, or at least new arguments, I believe we are chartered not to reopen the issue. Amy! (subtext: amy threatens to reopen several *other* issues. whoosh! the chakram pinballs off seventeen known issues and ...) -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 26 July 2004 14:40:49 UTC