Project

Profile

Help

Bug #1810

SXST0063: Template body is an expression that returns nodes from the streamed input document

Added by Michael Kay over 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Streaming
Sprint/Milestone:
-
Start date:
2013-06-15
Due date:
% Done:

100%

Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Found in version:
9.5
Fixed in version:
9.5.1.3

Description

When a streamable template consists solely of an xsl:result-document instruction, the spurious error

SXST0063: Template body is an expression that returns nodes from the streamed input document

is output.

History

#1 Updated by Michael Kay over 3 years ago

The immediate cause is that method ExpressionInverter.returnsStreamedNode() returns true.

The problem can be fixed for this case by changing this method to extend the test for "type = atomic" to "type disjoint with node". Since result-document returns nothing, this test will cause the method to return false.

However, this doesn't seem to address the root cause of the problem. The code for computing the path map of the result-document instruction seems wrong (in fact, it's using a default implementation). Looking at the path map of xsl:element and xsl:document, that seems to be better, but still not quite right. Unfortunately the path map code is complex, has been unchanged for a long time, and there aren't many tests that will show it up if it's wrong; so changing it is precarious. For 9.5 I'll put in the immediate fix above and leave the deeper problem to fester for a while.

#2 Updated by Michael Kay over 3 years ago

  • Status changed from New to Resolved

Marking this resolved as the immediate problem is fixed.

#3 Updated by O'Neil Delpratt over 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.5.1.2

Bug fix applied in the Saxon 9.5.1.2 maintenance release

#4 Updated by Michael Kay about 3 years ago

  • Status changed from Closed to Resolved

Another test case was raised that showed this still wasn't working properly. The pathMap code is very obscure, and its primary use for XQuery document projection might have slightly different requirements from the way XSLT is using it for streamability analysis. The xsl:result-document instruction is a bit of an anomaly because it doesn't return anything, and of course it doesn't get used in XQuery. So for the moment I've generated a path map for xsl:result-document that 's consistent with what xsl:element and xsl;document do, and this seems to fix the problem.

#5 Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • Fixed in version changed from 9.5.1.2 to 9.5.1.3

Big fix applied in the Saxon 9.5.1.3 maintenance release.

Also available in: Atom PDF