Bug #4962


SEF compiled with Saxon-EE returns system-property('xsl:product-name') as SAXON

Added by Martynas Jusevicius about 3 years ago. Updated almost 2 years ago.

XSLT export
Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
11, trunk
Fix Committed on Branch:
11, trunk
Fixed in Maintenance Release:
.NET, Java


I'm printing out <xsl:value-of select="system-property('xsl:product-name')"/> and getting SAXON when the stylesheet is compiled with Saxon-EE. I get Saxon-JS if it's compiled with Saxon-JS. Why the difference if in both cases it executes on Saxon-JS?

Also I don't think the browser-check proposed under XSLT 3.0 and XPath 3.1 Conformance can work with SAXON then:

<xsl:variable name="inBrowser" 
     select="system-property('xsl:product-name') eq 'Saxon-JS' and
                  system-property('saxon:platform') eq 'Browser'"/>

Related issues

Related to SaxonJS - Bug #5698: Changes for system-property()ClosedDebbie Lockett2022-09-28

Actions #1

Updated by Norm Tovey-Walsh about 3 years ago

  • Project changed from SaxonJS to Saxon
  • Applies to JS Branch deleted (2)

The why is that the Java processor optimizes the call at compile time. This is clearly a bug when compiling a SEF. Moving this issue to the Saxon issue tracker.

Actions #2

Updated by Michael Kay almost 2 years ago

  • Category set to XSLT export
  • Assignee set to Michael Kay
  • Applies to branch 11, trunk added
  • Fix Committed on Branch 11, trunk added

I have implemented a partial fix to this: if the current configuration doesn't match the target configuration for which we are generating a SEF file, then a call on system-property() will not be eagerly evaluated.

This is only a partial fix. If you use system-property in a static expression, for example a use-when expression, then you will get the property values appropriate to the compile-time configuration, not the run-time configuration.

In addition, if you're in SaxonJ EE and generate a SEF with target="EE" then it assumes the run-time environment is the same as the compile-time environment, which isn't necessarily the case.

I'm reluctant to abandon early evaluation of system-property() entirely because it's often used in 1.0 stylesheets to achieve cross-product stylesheet portability, and this may depend on static evaluation.

Actions #3

Updated by Michael Kay almost 2 years ago

  • Status changed from New to Resolved
  • Platforms .NET, Java added
Actions #4

Updated by Debbie Lockett almost 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 11.4 added

Bug fix applied in the Saxon 11.4 maintenance release.

Actions #5

Updated by Martynas Jusevicius almost 2 years ago

I'm not sure I understand the implications of this bug fix. Will the inBrowser check work correctly now when SEF is compiled with Saxon-EE and run on Saxon-JS or still not?

Actions #6

Updated by Norm Tovey-Walsh almost 2 years ago

I think the answer you're looking for is "yes". For ordinary, dynamically evaluated expressions, the SaxonJ compiler no longer eagerly evaluates the system-property() function call. That means it'll be evaluated at run time by SaxonJS and you'll get the answers you expect.

This is true except in cases where you put the expression in a statically evaluated context, such as a use-when. Those will still be evaluated by the compiler.

Actions #7

Updated by Debbie Lockett over 1 year ago

  • Related to Bug #5698: Changes for system-property() added

Please register to edit this issue

Also available in: Atom PDF