There are two well-known packages for processing XML documents in Tcl: TclXML [http://tclxml.sf.net/] (and related packages) and [tDOM]. One very common question is "Which package should I use for XML processing, and why?". This page summarizes the features and differences between the two packages in order to provide a (hopefully) unbiased view. I've started this page on the Wiki so that members of both the TclXML and tDOM projects can contribute on an equal basis. (A table would be best here, but I don't know how to get that in Wiki) Packages: * TclXML is separated into three packages: TclXML for parsing, TclDOM for tree processing, TclXSLT for transformations. * tDOM is a single, integrated package. Parser implementations: * TclXML: Pure Tcl (no extension required), C wrappers for expat and (in v3.0) libxml2. * tDOM: C wrapper for expat (plus the "simple" but even faster parser based on work by Richard Hipp, typically well suited for 'data-oriented' XML) DOM implementations: * TclDOM: Pure Tcl (no extension required), 2 C extensions: TclDOM/C and TclDOM/libxml2 (a wrapper for libxml2). * tDOM: C extension. XSLT implementations: * TclXSLT: C wrapper for libxslt. * tDOM: C implementation. TEA Compliance: * TclXML family: Yes. * tDOM: Yes. Performance: * tDOM is reported to have superior runtime performance. * Both tDOM and libxml2/libxslt out-perform most other XSLT processors, though MSXML is reputed to also be a well-performing processor. Memory demand: * tDOM trees need 1.5 - 2 times lesser memory overhead than TclDOM/libxml2 trees. TclDOM/Pure Tcl needs much more memory. * Most Java DOM implementations need notable more memory, to represent a DOM tree. Parsing XML * TclXML: SAX-style callback API, including interposing on external entity resolution. DTD validation. Work is underway on TclXML/TclDOM v3.0 which will allow XML Schema and RelaxNG validation. * tDOM: SAX-style callback API, including interposing on external entity resolution. DTD validation. Posteriori validation (DOM tree validation). Supports more then one script per sax event. Allows DOM building and SAX events in one parsing step. DOM Scripting: * TclDOM fairly strictly adheres to the W3C DOM API: IDL Interfaces are mapped to Tcl commands, live node lists, etc. Tree nodes are represented as "tokens" that are passed as arguments to the DOM commands. * tDOM is somewhat more "Tclish": Tree nodes are defined as Tcl commands. Additionally, tDOM supports also representing nodes as "tokens". Serializing/parsing of subtrees to/form nested Tcl lists. Very 'Tclish' way to create new subtrees (appendFromScript).([SRB] comment: last time I looked some aspects of the W3C DOM spec were not defined, such as '''live''' node lists - someone on the tDOM team may wish to correct or confirm that. [MC] as in methods such as ''$node childNodesLive''? See [http://www.tdom.org/domNode.html]. See below for [de]s notes on [SRB]s comment.) XSLT Scripting: * TclXSLT: Allows stylesheets to be compiled, transformations performed and reuse of the compiled stylesheet. Also allows XSLT/XPath extensions to be implemented as Tcl callbacks. * tDOM: Yes (including stylesheet "compilation" and reuse). XPath * tDOM supports XPath queries. It works very fast. Deplomyent: * tDOM can be used as one C library. There are tDOM modules as part of TclKit. But is not provided by ActiveState Tcl distribution. ---- [TV] As a question from a possibly interested user (because for instance I often use a USB based inet connection which happens to only have windows drivers currently), how safe is all this COM based stuff? -- oops, I thought this page was about COM objects, too. ---- [de]: It is a bit confusing, that TclDOM inlcudes not one DOM implementation, but at least three different ones with different characteristics. Not everything, mentioned above about 'TclDOM' is true for every of the included implementations. For exmaple, if you want to use XSLT with TclDOM, you must use the libxml2 wrapper, with the others you could not use XSLT. The note about strictly adherence to the W3C DOM API targets mainly the scripted TclDOM. The notes about speed and memory usage are about the C wrapper, the scripted TclDOM is much slower/memory hungrier. Etc. ---- SHB (Steve Ball) commented above: ''last time I looked some aspects of the W3C DOM spec were not defined, such as live node lists'' [de]: Since more than tree years (see [http://groups.yahoo.com/group/tdom/message/3]) Steve don't misses to repeat this claim at various occasions, including Tcl Cons. One could get the impression, that this is a major claim, and that this outwights by far any eventual advantages, tDOM may have. So lets take a closer look, what's this fuss is about. The claim is partly false. tDOM nodes have a method 'childNodesLive' (see [http://tdom.org/domNode.html]), even in the oldest tDOM version which I found on my disk (0.5a2 - around 3 years old, or so). Interesting enough, I replied at that time to Steves Mail mentioned above and showed, how one could get such a 'live nodelist' returning method in tDOM with a few lines of tcl code (see [http://groups.yahoo.com/group/tdom/message/6]) and Jochen added code along this lines to the distribution. Yes, there isn't a similar 'live' nodelist returning getElementsByTagName method (the method is there, it returns a tcl list of nodes) and in fact the mentioned childNodesLive is more a skeleton then a robust implementation. But although I'm one of the maintainers of tDOM I never ever have heard any problem report about this. Why so? This brings us to the next point. What about the pratical relevance of this thing? Given, that the programmer would have only a childNodes method at hand, which returns a live nodelist, he would have to write something like set liveNodelist [$node childNodesLive] for {set x 0} {$x < [$liveNodelist lenght]} {incr x} { set childNode [$liveNodelist item $x] # do something with childNode } With the current childNodes method, which returns a tcl list of the childs of the node you simply do foreach childNode [$node childNodes] { # do something with childNode } I only use the second way. Steve not only continues to repeat this claim since years, he is also the maintainer of TclXML/TclDOM. So one would think, that his stuff of course support this feature. In fact, the scripted TclDOM implementation does. But the flagship in the TclXML/TclDOM package is currently Steves Tcl wrapper around the libxml2 library. And guess what? It doesn't support live nodelists. See the release notes of the actual 2.6 release [http://tclxml.sourceforge.net/tcldom/2.6/RELNOTES.txt]. I believe, none of the C wrappers, Steve promoted over the years, ever supported live nodelists. I never understood, why Steve continues to bring up this thing. There are (and always were) tons of much more important points.