Project

Profile

Help

Bug #1763

closed

for-each-group binding variables

Added by John Lumley almost 11 years ago. Updated almost 11 years ago.

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

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Running under XSLT 3.0 mode, despite the documentation to the contrary, the compiler gives "for-each-group binding variables are allowed only with XSLT 3.0" failure.

This is in PE 9.5.0.1

(It is also somewhat confusing that system-property('xsl:version') produces 2.0, as I think I saw somewhere in the documentation... but it's definitely running under 3.0 as dynamic functions are supported.)

Actions #1

Updated by Michael Kay almost 11 years ago

  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Found in version changed from PE 9.5.0.1 to 9.5

I think it works correctly if XSLT 3.0 is enabled via the API (on the s9api XsltCompiler) or the command line (-xsltversion:3.0). It's not enough just to set version="3.0" on the xsl:stylesheet element.

I've been looking at other 3.0 extensions and the code seems a bit inconsistent; some of them check the version set via the API, some the effective version in the stylesheet, some both and some neither. This needs to be sorted out, but in the meantime the best strategy is to set both.

I've already changed the code for system-property('xsl:version') in the development branch so it returns a value dependent on the API setting, and I think it makes sense to retrofit this change to 9.5.

Actions #2

Updated by Michael Kay almost 11 years ago

I've retrofitted the change for system-property('xsl:version') to the 9.5 branch, so it now returns "3.0" if and only if 3.0 features are actually enabled.

Actions #3

Updated by Michael Kay almost 11 years ago

I've made a number of changes on both the 9.5 and 9.6 branches to achieve consistency in the decision whether new 3.0 constructs are allowed or not. These changes affect cases where a new attribute has been introduced for an existing XSLT instruction. These now use the same logic as for new XSLT instructions: the new construct is allowed if 3.0 was requested at the command-line/API level, or if no specific version was specified at the command-line/API level, and 3.0 was specified in the xsl:stylesheet/@version attribute for the stylesheet module in question.

A less urgent change which still needs to be applied is for the case where a 2.0 processor is requested at the API level, and the xsl:stylesheet/@version is "3.0", and a 3.0 construct is used. In many cases this is currently treated as an error; it should follow the XSLT 2.0 rules for forwards compatibility mode.

Actions #4

Updated by Michael Kay almost 11 years ago

  • Status changed from In Progress to Closed
  • Fixed in version set to 9.5.1.1

Fixed in 9.5.1.1, except for the minor point about running XSLT 2.0 in forwards compatibility mode, which is not a pressing requirement.

Please register to edit this issue

Also available in: Atom PDF