W3C home > Mailing lists > Public > www-ws-desc@w3.org > December 2003

Re: Two logical WSDL documents describing the same service

From: David Booth <dbooth@w3.org>
Date: Thu, 18 Dec 2003 11:04:01 -0500
Message-Id: <5.1.0.14.2.20031218105646.0324a210@localhost>
To: www-ws-desc@w3.org
Cc: Amelia A Lewis <alewis@tibco.com>, Paul Downey <paul.downey@bt.com>

It now looks to me like this is actually the same as issue #93[1], just 
approached from a different perspective, and it looks like our Oct 2 
decision[2] to mention it in the Primer is consistent with my analysis below.


1. Issue 93: http://www.w3.org/2002/ws/desc/2/06/issues.html#x93
2. Oct 2 call:  http://tinyurl.com/324da (find "uniqueness")



At 10:22 PM 12/17/2003 -0500, David Booth wrote:

>At the last WS Architecture F2F meeting, a question arose about whether 
>the WSDL 2.0 specification has anything to say about a single service 
>being described by two different WSDL documents.  I took an action to 
>write to the WSD WG to ask.
>
>The question arose in the context of discussing WS Management: A single 
>service wishes to expose a functional interface for its regular users, but 
>it also wishes to expose a management interface.  Since a Web service 
>description (WSD) in WSDL 2.0 is not allowed to specify more than one 
>wsdl:interface, one obvious approach would be to write two WSDL documents 
>that define different interfaces -- a functional interface and a 
>management interface -- but that specify exactly the same targetNamespace 
>and service name, so they are describing the same service.  In fact, they 
>might even specify the same endpoint address.
>
>This problem may sound familiar, because it's exactly the problem that the 
>proposed @targetResource attribute was intended to address.   But in this 
>case it skips the additional attribute.
>
>At present, our Part1 document says that you cannot have two interfaces 
>for the same service.  HOWEVER, my understanding of the context of that is 
>that it pertains only to a *single* logical WSDL document[1] -- not 
>multiple logical WSDL documents.  (By "logical WSDL document" I mean the 
>infoset or WSDL components obtained from a single WSDL document and any of 
>its includes, imports, etc.  See [1] if you're unclear about what I mean 
>.)  Since this issue of single versus multiple logical WSDL documents[1] 
>has only recently been raised, I don't think we've addressed the question 
>of multiple logical WSDL documents describing the same service in this context.
>
>My own reasoning about this is as follows.
>1. The WSDL 2.0 spec should only define the meaning of any *single* valid 
>sentence in the language, i.e., only any *single* logical WSDL document.
>2. Therefore, the WSDL 2.0 spec should have nothing to say about the 
>meaning or validity of two logical WSDL documents (each independently 
>valid) when considered together.
>3. In the Web in general, it is entirely normal to have multiple documents 
>that describe the same resource.  Each such document may add to your 
>knowledge of that resource.  Furthermore, following an "open world 
>assumption", you should never assume that you know *everything* about a 
>particular resource.  The idea of having two WSDL documents that describe 
>the same resource seems entirely consistent with this view.
>4. Therefore, I see nothing wrong with using two logical WSDL documents to 
>describe the same service, even if those documents specify different 
>interfaces.  If someone wants to create a PrinterService whose 
>PrintDocument interface is defined in one WSDL document, but whose 
>ManagePrinter interface is defined in another WSDL document, they are free 
>to do so.
>
>Do others agree with this analysis?
>
>
>1. http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0085.html
>
>
>
>--
>David Booth
>W3C Fellow / Hewlett-Packard
>Telephone: +1.617.253.1273

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Thursday, 18 December 2003 11:06:38 GMT

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