Saxonica Developer Community

2025-04-11

• 
  Michael Kay Saxon

  18:59 · Closed issue

  The failures arise because the spec has changed, and the tests have changed accordingly.
  In general we aren't updating 12.6 to track the latest changes to the 4.0 specifications, but in this case I think it makes sense to do so. I've ... Bug #6748 (Resolved): 12.6 - xsl:array specification change

  In the candidate 12.6 release a number of XSLT 4.0 tests are failing, mainly relating to the xsl:array instruction. For example array-003.
• 
  Michael Kay In the candidate 12.6 release a number of XSLT 4.0 tests are failing, mainly relating to the xsl:array instruction. For example array-003.

  18:08 · Closed issue
• 
  Michael Kay Saxon

  12:05 · Closed issue

  Bug #6746 (Resolved): SaxonJ-HE 12.5 - xsl:use-package @package-version issue

  I was reading the XSLT 3.0 specification about packages and trying a few things out, when I got an error about the value of the package-version attribute in the use-package element.
  The https://www.w3.org/TR/xslt-30/#package-versions...
• 
  Michael Kay The code incorrecty allows a range such as `"1 to 10, *"`

  10:40 · Commented on issue
• 
  Michael Kay I'm creating a set of unit tests for the underlying implementation classes, as it's much easier to get good coverage this way than by writing actual XSLT tests.
  

  00:34 · Commented on issue

2025-04-10

• 
  Michael Kay Saxon

  23:17 · Commented on issue

  Indeed, there appear to be no tests for the keyword "to" being followed by a VersionPrefix, and no code in Saxon to handle this case.
  On the documentation question, I'm pretty sure "the first one" is intended to be read as "the first ... Bug #6746: SaxonJ-HE 12.5 - xsl:use-package @package-version issue

  I was reading the XSLT 3.0 specification about packages and trying a few things out, when I got an error about the value of the package-version attribute in the use-package element.
  The https://www.w3.org/TR/xslt-30/#package-versions...

2025-04-07

• 
  Michael Kay Saxon

  19:03 · Commented on issue

  Here's the sequence of events for this unit test.
  `StylesheetModule.getAssociatedStylesheet()` is called with resolver=null, source=a StreamSource with `systemId=/Users/mike/(repo)/src/test/testdata/trax/xml/embedded.xml`
  The PIGra... Bug #6721: Failing to resolve URI with href="#xsl"

  On the 12.x branch, unit test TraxTest.testUseEmbedded is failing.
  I'm running it with a right-click in IntelliJ, which apparently invokes the Gradle task
  :java:test --tests "jaxptest.TraxTest.testUseEmbedded"
  The test is trying...

2025-04-04

• 
  Michael Kay Saxon

  13:18 · Closed issue

  Changed so try/catch in XSLT and XQuery no longer catches a stack overflow exception. Bug #6738 (Resolved): Recursive function, try/catch

  ```
  declare function local:f($a) {
  try {
  if($a > 0) then local:f($a - 1) else error()
  } catch * {
  $a
  }
  };
  local:f(10000)
  ```
  …returns a number close to 10000, but not 0 as expected (Saxon EE, latest release).
• 
  Michael Kay Saxon catches a StackOverflow exception in order to try to produce better diagnostics when it happens, but we shouldn't allow a user application to catch it, because we can't really offer any guarantees about the state of play at the tim...

  13:09 · Commented on issue
• 
  Michael Kay Saxon

  13:04 · Closed issue

  I've patched TinyNodeImpl so that the tree and nodeNr fields are final. This change can't do any harm, but it's only a conjecture that it might solve the problem. In the absence of any ability to test it, though, it will have to do for now. Bug #6735 (Resolved): net.sf.saxon.tree.tiny.TinyNodeImpl.getLocalPart throws NullPointerException - race condition

  I don't know if this issue is related to bug #6348, but occasionally, with Saxon-EE 12.5 and saxon:transform(), we still encounter the following problem:
  ```
  2025-03-27 18:25:52 [main] Transforming file:/var/opt/app/arte2/u00p/interfac...