W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: help with incorporating operation name v3 proposal (issue 168)

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 28 Jul 2004 11:13:00 -0400
To: Glen Daniels <gdaniels@sonicsoftware.com>
Cc: dorchard@bea.com, www-ws-desc@w3.org
Message-id: <20040728111300.1879a1f1.alewis@tibco.com>

On Tue, 27 Jul 2004 18:41:16 -0400
Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> I'm not sure I understand what you think is "absurd" here.  We are

Creating a feature which, in toto, reads "This feature, identified by the
URI http://www.example.org/alkahest/, fulfills the requirement of being a
required extension."

And this *will* happen, because in the case under discussion (which we
shouldn't be spending time on now, since it's already been voted on, and I
lost), at least two companies that I know of will document how to sidestep
the Stupid Requirement.  Since all that a processor can tell, looking at
the thing, is that it contains or does not contain an extension which is
marked wsdl:required, that's all that can be tested.  If that's missing,
the processor can say "missing required extension," but can't identify the
extension that's required.  Something is required to be required.  

We encounter a great many companies who want to describe existing legacy
services, which may not, in the first pass of modernization, actually use
a reasonable dispatch mechanism.  They have to put *something* there.  So
they will.

*shrug*  Clearly, that's an optional extension.  Only it isn't, it's

What's absurd is for the Description language to make a Prescription for
best practice.  A recommendation, fine.  A requirement?  Just means less
interop.  Why bother defining the algorithm you use to dispatch, when you
can just plug in Meaningless Feature to fulfill Stupid Requirement?

dadadadadadadadadadadadadadadadadadadadadadadadadadada dada

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Wednesday, 28 July 2004 11:13:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:49 UTC