Re: Two logical WSDL documents describing the same service

Amy, 

did you by namespace mean a namespace-qualified name, that is a pair of
a (namespace) URI and a local name? I can see reasons (even other than
versioning) for splitting the description of different things in one
namespace into different physical files (that can be included in each
other), but apart from versioning I can't see a reason for different
definitions of one QName in one symbol space. And even with versioning
one has to be very careful not to break things.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Thu, 2003-12-18 at 16:18, Amelia A Lewis wrote:
> Summary response: disagree.
> 
> From the point of view of a catalog or register, the distinguishing
> characteristic of a service description is its namespace.  As each new
> namespace is encountered, it is added to a cache, map, registry, etc.
> which provides access to the service description by its namespace.
> 
> Redefining the same namespace results in a clash.  If a
> catalog/registry/whatsit user says "what's this namespace http://joe?"
> expecting a single answer, the registry/catalog/whatsit either picks one
> (which may be the wrong one), or provides some sort of error that
> indicates "more than one exists".  This leaves the requester expected to
> disambiguate the result, at best, and at worst leaves the requester with
> a 50% chance of receiving the wrong description.
> 
> WSD WG probably can't mandate that each namespace be unique (although
> that's a pretty clear expectation for namespaces, on the whole, when no
> recommendation is made as to how to "combine" different documents that
> define the same namespace), since we deal with a single description at a
> time.  Possibly a registry/catalog/baz API/description/recommendation
> could clarify this.  But, given that the only available identifier is
> now considered to be an incomplete identifier, it would be nice to know
> what sort of other data should be used to disambiguate.
> 
> Amy!
> (in late-breaking news, I consider the single-interface restriction on
> services to be a broken design; many will be *shocked* to learn of this,
> I'm certain)
> On Wed, 17 Dec 2003 22:22:59 -0500
> David Booth <dbooth@w3.org> 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
> > 
>

Received on Sunday, 4 January 2004 10:03:55 UTC