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

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

From: Jacek Kopecky <jacek.kopecky@deri.org>
Date: Thu, 12 Aug 2004 11:01:50 +0200
To: Paul Downey <paul.downey@bt.com>
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1092301307.4993.12.camel@Kalb>

Paul, objecting minority,

The problem I see with dispatching upon policy is that the client has no
idea which of the multiple operations with the same on the wire message
contents is in effect and also which of the potential different result
messages it can expect back (this can be appropriately modified for
non-req-resp patterns).

As a client, I'd like to be sure that it's operation A (and none
different) that is in effect, especially if I choose to ascribe
different semantics to different operations at the endpoint. Of course
one could view the situation that from the initiator's point of view,
both (or all) ambiguous operations could be viewed as a single one with
an out-of-bound switch between the various result formats, but then I
believe it should also be modeled as a single WSDL operation.

On this issue, I agree with the status quo that describing the dispatch
mechanism is good and mandatory.


On Thu, 2004-08-12 at 10:33, paul.downey@bt.com wrote:
> Mark wrote:
> > I'm confused.  There's always an operation, no?  
> > Sometimes what's in the message isn't the "name" per se, 
> > but there's always some token in the message envelope 
> > that can be mapped to some spec which describes the
> > operation's semantics.  
> my understanding of this issue is that it is possible to 
> dispatch messages to two different operations that accept 
> exactly the same message contents based upon something 
> completely out of band, e.g. i've credit left in my account, 
> it's raining, we're now at war. That's dispatching based
> upon /policy/ rather than /description/.
> Paul
Received on Thursday, 12 August 2004 09:02:23 UTC

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