[jdom-interest] Element Reference from Attribute

Patrick Dowler Patrick.Dowler at nrc.ca
Wed Nov 22 11:58:20 PST 2000


On Wed, 22 Nov 2000, philip.nelson at omniresources.com wrote:
> > 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:

<<snip example since it is rewritten below>>

> > 
> > 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. 
> 
> And to figure out when to share the attribute reference or not you would do
> <?????>

Ok, just to be totally clear, I was talking about MY apllkication where I know what
MY XML files are going to look like. This could be handled in a variety of
ways, including:

<table>
  <internable type="attribute">width=20</internable>
  <internable type="attribute">width=40</internable>
  <row>
      <cell width=20>narrow</cell>
      <cell width=40>wide</cell>
  </row>
  <row>
     <cell width=20>narrow</cell>
      <cell width=40>wide</cell>
  </row>
  ...
</table>

There are plenty of ways to encode this sort of thing. The I would write 
my custom Builder to use

	Attribute a = internAttributeWhenPossible(key, value);

where the method would check my internable map and either share or
create. 

*** The point is, if I want to do this, I should be able to. If the API makes it
impossible, then I have to go and fork JDOM into SimpleDOM and 
duplicate alot of work trying to keep the SimpleDOM API  in line with 
half of the JDOM API. That sucks. :-(

> And then when the second row's cell width changed you would do what?

Obviously I wouldn't use the shared attribute, would I? 

> As to the idea of a two level approach, would you have to rewrite the
> inputters, outputters, builders to use the Builder you mention?  Isn't this
> extra overhead as well for the most common thing that JDOM has to do?

The whole argument is based on the fact that there are two highly distinct
levels of use for XML. Some people want to handle simple (but potentially
very large) XML efficiently while others want full navigation power for more
sophisticated manipulation. In any project, there is always an argument of
efficiency vs features. If inheritance is used wisely, we can have both with little
real cost. 

Personally, I don't care if we have 

	Element
	NavElement extends Element
	etc.
or
	SimpleElement
	Element extends SimpleElement
	etc.

The very big issue is making it easy for people to extend JDOM classes for 
their own purposes. That lets people use JDOM without having everything 
in the core API. If JDOM core only provides the featureful level, then
it can't really be extended to handle large but simple XML where lots of
common objects can be interned. If there are two levels of features
(proposed is singly-linked tree vs. doubly linked tree) the people can
extend the feature level that works for them. 

-- 

Patrick Dowler
Canadian Astronomy Data Centre




More information about the jdom-interest mailing list