Re: Minority objection to requiring unique GEDs or required feature to distinguish operations

On Fri, 13 Aug 2004 12:58:10 -0400
Mark Baker <distobj@acm.org> wrote:
> Right.  The URI just identifies an algorithm for finding some token
> which can be unambiguously mapped to the operation (it needn't be an
> "operation name" ala "getStockQuote", but could just be "1" which means
> the same thing per the specifications describing the operational
> semantics).

Which is an utterly pointless requirement in the cases given.  They're not
trying to interoperate with random client toolkits.  Unless those random
client toolkits support user-defined plugins (which are going to amount to
little more than "yes, I know what that URL is, thanks very much"), they
aren't going to work with the service.  The actual code to insure that the
message contains the correct information to select the expected operation
is written by the customer of the toolkit, and isn't likely to be shared,
'cause this is custom, grotty, legacy stuff, not new deployment stuff that
should be emulated and widely distributed.

Some toolkits will provide the workaround to Stupid Requirement.  Others
won't.  Depending on your point of view, it is a Good Thing to a) provide
a workaround or b) keep WSDL pure and undefiled.  Under any circumstances,
a requirement that encourages vendors to create workarounds to avoid
conformance because that's what the customers want is a BAD REQUIREMENT.

In this particular case, it is a prescriptive requirement in an otherwise
descriptive language.  Mostly, we're describing things.  Here, the working
group has decided that you either describe what you're doing, or you don't
use the language, though there have been noisy objections.  I expect the
requirement to become a dead letter, because it's not a business
requirement, it's a naughty-bad-shame-on-you requirement.  I would
therefore rather see it made expressly into a recommendation (a SHOULD)
rather than a requirement, because that's how it's gonna happen
(guaranteed, in at least three cases that I know of).

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 13 August 2004 17:13:25 UTC