Bug #1595
closed
Namespace issue with relative XPath for result documents
Description
To a small test I have added three xsl:result-document instructions selecting the same element to illustrate the issue. The first one results in
WARNING: The following-sibling axis starting at a document node will never select anything
WARNING: result-document target not found for href: ?select=following-sibling::html:div context node: a
WARNING: result-document target not found for href: ?select=../html:div context node: a
Windows XP, Saxon-CE 1.0, file:// protocol
Files
- Status changed from New to In Progress
- Assignee set to Philip Fearon
- Priority changed from Low to Normal
- Found in version set to 1.0
Thanks for reporting this.
Some restrictions are imposed on the evaluation context for XPath expression within the href attribute - I'm not entirely sure of the history behind this.
An example of another restriction is that variables can't be referenced with the ?select= expression.
The simplest way to work around such restrictions is to enclose the xsl:result-document instruction within an xsl:for-each instruction which you can use to set the context node. Currently the xsl:result-document Saxon-CE documentation states:
bq. For elments [sic] in a namespace such as XHTML or SVG, ensure the appropriate namespace context is provided
Until there's any change to the implementation, I will modify this documentation to make it clearer what this actually means in practice
I just verified the problem with http:// protocol, same messages. Agreed, the documentation is a bit vague on this; it could also be helpful to note what happens if there is no xsl:result-document instruction (or no effective): elements are added at the bottom of the body element (after the @iframe@).
- Status changed from In Progress to Won't fix
Closing remaining Saxon-CE issues as "won't fix" since the product is now superseded by Saxon-JS and there is no plan to do any further maintenance.
Please register to edit this issue
Also available in: Atom
PDF
.