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:15:49 -0700
Message-ID: <7C083876C492EB4BAAF6B3AE0732970E0CAF9AD1@red-msg-08.redmond.corp.microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>

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.


> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Sanjiva Weerawarana
> Sent: 19 September 2003 01:59
> To: www-ws-desc@w3.org
> Subject: is the uniqueness constraint on top level components 
> sufficient?
> In the current draft, we say:
>       <p> For each Binding component in the {bindings} property of a
>       definitions container, the combination of {name} and {target
>       namespace} properties must be unique.  </p>
> (And similarly for Interface and Service components, the 3 
> top-level components within <definitions> that are of concern 
> for this issue.)
> Thus, we only require that the QName of an interface, a 
> binding or a service be unique WITHIN the definitions 
> container they're in. 
> That is, we don't say its not ok for two <definition>s for 
> the same target namespace to define two different interfaces 
> and call give them both @name="foo".
> I think that's not sufficient - we should say that the QName 
> MUST be unique, period. That is, its no koshure to define two 
> bindings with the same QName, for example. 
> Yes I realize totally that there's no way to enforce that. 
> However, without such a constraint referring by QName, from a 
> binding to an interface say, is not guaranteed to be correct. 
> Thoughts? Can we please track this with an issue #? 
> Thanks,
> Sanjiva.
Received on Friday, 19 September 2003 14:15:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:44 UTC