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

RE: is the uniqueness constraint on top level components sufficient?

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Fri, 19 Sep 2003 11:29:56 -0700
Message-ID: <7C083876C492EB4BAAF6B3AE0732970E0CAF9B18@red-msg-08.redmond.corp.microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>

Our spec only deals with a single definitions container at a time. It
has nothing to say about constraining the content of two disjoint
definitions containers ( and I'm unsure how we would ever enforce such
constraints ). 

So for any given WSDL processing episode, there is one definitions
container that may draw its components from multiple locations ( via
include and import ). All the top-level components within that
defintiions container must have unique names within their symbol space.


> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: 19 September 2003 11:21
> To: Martin Gudgin; www-ws-desc@w3.org
> Subject: Re: is the uniqueness constraint on top level 
> components sufficient?
> Hi Gudge,
> > I think you will find that as far as our spec is concerned there is 
> > always EXACTLY ONE definitions container even in cases where the 
> > contents of that container came from multiple locations.
> That's for included or imported stuff right? Is there 
> anything in the spec which says that *all* stuff for the 
> target namespace are part of EXACTLY ONE definitions 
> container? If so then we're in business. If not its certainly 
> possible for two documents to point to the same namespace yet 
> not be aware of each other:
> <definitions targetNamespace="http://www.ibm.com/">
>    ... stuff for one service ...
> </definitions>
> <definitions targetNamespace="http://www.ibm.com/">
>    ... stuff for another service ...
> </definitions>
> Sanjiva.
Received on Friday, 19 September 2003 14:29:57 GMT

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