[Bug 29231] [XT30] tests import-0001 and import-0002

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29231

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
Please hold fire on making changes here: I think the problem needs discussion.

At first glance, it seems XSLT 1.0 implied that namespace aliases applied to
the URIs in namespace nodes, as well as the namespaces in the names of elements
and attributes:

<xslt-1.0>
A namespace URI in the stylesheet tree that is being used to specify a
namespace URI in the result tree is called a literal namespace URI. This
applies to:

the namespace URI in the expanded-name of a literal result element in the
stylesheet

the namespace URI in the expanded-name of an attribute specified on a literal
result element in the stylesheet

the string-value of a namespace node on a literal result element in the
stylesheet
</xslt-1.0>

In the 2.0 spec, the third item in the list has disappeared:

<xslt-2.0>
The effect is that when names in the namespace identified by the literal
namespace URI are copied to the result tree, the namespace URI in the result
tree will be the target namespace URI, instead of the literal namespace URI.
This applies to:

the namespace URI in the expanded-QName of a literal result element in the
stylesheet

the namespace URI in the expanded-QName of an attribute specified on a literal
result element in the stylesheet
</xslt-2.0>

and 3.0 retains the 2.0 wording.

Was this change deliberate, and is it viable? Saxon appears to implement the
1.0 rule. The literal result element <out> has two in-scope namespaces, xsl and
f, and it is applying aliasing to these namespaces as well as to the element
and attribute names.

I would like to study this further before agreeing that the test case is wrong.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 22 October 2015 20:55:43 UTC