[jdom-interest] Refactoring JDOM (Was: Element Reference from Attribute)

[Patrick Dowler]

On Mon, 20 Nov 2000, James Strachan wrote:
> Maybe your XPath engine should accept a JDOM XPathDocument ;-)
> 
> > I'd rather not force folks to use a special builder for XPath-intended
> > documents.
> 
> Its a slipery slope though. As more and more things are required of JDOM
> from 'higher levels' to do XPath, XInclude, XSLT, RDF, XLink, ...., then
> before you know it JDOM is as bloated as DOM.
> 
> > What if I need XPathElement, and Mr. Harold needs XIncludeElement,
> > then we can't apply both XPath and XInclude to the same base
> > document.
> 
> Agreed - though I think either we allow XPath / XInclude style navigation
> semantics (Node interface, parent relationships) everywhere in JDOM or we
> have 2 standard trees, "JDOM light" and "JDOM heavier". "JDOM heavier" would
> support everything required for XPath, XSLT and XInclude. (So would be quite
> DOM like from the functionality perspective).

There are several ways to do it, but 2-3 levels of functionality would 
probably suffice. Such a design would not have classes named
XPathElement or XIncludeElement, but rather Element with various
levels of functionality so that a particular application could chose the
level they need. 

It is also a good idea to make it easy to refactor code to use more
functionality. For this reason, I suggested awhile back something like:

// basic features (singly-linked tree)
org.jdom.Element
org.jdom.Attribute
org.jdom.Document
...

// full navigation features (doubly-linked tree)
org.jdom.NavElement
org.jdom.NavAttribute
org.jdom.NavDocument
...

People who want to read a simple data file and display it could use the
basic feature set, which is very lightweight. Those that need to edit the
document or use XPath, XInclude, etc. would use the "navigable" classes.

I expect there are probably only a few likely places to draw the lines
between functionality levels that map to the class hierarchy, so this would be
a fairly simple refactoring. The line-drawing task is pretty much one of
making each level of sophistication useful in its own right AND making
moving your code to the next level a useful balance of weight and features.

Right now, I think 2 feature levels would let JDOM scale from j2me to j2ee.
It started out in the j2me to j2se range, but features have pushed it up to the
j2se to j2ee range already :-( 

There is also the secondary scalability of document size: a simple document 
with 1e6 elements should be doable (well, maybe not on j2me :-) but I don't
think it is (or will be) on a typical workstation/j2se setup unless we make this
wort of split.

Several months ago, Simon St. Laurent (sp?) posted an URL to his site
where he gave a break-down of XML "feature-levels". It was well thought
out and would provide a good foundation for such a split. I just can't
find that URL.

cheers,

--

Patrick Dowler
Canadian Astronomy Data Centre