[jdom-interest] Element Reference from Attribute

[Rosen, Alex]

<< Recently, as some of you know, I've been working on XInclude
processors. This is the largest project I've tried to do in JDOM, and
it's definitely changed my opinions about what is and isn't useful.
At least in this use-case I'm seeing a lot more point to doing things
the DOM way. >>

Hmm... I wonder if it's worth going down this slippery slope? Is it a goal
of JDOM to be able to easily support every use of XML? We've seen the added
requirements that XPath and XInclude bring; I wonder what added
functionality will be needed for the next X* implementation (XSLT, XQuery,
etc).

As I see it, JDOM can have two objectives:

(1) Be extrememly easy to use for simple XML processing, but not provide
100% of XML functionality (no XInclude, some valid (but perhaps esoteric)
XPath values not supported, etc).

(2) Support all XML functionality, and be easier to use than DOM, but not as
easy as possible.

I see (2) as being a Java version of DOM. If DOM had been designed for Java
only, the result would be similar to (2) - easier to use than DOM, but not
much more intuitive. You get the 4 benefits that you listed (classes instead
of interfaces, etc), but nothing more. I see (1) as more of a rethinking of
DOM, to make it intuitive to use. That's what I thought JDOM was originally
meant to be, and I think it's what the current JDOM API is very close to
being.

There is a whole world of uses for XML for which the current JDOM is very
apt - simply reading, manipulating, and writing XML files, such as
deployment descriptors and other data files. As we've seen with J2EE
deployment descriptors, XML will continue to be a more and more popular way
of storing structured data, and I think we need a dirt-simple API for doing
this. My question is, for more complicated things, should we complicate the
basic JDOM API, or should there be some things that just can't be done with
JDOM?

--Alex