Bug #6036: Undeclaration of default namespace is not reported to a SAXResult - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #6036

closed

Undeclaration of default namespace is not reported to a SAXResult

Added by Radu Coravu 12 months ago. Updated 8 months ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

JAXP Java API

Sprint/Milestone:

Start date:

2023-05-12

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

11, 12, trunk

Fix Committed on Branch:

11, 12, trunk

Fixed in Maintenance Release:

12.3, 11.6

Platforms:

Java

Description

I need some advice, the problem might be on our side though... I have this XML:

<?xml version="1.0" encoding="UTF-8"?>
<colors>
    <red>10</red>
    <blue>20</blue>
    <green>15</green>  
</colors>

and this XSL:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
    <xsl:output method="xml" indent="yes"/>
    <xsl:template match="/">
        <svg xmlns="http://www.w3.org/2000/svg">
            <xsl:apply-templates/>
        </svg>
    </xsl:template>
    <xsl:template match="colors/*">
        <circle cx="{(position() - 1) * 100}" cy="100" r="{.}"/>
    </xsl:template>
</xsl:stylesheet>

For the Oxygen debugger we serialize the XML using the net.sf.saxon.event.ComplexContentOutputter class with a serializer. The resulting output is this one:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
   <circle cx="100" cy="100" r="10"/>
   <circle cx="300" cy="100" r="20"/>
   <circle cx="500" cy="100" r="15"/>
</svg>

which is incorrect because the "circle" element should have an empty xmlns="" set on it.

Lookin at the callbacks we receive in our content handler, we do not receive a startPrefixMapping("", "") before the startElement("circle") is received.

Looking at the code here: net.sf.saxon.event.ComplexContentOutputter.startContent() it does something like this:

        if (pendingStartTag.hasURI("") && !pendingNSMap.getDefaultNamespace().isEmpty()) {
            pendingNSMap = pendingNSMap.remove("");
        }

but I'm not sure it is to blame for the problem.

Actions

Copy link

Updated by Michael Kay 12 months ago

I've reproduced this with a unit test (SAXTest.testSAXResult) that runs the transformation using JAXP and sends the output to a SAXResult. If we send the output to a serializer, it's fine, but if we send it to a SAXResult, the startPrefixMapping() call is missing.

The NamespaceMap objects being passed to the startElement calls in the ContentHandlerProxy are fine, but the ContentHandlerProxy seems to be making no serious attempt to determine how the current namespace map differs from the one on the parent element, which is needed to generate the startPrefixMapping events.

It actually appears to call startPrefixMapping() for all in-scope namespaces on the child element, whether or not they were present on the parent; and it doesn't detect the need to issue an undeclaration event because the namespaceMap on the child element contains no evidence that it is needed. This requires comparison with the parent namespace map.

Actions

Copy link

Updated by Michael Kay 12 months ago

Tracker changed from Support to Bug
Subject changed from Empty namespace not getting serialized to Undeclaration of default namespace is not reported to a SAXResult
Category set to JAXP Java API
Status changed from New to In Progress
Assignee set to Michael Kay
Priority changed from Low to Normal

Actions

Copy link

Updated by Michael Kay 12 months ago

The way we handle this for the XML serializer is that we put a NamespaceDifferencer in the output pipeline. This handles the maintenance of the namespace stack and passes a NamespaceMap containing only the differences to the next step in the pipeline. We should do the same thing for the SAX output pipeline.

This can be achieved in SAXDestination.getReceiver().

This seems to be sufficient to make the test work, but I think we can do some further tidying up in the ContentHandlerProxy.

Moreover, we need to look at other places where we create a ContentHandlerProxy. Since this is supposed to bridge between Saxon's Receiver events and SAX push events, I would think we need the namespace differencing whenever we do this, and this certainly isn't happening at the moment: there are five places we create a ContentHandlerProxy.

Actions

Copy link

Updated by Michael Kay 12 months ago

Status changed from In Progress to Resolved
Applies to branch 11, 12, trunk added
Fix Committed on Branch 11, 12, trunk added
Platforms Java added

On the 12.x and main branches I reviewed all uses of ContentHandlerProxy to add a NamespaceDifferencer in front of them.

On the 11.x branch I only changed the one that caused the failure, in SAXDestination.getReceiver().

Actions

Copy link

Updated by Radu Coravu 12 months ago

Thanks Michael for investigating this, I will try to identify your changes and see if we can make a patch on our side for a minor Oxygen 25.1 bug fix release. We plan to maybe look into upgrading Oxygen to using Saxon 12 in Autumn this year for version 26 if time allows.

Actions

Copy link