No subject

tossed in favor of keeping the api simple and lightweight.  So far, the api
has not fundamentally changed but lightweight has already been challenged as
real.  As I see it, these changes would make the api more complicated and
even less lightweight.

> 
> 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.
> 
snip

> 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?

The use of xml for storing structured data will be my most common use by
far.  As JDOM moves closer and closer to DOM, the reasons for walking away
from a "standard" starts to seem questionable.  Especially if JDOM can't
achieve the "lighter weight than DOM" goal it was started with.  I remember
hearing (echoed on this list I think) references to DOMers who were upset
with JDOM seemingly stepping away from this hard fought for standard.  The
response was that JDOM works with DOM and didn't fundamentally try to
accomplish the same thing.  

There is already an open source and a number of commercial DOM tools out
there.  Should JDOM really try to compete with that?  Is it good thing for
JDOM to try to be the java way of doing xml whereas every other language is
busy implementing the standard DOM?  Won't JDOM always be behind the other
tools in implementing new DOM functionality?

At the start of this project, I wanted some features that either will be
(XPath) or won't be (listeners, pluggable validation) part of JDOM.
Everyone will be in that boat to a degree (User data, XQuery, schema...).
While I am continually amazed at the amount of effort made for JDOM by it's
contributors, it still doesn't match that of Xerces or the commercial tools.
So, trying to do it all with JDOM seems like it could be doomed to be in
beta forever.

Now if we could do it *and* keep it light weight...