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

I've been meaning to reply to Gudge about this anyway, so I might as well 
take this opportunity.

It is true that one could always specify a feature like
"http://example.org/wsdl/operation-name-features#custom-app-specific"
and that would cynically fulfill the letter of the requirement while 
subverting its intent, but this doesn't necessarily render the requirement 
useless.   As Glen points out, the requirement is testable.  What isn't 
testable is whether the WSD author made the best choice of which 
feature/URI to specify.

If unique GEDs are not used, and the wsdl:operations are meaningful to the 
services, then there are three cases:

Case 1: The service uses a well-known mechanism for determining the 
wsdl:operation name from the received, and hence such mechanism is likely 
to already be automated in other toolkits.  In this case the WSD author 
SHOULD specify the operation name feature as a well-known URI that 
identifies that well-known mechanism.  This will maximize the changes that 
other parties' toolkits can automate whatever is needed to support that 
mechanism.

Case 2: The service does not use a well-known mechanism, but uses a 
mechanism that is likely to automatable in other toolkits, even if it isn't 
already automated. In this case the WSD author SHOULD specify the operation 
name feature as a standard URI that identifies that mechanism.  If no 
existing URI for that mechanism is known, then the WSD author will need to 
create a new one.  This will maximize the changes that, in the future, 
other parties' toolkits can automate whatever is needed to support that 
mechanism.

Case 3: The service uses a custom, application-specific mechanism that is 
very unlikely to be automated in other toolkits.  Therefore, the WSD author 
specifies the operation name feature URI as
"http://www.example.org/wsdl/operation-name-features#custom-app-specific",
which indicates that the operation name mapping mechanism is defined in the 
application semantics.  It may make sense for this WG to define such a 
standard feature/URI for use in these cases, and clearly document it that 
SHOULD NOT be used in cases 1 or 2 above.

On the other hand, if the service assigns no meaning whatsoever to the 
wsdl:operations, i.e., if the grouping of messages into operations is 
completely arbitrary, then the requirement to specify the operation name 
mapping mechanism would seem to place an unnecessary burden on the WSD 
author.  However: (a) to some extent I think the use of meaningless 
wsdl:operation groupings goes against the intent of WSDL; and (b) the 
requirement would be trivially satisfiable anyway, by specifying the feature as
http://www.example.org/wsdl/operation-name-features#custom-app-specific
(or whatever we call it).


At 10:59 AM 7/27/2004 -0400, Amelia A Lewis wrote:

>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

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Tuesday, 27 July 2004 18:31:46 UTC