Bug #3923

Invalid result-document output in Saxon-HE-9.9.0-1

Added by Vladimir Nesterovsky 11 months ago. Updated 10 months ago.

XSLT conformance
Start date:
Due date:
% Done:


Legacy ID:
Applies to branch:
9.8, 9.9
Fix Committed on Branch:
9.8, 9.9
Fixed in Maintenance Release:


I've tested latest version of Saxon HE and got invalid output with duplicate namespace. The code looks like this:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="3.0"

  <xsl:template match="/">
    <xsl:variable name="entity" as="element()">

    <xsl:sequence select="$entity"/>

    <xsl:result-document href="out2.xml">
      <xsl:sequence select="$entity"/>


Any input xml should be supplied. Stylesheet produces two outputs.

out2.xml for me is like this:

<?xml version="1.0" encoding="UTF-8"?><unit xmlns="x" xmlns:xs="" xmlns="x"/>

Note xmlns twice.


#1 Updated by Michael Kay 11 months ago

I think this is probably related to bug #3889, which proved very disruptive. Perhaps the patch for that bug wasn't applied correctly on the 9.9 branch, or was inconsistent with some other change.

Current state: I've reproduced the problem, but walking it through in the debugger, I can't see where the excess namespace declaration is coming from. There seems to be a NamespaceReducer in the pipeline that is successfully eliminating duplicate declarations, but somehow this one slips through...

#2 Updated by Michael Kay 11 months ago

There is a rather remarkable error in NamespaceReducer.namespace(), which is present also in 9.8. The code:

       for (NamespaceBinding ns : namespaceBindings) {
            if (isNeeded(ns)) {
                countStack[depth - 1]++;
                nextReceiver.namespace(namespaceBindings, properties);

processes a set of namespace bindings. If any of the namespace bindings is needed, then it outputs all of them.

The ability to pass multiple namespaces in a single call of Receiver.namespace() was introduced in Saxon 9.8, it was found to give significant performance improvements when doing a deep-copy of a tree in which elements had many (like a dozen) in-scope namespaces.

Why this obvious error hasn't caused more problems is anyone's guess.

#3 Updated by Michael Kay 11 months ago

Confirmed that correcting this code fixes the problem. More regression testing is needed before closing the bug, however.

#4 Updated by Michael Kay 11 months ago

  • Applies to branch 9.8, 9.9 added
  • Fix Committed on Branch 9.8, 9.9 added

I'm currently getting quite a lot of failures in xsl:result-document tests. These are probably the result of unfinished work on bug #3920, but I can't be sure, so I will leave this open until #3920 is settled. However, I am committing this patch for both 9.8 and 9.9 as the code is so obviously wrong.

#5 Updated by Michael Kay 11 months ago

  • Category set to XSLT conformance
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

I'm closing this one as resolved. There are still one or two xsl:result-document test failures, essentially concerned with saxon:next-in-chain, but I will tackle these under bug #3920.

#6 Updated by O'Neil Delpratt 10 months ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release added

Bug fix applied in the Saxon maintenance release. Leave open to the Saxon 9.9 maintenance release.

#7 Updated by O'Neil Delpratt 10 months ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release added

Bug fix applied in the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF