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...) ---- 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? [JAC] 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 [TclXML]s 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. [JAC] 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. [SRB] [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. ---- [[ [Category XML] | ]]