Bug #4962
closed
SEF compiled with Saxon-EE returns system-property('xsl:product-name') as SAXON
Applies to branch:
11, trunk
Fix Committed on Branch:
11, trunk
Fixed in Maintenance Release:
Description
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'"/>
- 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.
- 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.
- Status changed from New to Resolved
- Platforms .NET, Java added
- 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.
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?
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.
- Related to Bug #5698: Changes for system-property() added
Please register to edit this issue
Also available in: Atom
PDF
.