XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Thanks!
- The specific application here is to run an XQuery over Saxon, then 
convert the DOM results to XOM.
An unchecked exception seems sensible, but I could also live well with 
null or a check exception.

- By the way, what is the current status of your thinking on how to 
better support getting a builder with the "right" features? I submitted 
a proposal, but it did not seem good enough. See thread starting at

https://lists.ibiblio.org/sympa/arc/xom-interest/2003-October/000753.html

- Suggestion: A package that contains a single public class only seems 
to me a little like overkill: increases complexity with little gain in 
modularity. Hence, move nu.xom.canonical.* --> nu.xom.*
This would make it easier to learn (less packages) and not significantly 
less modular (affects one class only).

- While we are at it, are there plans further down the road to integrate 
XPath? Perhaps more directly than the code recently checked into the 
jaxen CVS...

Thanks for your considerations,
Wolfgang.

Elliotte Rusty Harold wrote:
> At 12:48 PM -0700 7/18/03, Wolfgang Hoschek wrote:
>
> > I tentatively made convert(Node) and convert(Element) public and added 
> > a public convert(Attr) and it works fine for me.
>
>
> I'm adding this into XOM now. This is hopefully the second to last API 
> change before declaring XOM alpha quality (i.e. API freeze). One 
> question came up:
>
> What should convert(Attr) do with a DOM object that represents a 
> namespace declaration? i.e. where the name is xmlns or xmlns:prefix? XOM 
> does not represent such attributes as Attribute objects. Should convert 
> throw an exception here or should it return null? Does anyone have a 
> strong preference on this one way or the other?