XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

I think you're correct that when Saxon creates a DOM view of an underlying
Saxon tree, the attribute node that represents the xmlns="xyz" declaration
has a null namespace URI, whereas the DOM specifications strongly suggest
that it should have a namespace URI of "http://www.w3.org/2000/xmlns/";. The
reason for this rule escapes me completely, but it's what DOM says. At any
rate, this would be true if the attribute were created using
setAttributeNS(), so it seems reasonable to do the same when the attribute
is created any other way.

I fixed this a while ago for the case where Saxon generates DOM output, but
it doesn't seem to have been fixed for the case where it generates a DOM
wrapper. The code is in NodeOverNodeInfo.getNamespaceURI(), which currently
reads:

    public String getNamespaceURI() {
        if (node.getNodeKind() == Type.NAMESPACE) {
            if (node.getLocalPart().length() == 0) {
                return null;
            } else {
                return NamespaceConstant.XMLNS;
            }
        }
        String uri = node.getURI();
        return ("".equals(uri) ? null : uri);
    }

and it needs to change to:

    public String getNamespaceURI() {
        if (node.getNodeKind() == Type.NAMESPACE) {
            return NamespaceConstant.XMLNS;
        }
        String uri = node.getURI();
        return ("".equals(uri) ? null : uri);
    }

Please try this patch and let me know if it works.

> 
> The second bug occurs in 
> DOMConverter.convert(org.w3c.dom.Element element, 
> NodeFactory). It seems evident that the algorithm walks down 
> and up the given tree and quits when it again arrives at the 
> root node (i.e. element). In my application, this case never 
> occurs; instead, the algorithm arrives at a point where the 
> current node is null and runs into a NullPointerException. 

Without more information as to how the tree appears to be corrupt it's
difficult to help.

A general point, though: is this really a sensible architecture? Converting
between three different representations of the data model seems to introduce
a lot of complexity and overhead. One feels there must be a simpler way: in
particular, can't you convert directly from the Saxon model to XOM, rather
than going via DOM interfaces?

Michael Kay
http://www.saxonica.com/