[jdom-interest] Limitations wrt XPath

[Jason Hunter]

> Lack of Attribute.getParent() --
> 
>         While an Attribute is not a child of an Element,
>         the parent of an Attribute is an Element.  Odd,
>         sure, but that's the spec.  Mostly, this is so
>         the child:: axis doesn't include Attributes.
> 
>         Though, the parent:: axis of an Attribute should
>         contain it's owning Element.
> 
>         This could be solved within JDOM through a
>         getParent() on Attribute.

I'm up to have this fixed.

> Lack of Namespace.getParent() --
> 
>         Exact same situation as Attribute.  Though,
>         implementationally, due to the way Namespaces are
>         currently handled, a getParent() cannot be easily
>         added.   (Because JDOM essentially interns all
>         Namespaces to prevent replication).
> 
>         An overhaul of the Namespace mechanism would again
>         be needed to provide the getParent() stuff.

I'm up to have this fixed too, but I'd want to do some public review of
the design to make sure it's worth the cost.

> WRT String vs Text nodes...
> 
> We currently get back 'live' Lists from Element.getChildren(),
> but Element.getText() doesn't return a 'live' object.  Just
> the value semantics of the data stored within.  (Though, I also
> realize that getText() might be glueing many Strings together
> from the MixedContent).
> 
> I propose (feel free to disagree), that getMixedContent() return
> Elements and TextNodes, but have getText() do the normal gluing
> together of the TextNode data to produce a bare String.
> 
> That way, if you were to obtain a TextNode, a setText() method
> could be used to change the data live, in-place, without having
> to remove a String from the List, and re-insert a new one.
> 
> ie, have a TextNode which acts like the CDATA class, in all regards,
> except for outputtng.  In fact, CDATA IS-A TextNode.

I've been pondering that independently for a while.  What do others
think?

<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>

-jh-