We're getting pretty far afield here, so this will probably be my last post
on the topic. If the community Really Wants to hear it debated... and if so
we should probably find a more appropriate venue.
>In practice, the single implementation means JDOM code is more
>portable, not less.
We agree that we disagree. "Only one implementation" means JDOM can't be
implemented as a wrapper around other models, which means that unless
*everything* you're doing is built around JDOM you have to pay the overhead
of copying the data out of something else and into JDOM. That imposes
storage/CPU overhead, and multiple imports reintroduces most of the same
portability risks that multiple DOMs would have.
If you're doing an isolated one-off application, this doesn't matter. If
you're looking at writing reusable components, it does. As I say, there are
JDOM derivitives which solve this particular problem more elegantly.
I still haven't seen realworld evidence that JDOM actually adds much
convenience. The small samples I've seen have generally been
(unintentionally, I'm sure) biased, since they did things that made the
JDOM sample more efficient which could equally well have been done in the
DOM sample and were simply missed, or leveraged JDOM features but not DOM
features. In larger samples, some of the differences mostly disappear; how
many lines it takes to load a document from a file is less significant when
load is a tiny percentage of what your application is actually doing with
the document.
The remaining functional difference seemed to be the sorts of things where
a trivial set of helper functions provide the equivalents.
Which leaves us with stylistic differences. JDOM, since it's Java-specific,
is more idiomatically Java-ish; the DOM, because it's intended to be
language independent, avoided things like method overloading. I honestly
consider that a nit, but I recognize that some folks consider it more
important. I just don't think locking yourself into a specific back-end
model because you don't like a particular API is a wise trade-off.
I agree that the cross-language nature of the DOM doesn't buy you much
direct code portability. What it does buy is algorithmic portability --
making it easier to move your solutions, and your skills (!), to a
different language. Whether that matters to you depends on whether you
expect your boss or customers to ever be interested in non-Java solutions.
(Sure, you could port JDOM to the new language. But you'd probably have to
do so yourself rather than leveraging someone else's work, you'd risk
running into the language-specific-features issues the DOM deliberately
avoided.)
I *don't* think the DOM is a perfect solution for everyone, and I
absolutely agree that for specific applications non-DOM code is the Right
Way To Go. Xalan, for example, uses a custom data model under the covers
because a naive DOM didn't suit our needs. (And in fact we're currently
looking at generalizing that API, which among other things might make
reading from a JDOM easier...) If that sort of internal/back-end model is
what you're looking for, JDOM might be one off-the-shelf solution worth
looking at. But that's where I see JDOM fitting -- it's specifically a
model implementation, rather than an API, and I'm a firm believer in
standardized APIs that can be reimplemented to address varying needs.
Your milage may vary. Void where prohibited by law. Post no bills.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
