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

[James Strachan]

----- Original Message -----
From: "Patrick Dowler" <Patrick.Dowler at nrc.ca>
To: <jdom-interest at jdom.org>
> 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:

I agree with your and Amy's points on this. I think 2 levels of JDOM, single
or double-linked tree is a good compromise. One derives from the other so we
have 2 useful functional trees of differing weights and functionalities.
Plus we allow people to easily extend whichever level they see fit.

Summarising these levels, and addressing Jason's issue on Attribute
uniqueness, we could focus the levels on:-

JDOM lite: single linked tree.
> org.jdom.Element
> org.jdom.Attribute
> org.jdom.Document

* designed for minimum RAM usage, efficiency and simplicity.
* good for J2ME and generally useful in low RAM environments
* good in high throughput environments (e.g. servlets) where lots of parsing
and quite simple naviagtion is required
* can possibly share Attribute instances (maybe immuatable) around the tree
to conserve RAM.


JDOM power: double linked tree.
> org.jdom.NavElement
> org.jdom.NavAttribute
> org.jdom.NavDocument

* designed for powerful navigation, where the extra expressiveness and
navigation are worth the extra RAM overhead
* supports XInclude and XPath and would be a useful base library for an XSLT
implementation
* supports most of the functionality that DOM offers, with maybe more
besides ;-)
* Attribute instances are mutable and cannot be shared (due to the unique
parent constraint, like Elements)
* supports new Node interface throughout for getParent() / getValue() /
XPath semantics.

A really cool addition at this level would be full XPath integration, with
new selectNodes() and selectSingleNodes() methods like in MSXML for
evaluating XPath expressions from any Node. e.g.

public interface Node {

    public Node selectSingleNode( String xpathExpression );
    public List  selectNodes( String xpathExpression );

    ...
}


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.