We have several tools to deal with XML: TclXML, tDOM... which serve the same purpose with different interfaces. It might be a good idea to unify those under a single Tcl interface, so one can plug in different implementations (including the gnome XML libraries...)
KMG - 2005 Sep 08
I think snitDom goes a long way towards solving this problem.
Please explain why this is necessary? I think in general development, people pick the tool they like the best and stick with it. So what advantage would I have if I used a single interface? I always wondered about this same problem with SQL interfaces. The example I can think of is the ns_db command in AOLserver. Yes its great. However it only provides a basic interface to SQL databases. Look at the Oracle driver. They had to create a separate command to implement things such as binding. Is it possible that a single XML interface could be susceptible to the same problems? And what advantages would I gain by plugging in different XML libraries?
Well, I for one would find it useful. I have occassional interest in writing generic code (such as StarSite) where I would like to plug in XML processing capabilities. However, I don't want to limit developers using my code to my favourite XML processor. With a universal API, anyone could plug in their processor of choice. Sometimes, I like tDOM because of its speed and efficiency, and its excellent XPath capabilities, but others I long for TclXMLs pure-Tcl version, so I don't have portability problems on platforms that I don't have a compiled tDOM for.
NEM.
But either way you are forcing something on the user. Either a specific XML processor or a specific API. I do suppose there is a small advantage to being able to plug in any XML processor should someone need to increase speed or run on a platform that is lacking a binary for a given XML processor.
<rant> Two to three years ago I tried to have discussions, on various occasions, with Jochen Loewer about merging the TclXML/TclDOM and tDOM projects - all to no avail. I've pretty much given up now. Personally I've always thought that it is pointless having multiple interfaces to do the same thing and requiring developers to make a choice (when that would be so easily avoided).
Is there a danger in this, similar to SQL APIs? Any danger is minimal. Look at the SAX API - there are several implementations for Java, as well as Python and Perl (and C, C++) but the API remains stable. </rant>
PT writes: I have a TclDOM to tDOM interface conversion package in TclSoap - however, tDOM currently cannot create an empty DOM document. In tcldom and using Microsoft's DOMDocument via tcom we can create a document with no elements and then pass it around to be filled up. TclSOAP uses this extensively. Once the tDOM document is enhanced to support this (and de has suggested this might be quite soon) then we have an 'shim' package that can plug-in tDOM as a replacement for tcldom. (de: Creation of documents with no elements was added to tDOM 0.8.0, released 8/2004.)
JR: forcing - or mostly forcing - something on the user isn't really all that bad; in fact it can be good by reducing the number of decisions they need to make. The ns_db interface is a great example if this: the functionality it provides covers 95% of what most users need from it. For that remaining 5% there is the ns_ora escape hatch. Providing every bit of functionality that anyone might want leads to a bloated and unnecessarily confusing interface. This is a common flaw, particularly in bindings to C libraries; one could blame the simplicity of using SWIG to generate interfaces to every existing function, but the blame lies on implementors who don't want to bother thinking about what people would actually find useful. Yes, there are a few people who would find it useful to have a direct tcl binding to Xlib instead of Tk, but the other 95% find Tk mich simpler to use.
As to how this applies to an XML wrapper, I too think this would be useful, in part because it would let me choose which escape hatch I want to use. In my SOAP application I do my own processing of XML and I find tDOM much nicer to use than TclDOM but because TclSOAP uses the latter I need both. The shim mentioned above would be useful in this respect, but I don't think TclDOM's interface - or any interface modelled directly after the DOM - is the best one; 95% of the useful work can probably be done with a much smaller, simpler interface.
[ Category XML | ]