XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Elliotte Rusty Harold wrote:
> At 12:00 PM -0800 11/13/03, Wolfgang Hoschek wrote:
>
>
> > Since the XQuery can be arbitrary, I don't know what I'll get back as 
> > a result, but I'd still like to convert it to XOM as far as possible. 
> > If some unexpected things can't be converted (as in your DOM level 3 
> > example), that's okay, we can live with that, in that case 
> > convert(Node) should raise an exception ("can't convert xyz"). The 
> > overall idea is to delegate the converting to XOM as far as possible, 
> > and only do something special if that won't work. The best place to 
> > decide what can and cannot be converted, and how it should be 
> > converted is the convert(Node) method, it seems.
>
>
> I wouldn't suggest using Saxon's XPath API. It's a mess. Try Jaxxen 
> instead. What does an XQuery return from Saxon?
>
> Seems like Document and DocumentFragment would be problems now, plus 
> whatever they're using to represent namespace APIs and other non-node 
> types. And as I recall Saxon is very tricky because it's one of the few 
> DOMs that really does use the same class for all nodes, distinguished 
> only by getNodeType(). Maybe that's changed in 7.x, I'm not sure.

Saxon7 currently seems the only reasonable option for XQuery (and 
perhaps also XPath 2.0). The query essentially returns a list (or 
iterator) of "Item". Each Item can be distinguished by getItemType(), 
but depending on the type it also implements the various DOM interfaces 
(even though one would not know by looking at the public javadoc - need 
to sieve through the source to realize the fact).

Anyways, we convert an Item to XOM roughly along the lines of the 
snippet below. The DOMConverter.convert(Node) method could perhaps be 
used in a more general way:

protected static Element toWrappedXOM(Item item) throws XPathException {
        log.trace(item.getClass().getName());
        switch (item.getItemType()) {
                case Type.DOCUMENT: {
                        org.w3c.dom.Document node = 
((org.w3c.dom.Document)item);
                        return DOMConverter.convert(node).getRootElement();
                        //return XMLUtil.dom2xom(node).getRootElement();
                }
                case Type.ELEMENT: {                                          
  
                        org.w3c.dom.Element node = 
((org.w3c.dom.Element)item);
                        return DOMConverter.convert(node);
                }
                case Type.ATTRIBUTE: {
                        org.w3c.dom.Attr node = ((org.w3c.dom.Attr)item);
                        Element wrapped = ItemSet.newItem();
                        wrapped.addAttribute(DOMConverter.convert(node));
                        return wrapped;
                }
                case Type.TEXT: {
                        org.w3c.dom.Text node = ((org.w3c.dom.Text)item);
                        Element wrapped = ItemSet.newItem();
                        wrapped.appendChild(DOMConverter.convert(node));
                        return wrapped;
                }
                case Type.NODE: {
                        org.w3c.dom.Node node = ((org.w3c.dom.Node)item);
                        Element wrapped = ItemSet.newItem();
			wrapped.appendChild(DOMConverter.convert(node)); // XOM's 
DOMConverter.convert(Node) should be public !
                        return wrapped;
                }
                default: {
                        Element wrapped = ItemSet.newItem();
                        wrapped.appendChild(item.getStringValue());
                        return wrapped;
                }
        }       

As can be seen here, there is not only the suboptimal issue of how to 
convert DOM to XOM, but also how to serialize a list of arbitrary nodes 
into a well-formed XML document (e.g. free standing attributes need to 
be wrapped in elements, one way or another). But the lack of a node list 
serialization standard has nothing to do with XOM.

Wolfgang.