Saxon

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.

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 ....

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.

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 ?

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.

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.