Bug #4660


Incorrect xpath-default-namespace on included files with XX compiler

Added by John Lumley almost 4 years ago. Updated over 3 years ago.

XSLT Conformance
Start date:
Due date:
% Done:


Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Contact person:
Additional contact persons:


In the case where an included stylesheet has an @xpath-default-namespace on the stylesheet|transform element, and the top-level stylesheet does not, templates within the included stylesheet, which do not themselves have @xpath-default-namespace attributes, do not inherit the property from their parent.

Minimal reproduction of the problem attached.


bugXXX.xsl (468 Bytes) bugXXX.xsl John Lumley, 2020-07-31 12:02
bugXXXinc.xsl (380 Bytes) bugXXXinc.xsl John Lumley, 2020-07-31 12:02
Actions #1

Updated by John Lumley almost 4 years ago

It appears to be an error in the static phase, as the result after static processing is:

<xsl:stylesheet xmlns:ex="" xmlns:math=""
      xmlns:xs="" xmlns:xsl="" xmlns="FOO" 
     version="3.0" ex:ns="xml=~ xsl=~ xs=~ math=~ =FOO">
   <xsl:template ex:ns="xml=~ xsl=~ xs=~ math=~ =FOO" ex:baseUri="http://localhost/XSLT3/special/bugXXXinc.xsl"
            ex:precLabel="A" ex:lineNr="2" match="a">
      <A ex:lineNr="3" ex:exclude=""/>
   <xsl:template ex:ns="xml=~ xsl=~ xs=~ math=~ =FOO" ex:baseUri="http://localhost/XSLT3/special/bugXXX.xsl" 
        ex:precLabel="A" ex:lineNr="3" match="b" xpath-default-namespace="FOO">
      <B ex:lineNr="4" ex:exclude=""/>

where the template matching b does not have an inherited @xpath-default-namespace from its original parent.

Actions #2

Updated by Debbie Lockett almost 4 years ago

  • Assignee set to Michael Kay
Actions #3

Updated by Michael Kay almost 4 years ago

  • Category set to XSLT Conformance
  • Status changed from New to In Progress

I have created xslt3 test case xpath-default-namespace-1202 and have confirmed that it succeeds under Saxon-J and fails under -JS.

Actions #4

Updated by Michael Kay almost 4 years ago

It seems that it can be fixed by adding

<xsl:apply-templates select="../@xpath-default-namespace" mode="#current"/>

at static.xsl#938. At this point we're processing a top-level component and we're about to process its own attributes; this processes the xpath-default-namespace attribute on the parent element first. I do wonder if there are other attributes that should receive the same treatment: the ones to look at are

default-collation, default-mode, default-validation, exclude-result-prefixes, expand-text, extension-element-prefixes, use-when, version.

I'll think about adding tests for some of these.

Actions #5

Updated by Michael Kay almost 4 years ago

Added tests for expand-text on an included module (cvt-046, cvt-047). The tests pass on both Saxon-J and Saxon-JS -- though it looks to be a case that was definitely untested before.

default-mode seems to be covered by test mode-1617.

Added tests collations-0126 and collations-0127 to test default-collation at xsl:stylesheet level. These tests are failing on Saxon-JS, along with many other collation tests, but that's within the scope of bug #4616.

Actions #6

Updated by Michael Kay almost 4 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on JS Branch Trunk added
Actions #7

Updated by Community Admin over 3 years ago

  • Applies to JS Branch 2 added
  • Applies to JS Branch deleted (2.0, Trunk)
Actions #8

Updated by Debbie Lockett over 3 years ago

  • Fix Committed on JS Branch 2 added
  • Fix Committed on JS Branch deleted (Trunk)
Actions #9

Updated by Debbie Lockett over 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 2.1

Bug fix applied in the Saxon-JS 2.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page