[jdom-interest] What do we want JDOM to be?

[Brett McLaughlin]

Guy Nirpaz wrote:
> 
> Hi All,
> 
> Recent discussions on this mailing list clearly show that not everybody
> understands the same way what is 80% (or 95%) and what isn't, and belongs to
> 20% (or 5%). The project initiators (Brett and Jason) stated that JDOM isn't
> going to encapsulate everything that can be done with XML API .The big
> question is what goes in and what stays out?
> 
> Most people really like JDOM the first time they lay their hands on it. And
> the excitement even increases when they do actual coding using JDOM (at
> least me and my team have). But, after a while people start looking for more
> advanced features - like XPath, XSLT, etc... . Some of them are inside JDOM
> some aren't yet and some will never be.

I adress your "some will never be" below, as being incorrect. And it's
worth pointing out that you aren't really talking about what I consider
a feature. A feature, at least as I would define it, is something like
"getParent()" or interfaces. They are things about the API. XPath and
XSLT are specifications that JDOM would have to directly or indirectly
support/implement. And I wouldn't rule out any spec. as something we
will never agree to implement, or roll in an implementation of.

> 
> I think it is a good point in the JDOM lifecycle to have a discussion on
> what eventually will get into JDOM and what will stay out.

It's not that simple. If there is a good use-case and it makes sense, it
goes in. If not, not. There seems to be an impression that certain
things will never go in, certain things will never go out. That's simply
false; it indicates that people are upset because they are unable to
justify their changes to us. In other words, it often indicates poor
design on an issue, and someone is mad because we don't accept that poor
design.

Case in point - Factories/Interfaces. People think they will never go
on, arbitrarily. That's completely wrong. If someone lays out a clear,
succint use case where they are required, proves that the use-case is a
common one (affects 80/20), and designs a way to do it, we'll strongly
consider putting them in. Nobody has yet done that. Tom Bradford has
spent some time working on that lately, but we are still in very early
stages of discussion. James lobbies for interfaces, and makes rather
wild statements that Jason and/or I have closed that door forever.
That's simple false. In Tom's case, his initial reason for interfaces
for for a JDOM/DOM implementation (where one class implemented both). I
don't think that's either a compelling reason or a common one. James
never really argued much for interfaces, he argued for this
doubly-linked tree idea which I have yet to see justified or made
arguable as a common, solid idea.

So it's not that we say "No" to anything arbitrarily, or "yes" to
anything arbitrarily. We require the submitter to do some work, rather
than just throw an idea over the wall to us and expect adoption. If the
idea is clearly outlined, and seems common, sometimes we even do the
implementation ourselves! But use-case, use-case, use-case must occur.
Call it unfair, but Jason and I are judges of what is common, because we
are fortunate to have the widest audiences that we have worked with
(with our books), and both have a good feel, in our opinion, as to what
people are looking for because we get their zillion questions in email
;-)

> 
> For example - is JDOM going to support XPath? (I know bob is working on
> that) If so, what are the features that we need to add to the API for XPath
> support? The same question is valid for XLink, XInclude, XSLT and others.

Yes, it will support XPath. Not, it will not support these until JDOM is
at 1.0. It is fun and exciting to talk about all these other APIs, but
they are useless unless the core is rock-solid. That isn't the case yet,
and until it is, all these discussions about XPath and XLink and so
forth are fairly premature ;-) We're lucky to have Bob working his butt
off on XPath, and he is funneling problems back to the core. For
example, the whole getParent() thing. Problems that he raises that are
core-level (like that one), we look and and almost always put into the
core API. Sometimes that takes some time, though, as it introduces all
sorts of other "gotchas", so it looks like we're not moving, when we are
really moving carefully. The abstract base class (Node) and getParent()
are two good examples of that. But as for XPath specifics, they won't go
in until 1.1... just so we can ensure we have a good 1.0 product. Make
sense?

> 
> I believe that if we get to agree on the functional spec. we will be able to
> clearly identify the design choices. People will be able to find out if JDOM
> is right for them (or will be in the future) or not - and yes, there are
> cases when it isn't ;-)

Finally, I want to again point out that we do not and cannot outline
what JDOM will for sure have and not have in the future. That's open
source for you, in that it is highly fluid. For example, Bob has said
once XPath is done, he's on to XSLT. That's great - but I don't want to
announce to the world that "for sure, XSLT is coming as soon as XPath is
done", because Bob may lose interest, he may get busy at work, he may
get hit by a bus (we hope not), etc. That doesn't mean that XSLT
wouldn't happen, but we depend on people, not deadlines. So I would hope
people continue to realize that JDOM is an API designed to make Java and
XML come together in an intuitive way in Java. It is not, as some people
might claim, a simple API, or for beginning or intermediate programmers
only. If it was, then I'm officially an intermediate programmer only
(which I would beg to differ with), because I've been using it for
industrial strength problems like data binding and soon XMLC for a long
time now.

Hope that at least helps clarify some things.
Brett

> 
> Guy Nirpaz
> Java Architect
> 
> Tantian Corp.
> guyn at tantian.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com