[jdom-interest] getChildren() vs getElements()

[Amy Lewis]

On Fri, Sep 15, 2000 at 09:18:27PM -0700, Peter V. Gadjokov wrote:
[snip]
>How about this alternative - A Document/Element describes a tree of
>_elements_. Everything else is not really part of the tree (might be part of
>the DOM tree, but JDOM is not DOM), everything else is just a property (or
>property list) of an element. So, that means getChild/Children get to stay
>since the refer to elements, always. The content thing goes away, a lot of
>crazy PartialList magic goes away, things are stored explicitly in
>containers appropriate for their type (gives you the option to go typesafe
>when Java gets genericity), nothing other than an element is ever referred
>to as a 'child'. So if you want to add comment, pi, you addPi, you
>addComment, etc. What you lose - you lose the ability to represent
>everything an element contains as a mutable list - why is this important
>(I'm really asking, everthing I see in the implementation that gets the list
>is always instanceof-ing it into components but there is likely a use I'm
>not thinking of). If mutability is not important, a List of all sub-pieces
>can be constructed on demand. You lose (at least, trivially, it can be
>addressed) the ability to retain the exact location of the element text
>among sub-elements. It is a lot simpler, though, conceptually. It does let

More than that, you lose any sense of relative location for all the
child nodes, between nodes of different types.  If you happen to have
an enormous (badly designed) element that contains two PIs, thirty
comments, and seventy element children, you've lost the ability to
associate the comments with the siblings that they pair with (which is
pretty much the way that comments generally work, even though in a tree
model they "belong" to the mutual parent of the thing that they're
commenting on).  To take an example from html/xhtml, you've changed
"This is <em>important</em>, please take note!" to "This is, please
take note!<em>important</em>" or <em>important</em>This is, please take
note!".  While the latter has a certain Yoda-like charm, it isn't at
all accurate.  The two PIs, which (let us say) represent page breaks,
have now moved to the top (or bottom?  Or some other "standard"
location that has nothing to do with their actual placement in the
document?) where they live happily together spewing out blank sheets,
while the rest of the text runs on and on, like this paragraph.

So, somewhere, somehow, in the API, you have to *preserve* document
order.  You have to preserve among children of unlike type (and unlike
others here, I tend to think of "child" in the more XPath-y sense of
"everything except the attributes and namespaces").  If you lose
document order, you prolly ought to just not support comments and PIs,
and you ought to warn folks not to expect mixed content to work in any
complex context, since you've lost the original relative positions of
the content.

So, while from a programming sense it is certainly *cleaner* to
describe a tree of elements, it doesn't usefully describe the documents
that the programmers are going to encounter, and isn't, therefore, a
good abstraction.

Amy!
-- 
Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
There are two major products that came out of Berkeley: LSD and BSD Unix.
We don't believe this to be a coincidence.