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

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

From: David Booth <dbooth@w3.org>
Date: Tue, 13 Jul 2004 17:50:00 -0400
Message-Id: <5.1.0.14.2.20040713140809.041dbe80@localhost>
To: "Martin Gudgin" <mgudgin@microsoft.com>, "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "WS Description List" <www-ws-desc@w3.org>

At 08:44 AM 7/13/2004 -0700, Martin Gudgin wrote:
>. . . I'm happy with anything that is OPTIONAL, I'm just not happy mandating
>that the service expose internal implementation details... . .

Are they REALLY internal implementation details?  If so, then I see no 
problem.  But if the requester agent needs to follow the same convention C 
as the provider agent in order properly use the service, then those 
implementation details emphatically are NOT "internal".

The key question is whether convention C is engaged with the provider 
entity's explicit knowledge and intent, such that the provider entity is 
likely to document its use in the application semantics documentation.  If 
convention C is enabled automatically or transparently by the provider 
entity's toolkit, then it is unlikely that the application developer will 
know to document the need for it in the application semantics 
documentation, thus leading to the interop issue described in Scenario X.

Furthermore, conveying such implementation details (i.e., details that both 
parties need to know about) in a machine-processable form is one of the 
main purposes of WSDL.   Even if such information *does* appear in the 
application semantics documentation, it would be NICE if the toolkit would 
indicate the use of such details in the WSD, so that other toolkits could 
notice it and automatically engage it for requester agents, rather than 
requiring the requester entity to perform manual steps to engage it.

References
1. Scenario X: 
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html
or: http://tinyurl.com/4krve


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Tuesday, 13 July 2004 17:50:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT