xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Date Sun, 01 Apr 2001 22:00:39 GMT
For the record, it was not my intention to re-ignite the DOM vs. JDOM war.
I could have used W3C Schema vs. TREX or RELAX as well.   The original
context was the use of "standards" as a constraint on the kinds of projects
covered by the charter.   During the discussion, it was claimed that
had never been used to exclude promising work from xml.apache.org.  I
dredged up the JDOM issue because in fact "standards" had been used
for this purpose.

My position is essentially the one the Scott has stated recently.  Standards
(good or bad) are an important part of what we do here.   I don't really
that's ever been open to debate (at least in my mind).   But standards are
not the only thing that is important for xml.apache.org projects.

We now return you to our regularly scheduled disagreement...

----- Original Message -----
From: "Brett McLaughlin" <brett@newInstance.com>
To: <general@xml.apache.org>
Cc: "Jason Hunter" <jason@jdom.org>
Sent: Sunday, April 01, 2001 12:29 PM
Subject: Re: JDOM in Apache (was Re: xml.apache.org charter proposal)

> Arnaud has some points that are good, and some that I want to address. See
> comments inline... and we'll try and be nice to each other this go round
> ----- Original Message -----
> From: "Arnaud Le Hors" <lehors@apache.org>
> To: <general@xml.apache.org>
> Sent: Sunday, April 01, 2001 12:52 PM
> Subject: Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
> > I'm being cited so I should probably state my position to make it clear.
> >
> > It is true that I think we should not use JDOM in Xerces because it is
> > not a standard. But it is also true that I think we should not use JDOM
> > in Xerces because I don't like it. So both Ted and Scott are right. :-)
> Good starting point :) It's also fair to point out that I don't like DOM,
> which is why Arnaud and I are often at odds ;-)
> >
> > Now, before Jason or Brett jumps in with one of their favorite
> > statements a la 'but JDOM is now a JSR and is in the process of becoming
> > a standard', let me explain why I don't like it. Because this won't be
> > changed by the fact that JDOM becomes a standard.
> OK. So that's fair; if the standard argument goes away, though, we can at
> least talk technical merits; that's a more interesting discussion, anyway.
> However, I would think that it would be apparant that JDOM standardization
> at least /increases/ the impetus to have a JDOM option as part of Xerces,
> even if it's an add-on (as we've always said would be a good compromise).
> At the end of the day, if Xerces (as a parser) is only what you or another
> developer likes, I think that is a problem. If this was Cocoon or some
> one-off type new innovation, that wouldn't be true. But this is an "XML
> parser" and as such needs to support XML parser and related APIs in my
> opinion. But I still think it's good to discuss JDOM technically, as (1)
> educates and (2) it can improve JDOM.
> >
> > I don't like JDOM mostly because it has been promoted from the beginning
> > on bogus assertions, by people who don't know what they were talking
> > about (Jason admitted to me, in public, that he had never read the DOM
> > spec). To start with, even though it doesn't compare to the DOM, it's
> OK. Let's deal with that, first. That's probably true. However, Jason
> was and never will be the XML guy; he's the Java guy. And he'll also admit
> that I wrote 90% of the code for the first three or four versions of JDOM,
> including all the DOM and SAX code. He's now very current on those specs
> does lots of work on the two, but you are saying "JDOM authors don't know
> XML because Jason doesn't know DOM." Really a false assertion. I at least
> know XML well enough to write the O'Reilly book on Java and XML
> of what you think about that), so that's certainly something. The fact
> I've written a Java API for XML, a data binding API for XML (twice now),
> close to thirty articles for online publications (including IBM, over 5
> them!) should establish me as knowledgeable about XML. So to say I don't
> know what I'm talking about is simply false ;-)
> > been promoted as 'faster and smaller than DOM'. But how in the world can
> > a set of concrete classes be faster and smaller than a set of
> > interfaces?? This doesn't make ANY sense.
> Hmmm... smaller? Maybe "smaller memory footprint" which turns out to be
> in the sense which we used it; which is, for an XML document (call it
> using any existing DOM implementation within a parser we have found
> Xerces, XML4J, Crimson, etc), using JDOM to parse that document via
> SAXBuilder versus using DOM, the JDOM parse/build is faster than the DOM
> one. That's emprical evidence. That's also still the case when using
> deferred DOM, btw (although I don't have the numbers to post, that's a
> recent test). And that's for any XML document we've tried, not ones we
> specifically formulated.
> Yes, there is the possibility that a better DOM impl could be written, and
> that it might be faster than JDOM. But to say that "JDOM might not be
> than some theoretical DOM" is, at best, fairly stupid to say ;-) Just
> because we're technical doesn't mean we have to be idiots about promoting
> JDOM, right? :-) And there is certainly no value in comparing "size" of
> classes, unless you mean memory footprint. And btw, the deferred DOM did
> have a smaller memory footprint, but as we all know that is a tradeoff for
> performance. But, I want to be in full disclosure mode here :) So I don't
> see those statements as ambiguous; we don't hide that JDOM is concrete
> classes. In fact, it's one of the first things we point out, as that has
> been a popular aspect of it. At the same time, I'm not going to lecture
> 30 minutes on classes versus interfaces to ensure that people walk away
> a byte-level understanding of what a faster implementation means.
> >
> > In addition, I really dislike the way Jason and Brett have been
> > marketing JDOM. They say it has nothing to do with DOM, but its name for
> > a starter leads the mass to confuse the two. And this is no accident.
> It has plenty to do with DOM. It's a tree model for parsing XML documents,
> it's a document object model, etc., etc. I've never said that; I've said
> is not related to the DOM specification in implementation. We don't wrap
> interfaces, extends interfaces, extend impl classes, or anything technical
> that ties or relates us to DOM. In fact, I finished the 2nd edition of my
> chapter on JDOM just this week, and all this is very clear in that.
> > Even though they don't compare, DOM is being used to leverage JDOM. At
> > the XMLDevCon in San Jose, after a two hour presentation on JDOM a guy
> > asked 'DOM Level 2 just became a recommendation, is JDOM compliant?'.
> > Jason clearly annoyed first tried to explain why it is not, but this
> > statement was quickly softened by Brett who said it was 'DOM Level 2
> > compatible' because one could build a JDOM tree with DOM Level 2. At
> > that point the guy looked relieved... What do you think he understood???
> Oh, come on ;-) Do you, every time someone asks you how fast Xerces builds
> DOM tree, explain that it is actually SAX being used to build the DOM
> and their question is really not correct? No; you answer them. And that's
> exactly what I would do. I a conference setting, you answer at the level
> the questioner. Jason gave some technical answers, the guy looked
> so I brought it up to his level. That's a good presentation (by both of
> not marketing ;-) I understand that you like DOM far better, and I'm OK
> that; but I'm not going to give you a hard time about not mentioning why,
> for example, using the DOMParser in Xerces might throw a SAXException...
> that something you always cover? Isn't that confusing to some who you are
> trying to get a higher-level point across to?
> >
> > I also dislike the fact that from day one JDOM was self declared as an
> > 'emerging standard'. De facto standards happen because of their
> > technical merit. There is no need to give a presentation in every
> > conference and write an article in every magazine for that to happen.
> Fair enough. And I think it's also fair to say that we have significantly
> toned down the "marketing machine." I haven't written a JDOM article in 9
> months, Jason in about that long. The last presentation on it was at the
> conference (duh... that's where it got started), and before that at XML
> DevCon. So 3 or 4 presentations a year is not that much; however, it's
> to say that we get asked to do these, and now have many others in the
> community doing the work for us. The latest version of Java Examples in a
> Nutshell covered JDOM, Elliotte Rusty Harolde includes it in his XML
> presentations and has done JDOM presentations, Simon St. Laurent uses it
> some of his... there is certainly an emerging API, and I'll leave Sun to
> standardize, as they have wanted to do (without our urging I might add).
> So I will apologize for the initial way in which things were handled; I
> admit that I, and we, could have been more tactful. We were excited, and
> excited, and ... well, excited. I think that's OK in general, and for the
> trouble we caused I think we both regret that. However, that's in the
> and I think it's more than fair to say that we've been increasingly
> and careful. When is the last time you have seen Jason or I on lists like
> this talking JDOM? In fact, it was Ted that brought it up this time
> Ted ;-) ).
> >
> > And apart from all of this, I don't like JDOM because it is too much
> > object oriented. In my opinion relying on Java 2 collections which force
> > you to create new objects to perform a simple traverse is bad. Yes, I
> > know, I'm going to choke more than one person here, but the fact is that
> > objects are expensive, despite what Sun's marketing machinery would like
> > us to believe. As a matter of fact I wish the DOM wasn't so much OO. And
> > for that reason I certainly don't think DOM is the only API that should
> > exist to manipulate XML documents in memory. I would fully support a DTM
> > effort at Apache (cf Scott's message).
> OK. I agree, technically, with you here 100%. Objects are VERY expensive,
> and trusting a JVM to take care of that is not very smart, IMO. However,
> that does not mean, in any case, that objects are not very USEFUL. 90% of
> Java developers never want to worry about performance optimizations by
> weak references and the like, and the other 10% go out and buy JProbe.
> Optimization these days is using StringBuffers instead of Strings. So, we
> had a choice; we could either put in all these optimizations, and create
> classes for our own lists and things, and confuse some users (as,
> DOM does). Or, we could accept that people want to work in a way that's
> familiar to them, and accept that that way has a cost (we all know C is
> still faster than Java for most tasks when programmed in correctly, but
> which language are we all using?). Once you accept that, as we did, it
> became clear that people wanted to work in that way; that way, in this
> included Collections and OO-programming. So we made JDOM conform. So yes,
> could be faster, it could be optimized, it could be less costly to use;
> at the COST of usability. And for JDOM, the goal is USUABILITY. So I agree
> with you technically here completely, but I also think that JDOM clearly
> states that its goal is usability, not to squeeze out every drop of
> performance at the cost of that usability. I think we've been very clear
> that (check the webpage - it's in the mission statement), so using that as
> watermark is not really appropriate, IMO.
> Again, lots of good points, Arnaud. Some I agree with, some I think are
> valid but I don't agree with, and there are a few that are based on some
> incorrect information, which I've tried to correct to some degree here. I
> hope we can both agree to disagree a little more nicely here, and accept
> that at times I am going to cast a poor light on DOM, because I don't like
> it; and the converse is true for you, which is fine too. I'd just rather
> keep the war off of the streets... fair enough?
> -Brett
> > --
> > Arnaud  Le Hors
> >
> > ---------------------------------------------------------------------
> > In case of troubles, e-mail:     webmaster@xml.apache.org
> > To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> > For additional commands, e-mail: general-help@xml.apache.org
> >
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message