XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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.