[DM] Expanded QName as a triple

I'd like to float a slightly radical idea in order to reduce our
problems handling QNames: we should treat an expanded QName as a triple
consisting of a prefix, uri, and local name.

The typed value of a QName-valued node would retain the original prefix
in rather the same way as a date/time value retains the timezone:
something that does not contribute to equality testing but is available
for use when converting back to a string. In retaining information
beyond what XML Schema considers to be the value space, we thus have a
precedent.

All operations on QNames work unchanged, they ignore the prefix. Except
for casting to string, which returns the prefix:local-name
representation.

This reinstates the ability to cast a QName to a string. The result may
not be very meaningful, because there is no way of knowing what the
prefix refers to; but it means that every atomic value can be cast to a
string without a failure and without any dependency on the context,
which makes life a lot easier. It means, for example, that writing a
QName-valued attribute such as xsi:type="{$qname}" will work, provided
that the user takes care to ensure the prefix is declared in the result
tree, whereas at present it always fails.

This doesn't solve the problem of converting a lexical QName to an
expanded QName, which can still only be done by providing a namespace
context. Therefore, I think we should continue to say that casting from
string to QName is not supported.

Making expanded-QName into a triple would suggest some changes to F+O:

(a) the expanded-QName() function should require a prefix to be supplied
(b) the node-name() function should establish a prefix (in the same way
as name()) alongside the local name and URI.

The fact that a prefix is present in the value doesn't mean that it has
to be used by all operations. For example, it doesn't constrain the
serializer to use this particular prefix.

Everything said here applies to xs:NOTATION as well as xs:QName, of
course.

Michael Kay

Received on Tuesday, 3 February 2004 09:15:35 UTC