XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 2:14 PM -0500 2/2/04, jcowan AT reutershealth.com wrote:

> Builder:
>
> 1) 3-argument constructor doco doesn't mention NodeFactory.  Also, 
> the constructors
>    should have consistent doco:  all should read "Creates a new".

fixed

> 2) Consider dropping Builder(XMLReader parser, boolean validate); 
> it's clutter,
>    and it's very easy to ask the XMLReader for validation before passing it.

I'll think about it.

> 3) There should be a flavor of build() that accepts a org.xml.sax.InputSource.

What's the use-case here? I prefer not to expose more of SAX than I 
have to; but if there's a compelling need it's easy to do. I just 
have to change a private method to public.

> 4) Expose the chosen parser with a getXMLReader method, so that you can let
>    XOM choose the parser but still set properties on it before 
> calling build().

No, I really don't want to do that. XOM depends pretty heavily on 
having some features and properties set "just so" and I don't want to 
make it easy to change those. Right now you could pass in your own 
XMLReader to construct a Builder, change the features on it, and then 
call build, and honestly that makes me nervous.  Such are the dangers 
of violating encapsulation. I'm wondering if I should check and reset 
the features XOM needs before each build().

I suspect that the vast majority of series-builds (using the same 
Builder for multiple documents) will want to use the same 
configuration for each document anyway, and it's not that big a deal 
to use several different builders if that's not what you want.

--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Effective XML (Addison-Wesley, 2003)
  http://www.cafeconleche.org/books/effectivexml
  http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA