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

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

From: Amelia A Lewis <alewis@tibco.com>
Date: Tue, 14 Sep 2004 13:25:29 -0400
To: Mark Baker <distobj@acm.org>
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-id: <132D0570-0673-11D9-A686-0050E416A465@tibco.com>

On Sep 14, 2004, at 1:16 PM, Mark Baker wrote:
> On Tue, Sep 14, 2004 at 01:07:13PM -0400, Amelia A Lewis wrote:
>>> But finally, without the requirement, one cannot tell whether two
>>> different services with the same binding use the same dispatch
>>> mechanism
>>> or not, if one is not explicitly mentioned. I'm slightly uneasy about
>>> this.
>> On the other hand, this gives me warm fuzzies.  The dispatch mechanism
>> (or mechanisms) used by the service are probably not properly the
>> interest of the users of the service.
> I think this is the crux of the disagreement.  IMO, that information
> is critical.  Without it, there is no contract.

I couldn't disagree more.  With it, the contract has been fouled with 
extraneous information that enforces implementation decisions on the 
service that shouldn't be exposed, much less enforced for the long 

I think we repeatedly come at this from different directions.  I 
(because my company's customers demand it) want to be able to begin to 
describe existing services, even if they do not implement best current 

As far as I can see, the backers of publicized/enforced dispatch are 
attempting to ensure that new code follows best practices, by requiring 
these practices.  As I've said before, I'd love to be in a position to 
write new code whenever I wanted, but I'm not.

It is, at best, a bloody best practice.  That's not a requirement.  
Make it a requirement, and you make it necessary to avoid it, 
effectively making *any* published information less useful, because it 
all has to be treated as potentially a lie.

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Tuesday, 14 September 2004 17:22:43 UTC

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