"Thinking longer-term, could we persuade Schema to add the Clark
representation of expanded QNames (that is "{uri}local") as a valid (and
canonical) lexical representation of the xs:QName data type? This would
make a lot of problems go away."
+100. And make it as a revision to XSD 1.0 (3rd edition)....
Michael
________________________________
From: w3c-query-operators-request@w3.org
[mailto:w3c-query-operators-request@w3.org] On Behalf Of Kay, Michael
Sent: Wednesday, September 24, 2003 2:52 PM
To: XPath Operators TF (w3c-query-operators@w3.org);
w3c-xml-query-wg@w3.org; w3c-xsl-wg@w3.org
Subject: ACTION A-TORONTO-06 Replacement for casting QName to string
ACTION A-TORONTO-06 MikeK to prove that the Qname to string cast
function can actually be written as a user-defined function.
Summary: (a) it can't be done.
(b) I don't think it needs to be done.
We removed the function that made it possible. With cast of
QName-to-string gone, the only thing in XPath that uses the static
namespace context is casting string-to-QName. (There are plenty of
things in XQuery and XSLT that use the static namespace context, but
only one now in XPath.)
Let's be clear what we are talking about. If the value of the QName is
known statically, e.g. if it's known to be {my.foo}bar, then the
programmer knows whether there is a prefix declared in the query for
xmlns:p="my.foo"; if there isn't, then he declares one, and he can then
write the string as a literal "p:bar".
The case of interest is where the QName isn't known statically. This
means that either the namespace URI or the local name isn't known
statically.
If the namespace URI is known statically but the local name isn't, the
programmer again knows the prefix for the namespace and can write
concat('foo:', $local).
If the namespace URI isn't known statically, then in my view it is
rather unlikely that there will be a namespace declaration for it in the
static context. As a worst case, the programmer knows all the namespaces
that have been declared, and can test them in turn:
let $prefix := if ($uri="my.foo") then "foo"
else if ($uri="your.foo" then "yfoo" ...
Having gone through this exercise, the result is a string that's not
good for any purpose other than casting it back to a QName (which will
only work if you do it in exactly the same static context).
My conclusion is that I don't think there is a plausible use case for a
facility that tries to look up a dynamic namespace URI in the static
namespace context. So the fact that it can't be done doesn't matter.
If anyone does feel we need programmatic access to the in-scope
namespaces, I would propose providing variants of the two functions
get-in-scope-prefixes() and get-namespace-for-prefix() in which the
$element parameter is omitted, with the semantics that when the $element
is omitted, the static in-scope namespaces are searched instead of the
namespaces for the specified element.
Converting a QName to a string (ignoring error cases) would then be done
as:
concat(
get-in-scope-prefixes()
[get-namespace-for-prefix(.) =
get-namespace-uri-from-QName($qname))][1],
':',
get-local-name-from-QName($qname)
)
Thinking longer-term, could we persuade Schema to add the Clark
representation of expanded QNames (that is "{uri}local") as a valid (and
canonical) lexical representation of the xs:QName data type? This would
make a lot of problems go away.
Michael Kay