There are two well-known packages for processing XML documents in Tcl: TclXML [L1 ] (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:
Parser implementations:
DOM implementations:
XSLT implementations:
TEA Compliance:
Performance:
Memory demand:
Parsing XML
DOM Scripting:
XSLT Scripting:
XPath
Deplomyent:
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 [L3 ]) 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 [L4 ]), 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 [L5 ]) 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 [L6 ]. 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.