[jdom-interest] Element Reference from Attribute

[Patrick Dowler]

On Tue, 21 Nov 2000, Louis Tribble wrote:
> 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. 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.

In a singly-linked version, you could write a Builder that tried to share 
references to Attributes. In some cases, this could give a great advantage
in memory consumption. For example, say I have a dataset written as:

<table>
  <row>
      <cell width=20>narrow</cell>
      <cell width=40>wide</cell>
  </row>
  <row>
     <cell width=20>narrow</cell>
      <cell width=40>wide</cell>
  </row>
  ...
</rable>

You could have only two distinct attributes: Attribute("width",20) and
Attribute("width",40). Normally, a table with 10k rows has 20k attribute
objects when it could have 2. If I was wriitng a servlet that processing
query results into an HTML table, I might want to make this sort of 
optimization. If I am writing a client GUI which reads a large table and
displays it, I would do the same with 10k objects that were effectively
the same.

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

True enough. 

--

Patrick Dowler
Canadian Astronomy Data Centre