Bug #1595


Namespace issue with relative XPath for result documents

Added by Manfred Staudinger almost 12 years ago. Updated over 6 years ago.

Won't fix
Start date:
Due date:
% Done:


Estimated time:


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


Ind_Pers_de.html (1.15 KB) Ind_Pers_de.html Manfred Staudinger, 2012-07-24 17:16
Ind_Pers_de.xsl (1.99 KB) Ind_Pers_de.xsl Manfred Staudinger, 2012-07-24 17:16
ind_pers_b.css (2.21 KB) ind_pers_b.css Manfred Staudinger, 2012-07-24 17:16
Actions #1

Updated by Philip Fearon almost 12 years ago

  • 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

Actions #2

Updated by Manfred Staudinger almost 12 years ago

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@).

Actions #3

Updated by Michael Kay over 6 years ago

  • 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