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:

> 1) Point out that NF doesn't do anything unless subclassed.  For 
> each call, make
>    sure the default result is explained.
>
> 2) Initial text refers to non-existent makeDocTypeDeclaration().

Both fixed.

> 3) It's asymmetrical that makeDocType can't return an Element, whereas
>    finishMakingElement (of the root element) can return a DocType.
>    Make it one way or the other.

There is an asymmetry here, but I think it makes sense. If 
makeDocType were to return an Element, then this could only be the 
root element. But makeRootElement can't return nullk to match it. 
It's just very messy all around. There's also an implicit rule that 
makeComment() and makeProcessingInstruction can't return an element 
if they're in the prolog or epilog. This isn't hugely different. 
XML's one root element rule makes the root element special, and I 
think that's what we've got here. Hmm, I do need to check that 
something sensible happens when makeRootElement returns a DocType 
though.

> 4) In finishMakingElement, it's better to ignore attempts to detach
>    the root rather than to simply warn against doing so.
>    That way, the root need not be treated specially (good for recursive
>    doctypes).

Perhaps, but I don't think this is possible. The element is passed to 
finishMakingElement(), and there's no way to force the subclass not 
to call element.detach(). Possibly, though, I could make doing so 
less damaging, maybe reattaching it in XOMHandler if necessary? But 
no, that would be very surprising to somebody who tried to detach it. 
I'll look into this and see what I can figure out.

> 5) Consider handing makeDocType the internal subset so it can look inside,
>    but except on attempts to change it.

Reasonable. On the other hand, there's no setInternalDTDSubset 
method, so I'm not sure what the makeDocType method could do with 
this. I don't need to except on attempts to change it because it's a 
string, and strings are immutable. It's basically read-only. But it 
is a part of the document content that doesn't get passed to the 
NodeFactory and is thus not easily accessible when streaming. I'll 
think about it. My inclination at the moment is to leave this out. 
However, I've been babck and foirth on this several times. I'll think 
some more.
--

  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