cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Visco <>
Subject Re: JDOM and Thank You :)
Date Thu, 27 Apr 2000 23:24:00 GMT


> >
> > Personally your API looks very much like the W3C DOM.
> Hey Keith.  Actually, I'm surprised by that (and you're the first to say
> that).  

Well, when you get down to it, it is similiar. I guess I should have
refrained from saying *very much*, but it's definately simliar. 

> We don't do all the Node inheritance stuff (no getNodeType() or
> instanceof), we don't treat everything as Nodes (element.getContent()
> instead of element.getFirstChild().getValue()), we don't store the lists
> as NodeList and NamedNodeMap, the only similarity is that we allow
> random access to the document, in a tree-like format.

The problem with your random access is that you must do a lot of
instanceof operations. getNodeType() which returns a short is alot
faster than putting 
if (obj instanceof Element) ...etc.

> So yes, the concepts are the same.  One comment we receive a lot of is:
> It's MUCH simpler to use than Xerces or DOM.  It's the
> interface I expected when I first looked at org.w3c.dom.

Actually that is surprising. Though I did see the comment. I agree that
it does remove a small amount of complexity, but at the cost of either
speed (ie. your mixed object list) or being able to move about the tree
in any direction.

> > Of course you've added support for Namespace
> > handling, which DOM level 1.0 doesn't address (mainly because it wasn't
> > relavant at the time), but DOM level 2.0 does address.
> Yes, but does it address it in an intuitive way?

That is subjective (which most of this is anyway), but I do believe it
addresses it in a compliant way and straight forward way.

> > One difference I do see is the Element#getContent() method. I actually
> > don't like this because it removes document order, and I think any good
> > "Document Object Model" (i.e. something modeling the document and not
> > the data) should preseve document order.
> You can still get that through getMixedContent(), which returns
> Elements, Strings, Comments, Entities, etc.  However, it is much more
> common to juse want the Textual value, and not to desire to do lots of
> casting (to CharacterData, Text, CDATA, etc).  "Just give me the
> value!"  However, getMixedContent() gives you everything, in an ordered
> fashion, and you can deal with it how you like.

Ok..I missed that method on my first glance. I do agree that many people
will not always need the proper order of the mixed content. But if you
do, then your API is not an ideal one, since it would most likely be
lots of overhead.

Keep in mind, when you get Node#getNodeType(), you don't always need to
cast the node into an Element or CDATA or Text, etc, since
org.w3c.dom.Node itself provides most of the necessary methods such as
#getNodeName(), #getFirstChild(), etc. 

And if you serious about just dealing with the data of an XML document,
and not the structure of the document, then I suggest doing XML

> >
> > So unless I've failed to see something here, I don't understand what
> > JDOM is actually providing which is supposedly better than DOM?
> speed.  intuitive method calls (getChildren() returns the child elements
> - no need for casting [for example]). 

As I mentioned above, in most cases you just need to know the Node type,
and you don't always need to cast to the proper type.

> Java-centric contructs like List and Map. 

JDK 1.2 centric constructs. As I've learned with my involvement in a
number of open source projects...JDK 1.2 is still not widely used. 

> flyweight implementation.  etc.... (we have a whole website of
> press - I don't want to drone on, as /maybe/ I'm a little biased ;-) )

That's have a right to be biased...I'm just trying to grasp
what I do not.

> Appreciated - you should hop onto jdom-interest and see how things are
> coming - I think you'll see we are quite different from JDOM. ...thanks.


View raw message