[jdom-interest] Limitations wrt XPath

[bob]

Okay, 

Here's a quick summary of issues I have, with regards to
an implementatino of XPath on top of JDOM.

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.

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.

Lack of String.getParent() --

	Same thing.

While I'd like a getParent() on those three, I know String
will never have it (unless we move to a Text node class,
which contains it, but I think that's against the JDOM
philosophy?).  Namespace would require lots of work, and
adding to Attribute would increase memory overhead.

So, that leaves me implementing wrappers such as 
WrappedAttribute(Element parent, Attribute attr).  

My problem with that is then that the XPath implementaion
will return a NodeSet of JDOM Elements, and some wrapped 
Namespaces, Attributes, and Strings.  Adding the extra
layer of wrapping will add overhead, and my it somewhat
less symmetric, since Element won't be wrapped.

I could bite the bullet, and wrap *everything*, but
that'd be a little odd, I'd think, and would seem like
less of a 'native' implementation of XPath on JDOM.

Stepping forward to a XSLT, an unwrapping stage would
then have to occur, to affect the transformation.

Personally, if I were to implement JDOM, I'd view Namespace
as an IS-A relationship to Attribute, and implement similarly.

We're globally interning Namespaces, but not Attributes.  I'd
prefer to not intern the Namespaces, and thus allow them to
follow their Elements, which actually own them.  Sure, more
objects will be created, but the number of Namespaces in a
document is small, compared to Elements and Attributes,
I'd assume.

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.

Just my $0.002. ;)

	-bob