Bug #5398


Saxon 10.x: injects empty namespaces

Added by M. Hilpert 9 months ago. Updated 4 months ago.

DOM Interface
Start date:
Due date:
% Done:


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


After upgrading from 9.6... to 10.7, our SOAP messages don't work anymore. The parses injects empty namespaces that cause the error. Exmaple:

Before / working:

<PutUserLogon xmlns="">
		<Password  asf:NoLog="true">[blanked]</Password>

after installing V 10.7:

<PutUserLogon xmlns="">
    <asfUserLogon xmlns="" >
	<Password  asf:NoLog="true">[blanked]</Password>

Usually, the namespace should be internally used from the parent.

Actions #1

Updated by Michael Kay 9 months ago

There are a number of things that could cause this: for example issues #5059 and #5254 both report a similar effect occurring which was found to be caused by using a non-namespace-aware DOM as input, which isn't supported.

We would need to see exactly what you are doing to establish the cause.

Actions #2

Updated by M. Hilpert 9 months ago

I was able to "resolve" this by adding the same namespace to all subsequent elements.

But there are lots of other XSL-FO errors that occured. We have to go back to Saxon 9.x und need much more time to evaluate all those bugs that occured after switchung to V 10 ....

Actions #3

Updated by Michael Kay 9 months ago

If adding a redundant namespace declaration makes a difference, that does sound very much as if you are hitting the same problem of using a non-namespace-aware DOM.

Unfortunately the DOM API provides no way for Saxon to ask whether it is namespace-aware or not, so it's hard for us to handle the situation. It's a shame that so many people are still using DOM after all these years.

Actions #4

Updated by M. Hilpert 9 months ago

Well, I guess no boss wants to pay to change a working / running system to replace DOM ... and it's a lot of risk involved changing such "legacy" code. And DOM is not 'per se' bad, it has its advantages.

I just wonder why this worked flawlessy up to Saxon 9.x and became a problem with Saxon 10.x ?

Actions #5

Updated by Michael Kay 9 months ago

I just wonder why this worked flawlessy up to Saxon 9.x and became a problem with Saxon 10.x ?

Hard to know. I don't think it did work flawlessly, I think you simply didn't find the bugs. We've never supported non-namespace-aware DOM input, therefore we've never routinely tested it, and I think on the rare occasions when I've looked at whether it was something we could support, we found there were so many problems that it wasn't worth attempting.

One of the issues is simply that although you can set the DOM factory to be namespace-aware (or not), there's no way Saxon can ask whether the DOM is namespace aware, and trying to write code that handles both possibilities makes it very inefficient.

Actions #6

Updated by Michael Kay 9 months ago

As a first step, I have added logic to DomObjectModel.sendDOMSource() that detects two common cases (where top is the document element):

(a) top.getNamespaceURI() == null && top.getNodeName().contains(":")

(b) top.getNamespaceURI() == null && top.hasAttribute("xmlns")

Both these conditions indicate that the user has supplied a non-namespace-aware DOM, and this will now be detected and treated as an error rather than resulting in bad output.

This doesn't detect all cases of non-namespace-aware DOMs (e.g. if the top-level element contains no namespace declarations, but lower-level elements do), but it's a quick check that will detect the majority of cases.

Actions #7

Updated by Michael Kay 8 months ago

  • Status changed from New to In Progress

Following review of test failures, I decided to change the patch so when it detects a non-namespace-aware DOM, it now reports a warning rather than an error. (This patch will be in the 11.3 maintenance release even though the bug is not closed.)

Actions #8

Updated by Michael Kay 8 months ago

  • Applies to branch 11, trunk added
  • Fix Committed on Branch 11, trunk added
Actions #9

Updated by Michael Kay 4 months ago

  • Category set to DOM Interface
  • Status changed from In Progress to Resolved
  • Assignee set to Michael Kay
  • Priority changed from High to Normal

I think we've done all we can on this: the effects of using a non-namespace-aware DOM with Saxon are unpredictable. We've added code to detect some common cases and generate warnings, and I've committed some documentation changes to emphasize the restrictions.

Actions #10

Updated by Debbie Lockett 4 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 11.4 added

Bug fix applied in the Saxon 11.4 maintenance release.

Please register to edit this issue

Also available in: Atom PDF