XOM API for Processing XML with Java

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

At 10:20 AM +0200 9/11/03, Hallvard Trætteberg wrote:
> Hi,
>
> I've done something similar for JDOM and the same problem occurred
> there: I think it was setAttribute that created new attributes with a
> standard constructor instead of giving a chance for a specific factory
> to create it. One possibility is to make Document implement NodeFactory
> (or return a NodeFactory) and use it for creating all kinds of nodes if
> needed outside of the building process. E.g. copy would call
> getDocument.copy(element) or something like that. There should at least
> be a way to change the behavior, so the method shouldn't be final.

OK. This is reasonable.

I can see how to make this work with factories but it would involve
carrying around an extra 4-byte reference in every node which I'm
loathe to do.

I could just put the references to the factory on the Document, and
let copy walk up the tree to find the factory. However, this doesn't
really help with nodes that aren't in a document, and would mean the
factory changed when a node moved from one Document to another.

I can also see how to fix this by using clone() but that would
require making all the classes Cloneable. Yuck.

Letting subclasses override copy() would let them change its
semantics, which I don't like, but it would also let them be more
accurate with respect to the semantics by returning the right
subclass, so it's probably a net plus. I don't see any way a subclass
overriding copy() would allow it to create a malformed document, so
I'm probably just going to make copy() non-final.
--

  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