W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2011

[Bug 11964] Function conversion rules and QNames

From: <bugzilla@jessica.w3.org>
Date: Fri, 04 Feb 2011 16:39:14 +0000
To: public-qt-comments@w3.org
Message-Id: <E1PlOgk-0004U0-0K@jessica.w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:34 UTC