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: Thu, 13 Nov 2003 12:00:33 -0800

Elliotte Rusty Harold wrote:
At 9:46 AM -0800 11/13/03, Wolfgang Hoschek wrote:

In d22, could we please also make the following method public:

private static Node convert(org.w3c.dom.Node node)

If it is not made public, all user code that gets handed an arbitrary dom node must duplicate what is in that method.


What's your use case? I remember there was a reason I didn't do that, though it escapes me at the moment. I think it may have been that this method doesn't actually handle all types of DOM nodes. For instance it does not handle Document nodes. That could be fixed, but more importantly DOM allows implementations to create new node types. I've seen this at least once, in an XPath or XSLT API I think (DOM Level 3 XPath? Yes, that's it. See http://www.w3.org/TR/2003/CR-DOM-Level-3-XPath-20030331/xpath.html#XPathNamespace) and there's no way I can plausibly handle all the custom Node types one might encounter.

I could just throw an exception if I encounter an unexpected node type, but I'd rather not do that until someone demonstrates a real need for this functionality. The use cases I've heard so far just involved individual Elements and Attrs. I threw in the other types out of a sense of completeness, but so far I haven't heard a use-case for converting arbitrary nodes.

The use case here is general-purpose processing of arbitrary queries over arbitrary data - making an arbitrary XQuery via Saxon (or an XPath query), getting an arbitrary node list as a result, then converting each node into the corresponding XOM representation, then work from there and do more arbitrary transformations, and in later steps serialize it over the network.

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.
Does this make sense?

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page