Bug #4962
closed
SEF compiled with Saxon-EE returns system-property('xsl:product-name') as SAXON
100%
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'"/>
Related issues
Updated by Norm Tovey-Walsh over 2 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.
Updated by Michael Kay about 1 year 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.
Updated by Michael Kay about 1 year ago
- Status changed from New to Resolved
- Platforms .NET, Java added
Updated by Debbie Lockett about 1 year 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.
Updated by Martynas Jusevicius about 1 year 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?
Updated by Norm Tovey-Walsh about 1 year 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.
Updated by Debbie Lockett 12 months ago
- Related to Bug #5698: Changes for system-property() added
Please register to edit this issue
.