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

Looks like I've been out-voted, but let me whether I can explain
why I think we need to put some more clarification. I am *not*
looking for a way to check or test whether QNames are indeed
unique, but it is fully within our purview to say that they
must be. If we say that then someone receiving a WSDL component
QName and resolving it to a component with that name has some
reason to believe they've got the right one: the WSDL spec says
it must be so. If we don't require it, there is no such confidence.

Let's say I'm writing a BPEL thing and want to refer to a WSDL
interface (portType today). BPEL will refer to it by QName, a:foo.
Now "somehow" the BPEL process will find the portType named a:foo
from a WSDL. How does it know it indeed got the "right" one named
a:foo? If the WSDL spec says that there must only be one portType
named a:foo then that provides some confidence that it did indeed
get the right one. Now, the owner of the a: namespace could've
of course screwed up and allowed two a:foo's to exist but that's
that guy's fault. At least the WSDL spec says that's not legal.

The wording we currently have doesn't preclude one from naming
two different interfaces a:foo. What I'd like to do is tighten
that wording so that the spec says that QNames of top level WSDL
components MUST be unique period. I am happy to even add a note
saying "we realize this is not testable and that its totally
up to the owner of the namespace to enforce it."

Anyone crossing over to my camp?


----- Original Message -----
From: "David Orchard" <>
To: "'Roberto Chinnici'" <Roberto.Chinnici@Sun.COM>; "'Sanjiva Weerawarana'"
Cc: "'Martin Gudgin'" <>; <>
Sent: Saturday, September 20, 2003 2:28 AM
Subject: RE: is the uniqueness constraint on top level components

> Indeed, I agree with gudge and roberto.  Seems like it's the
> of the ns owner to figure out the names, vocabularies and languages within
> it's namespaces.  Using URIs for ns names at least makes it very clear
> the domain authority is.  Now if we had better RDDL support, it might be
> easier to check what sanjiva wants.  And I think that's the route to go.
> For now, I think the constraints on names are reasonable.
> Cheers,
> Dave
> > -----Original Message-----
> > From: []On
> > Behalf Of Roberto Chinnici
> > Sent: Friday, September 19, 2003 11:33 AM
> > To: Sanjiva Weerawarana
> > Cc: Martin Gudgin;
> > Subject: Re: is the uniqueness constraint on top level components
> > sufficient?
> >
> >
> >
> > Sanjiva Weerawarana wrote:
> > > 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="">
> > >    ... stuff for one service ...
> > > </definitions>
> > >
> > > <definitions targetNamespace="">
> > >    ... stuff for another service ...
> > > </definitions>
> >
> > I don't think that adding an untestable requirement of this kind to
> > the spec does any good. If somebody wants to have two WSDL documents
> > for the same target namespace, so be it. The burden to be
> > extra-careful
> > in their definitions falls on them.
> >
> > Roberto
> >
> > --
> > Roberto Chinnici
> > Java Web Services
> > Sun Microsystems, Inc.
> >
> >
> >

Received on Friday, 19 September 2003 17:32:13 UTC