Re: service name as local part of a qname

Sanjiva Weerawarana wrote:
> 
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >
> > +1 to making the change both to the uniqueness of the port@name
> > (discussed earlier at [1]) and to removing the wording that implies that
> > it must not be reference-able as a QName.
> 
> Note that the "it must not be referenceable as a QName" restriction
> does NOT go away with this change. In fact, it becomes even more
> critical.
> 
> To be able to refer to directly point to a port via a QName, one
> would have to require portNames to be unique across the entire
> namespace. IMO that's the wrong direction ..

+1 on making port names explicitely non-qualified.

As far as the wording is concerned, though, I don't like the current one much:

"Note that while the name property is of type NCName, it SHALL NOT
be used as the localPart of a qualified name with the targetNamespace
of the containing descriptions group as the namespace name."

Having "note that..." and "SHALL NOT" in the same sentence seems strange,
and it isn't clear whom this warning is addressed to. Can we simply replace
"SHALL NOT" with "cannot" and leave it to other sections to make it
explicit that port names don't map to QNames?

For instance, we can change the paragraph in section 2 that deals with
QName resolution to include a list of all symbol spaces (and there would
not be a "port" symbol space).

Moreover, the abstract model will list properties for each component,
and I'm guessing that a "port description component" will have a [name]
property but no [namespace name] one, so that making a QName for it
will be out of question.

By the way, I'm not advocating putting these changes in the current
draft. I think it's better to wait until more of the abstract model
is in place.

Roberto

Received on Thursday, 4 July 2002 11:34:12 UTC