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

Hi Amy!

I'm not sure I understand what you think is "absurd" here.  We are
talking about an extensibility point.  By definition, our spec cannot,
and should not, say anything about the kinds of things that might be
written to slot in there.  However, we DO provide a mechanism by which
you can name particular extensions/features which are mandatory, and
then if you determine (in some implementation-specific way) that you
don't support them, you have a clear opportunity to fail with an
indication of exactly what the problem was.

This is precisely like what SOAP does - it is up to a processor to
decide whether it "understands" a given header or not.  Now, to get to
what I think connects to your argument - nothing would prevent someone
from writing a SOAP processor which claimed to "understand" all headers
sent to it.  However, it wouldn't be spec compliant with any of the
actual semantics of those extensions it claimed to "understand", and the
market would hopefully punish the vendor of such a beast appropriately.

So it is with the "meaningless feature" below.  I am in NO WAY
advocating that anyone in the real world should actually specify or
implement a feature which simply removes the operation name requirement.
I won't implement anything like that in Axis, for instance, although I
*will* make sure that our extensibility APIs allow someone else to shoot
themselves in the foot in that way. :)  However, since we are ONLY (I
think - see below) testing the WSDL processor and not actual runtime
message flows, the best we can do is to specify that certain extensions
are "understood" in our contrived test environment, and certain ones are
not.

Personally I'd be in favor of altering the test below to add actual
functionality - i.e. a SOAP module which transfers the
interface/operation tuple in a header, and then test that we get the
right tuple by echoing it back - but that presupposes that we've decided
to do "runtime" testing as well as just document processing.

Again, just to be clear - we have given WSDL an abstract "switch" which
says "you should be able to get the operation name somehow".
Unfortunately (IMHO) we didn't use the F&P mechanism for clearly naming
and describing the semantic, but nonetheless each implementation will
have some way of indicating whether a given extension/plugin satisfies
the requirement.  For a given WSDL in the wild, either the GEDs will be
unique OR some plugin triggered by extensions/features in the WSDL will
have the "I do that" flag set - and in the wild, that flag means that
the extension really WILL somehow convey the interface/operation tuple,
not that someone just arbitrarily set it.

--Glen 

> -----Original Message-----
> From: Amelia A Lewis [mailto:alewis@tibco.com] 
> Sent: Tuesday, July 27, 2004 11:00 AM
> To: Glen Daniels
> Cc: dorchard@bea.com; www-ws-desc@w3.org
> Subject: Re: help with incorporating operation name v3 
> proposal (issue 168)
> 
> On Mon, 26 Jul 2004 18:16:30 -0400
> Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> > I would think the tests would be something like:
> > 
> > - 1 -
> > Define a WSDL with unique GEDs, processor does fine
> > 
> > - 2 -
> > Define a WSDL with non-unique GEDs and no extensions, 
> processor barfs
> > 
> > - 3 -
> > Define an feature "http://www.w3.org/wsdl/testFeature" which 
> > "satisfies the requirement" (in other words this feature 
> simply exists 
> > for this test).
> > 
> > Define a WSDL with non-unique GEDs which uses the above 
> feature in the 
> > <interface>, processor does fine.
> 
> Exactly.  This is how an optional extension can be required 
> to be required, and how to code around it.
> 
> *sigh*  I really *shouldn't* point out that this is massively 
> silly, since it went through formal vote, but I really just 
> can't resist.  Especially when someone else is pointing out 
> the absurdity straight-faced ("this feature fulfills that 
> requirement").
> 
> Amy!
> --
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> alewis@tibco.com
> 
>

Received on Tuesday, 27 July 2004 18:41:28 UTC