Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: JAXP and Java XML APIs (was RE: difference bet. xercesand
 From: "Leigh Dodds" <ldodds@i...> > > > -----Original Message----- > > From: Dylan Walsh [mailto:Dylan.Walsh@k...] > > Sent: 26 September 2001 17:17 > > To: gharesh@v...; Xml-Dev > > Subject: RE: difference bet. xerces and crimson > > [Crimson/Xerces comparison snipped] > > > Xerces supports the JAXP API, so if you write your code to use that API > > exclusively, you can use either parser and switch between them using a > > simple configuration change. > > I've been strongly recommending JAXP mainly because of this reason. > I had some reservations about it initially, simply because it didn't > offer very much (adding a few factory classes isn't that much effort). > However the improvements in JAXP 1.1 caused me to revise my opinion. Agreed - the transformation part of JAXP 1.1 is particularly good. > To me, JAXP seems to be the 'best practice' API for Java (acknowledging > that not everyone agrees on the precise meaning of 'best practice'). > With the only apparent downside being that you 'lose out' on the ability > to use APIs like JDOM and dom4j. Both JDOM and dom4j can use JAXP internally to do the SAX parsing and both can be used as a Source or Result of a JAXP transformation (certainly this is true of dom4j, I think its currently true of JDOM or at least soon will be). Also 'empty' transformers can be used so using JAXP its easy to stream SAX <-> text <-> DOM <-> dom4j <-> JDOM. i.e. JAXP can now be used to go from any XML representation to any other with or without a transformation in between. There's obviously a transformation costs (mostly SAX events are the connectors) but at least its easily possible. This is cool stuff - hats off to the JAXP 1.1 team. I would hope things like JAXB and castor support the JAXP Souce and Result interfaces too, then we can connect 'data binding' approaches with the various doms and SAX and text too. > However quotes such as that on todays Cafe Con Leche (from this > jdom-interest posting [1]) make me wonder if I'm missing out on a trick or > two somewhere. > > I can only attribute this '3 months saving' to the difficulty in the DOM > model. From my own experiences the amount of code I have to write > could have been greatly reduced by a means to query a DOM using > XPath; something which seems to be on the way. > > Anyone else have any thoughts on this? dom4j (http://dom4j.org) has been an easy to use, XML API with integrated XPath navigation for quite some time, maybe you should give that a try ;-) Or there's the cross-model Jaxen XPath engine (http://jaxen.org) which works on DOM, dom4j, EXML and JDOM. For read only access to XML data, I've often wondered if XPath could be a complete replacement for a DOM altogether. i.e. so long as an engine like (say) Jaxen can evaluate XPath expressions on some kind of internal node or nodeset data structure, who cares what its interface looks like. Particularly if it had a way to expose the result of an XPath expression as a JAXP Source and Result so fragments of XML could be turned into specific dom trees if needed. Just a thought... James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
