- From: Michael Kay <mhk@mhk.me.uk>
- Date: Fri, 20 Feb 2004 16:58:44 -0000
- To: <public-qt-comments@w3.org>
- Cc: <w3c-xsl-wg@w3.org>
> > Section 11.1.4 > > The second bulleted list reads as follows: > > << > When a literal result element is processed, its namespace nodes are > handled as follows: > > o A namespace node whose string value is a literal namespace URI is > not copied to the result tree. > > o A namespace node whose string value is a target namespace URI is > copied to the result tree, whether or not the URI identifies an > excluded namespace. > >> > > This seems to be a change from XSLT 1.0. We discussed this change at the Bangkok meeting. In a previous 2.0 draft we had inserted a clause that attempted to remove the ambiguity in the 1.0 specification as to whether the rules for excluding namespaces when literal result elements are copied applied to the URIs before aliasing or after aliasing. Further analysis (and, IIRC, a comment from Oliver Becker) showed that this fix didn't work. We felt we needed predictability of the prefixes used in the result tree to handle the case where the generated stylesheet contains a construct like select="system-property('xsl:version') This change means that when you write <xsl:namespace-alias stylesheet-prefix="axsl" result-prefix="xsl"/> then you will normally end up with the "xsl" prefix being declared in the result document, and with the "axsl" prefix not appearing in the result document, which is what most people would instinctively assume. (I say "normally", because you might get different results if the namespace declaration of the result prefix "xsl" isn't in scope for the literal result element being copied: but this is unusual, normally both namespace declarations will be in scope, so this rule makes it clear that one is copied and the other isn't). > In XSLT 1.0, a namespace node > whose string value was declared to be an alias for another > resulted in a > namespace node in the result tree whose string value was the > correspond URI. Yes; but the problem was that it wasn't clear what the name of this namespace node should be, i.e. what namespace prefix should be used. The text quoted above indicates that no such > translation will occur > in XSLT 2.0. If this change in semantics was not intended, > the quoted > text could be replaced with the following: > > << > A namespace node whose string value is a literal namespace > URI will not be > copied to the result tree; instead a namespace node whose > string value is > the corresponding target namespace URI will be produced > >> > I think that the new text is correct, that it solves the ambiguities in the 1.0 specification, and that it does what most users expect and what most 1.0 implementations actually do (Saxon being a notable exception...) If you're not comfortable with this, we need to put it on the WG agenda for discussion. I'm leaving it open for now. Regards, Michael Kay
Received on Friday, 20 February 2004 11:58:03 UTC