- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Feb 2011 16:39:14 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11964
Michael Rys <mrys@microsoft.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrys@microsoft.com
--- Comment #2 from Michael Rys <mrys@microsoft.com> 2011-02-04 16:39:13 UTC ---
(In reply to comment #1)
> While on the subject of casting to QName, it occurs to me that one might expect
> cast @xsi:type to xs:QName
> to use the namespace context of the xsi:type attribute node, rather than the
> static context of the query. In fact, using the static context of the query
> here seems distinctly wrong. There are two things we could do, both involving
> some sacrifice of orthogonality (though not as severe a departure as the rule
> about string literals in 2.0):
> (a) ban atomization of the operand of cast|castable if the target type is
> namespace-sensitive
> (b) use a customized variation of the atomization rules for the operand of
> cast|castable, whereby if the operand is a node and the target type is
> namespace sensitive then the namespace context used is that of the node. (This
> is similar to the behaviour of the document() function in XSLT, which uses the
> base URI of the supplied node when the argument is a node, before atomizing it
> as normal).
I agree that these two are the right options, but I am strongly favoring option
(a). I think it makes little sense supporting this and having to carry around
all in-scope namespaces for every node for such a rare and meaningless query
seems like too much overkill.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 4 February 2011 16:39:15 UTC