Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] NodeFactory issues

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: jcowan AT reutershealth.com
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] NodeFactory issues
  • Date: Thu, 5 Feb 2004 21:22:29 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page