Will, FWIW, here's my 2cents.
A few months back, I started a project using both Xerces-C++ and
libxml (http://xmlnanny.com).
Initially, I was more attracted to Xerces (probably because it was C+
+/OO, which I prefered), so used Xerces wherever I could in my
project (basic XML parsing, DTD and XSD validation), and supplemented
with libxml for features Xerces didn't have (RNG, pull parsing).
Although Xerces is a wonderful toolkit, after having used both, I'm a
much bigger fan of libxml. I've done several xml projects since then,
and chosen libxml exclusively for each. I'm currently planning a
rewrite of my original project and will be using libxml exclusively
and removing Xerces.
Some things I prefer about libxml that I couldn't get Xerces to do
(maybe it was my fault, don't know for sure):
1. libxml allows you to dynamically specify a DTD for validation
without having to hard code the Doctype in the source doc. AFAICT,
you can't do this with XercesC.
2. dynamically specifying an XSD against which to validate a source
document seems MUCH, MUCH easier with libxml.
3. I prefer libxml's error messages... they seem more complete and
make more sense to humans (JMHO).
4. libxml has XmlReader (pull-parsing)
5. libxml has RNG support
6. libxml has XPath support
7. libxml has XInclude support (AFAICT, XercesC doesn't)
To be fair, I found the quality of documentation of the two products
to be about equal.
I don't understand anyone choosing XercesC because it has DOM
support... everyone knows DOM is a pretty crap API, and libxml has
it's own tree api that can do the exact same things, more or less.
Who cares if it's technically 'DOM' or not? I don't get it.
I hope you give libxml a fair shot... screw the DOM ;)
Todd Ditchendorf
Scandalous Software - Cocoa Developer Tools
http://scan.dalo.us
On Dec 19, 2006, at 9:23 AM, Will Sappington wrote:
Hello to all,
I’m a new user of libxml and new to XML in general. I’ve been
asked to evaluate XML libraries, preferably Open Source projects,
for some things we want to do with XML in our products. We provide
an archival/retrieval system for medical records and images and we
use XML for attaching metadata to the files we store. We have some
front-end UI components that make some use of XML but currently
most of the work is done in the transport layer and the backend
database components. Due to the volume of data involved,
efficiency and execution speed is a prime concern, though not
necessarily an overriding one. Most of the XML work being done now
is with roll-your-own string processing. Going forward we will
need to be more sophisticated and standards-compliant.
Of the packages that turned up when I did a search, Xerces and
libxml are the leading candidates. I’ve downloaded, installed,
built, and written test code for both and based on my findings, I’m
leaning very heavily toward recommending libxml. The person I
report to has a very strong bias toward Xerces in general, and the
W3C DOM standard in particular, as the hammer with which to pound
all nails, even if the problem isn’t a nail. I’ve also received
feedback from some of the users in the Xerces group and they make
some points that I should at least consider. What I’d like to do
is present my reasons for recommending libxml, given the job we
need to do as described above, include some of the Xerces users’
comments, and hopefully get your thoughts as well. I like libxml
because:
It’s fast, about 3x faster than Xerces in some fairly rudimentary
tests
It supports XPath (one of our big requirements) on its own, Xerces
requires a bolt-on component like Xalan or Pathan to do XPath.
Being written in C, it has a much simpler programming interface
than Xerces’ C++ object model. Nothing against C++, it’s my
primary language and I like it, but the interface to Xerces is more
complicated, perhaps unnecessarily so, than most of the C++ I’ve
been exposed to. To me, a simpler interface translates to better
understanding by a wider range of programmers, faster up-and-
running time, and potentially better, safer code.
It’s better documented. In addition to the API reference manual,
there’s the let-me-walk-you-through-it tutorial, well documented
sample code, and many pages of additional information on a variety
of topics. The information presented in all areas is more
thorough. Xerces has the Doxygen-generated ref. man., a
Programming Guide (equivalent to the tutorial, but sparse by
comparison), and some commented sample code.
(I may be mistaken about this, but…) for character encodings libxml
uses a standard library (iconv) that is distributed with most
versions of Linux and Unix (and has been ported to Win32), Xerces
uses its own internal routines (?).
In addition to a DOM-like interface and SAX support, libxml has the
XMLTextReader interface which I haven’t tried yet, but I’m assuming
is a fast efficient way to do simple XML queries. Xerces has only
DOM and SAX.
I’ve likened the use of big packages like Xerces for some of the
things we need to “using a blowtorch to light a cigarette”. Here
is one response from a Xerces user:
“Libxml is a great library with somewhat different goals than
Xerces. I
don't think it's explicitly stated on the Web site, but Xerces and
other
projects that build on it tend to implement W3C standards (DOM, XML
Schema), while libxml implements what its maintainer prefers (a unique
API, RelaxNG), with a focus on efficiency. Both approaches are
reasonable, and which is appropriate depends on your needs.
In your shoes, if I were certain that lighting a cigarette is all I
would ever need to do, I'd probably use libxml. In my experience,
though, XML is useful for so many things that I'd probably want to be
prepared to bake, boil, weld, and power fighter jets as well - in a
variety of local languages. I'm a nut for portability, and a DOM
interface has the advantage of being similar or identical in a wide
range of environments (C++, C#, JavaScript, etc).”
What about this? Is Xerces that much more powerful, as the writer
suggests? Is portability the only advantage to W3C-compliant
interfaces like DOM?
And then this:
“In cases where performance is critical, I think you'd be best off
avoiding XPath altogether. (snip) An optimal Xerces SAX parser
might well be more efficient than
libxml parsing + XPath evaluation.”
Finally:
“One big difference between Xerces-C++ and Libxml2 is that the latter
does not have a functional XML Schema validator. I don't know if it
is important to you or not. Also note that much of the speed-up of
Libxml2 compared to Xerces-C++ comes from the fact that Xerces-C++
uses 2-byte characters (UTF-16) while Libxml2 uses 1-byte characters
(UTF-8). Since most performance tests that I am aware of are done
on XML files that are either ASCII or UTF-8, Libxml2 has a natural
advantage here. This is also something to consider depending on the
type of applications you are planning to build.”
I’m unsure of the importance of an XML Schema validator so I can’t
comment on this. I don’t think I agree with the comment about
speed vis a vis UTF-8/16. Encoding conversions using UTF-8 are
more computationally intensive than UTF-16 so what you lose by
moving around double the number bytes would, I think be offset by
the greater CPU requirement for translating the data. Does Xerces’
use of UTF-16 provide support for a wider range of encodings and
local languages?
I know this is rather long and I apologize in advance if it is too
much so, but obviously there’s a lot to be considered, this is a
hefty decision, and I want to provide anybody who might be inclined
to help with as much to go on as possible. Thanks in advance for
any responses,
-will
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
