[jdom-interest] API Inertia

[Elliotte Rusty Harold]

At 11:22 AM -0400 4/30/01, Rosen, Alex wrote:

>I haven't tried it in either one, but... why would a Node interface help?
>Assuming you actually want to do something useful with each visited node, why
>is getting a Node any better than getting an Object? It seems clear that the
>Node interface would have few (if any!) methods on it, so you'll probably need
>to cast anyway.
>

I think it would help because the Node interface would have 
hasChildren() and getChildren() methods. These would be applicable to 
all nodes. Sometimes hasChildren() would return true, sometimes it 
would return false. Sometimes getChildren() would return a list that 
has members. Sometimes it would return an empty list. This lets you 
walk the tree without caring excessively about the type of each node 
in the tree or without a lot of casting.

Frankly I'm amazed that Jason seems worried about typing an 
occasional few lines of extra code in the rare case that he needs to 
move an element, as evidenced in the detach() thread, while being 
completely unfazed by the huge number of lines doing nothing but 
casting and type checking that permeate the JDOM code base today. 
Both positions are reasonable and well argued by Jason. I just don't 
see how he can fit both of them into the same brain at the same time. 
:-)

>Also - I would imagine that a lot of tree traversing code only cares about
>Elements, no? Node would be irrelevent here. And, if you didn't just 
>care about
>Elements, which things would you care about? Would you want to visit Entities?
>Attributes? CDATAs? Strings? It's not clear what should be a Node and what
>shouldn't.
>

Everything's a node. By default you visit everything except 
attributes (which aren't children) but we can put filters in the 
utilities package.

The one exception I'd be willing to make (WARNING: BIG YUCKY CAN OF 
WORMS ABOUT TO BE OPENED) are entities. In fact I'd like to throw 
entities out completely. Here's my logic:

1. Entities are part of the physical structure of an XML document, 
not the logical structure.Anytime you start mixing and matching the 
logical and physical structures of an XML document the API gets way 
complicated.

2. The 90/10 split is on the logical side; not the physical side. 
Proof of point: entities are totally broken now and almost nobody's 
noticed or complained!

I think we should resolve all entities at build time, and then forget 
about them. This requires the use of a validating parser, which is 
not a big problem. It does not require us to validate, merely to read 
the external DTD subset, which is not a big deal.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+