I have a hard time agreeing with the argument of increased performance using
an XML to Java binding mechanism over an API that provides generic access to
any XML data source. Any increases in performance gets foreshadowed by the
increase in complexity required to apply/maintain the bindings. I'm
generally never pro or con against any idea. I strive to stand in the
middle of everything and evaluate everything based upon the environment and
the requirements for that particular environment. That said, in the XML
space, real-time communication is the only environment that I know about
that would require the speed gains "implied" by XML -> Java bindings. So if
real time is what you are doing then XML is not the data format you want to
use because XML carries overhead that a real-time system should be avoiding.
But if you are using generic XML and are some kind of speed freak, dom4j
(and other APIs) provide ways to turn up the juice. You can (in dom4j):
1) Write your own tree implementation
and/or
2) Use your own SAXContentHandler to make a custom built Document that
contain only the nodes that your application requires while ignoring the
rest.
Anyway, I've wasted enough of everyone's time with my opinions. Have a good
one
Dane Foster
Equity Technology Group, Inc
http://www.equitytg.com.
954.360.9800
----- Original Message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: "Balaji Iyer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 12, 2001 6:55 AM
Subject: Castor v dom4j (was: Re: [dom4j-user] Thread safety)
Hi Balaji
They are both valid approaches to a similar problem and both have their own
strengths and weaknesses.
Binding XML documents to Java objects is a bit more complex and may result
in a more complex build process as you may need to code generate Java
classes. You also must maintain some 'mapping schema' of some kind. Though
on the plus side, the xml-java binding approach can lead to faster parsing.
The dom4j approach allows you to work with any XML document easily and
allows you full and powerful navigation through that document using XPath
expressions along with easy integration with SAX and XSLT. The downside of
the dom4j approach is that it is a generic XML object model, rather than a
custom Java bean model and so it may be a bit slower to parse.
So I'd say it depends on what you're doing. If you're working with arbitrary
XML documents and find easy navigation with XPath or styling with XSLT
useful, then dom4j is a good approach. If you are using a single, fairly
static XML document schema and are happy to write all the Java code to
navigate your model and you don't mind spending some extra development time
to gain some increased performance then the xml-java binding approach may be
worth considering.
I tend to recommend people start with dom4j as its easier to get going and
XPath and XSLT are really cool and powerful. Then consider moving to Castor,
JAXB, Quick or whatever else if they think XML parsing is becoming a
performance bottleneck.
James
From: "Balaji Iyer" <[EMAIL PROTECTED]>
To: "James Strachan" <[EMAIL PROTECTED]>; "Bill la Forge"
<[EMAIL PROTECTED]>; "Dane Foster" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, June 12, 2001 11:45 AM
Subject: RE: [dom4j-user] Thread safety
Hi All,
I am planning to use Castor apis for xml-java translation. Kindly let
me know if there is any disadvantage compared to use with DOM4J.
For the past few days I have been testing with Castor and its mapping
facilities etc for converting my serializable objects to xml and so and
so forth...Looks good to me.
Thanks,
rgds,
Balaji
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
