Looking for a modern DOM/XSLT/Xpath implementation in C

June 14, 2005 3:47 PM

My boss has tasked me with tracking down a modern XML library written in C. The library has to run on (at least) RHEL3, Windows, and Solaris, but more is better.

I've seen tDOM, but it doesn't look like it's as up to date as we need. However, I'm not too up on the standards (that's part of my quest) so I don't know for sure. It's possible that domc is what I'm looking for, but, again, I lack the knowledge of the standards required to judge it.

Can someone help direct my inquiries here? Are there other options? How would I best evaluate them?

posted by ChrisR to computers & internet (9 comments total)

The one-two-three punch of libxml/libxslt/libgdome?
posted by togdon at 4:03 PM on June 14, 2005

I'm happy with TinyXml, though it's C++.
posted by funkbrain at 5:01 PM on June 14, 2005

Use the big daddy http://expat.sourceforge.net/
or xerces (xml) and Xalan (xslt) of apache fame http://xml.apache.org/index.html.

all are written in c or c++ and compile on unix and windows
posted by jumpsuit_boy at 6:03 PM on June 14, 2005

I use libxml without (major) problems under Linux, Solaris and Windows.
posted by phatboy at 6:11 PM on June 14, 2005

I use libxml2 on Linux, as well. It's easy to work with, portable, it has both DOM and SAX interfaces, and it's MIT licensed, so it's very permissive.
posted by cmonkey at 8:51 PM on June 14, 2005

As far as I know, Xerces and Expat are the most popular. Xerces is provided under the Apache license and Expat is provided as-is.
posted by azazello at 11:50 PM on June 14, 2005

Expat is kind of the universally-available default. Experience at my workplace has been that Xerces/Xalan is a real pain to work with (massively overengineered?) and libxml2 is what we're moving to instead (except for where we're sticking to expat, or totally proprietary stuff). It's possible that we just don't need what Xerces is designed to provide.

Re "how should I evaluate them": first figure out what you need. Do you want to write something that builds and manipulates an in-memory representation of the XML tree (a DOM or whatever), or something that feeds into/out of your existing data model? Do you need DTD or schema checking? External entities? XSLT? Can your whole document fit in RAM or do you need to stream stuff? etc.
posted by hattifattener at 12:09 AM on June 15, 2005

are you sure you need c? in my experience, java libraries tend to be maintained more often, especially in obscurer corners of standards. of course, you may need c if this is for linking directly, but with something xslt or svg (which you don't mention) a standalone solution may be sufficient.

also you sounds worryingly vague about your requirements. do you understand the difference between sax and dom? do you want to a quick and easy solution to for small datasets (dom), or are you looking to process large structures/volumes efficiently (sax)? if you're thinking of xsl, have you actually tried using it (it's cool, but has a steep learning curve if you're not used to functional / declarative programming).
posted by andrew cooke at 3:38 AM on June 15, 2005

Yes, we strictly require c. This would have to integrate directly with existing C code, without the overhead of a JVM.

Also, we're working mainly with small data sets -- XML descriptors and messages, specifically, that will be handled entirely in-memory. At the moment, we have a home-grown DOM 1.5-ish (yep, that's what I meant) xml parser with a good, if incomplete, xpath library, and for the stylesheets we're regrettably using Java... which has performance characteristics that are not going to remain acceptable for long, in the situation that we're using it.
posted by ChrisR at 6:52 AM on June 15, 2005