You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Brett McLaughlin <br...@earthlink.net> on 2000/04/18 22:33:16 UTC
ANN: JDOM
Java + XML = JDOM
If you're from the Silicon Valley area, you may be interested in
attending the Mountain View Java User's Group meeting April 26th where
I'm scheduled to talk about JDOM. Here's the blurb:
What do you get when you mix Java and XML? You get JDOM, the Java
Document Object Model. Haven't heard of JDOM? That's because it's *brand
new* and this talk is one of the first chances to learn about it! Soon
you'll probably hear about JDOM everywhere.
JDOM is an open source API for easily and efficiently reading and
writing XML data. It's a replacement for the ridiculously complex DOM
and SAX APIs. Unlike DOM and SAX, JDOM is optimized for the Java
programmer; it uses standard Java programming idioms and takes advantage
of Java language features. The result is a document model that's more
powerful than DOM and operates at roughly the speed of SAX.
This talk is being given by the co-creators of JDOM -- Jason Hunter,
author of "Java Servlet Programming" (O'Reilly), and Brett McLaughlin,
author of the soon-to-be-released "Java and XML" (O'Reilly).
For details see http://www.mtvjug.org.
If you're in the area, folks, check this out - we have quite a few
surprises in store for you. Not only do we offer a /very/ attractive
alternative to SAX and DOM, we are still 100% interoperable with SAX and
DOM - you can create a JDOM Document from SAX, DOM, and a variety of
other formats, and output to DOM, fire SAX events, plus some more
treats.
This is, in fact, an idea that Jason and I came up with merged with
support from James Davidson and Pier Fumagalli, who had done some
initial work of their own on the concept. I hope to see you there.
-Brett McLaughlin
Author, "Java and XML" (O'Reilly) July 2000
Author, "Enterprise Applications in Java" (O'Reilly) 4th Qtr 2000
Re: ANN: JDOM
Posted by Jason Hunter <jh...@acm.org>.
Arnaud Le Hors wrote:
>
> Hi all,
And an awful lot of "all" there are! I'm replying to everyone since
I think we need to hear from both viewpoints here. PLEASE IF YOU WANT
TO REPLY, join and post to jdom-interest (see http://jdom.org for
sign-up).
> I'll be the first one to say that the DOM is far from being the
> cleanest and leanest API one could dream of but, unlike JDOM, at
> least it truthfully represents XML.
The goal of JDOM is to solve 80% (or more) of a Java programmer's XML
problems with 20% (or less) of the traditional effort. We also need to
be lightweight and fast. This means that some end cases will not be
supported, because to support them would overly complicate learning the
API, overly complicate using the API, require too much memory overhead,
and/or require too much CPU work.
> JDOM appears to fail to even simply represent the XML document tree as
> it should. Processing instructions, for instance, aren't found in the
> tree but instead are stored at the document level.
Yes, this was a conscious decision. In our analysis, we believe that
PIs are (by far) most commonly used by Java programmers without regard
to placement in the Document. Cocoon is a good example. By our
attaching PIs to the Document itself they can easily be retrieved
together, retrieved by name, and manipulated as a set. Order of
appearance is always respected.
We could place them in the tree like we place Comment objects. But do
people really think that's part of the 80% and that losing the
simplicity and efficiency of retrieval (you'd have to walk the tree to
get them) doesn't extend us beyond the 20%? That's a serious
question. Post answers to jdom-interest.
> JDOM confuses entity references and entities. While entity refs are
> represented by an Entity object, entities are simply absent.
Entities are an area of active design. We haven't talked much about
them because they aren't finished. Please join the jdom lists and make
suggestions.
> The way namespaces are handled show a clear misunderstanding of the
> basics of XML namespaces and, unless a serious redesign is undertaken,
> it will only work for simple cases.
It doesn't represent a clear misunderstanding. It represents an
intentional simplification. Implementing scoped namespaces
*efficiently* is quite a challenge. The obvious approach is to store
all the namespace information inside every Element, but that causes
tremendous memory bloat and makes it a lot harder to move elements
between documents. We're investigating good designs. If you have
ideas, pipe up.
> So, if the DOM is "ridiculously complex", JDOM appears to be
> ridiculously simple... Sorry, I couldn't resist. ;-)
Hey, Java can't do everything C can do either. :-)
-jh-
P.S. Remember, follow-ups to jdom-interest. Let's not annoy everybody.
Re: ANN: JDOM
Posted by Jason Hunter <jh...@acm.org>.
Arnaud Le Hors wrote:
>
> Hi all,
And an awful lot of "all" there are! I'm replying to everyone since
I think we need to hear from both viewpoints here. PLEASE IF YOU WANT
TO REPLY, join and post to jdom-interest (see http://jdom.org for
sign-up).
> I'll be the first one to say that the DOM is far from being the
> cleanest and leanest API one could dream of but, unlike JDOM, at
> least it truthfully represents XML.
The goal of JDOM is to solve 80% (or more) of a Java programmer's XML
problems with 20% (or less) of the traditional effort. We also need to
be lightweight and fast. This means that some end cases will not be
supported, because to support them would overly complicate learning the
API, overly complicate using the API, require too much memory overhead,
and/or require too much CPU work.
> JDOM appears to fail to even simply represent the XML document tree as
> it should. Processing instructions, for instance, aren't found in the
> tree but instead are stored at the document level.
Yes, this was a conscious decision. In our analysis, we believe that
PIs are (by far) most commonly used by Java programmers without regard
to placement in the Document. Cocoon is a good example. By our
attaching PIs to the Document itself they can easily be retrieved
together, retrieved by name, and manipulated as a set. Order of
appearance is always respected.
We could place them in the tree like we place Comment objects. But do
people really think that's part of the 80% and that losing the
simplicity and efficiency of retrieval (you'd have to walk the tree to
get them) doesn't extend us beyond the 20%? That's a serious
question. Post answers to jdom-interest.
> JDOM confuses entity references and entities. While entity refs are
> represented by an Entity object, entities are simply absent.
Entities are an area of active design. We haven't talked much about
them because they aren't finished. Please join the jdom lists and make
suggestions.
> The way namespaces are handled show a clear misunderstanding of the
> basics of XML namespaces and, unless a serious redesign is undertaken,
> it will only work for simple cases.
It doesn't represent a clear misunderstanding. It represents an
intentional simplification. Implementing scoped namespaces
*efficiently* is quite a challenge. The obvious approach is to store
all the namespace information inside every Element, but that causes
tremendous memory bloat and makes it a lot harder to move elements
between documents. We're investigating good designs. If you have
ideas, pipe up.
> So, if the DOM is "ridiculously complex", JDOM appears to be
> ridiculously simple... Sorry, I couldn't resist. ;-)
Hey, Java can't do everything C can do either. :-)
-jh-
P.S. Remember, follow-ups to jdom-interest. Let's not annoy everybody.
Re: ANN: JDOM
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Hi all,
While I unfortunately missed the presentation last night, I had a look
at JDOM. I must say that while it is definitely simpler, it can hardly
compare to the DOM.
I'll be the first one to say that the DOM is far from being the cleanest
and leanest API one could dream of but, unlike JDOM, at least it
truthfully represents XML.
JDOM appears to fail to even simply represent the XML document tree as
it should. Processing instructions, for instance, aren't found in the
tree but instead are stored at the document level.
JDOM confuses entity references and entities. While entity refs are
represented by an Entity object, entities are simply absent.
The way namespaces are handled show a clear misunderstanding of the
basics of XML namespaces and, unless a serious redesign is undertaken,
it will only work for simple cases.
So, if the DOM is "ridiculously complex", JDOM appears to be
ridiculously simple... Sorry, I couldn't resist. ;-)
--
Arnaud Le Hors
-----------
Brett McLaughlin wrote:
>
> Java + XML = JDOM
> If you're from the Silicon Valley area, you may be interested in
> attending the Mountain View Java User's Group meeting April 26th where
> I'm scheduled to talk about JDOM. Here's the blurb:
>
> What do you get when you mix Java and XML? You get JDOM, the Java
> Document Object Model. Haven't heard of JDOM? That's because it's *brand
> new* and this talk is one of the first chances to learn about it! Soon
> you'll probably hear about JDOM everywhere.
>
> JDOM is an open source API for easily and efficiently reading and
> writing XML data. It's a replacement for the ridiculously complex DOM
> and SAX APIs. Unlike DOM and SAX, JDOM is optimized for the Java
> programmer; it uses standard Java programming idioms and takes advantage
> of Java language features. The result is a document model that's more
> powerful than DOM and operates at roughly the speed of SAX.
>
> This talk is being given by the co-creators of JDOM -- Jason Hunter,
> author of "Java Servlet Programming" (O'Reilly), and Brett McLaughlin,
> author of the soon-to-be-released "Java and XML" (O'Reilly).
>
> For details see http://www.mtvjug.org.
>
> If you're in the area, folks, check this out - we have quite a few
> surprises in store for you. Not only do we offer a /very/ attractive
> alternative to SAX and DOM, we are still 100% interoperable with SAX and
> DOM - you can create a JDOM Document from SAX, DOM, and a variety of
> other formats, and output to DOM, fire SAX events, plus some more
> treats.
> This is, in fact, an idea that Jason and I came up with merged with
> support from James Davidson and Pier Fumagalli, who had done some
> initial work of their own on the concept. I hope to see you there.
>
> -Brett McLaughlin
> Author, "Java and XML" (O'Reilly) July 2000
> Author, "Enterprise Applications in Java" (O'Reilly) 4th Qtr 2000
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: ANN: JDOM
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Brett McLaughlin wrote:
>
> This is, in fact, an idea that Jason and I came up with merged with
> support from James Davidson and Pier Fumagalli, who had done some
> initial work of their own on the concept. I hope to see you there.
So, I believe I _have_ to come :) See you there :)
Pier
--
----------------------------------------------------------------------
pier: stable structure erected over water to allow docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
----------------------------------------------------------------------
Re: ANN: JDOM
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Hi all,
While I unfortunately missed the presentation last night, I had a look
at JDOM. I must say that while it is definitely simpler, it can hardly
compare to the DOM.
I'll be the first one to say that the DOM is far from being the cleanest
and leanest API one could dream of but, unlike JDOM, at least it
truthfully represents XML.
JDOM appears to fail to even simply represent the XML document tree as
it should. Processing instructions, for instance, aren't found in the
tree but instead are stored at the document level.
JDOM confuses entity references and entities. While entity refs are
represented by an Entity object, entities are simply absent.
The way namespaces are handled show a clear misunderstanding of the
basics of XML namespaces and, unless a serious redesign is undertaken,
it will only work for simple cases.
So, if the DOM is "ridiculously complex", JDOM appears to be
ridiculously simple... Sorry, I couldn't resist. ;-)
--
Arnaud Le Hors
-----------
Brett McLaughlin wrote:
>
> Java + XML = JDOM
> If you're from the Silicon Valley area, you may be interested in
> attending the Mountain View Java User's Group meeting April 26th where
> I'm scheduled to talk about JDOM. Here's the blurb:
>
> What do you get when you mix Java and XML? You get JDOM, the Java
> Document Object Model. Haven't heard of JDOM? That's because it's *brand
> new* and this talk is one of the first chances to learn about it! Soon
> you'll probably hear about JDOM everywhere.
>
> JDOM is an open source API for easily and efficiently reading and
> writing XML data. It's a replacement for the ridiculously complex DOM
> and SAX APIs. Unlike DOM and SAX, JDOM is optimized for the Java
> programmer; it uses standard Java programming idioms and takes advantage
> of Java language features. The result is a document model that's more
> powerful than DOM and operates at roughly the speed of SAX.
>
> This talk is being given by the co-creators of JDOM -- Jason Hunter,
> author of "Java Servlet Programming" (O'Reilly), and Brett McLaughlin,
> author of the soon-to-be-released "Java and XML" (O'Reilly).
>
> For details see http://www.mtvjug.org.
>
> If you're in the area, folks, check this out - we have quite a few
> surprises in store for you. Not only do we offer a /very/ attractive
> alternative to SAX and DOM, we are still 100% interoperable with SAX and
> DOM - you can create a JDOM Document from SAX, DOM, and a variety of
> other formats, and output to DOM, fire SAX events, plus some more
> treats.
> This is, in fact, an idea that Jason and I came up with merged with
> support from James Davidson and Pier Fumagalli, who had done some
> initial work of their own on the concept. I hope to see you there.
>
> -Brett McLaughlin
> Author, "Java and XML" (O'Reilly) July 2000
> Author, "Enterprise Applications in Java" (O'Reilly) 4th Qtr 2000
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: JDOM
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: Brett McLaughlin [mailto:brettmclaughlin@earthlink.net]
> Sent: Wednesday, April 19, 2000 12:50 PM
>
> Yup. Look for a major announcement within the next 2 weeks - after
> that, it will be all open, all the time...
Excellent!
> Parts of the sitemap, and maybe JDOM integration...?? ;-)
JDOM to parse the sitemap config file... that would be nice. I'm was about
to add some new features to my own sitemap, but I needed to move from a
properties file to an XML config file to handle the more complicated
mapping. Just about to do this when you mentioned JDOM, so I decided to wait
until I can get my hands on the beast. Since I have to rework my own sitemap
and I plan on using cocoon 2 to handle the presentation layer, maybe I
should jump in and help out with the cocoon 2 sitemap where there is some
common ground.
> That site is on the list, but after the JDOM site (too many things, too
> little time). But it will get there... my schedule is getting better,
> so it shouldn't be too long...
Oh Good! I'll be waiting...
OK, back to playing with Castor.
-david
Re: JDOM
Posted by Brett McLaughlin <br...@earthlink.net>.
David Duddleston wrote:
>
> > Java + XML = JDOM
> > If you're from the Silicon Valley area, you may be interested in
> > attending the Mountain View Java User's Group meeting April 26th where
> > I'm scheduled to talk about JDOM. Here's the blurb:
>
> Wish I could attend. Are you going to post anything for those of us who are
> not in the Mountain View area.
Yup. Look for a major announcement within the next 2 weeks - after
that, it will be all open, all the time...
>
> > Cocoon 2
>
> I get the idea that you will be working on Cocoon 2 from your post on the
> cocoon-dev list. What part are you going to tackle?
Parts of the sitemap, and maybe JDOM integration...?? ;-)
>
> > Framework
>
> Any chance you will be releasing the code for your new framework before the
> 2nd book? I'm real interested in checking it out. I have a feeling it is
> just the framework I'm looking for.
That site is on the list, but after the JDOM site (too many things, too
little time). But it will get there... my schedule is getting better,
so it shouldn't be too long...
>
> Damn Brett, you are killing me with the suspense.
That's good; it will keep you interested!! Seriously, we'll have
something *very* soon.
-brett
>
> -david
RE: JDOM
Posted by David Duddleston <da...@i2a.com>.
> Java + XML = JDOM
> If you're from the Silicon Valley area, you may be interested in
> attending the Mountain View Java User's Group meeting April 26th where
> I'm scheduled to talk about JDOM. Here's the blurb:
Wish I could attend. Are you going to post anything for those of us who are
not in the Mountain View area.
> Cocoon 2
I get the idea that you will be working on Cocoon 2 from your post on the
cocoon-dev list. What part are you going to tackle?
> Framework
Any chance you will be releasing the code for your new framework before the
2nd book? I'm real interested in checking it out. I have a feeling it is
just the framework I'm looking for.
Damn Brett, you are killing me with the suspense.
-david