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

RE: Action Item 2004-07-01 Solution to 168/R114

From: Tom Jordahl <tomj@macromedia.com>
Date: Tue, 13 Jul 2004 10:05:05 -0400
Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB08E847C7@S1001EXM02.macromedia.com>
To: "'WS Description List'" <www-ws-desc@w3.org>


I understand your scenario, but I don't like it.  It's icky. :-)

I would much prefer that WSDL 2.0 does not allow this situation to occur. As
I read the requirement (114), we are tasked with providing a mechanism to
ensure that this does not occur.

I am fairly agnostic about how we accomplish this, I think I would prefer
unique GEDs (and I voted for that) but I am also willing to support
Sanjiva's SOAPAction oriented (for the SOAP binding) proposal.  

I am not so much in favor of a features and properties based approach
however, as I believe this would create interop problems from day 1.

Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Martin Gudgin
Sent: Tuesday, July 13, 2004 6:01 AM
To: David Booth; Jeffrey Schlimmer
Cc: Umit Yalcinalp; WS Description List
Subject: RE: Action Item 2004-07-01 Solution to 168/R114

Let's take an interface with operations B and C both of which have the
same input message, X. Operation B has an output message Y, while
operation C has a different output message Z. Both B and C use the
In-Out pattern.  Whether you get message Y or Z back depends on the
content of X. Let's for the sake of argument say that if a particular
value in X is over 1000 you get Z, otherwise you get Y.

I believe that this is a coherent (if somewhat simplistic) example in
messaging systems. I also understand that it does not fit particularly
well into the RPC style. And that the WSDL does not describe the details
of how the server determines whether to send Y or Z. C'est la vie. There
is still enough information in the WSDL to construct messages that the
service will accept and to deconstruct messages the service will emit,
that is to interoperate with the service.

Some of you are wondering what happened to operation A. But that's
another story...


Received on Tuesday, 13 July 2004 10:05:41 UTC

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