RE: TAG Finding: Using Qualified Names (QNames) as Identifiers in Content

> MK> I think that identifying QNames using the schema type 
> xs:QName is a 
> MK> very partial solution, as the document notes, it fails to 
> catch many 
> MK> cases where QNames (or more generally, namespace prefixes)
> 
> 
> "namespace prefixed' seems less general. Qname implies a 
> tuple of local name and namespace URI, connected together 
> syntactically by a namespace prefix.

What I was trying to say is that the problem applies to any value that
contains a namespace prefix, for example the xsl:exclude-result-prefixes
attribute in XSLT whose value is a space-separated list of namespace
prefixes. Values that contain QNames are just a special case of values
that contain namespace prefixes.
> 
> "namespace prefixed' merely refers to one syntactic aspect of that.
> 
> MK> A more powerful approach would be for XML Schema to introduce a 
> MK> boolean facet, "uses-namespace-prefixes", which could be 
> attached to 
> MK> any value that depends on the namespace context...
> 
> That would be a valuable addition (any you always know which 
> namespace it depends on, surely - the one that is bound to 
> the prefix in question in the scope of that element) but 
> having it as a facet does introduce ambiguity because some 
> combinations of facets will be unclear. Take an attribute 
> typed as anyURI with the "uses-namespace-prefixes" facet set to true.

I would assume that the facet would only be applicable to certain types,
of course it wouldn't make sense to apply it to (say) an integer or an
anyURI, while it would make sense to apply it to String or to NCName.

I wasn't suggesting that the prefix has to appear at the start of the
value. For example an attribute containing an XPath expression would
have this facet, but only an application understanding XPath syntax
could determine which namespace prefixes are actually present in the
value.

MK> Another way of mitigating the problem is to define a lexical 
MK> representation of the value space of QNames, for example the form 
MK> "{namespace-uri}local-name", that is independent of the namespace 
MK> declaration context. (The above form has been adopted in the Java 
MK> JAXP
MK> interface.)


>That sort of disambiguating syntax would be a great suggestion if the
situation were 
>not, as has been pointed out, one where there is significant deployment
of genies in 
>extra-bottle situations.

I think it could still be helpful. Standardising a lexical
representation of expanded QNames, allowing them in the lexical space of
the QName data type, and recommending that they be allowed in any
context where a QName is allowed, would at least provide a way of
creating context-free values (such as XPath expressions) that could be
copied around. Software would still have to be able to read
namespace-dependent content, but at least it would no longer have to be
able to write it (which is much more difficult, as users trying to
generate schemas using XSLT will testify).

Michael Kay

Received on Tuesday, 9 July 2002 08:58:40 UTC