Project

Profile

Help

Bug #5540

closed

Namespace context should be reset at the beginning of an XSLT stylesheet

Added by Norm Tovey-Walsh over 2 years ago. Updated 7 days ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Sprint/Milestone:
Start date:
2022-05-26
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
2, Trunk
Fix Committed on JS Branch:
2, Trunk
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

Martin Honnen reports that the following transformation works successfully in SaxonJS:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="3.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="#all"
  expand-text="yes">


  <xsl:template match="/" name="xsl:initial-template">
    <xsl:comment>Run with {system-property('xsl:product-name')} {system-property('xsl:product-version')} {system-property('Q{http://saxon.sf.net/}platform')}</xsl:comment>
    <test>{fn:current-dateTime()}</test>
  </xsl:template>
  
</xsl:stylesheet>

If you run fn:transform() through SaxonJS.XPath.evaluate. Note also that the documentation for XPath.evaluate says "For convenience the usual namespaces for prefixes xml, fn, xs, map, array, math, and saxon are defined by default, but can be overwritten."

It appears that the namespace context of XPath.evaluate "leaks" into the transformation allowing the undeclared use of "fn:".

Actions #1

Updated by Michael Kay over 2 years ago

Added XSLT3 test case namespace-6202 to check that failure to declare "fn" throws an error. (The test isn't specific to the fn:transform case.)

Actions #2

Updated by Michael Kay over 2 years ago

In the XX compiler, XPath compilation is trigged from XPath.xsl line 1027 by a call to saxon:compile-XPath(), which is in ExtraFn.js line 914, and results in a call to SaxonJS.XPath.compileToXML(), which invokes XPathEval.compile(), which invokes makeTopContext(). This (line 407) adds to the static context any namespaces explicitly supplied, but it adds them to an initialised variable which I suspect already contains a binding for the fn namespace, as a result of the initialisation at XPathEval.CompileContext.init(), line 165.

So I think the unwarranted declaration of the fn namespace is happening at the point where the XX XSLT compiler invokes the JS XPath compiler.

Actions #3

Updated by Norm Tovey-Walsh over 2 years ago

  • Priority changed from Low to High
  • Sprint/Milestone set to SaxonJS 3.0
Actions #4

Updated by Norm Tovey-Walsh 2 months ago

  • Status changed from New to Resolved
  • Applies to JS Branch 2, Trunk added
  • Fix Committed on JS Branch 2, Trunk added

Indeed. The fn: namespace was being declared by default. Fixed by not doing that :-)

Actions #5

Updated by Debbie Lockett 2 months ago

Further fix committed in XPathEval.js to add "fn" to the list of default prefixes in makeTopContextJS, to ensure that the "fn" prefix is still provided by default for SaxonJS.XPath.evaluate. Also added some tests which make use of this: unit_test_browser_xpath_evaluate06, and xp023 in unit_test_nodejs_xp.

Also now removed namespace-6202 from the xslt30 exceptions list.

Committed on the main and saxonjs2 branches.

Actions #6

Updated by Debbie Lockett 7 days ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to SaxonJS 2.7

Bug fix applied in the SaxonJS 2.7 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page