OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JAXP and Java XML APIs (was RE: [xml-dev] difference bet. xercesand crimson)



From: "Leigh Dodds" <ldodds@ingenta.com>
>
> > -----Original Message-----
> > From: Dylan Walsh [mailto:Dylan.Walsh@kadius.com]
> > Sent: 26 September 2001 17:17
> > To: gharesh@vsnl.com; Xml-Dev
> > Subject: RE: [xml-dev] 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