XOM API for Processing XML with Java

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

At 9:13 PM +0200 9/29/03, Hallvard Trætteberg wrote:
> Elliotte,
>
> In the latest version of XOM you have made the copy method protected, so
> a class may control the class of its copies. Together with the
> NodeFactory this gives full control over instantiation of nodes. Almost,
> as I think the XIncluder class does not support a custom NodeFactory. In
> the XIncluder code, a Builder is created, but there is no way to pass in
> a NodeFactory. I believe it makes sense to add a NodeFactory argument to
> the resolve family of static methods in XIncluder, what do you think?

I've now written a prototype (a.k.a not in CVS 
yet) version of XIncluder that does this, and it 
wasn't particularly hard to do. However, this did 
demonstrate that maybe this is the right answer 
to the wrong question. Letting a NodeFactory be 
specified when XIncluding is really just a subset 
of letting a Builder be specified for XIncluder. 
If you could specify a Builder, then you could 
set the NodeFactory on that Builder, thus neatly 
answering your use-case. However, you could also 
set a number of other options on the Builder 
including:

1. Setting validation
2. Setting a SAX EntityResolver
3. Setting a SAX filter
4. Setting various features and properties

The downside to this approach is that it will be 
relatively hard to get data included with 
parse="text" to use the right node factory; not 
impossible, but it will be a hack. However, the 
hackishness should not be publicly visible. 
Thoughts?

--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA