Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Make convert(Node) public

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Make convert(Node) public
  • Date: Fri, 14 Nov 2003 08:24:22 -0800

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.






Archive powered by MHonArc 2.6.24.

Top of Page