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

 

> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Mark Baker
> Sent: 13 July 2004 15:34
> To: Tom Jordahl
> Cc: 'WS Description List'
> Subject: Re: Action Item 2004-07-01 Solution to 168/R114
> 
> 
> +1.  The type of service this is meant to describe is an 
> architecturally
> abhorrent one to me, since it's objective appears to be to remove
> important self-descriptive features from messages for no 
> apparent gain.

No. It's objective is to point out that the service itself is in charge
of message dispatching, not the W3C WSDL WG.

> Nothing but interoperability problems can result from such an 
> approach,
> IMO.

I don't see any such problems. The WSDL tells you what messages the
service accepts and what messages the service emits. What more is
needed?

> 
> If you want to send messages without operations in them, the 
> operations
> have to be implicit via some bit in the message, e.g. the TCP port.

Or a value being > or < 1000?

> There's *always* an operation.  Pretending there isn't one by removing
> it from the message only makes things worse.

I'm not pretending there is no operation. I'm just saying that it's up
to the service how it determines which operation to perform.

Gudge

> 
> On Tue, Jul 13, 2004 at 10:05:05AM -0400, Tom Jordahl wrote:
> > 
> > Gudge,
> > 
> > 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.
> 
>

Received on Tuesday, 13 July 2004 11:03:35 UTC