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

 

> -----Original Message-----
> From: Amelia A Lewis [mailto:alewis@tibco.com] 
> Sent: 13 July 2004 17:03
> To: Martin Gudgin
> Cc: www-ws-desc@w3.org
> Subject: Re: Action Item 2004-07-01 Solution to 168/R114
> 
> On Tue, 13 Jul 2004 07:13:53 -0700
> Martin Gudgin <mgudgin@microsoft.com> wrote:
> > > From: www-ws-desc-request@w3.org 
> > > [mailto:www-ws-desc-request@w3.org] On Behalf Of Tom Jordahl
> > > Sent: 13 July 2004 15:05
> > > To: 'WS Description List'
> > > Subject: RE: Action Item 2004-07-01 Solution to 168/R114
> > > I would much prefer that WSDL 2.0 does not allow this 
> > > situation to occur. 
> > 
> > Then WSDL 2.0 will not be able to describe a certain class 
> of service.
> 
> Which is a deep, serious problem.

Oh yes!

> 
> > > As
> > > I read the requirement (114), we are tasked with providing a 
> > > mechanism to
> > > ensure that this does not occur.
> > 
> > Then I think the requirement is wrong.
> 
> In fact, Tom's interpretation of the requirement is not 
> necessarily the
> correct one.  
> R114 may be taken to read as "permit authors to indicate
> this" rather than "require authors to indicate this".  

I agree with you. However, I note David Booth said, earlier in this
thread:

"However, I think the precise wording of R114 is somewhat irrelevant.
The 
real question is what does the WG think we need."

> If it 
> is "permit",
> we're done.  

Yes, in this case RPC style is sufficient.

> If it is "require", then there will be 
> significant opposition
> to selection of any particular dispatch algorithm, which in turn means
> that the indication of a dispatch algorithm must be "open", 
> which means
> that I can define mine as "none://of.your/business/".
> 
> The client can trust that the service *will* dispatch the message,
> somehow.  How, is not information necessary to the client.

Absolutely!

Gudge

> 
> Amy!
> -- 
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> alewis@tibco.com
>

Received on Tuesday, 13 July 2004 12:12:13 UTC