Re: Two logical WSDL documents describing the same service

On Thu, 18 Dec 2003 15:56:51 +0000
paul.downey@bt.com wrote:

> Amy
> 
> I'd anticipate being able to publish several versions of the same
> schema with the same namespace - so as not to break existing users of
> a Web service.
> 
> All of these schemas could be used to validate documents exchanged
> using the same namespace. The later versions would contain more detail
> added at xs:any points in the earlier schemas. 
> 
> AIUI you're concerned that there isn't a formal way of distinguishing
> these separate versions apart from the namespace ?

That's one problem, but for the scenario that you describe (which you
indicate is based on David Orchard's advice on how to version W3C XML
Schema) is different than the scenario which David Booth describes.

David Orchard, and by extension you, suggest that a namespace need not
change if backward and forward compatibility is maintained.  That's
fine.  David Orchard also suggests that when the schema (in our case,
interface) changes incompatibly, then the namespace *must* change, so
that the software breaks early.

I think that multiple incompatible interfaces, as described in David
Booth's proposal, are equivalent to multiple incompatible schemata,
which, in David Orchard's article, requires a change of namespace.

Amy!
> 
> Paul
> 
> 
> 
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Amelia A Lewis
> Sent: 18 December 2003 15:19
> To: David Booth
> Cc: www-ws-desc@w3.org
> Subject: Re: Two logical WSDL documents describing the same service
> 
> 
> 
> 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
> 


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

Received on Thursday, 18 December 2003 11:06:58 UTC