Project

Profile

Help

Bug #3923

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

Added by Vladimir Nesterovsky about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2018-09-28
Due date:
% Done:

100%

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

Description

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"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns="x">

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

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

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

</xsl:stylesheet>

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="http://www.w3.org/2001/XMLSchema" xmlns="x"/>

Note xmlns twice.

History

#1 Updated by Michael Kay about 1 year 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 about 1 year 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)) {
                addToStack(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 about 1 year ago

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

#4 Updated by Michael Kay about 1 year 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 about 1 year 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 about 1 year ago

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

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

#7 Updated by O'Neil Delpratt about 1 year ago

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

Bug fix applied in the Saxon 9.9.0.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF