xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Le Hors <leh...@us.ibm.com>
Subject Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Date Mon, 02 Apr 2001 17:54:39 GMT
I've been pondering whether I should reply or not. I don't want a war,
I'm a peaceful guy. So I was thinking that maybe simply dropping the
ball was the best thing to do. As a middle ground kind of solution I
have decided to simply clarify a few points and to leave aside the rest
that might be more controversial.

Brett McLaughlin wrote:

> ... you are saying "JDOM authors don't know
> XML because Jason doesn't know DOM."
> Really a false assertion.

You're wrongly extrapolating what I say here. All I say is that Jason
criticized the DOM even though he didn't know it. Nothing else.

> And there is certainly no value in comparing "size" of
> classes, unless you mean memory footprint.

There can actually be value in comparing the size of classes in contexts
such as hand-held devices, but I meant memory footprint.

Note that the DOM implementations you're referring to are all 'vanilla
implementations'. These are implementations which do not carry any
particular behavior and which are not designed for any particular use.
Too few people know that this is not what the DOM was designed for in
the first place though. The DOM was designed so that applications that
have their own data structures could expose them in a standard way.
Which is why it's only made of interfaces.
Performance and memory footprint may greatly vary depending on the
implementation, but that's the price to pay for interoperability. It's
better to run slow than to not run.

JDOM is radically different for that matter. It's a specific structure.
If it suits your needs that's fine but if you have your own data
structure you have to convert from one to the other. Note that this is
often what people do with vanilla DOM implementations and I'm the first
one to say it's wrong! The right model is: build your own data structure
with SAX and expose it through DOM if you need to.

> Do you, every time someone asks you how fast Xerces builds a
> DOM tree, explain that it is actually SAX being used to build the DOM tree,
> and their question is really not correct?

FYI, the DOMParser in Xerces does not really use SAX. It's based on a
native SAX-like API.

> I understand that you like DOM far better,

I challenge you to find any quote from me stating that I like DOM. As
I've stated in the past I like STANDARDS. Being standard is to me far
more important than being something I like from an academic point of

> why, for example, using the DOMParser in Xerces might throw a SAXException... is
> that something you always cover? Isn't that confusing to some who you are
> trying to get a higher-level point across to?

It certainly is, but that's only because there is currently no standard
API to parse a document in DOM. When DOM Level 3 comes out with its
'Load and Save' module we will implement it and all this should
Arnaud  Le Hors - IBM Cupertino, XML Strategy Group

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