W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

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

From: Chris Lilley <chris@w3.org>
Date: Tue, 9 Jul 2002 13:29:55 +0200
Message-ID: <92337627187.20020709132955@w3.org>
To: www-tag@w3.org, "Michael Kay" <michael.h.kay@ntlworld.com>
CC: DPawson@rnib.org.uk

On Tuesday, July 9, 2002, 11:14:24 AM, Michael wrote:

MK> I have just read this [1], thanks to Dave Pawson who drew it to my
MK> attention.

MK> The document takes a reasonably pragmatic approach, recognizing that the
MK> horse has already bolted and it's too late to lock the door.

MK> I think that identifying QNames using the schema type xs:QName is a very
MK> partial solution, as the document notes, it fails to catch many cases
MK> 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.

"namespace prefixed' merely refers to one syntactic aspect of that.

MK> are used in element and attribute content.

MK> A more powerful approach would be for XML Schema to introduce a boolean
MK> facet, "uses-namespace-prefixes", which could be attached to any value
MK> that depends on the namespace context. This still doesn't fix the whole
MK> problem, of course, because when copying such a value you still don't
MK> know precisely which namespaces it depends on, so you have to copy them
MK> all, just in case. But at least it would indicate that copying the value
MK> without the namesapce context is unsafe, as is changing namespace
MK> prefixes.

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.

As an example


assume that the namespaces in scope on this element are

http://example.org/ns/http bound to http: prefix
http://example.org/ns/user bound to user: prefix
http://example.org/ns/hello bound to hello: prefix

and assume that the value of xml:base is whatever it takes to make
these more ambiguous, probably http://user:pass@example.org/some/stuff

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 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.

MK> If this form were accepted in any context where a QName is
MK> allowed (including perhaps even XML element and attribute names!) many
MK> of the problems of context-dependency could be solved more easily, for
MK> example this could form the basis of a context-free syntax for XPath
MK> expressions.

MK> Michael Kay

MK> [1] http://www.w3.org/2001/tag/doc/qnameids

 Chris                            mailto:chris@w3.org
Received on Tuesday, 9 July 2002 07:30:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC