[jdom-interest] Announce: JDOMPlus a flexible XML framework for Java

[Brett McLaughlin]

James Strachan wrote:
> 
> Whoops, I pressed send too early on that previous mail - sorry about that.
> That'll teach me to type before I've had my morning coffee ;-)
> 
> I was just about to say...
> 
> From: "Jason Hunter" <jhunter at collab.net>
> > Brett and I very much hope that people with design ideas continue to use
> > this list as the place for discussion.  I'm always happy to debate the
> > merits of different designs.
> 
> Me too its fun :-)
> 
> Though from Bretts responses such as...
> 
> http://lists.denveronline.net/lists/jdom-interest/2000-November/003901.html
> http://lists.denveronline.net/lists/jdom-interest/2000-December/003954.html
> 
> I think its pretty clear that interfaces, factories, multiple tree
> implementations ('dual' trees), read only & reusable branches and the like
> are not going to make it into JDOM. Period. JDOM has one Element
> implemention and one Attribute implementation end of story. Unfortunately, I
> don't see much point discussing such things on JDOM anymoreas it is clear
> JDOM will never move in the 'interface' direction.

Well, to be blunt, you are completely wrong. See my mail this morning to
Guy Nirpaz. James, at the risk of offending you (which I don't want to
do), you simply didn't justify the design choices you wanted to make. No
idea is arbitrarily turned away here - none. But for any idea to be
accepted, you must first present a compelling use-case that affects a
signficant number of JDOM users. You have yet to do that - you have a
niche that you want to fill that you have not convinced Jason or me is a
common one (although it certainly my be YOUR niche ;-) ). Second, you
must present a compelling design solution to that idea, one that is
sound in design. I have yet to see that as well. While I salute your
efforts, there are many, many interface design problems that you have
not addressed or mentioned. That indicates to Jason and I (who started
down this road, and went very far down it) that you may be in for some
unpleasant surprises down the line. While you may solve each in turn, it
doesn't absolve us of the responsibility to JDOM users to not trust you,
or anyone (no matter how good of a programmer they are ;-) ), to solve
those at that time, instead of up-front.

As with many suggestions that we don't use, people feel that we have
made an arbitrary decision. We haven't, and don't. Jason and I often
spend many hours emailing and talking these things over behind the
scene, and carefully weighing the merits (yeah, we're a real JDOM
Supreme Court ;-) ). And we were not satisfied that your ideas met a
common use case, and met it in a way that made sense. It is worth noting
that the other proponent of the doubly-linked tree also felt that the
implementation design you laid out was wanting. While that's no fun to
hear, it does indicate that perhaps Jason and I are being safe to not
want to include this sort of thing, at least at this point.

Finally, I want to ask, respectfully, that you don't state (in this mail
or on your API website) anywhere that we "won't" do something, because
it's simply not true. Yes, it's really hard to get changes into JDOM at
this point of a significant nature. ;-) People know that, and it is
frustrating. Sometimes I want to get in changes, and can't ;-) But that
also results in a carefully though out, mature API, well before it's
time. I wish DOM and SAX had been as stringent as to what got into their
first versions; we might be a lot better off with them today! But
there's not a single suggestion we dismiss out of hand. If it looks like
that, ask us why - we've probably already done a lot of homework ahead
of time. And realize, that I completely wrote JDOM in interfaces as a
first pre-alpha. The whole thing, completely working. And it was a pain
in the butt, and there were a ton of problems. And I'd submit that I'm
no dummy ;-) So it's not blindly that we are resistant to interfaces
without REALLY GOOD justification. Which nobody has supplied yet.

> 
> It is for this very reason that I started the 'project formerly known as
> JDOM+' ;-) project. For those people amongst us who want to freely mix and
> match different data structure implementations for different use cases /
> schemas within an API framework rather than relying on a 'one size fits all'
> approach to data structures.

That's an overstatement, and hopefully it wasn't intentional. Anyone who
wants to use subclasses can easily mix and match JDOM implementations.
Anyone who is familiar with the Collections API and facade patterns can
work with an immutable JDOM. It's really frustrating to see statements
like this; they are just as incorrect as the DOM-isms people slap us
with. It might not seem as obvious, and might not be the way you want it
to work, but it works the way that it works for a well-thought out
reason.

> 
> > I enjoy that discussion actually; it's one
> > of the nicest perks of this unpaid position.  :-)  It's unfortunate we
> > can't accept every idea,
> 
> Agreed - its unfortunate but trade-offs have to be made.

Yes.

> 
> > but we believe it's best when making API
> > changes to "Measure twice, cut once" as they say, and the factory model
> > promoted by the forked design definitely raised some hairy unresolved
> > issues.
> 
> What hairy unresolved issues are they? Though I like the term - hairy
> unresolved issue - HUI - I hope it catches on ;-)

This is the crux of our point - it is not our job to point out or poke
holes in idea submissions. But it is your idea to find them,
nonetheless. You will have interface issues, and when you hit them, you
will see what we mean. That's the thing - we haven't seen a far-reaching
design laid out in any of your emails. That, in addition to not seeing a
common use-case, is why we would not accept your ideas. You have to do
more than convince yourself it's good, and then expect that to flow out
in your emails. You have to really justify any new concepts to us, and
make us believe how great they are. That just hasn't happened yet.

> 
> If most of us can use interfaces for Map, List and Set quite happily I'm at
> a loss to understand what is so fundamentally wrong with using interfaces to
> represent a Java based XML tree data structure. The only problem with this
> approach as far as I can see (other than an increase in complexity which can
> be hidden from the user in many ways) is that politically it would make JDOM
> apprear more like DOM.

Well, you'll have quite a time down the line then ;-)

All, it may seem like I'm picking on James here. I don't mean to be -
he's perfectly allowed to fork JDOM and do his own implementation
(although it isn't going to be called JDOM or any other derivative). In
fact, anyone with an idea that we don't accept could do that, from a
small idea to a big one. I suppose you could have
JDOM_with_exceptions_instead_of_null and JDOM_with_Node_base_class and
JDOM_with_this_idea_I_like and JDOM_with_that_idea_I_like. But the point
is that Jason and I are working as hard, and as fairly, as we can to
ensure that JDOM, the API, is as bulletproof and wisely designed as
possible. As a result, many folks (possibly including James) might feel
like we are dictators, that we are inflexible, that we're too
close-minded. I can only ask that you believe me that that is not the
case. We have already completely re-written JDOM TWICE because our own
ideas didn't hold water. We're just as hard on ourselves as on others.
And lest you think we're hung up on our ideas, it was James Davidson who
convinced us that all our ideas on JDOM v.0.2 were wrong, and we rewrote
it all to NOT use interfaces! So if your idea isn't accepted, it's not
because we don't like you, or don't see your point, or are being
arbitrary. It's because we have a community that we feel responsible
for. There are a lot of people on this list, and a lot of people reading
my book, and a lot of people using JDOM, that we don't just make changes
that affect to. James's idea, as many ideas, didn't pass muster in our
opinion (based on what he wrote about the idea, not neccessarily the
idea itself). As a result, we have to either keep talking about the idea
or the submitter passes, and moves on. In this case, James has put his
efforts into another project. I think it would be fair to say that Jason
and I wish that hadn't been the case, and are unconvinced that the same
problems that drove us from interfaces will not haunt James at some
point. But we don't harbor any ill-will towards James, by any means.
Same to all others who have submitted ideas that have been rejected for
one reason or another. But if you are strongly in favor of something,
you need to let us know, and convince us. That's how open source works.

I hope this clears up some of the things going on, and of course
questions to the list are always welcome ;-)

-Brett

> 
> <James/>
> 
> James Strachan
> =============
> email: james at metastuff.com
> web: http://www.metastuff.com
> 
> ----- Original Message -----
> From: "Jason Hunter" <jhunter at collab.net>
> 
> > The name "JDOM", however, is protected.  As everyone can see from
> > reading the LICENSE.txt file and the license text attached to the head
> > of every source file, the JDOM code is licensed under an Apache-style
> > license and license terms 3 and 4 protect the original project name and
> > allow its use only with written permission from JDOM Project
> > management.  James has not sought after or received permission to use
> > the name JDOM, and thus we have asked James to select another name for
> > his project that complies with the license and does not include "JDOM",
> > and also to choose web site names that do not include JDOM either.
> 
> I'm a techie not a lawyer and hadn't looked too deeply at the licence.
> I'll change the name of the project shortly.
> Appologies to Brett & yourself and everyone else in the JDOM community.
> 
> > Brett and I very much hope that people with design ideas continue to use
> > this list as the place for discussion.  I'm always happy to debate the
> > merits of different designs.
> 
> Me too its fun :-)
> 
> Though from Bretts responses...
> 
> > I enjoy that discussion actually; it's one
> > of the nicest perks of this unpaid position.  :-)  It's unfortunate we
> > can't accept every idea, but we believe it's best when making API
> > changes to "Measure twice, cut once" as they say, and the factory model
> > promoted by the forked design definitely raised some hairy unresolved
> > issues.
> >
> > -jh-
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> >
> 
> <James/>
> 
> James Strachan
> =============
> email: james at metastuff.com
> web: http://www.metastuff.com
> 
> ----- Original Message -----
> From: "James Strachan" <james at metastuff.com>
> To: "Jason Hunter" <jhunter at collab.net>; <jdom-interest at jdom.org>
> Sent: Wednesday, December 06, 2000 9:29 AM
> Subject: Re: [jdom-interest] Announce: JDOMPlus a flexible XML framework for
> Java
> 
> >
> >
> > <James/>
> >
> >
> > James Strachan
> > =============
> > email: james at metastuff.com
> > web: http://www.metastuff.com
> >
> > ----- Original Message -----
> > From: "Jason Hunter" <jhunter at collab.net>
> >
> > > The name "JDOM", however, is protected.  As everyone can see from
> > > reading the LICENSE.txt file and the license text attached to the head
> > > of every source file, the JDOM code is licensed under an Apache-style
> > > license and license terms 3 and 4 protect the original project name and
> > > allow its use only with written permission from JDOM Project
> > > management.  James has not sought after or received permission to use
> > > the name JDOM, and thus we have asked James to select another name for
> > > his project that complies with the license and does not include "JDOM",
> > > and also to choose web site names that do not include JDOM either.
> >
> > I'm a techie not a lawyer and hadn't looked too deeply at the licence.
> > I'll change the name of the project shortly.
> > Appologies to Brett & yourself and everyone else in the JDOM community.
> >
> > > Brett and I very much hope that people with design ideas continue to use
> > > this list as the place for discussion.  I'm always happy to debate the
> > > merits of different designs.
> >
> > Me too its fun :-)
> >
> > Though from Bretts responses...
> >
> >
> > > I enjoy that discussion actually; it's one
> > > of the nicest perks of this unpaid position.  :-)  It's unfortunate we
> > > can't accept every idea, but we believe it's best when making API
> > > changes to "Measure twice, cut once" as they say, and the factory model
> > > promoted by the forked design definitely raised some hairy unresolved
> > > issues.
> > >
> > > -jh-
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > >
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> > t.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.
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com