Re: Two logical WSDL documents describing the same service

Dear Jacek,

On Sun, 04 Jan 2004 16:03:52 +0100
Jacek Kopecky <jacek.kopecky@systinet.com> wrote:
> 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

Well, the answer to that is a bit complicated.

In terms of caching/cataloging, it is a *great* deal simpler if it is
possible to identify a "namespace" as a unit.  Defined in one place,
complete in one place.

It isn't absolutely required, though.  It is possible to "segment" a
namespace into pieces, and define the pieces separately.  That still
works, so long as the principle that you point out here holds: there are
not two things named identically in one namespace that are not, in fact,
identical.

The workaround for the breakage caused by the
single-interface-per-service restriction that David suggests below
simply increases the breakage.  With single-interface-per-service, it is
not possible to define a service, as he describes, that has a management
interface and a standard-use interface.  The solution is to define
multiple "services" (in the WSDL sense) to represent this single
"service" (in the web services architectural sense).  Breaking the
expectation that {ns}service is the unique service identified by the
label "service" in the namespace "ns" effectively makes namespaces
worthless.

> 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.

Agreed.

Amy!
> 
> 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
> > > 
> > 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 5 January 2004 11:03:37 UTC