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

Indeed, I agree with gudge and roberto.  Seems like it's the responsibility
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 what
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: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Roberto Chinnici
> Sent: Friday, September 19, 2003 11:33 AM
> To: Sanjiva Weerawarana
> Cc: Martin Gudgin; www-ws-desc@w3.org
> 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="http://www.ibm.com/">
> >    ... stuff for one service ...
> > </definitions>
> >
> > <definitions targetNamespace="http://www.ibm.com/">
> >    ... 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.
> roberto.chinnici@sun.com
>
>

Received on Friday, 19 September 2003 16:32:18 UTC