[jdom-interest] Element Reference from Attribute

[James Strachan]

----- Original Message -----
From: "Louis Tribble" <louis.tribble at metamata.com>
To: <jdom-interest at jdom.org>
Sent: Tuesday, November 21, 2000 7:29 PM
Subject: Re: [jdom-interest] Element Reference from Attribute


> James Strachan wrote:
> > However I think we can have a usable standard base tree (such as the
current
> > Element / Attribute singly linked tree implementation) and carefully
thought
> > through additional layers of functionality (e.g. NavElement /
NavAttribute
> > doubley linked tree for doing XPath and XInclude).
> >
>
> If the major difference between the layers is navigation towards the
> root, and if the hit is something like 10-20%, as Jason suggests, two
> layers is not worth the complications.

Why should all users take the extra memory hit just because some optional
higher levels of XPath / XInclude / XSL require it?

For doubly linked trees we need to add an extra object reference to
Attribute, Comment, CDATA, Entity (maybe Text nodes too?). Sure its not a
huge change but neither is it trivial. It also means that instances of
Attribute and other leaf nodes cannot be shared throughout a tree which can
have a big effect on performance and memory consumption. (Attribute names
and values can often be quite common in an XML tree, particularly in web
site production, XHTML et al).

I'm yet to be convinced that we can brush away these performance penalties
for all users; XML parsing is slow & memory intensive enough as it is and in
highly loaded servers or J2ME environments, any performance gain is worth a
small API complexity. For some users, performance and memory consumption is
not a big deal, for others it is crucial.

I don't think 2 parallel trees would make the API that much more complex.
The biggest problem I can see is naming the 2 trees nicely.

> Additionally, since navigation
> towards the root seems necessary to solidly support XPath, XInclude,
> XSL, etcetera, and since I cannot see the JCP standardizing an API that
> doesn't support these standards, omitting this support does not seem
> like an option.

I'm not saying omit them at all. I'm saying have a quick, memory efficent
lower level tree to keep the performance bound people happy, and have a more
heavy weight, full power, supports everything tree for the
XPath/Xinclude/XSL to keep the higher level WC3 folk happy.

I think that there is a clear middle ground between SAX and full XPath /
XInclude / XSLT support and JDOM should support it.

> Removing the need to extend for upward navigation does not mean that
> the builders and hierarchy no longer need to be fully extensible, of
> course.

Sure. The question is, how much baggage do you force on people before they
are allowed to extend.

J.

James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com



If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.