[jdom-interest] Limitations wrt XPath

[bob]

> <philosophy_question>
> For all these things we're looking at adding extra cost both in terms of
> memory use and CPU cycles to manage the interconnections.  Is that a
> price we're willing to pay?  If we do pay the price wouldn't that give
> someone a reason to modify their version to not pay that price?  Things
> like XPath need the parentage, but how often is it needed by a normal
> API user?  Is it enough for XPath to use a simple JDOM structure and add
> full parentage itself?  Or on the String vs. Text class issue, how much
> memory will be consumed by wrapping all strings with a Text class, and
> having that Text class remember its parent?  That's a lot of extra
> object creation overhead that's not needed by most people and could be
> added "above JDOM" by an XPath implementation.
> </philosophy_question>

wrt to parentage, I fully agree that it may not be worth the
tradeoff (but I'd still like to have it, believe me).  

With the Text stuff, though, I think it also crosses the line
as to the philosophy of 'liveness' of returned data.

getAttribute() returns a directly modifiable Attribute.

Likewise with getChild().  getChildren() returns a directly
modifiable List of Elements, allow you to mutate the List,
or the Elements contained therein.

The textual data, though, does not follow that scheme.
setContent(String) blows away the internal list.  To alter
text, you have to getMixedContent(), create a new String,
remove the old one, and insert the new one.

Though, I'll admit, I've never had a case to need to change
the text in a mixed-content Element, but just pondering symmetry
at this point. ;)

	-bob