RE: simple case of IRIs for Components in WSDL 2.0

Would you be satisfied with adding a note along the lines of the
following:

"Note that the component designators given below are only one form of
identifier for WSDL components.  Other forms can be used.  For instance,
using targetNamespace#name is sufficient when out-of-band mechanisms can
be relied on to ensure no names are the same (across all symbol spaces)
within a WSDL component model.  Such a mechanism cannot be relied for
general purpose use as is the one defined below."

Trying to cast this as a concrete initial proposal the WG could
deliberate...

> -----Original Message-----
> From: Dan Connolly [mailto:connolly@w3.org]
> Sent: Monday, September 12, 2005 11:41 AM
> To: Jonathan Marsh
> Cc: public-ws-desc-comments@w3.org; Bijan Parsia; Henry S. Thompson
> Subject: RE: simple case of IRIs for Components in WSDL 2.0
> 
> On Mon, 2005-09-12 at 11:34 -0700, Jonathan Marsh wrote:
> > Are you suggesting that the form of the component identifier should
> be
> > dependent upon what other (local) identifiers are in the document?
> That
> > we should define an identifier to a component that might lose its
> > property of unique identification when other (unrelated but
> perfectly
> > legal) components are added to the document?
> 
> Yes.
> 
> > This might be possible when you're trusting some infrastructure like
> > Schemas, DTDs or xml:id to ensure no duplicate identifiers occur,
> but in
> > our case duplicates (between symbol spaces) are completely legal.
> 
> I'd recommend that people don't use the same name for different
> things in the same WSDL document; at least: not if they want
> nice URIs for them.
> 
> > Your suggestion seems quite unstable in the face of WSDL evolution
> and
> > the distribution of components between multiple documents, the full
> > combination of which might not be available until runtime.
> 
> I'm aware of those risks and I think they're manageable.
> 
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 12 September 2005 18:49:59 UTC