[jdom-interest] Element Reference from Attribute

[Amy Lewis]

On Mon, Nov 20, 2000 at 02:35:37PM -0000, James Strachan wrote:
>----- Original Message -----
>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).

I don't think that that's quite fair, either the "bloated" or the
"quite DOM like".

DOM isn't bloated because it carries lots of functionality.  It's
bloated because it's poorly designed, overly general, and badly
targeted.  A Java-specific tree manipulation, or specifically XML tree
manipulation API can be well-designed and specific, and is implicitly
targeting Java.  With a really *good* design (and I believe that we
have some really *good* designers hanging around this list), it can be
featureful and still not bloated.

My general argument, at the moment, would be that JDOM should make a
strong effort to permit developers to subclass its core classes
(Element, Attribute, Comment, etc.), so that projects with greater
needs can easily use the JDOM core as a basis for a more specialized
API (instead of starting from scratch--the removal of finals is one
step in that direction, as is the ability to substitute one's
customized builder-of-choice).  Along with that, I'd like to see all
these core elements implementing some unifying interface (such as
"Node").  This gives both core and extensions type safety that they
currently lack (as Elliotte pointed out, Object is a poor compromise
for a polymorphism).

My personal needs lie in the direction of enhanced navigability, or an
API that contains a path language (this means something similar to, but
not quite-quite XPath, because I want to avoid running Strings through
an engine (too little error-checking for my blood; debugging XPaths
often takes a couple of hours, which is a very high price)).  However,
I'm aware that this "heavies" the interface, so rather than asking for
it to go in core, I'd like core to be easily extended, so that I can
write these sorts of extensions on a JDOM base (I'm writing them
anyway, but for now it isn't a JDOM base, because the problem of
extension is intractable).

Amy!
-- 
Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
Early to bed and early to rise makes a man stupid and blind in the eyes.