Project

Profile

Help

Support #5059

NS default empty declaration added by transformer

Added by Youssouf MHOMA 2 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2021-08-10
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Taking a document with a default namespace and sub-element in its scope without a specified namespace, the serialization of this document will conduct to the addition of an empty namespace inside the sub-elements with saxon > 10.X

Example, build of the document below

<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg"><title>a_title</title></svg>
final DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
Document dom = dbf.newDocumentBuilder().newDocument();

Element rootEle = dom.createElement("svg");
rootEle.setAttribute("xmlns", "http://www.w3.org/2000/svg");

Element titleEem = dom.createElement("title");
titleEem.setTextContent("a_title");
rootEle.appendChild(titleEem);

dom.appendChild(rootEle);

The serialization of this document with version => 10.X (10.2 and 10.5 tested) adds a default namespace empty for the title element, which is wrong,

<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg"><title xmlns="">a_title</title></svg>

This code is OK in version 9.9.1-5.

SaxonTransformerExample.java (1.74 KB) SaxonTransformerExample.java Youssouf MHOMA, 2021-08-10 10:29
pom.xml (3.62 KB) pom.xml Youssouf MHOMA, 2021-08-10 10:29

History

#1 Updated by Michael Kay 2 months ago

Please use setNamespaceAware(true) on the DocumentBuilder. XPath and XSLT are defined in terms of the XDM model, which is always namespace-aware. The Java DOM by default isn't, and there's no defined "correct" mapping for a non-namespace-aware DOM to XDM.

However, I think that the behaviour of Saxon 10 here is reasonable. The Javadoc for Document.createElement(tagName) says:

returns a new Element object with the nodeName attribute set to tagName, and localName, prefix, and namespaceURI set to null.

This implies that the new Element node is in no namespace, and should therefore be serialized with xmlns="", because without that, it would be in the SVG namespace.

#2 Updated by Michael Kay 2 months ago

I decided to take a more detailed look at the specs to see if they confirmed this view.

If there is an "official" mapping from DOM to XDM, then it's obtained by first mapping the DOM to an Infoset, and then mapping the Infoset to XDM.

The DOM-to-Infoset mapping in https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/infoset-mapping.html (section C.2.2) says that the infoset [namespace.name] property is taken from the Node.namespaceURI property in the DOM, and the Javadoc for createElement() says that this is null: therefore the element is in no namespace.

The DOM-to-Infoset mapping also says that the infoset [local name] property is taken from the DOM Node.localName property, which the JavaDoc says is null, and this would make the infoset local name null, which means it cannot be mapped to a valid XDM instance.

It all comes back to this: you need to define the DOM as namespace-aware, and use namespace-aware methods such as createElementNS() to create nodes.

#3 Updated by Youssouf MHOMA 2 months ago

So i should assume that the previous versions of Saxons (<10) were not handling correctly the specification on this point. The transformer filtered the namespace attribute with null value and did not rendered it (which was good for me), whereas version 10 behaves like the specification. It sounds right.

#4 Updated by Michael Kay 2 months ago

I would prefer to say that the behaviour on a non-namespace-aware DOM is unspecified: it's not clear how it should be handled, and the case is best avoided.

(Incidentally, although you can set whether a DOM is namespace-aware or not when creating the DocumentBuilder, Saxon, when given a DOM, has no way of finding out whether it was built to be namespace-aware or not. If there were a way of asking, we would probably raise an error and reject a non-namespace-aware DOM.)

#5 Updated by Michael Kay 2 months ago

  • Tracker changed from Bug to Support
  • Status changed from New to Closed
  • Assignee set to Michael Kay

I've decided to close this with no action.

Please register to edit this issue

Also available in: Atom PDF