Project

Profile

Help

Bug #1595

Namespace issue with relative XPath for result documents

Added by Manfred Staudinger over 4 years ago. Updated over 4 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Sprint/Milestone:
-
Start date:
2012-07-24
Due date:
% Done:

0%

Found in version:
1.0
Fixed in version:

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
the second one receives a
WARNING: result-document target not found for href: ?select=../html:div context node: a
while the third, using ?select=../*[2], succeeds. To reproduce this click twice one of the letters on the left.

Windows XP, Saxon-CE 1.0, file:// protocol

Ind_Pers_de.html View (1.15 KB) Manfred Staudinger, 2012-07-24 17:16

Ind_Pers_de.xsl (1.99 KB) Manfred Staudinger, 2012-07-24 17:16

ind_pers_b.css View (2.21 KB) Manfred Staudinger, 2012-07-24 17:16

History

#1 Updated by Philip Fearon over 4 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:

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

#2 Updated by Manfred Staudinger over 4 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).

Also available in: Atom PDF