From AlphaWiki

Modes: XmlMode

It seems there is a lot of code in HTML mode which would be useful for XML. Also, now we've abandoned Alpha 7, we can then use things like tclxml, tcldom to parse xml files, etc.

Is anyone trying to do any of this?

I've added a simple mode framework to AlphaTcl to get us started....

To do...

(bd) It would be nice indeed to have a complete interface to the tclxml family packages. They do not seem to exist for MacOS 8/9 so I have built them today as shared libraries, ie loadable extensions to be loaded by Alpha8. I'll put them on my web page within a few days. I've built tclxml, tcldom, tcldompro, tclxml2, tclxslt and tclexpat. Note that on OSX Daniel's BI Distro provides all of them so we are set for AlphaX.

The shared libs can be found there:

Vince has started developing the xmlMode relying on the tdom C extension so I've also built tDOM, both for Classic and for OSX (as well as the tnc extension which comes as a complement to tDOM). The Classic package is for Alpha8 and the OSX package is for AlphaX. They can be found here:

Note that, most probably, Daniel will include another build of tDOM in a future release of his Tcl/Tk BI Distribution for OSX. When this is the case, beware of duplicates (ie remove my tDOM lib!). No such risk with Alpha8. (bd 03/02/22)

  1. It would be great to have comparison elements concerning the merits of using tdom rather than tclxml and Co.

Both the Tclxml family and tDOM have xslt support. My understanding so far is that there are two different approaches (please correct if this is not completely accurate):

the expat approach (tclxml, tclexpat) uses callbacks which are invoked when a certain type of element is found during parsing.

the dom approach (tcldom, tDOM) builds a complete representation of the associated tree in memory and provides method to walk through this tree.

Does anyone have some experience with both these solutions ? (bd)

Here is an interesting precision which Rolf Ade ( ) sent me about the previous comment:

<< These are the two classical XML processing paradigms: the SAX (stream-, eventbased) and the DOM (tree) oriented ways of processing. There's also a newer, third paradigm, the pull way of XML processing (also stream based).

The DOM and SAX approaches - although they have different characteristics - are not completely different worlds. You are always able, to use a SAX parser, to build a DOM tree, while parsing and you could always traverse a DOM tree and generate a stream of SAX events while doing this.

Both tDOM and some of the tclxml provide SAX and DOM. With tDOM you could also combine both: you're able to register SAX event handlers, which are called, while you're building a DOM tree in the same parser run. >>

(bd) It seems that DTD parsing is missing from all these extensions. With tDOM you can 'check' that an external DTD is syntactically correct with the following trick: build a minimal XML doc calling for this DTD and parse it. This will report errors found in the DTD. I suppose the same kind of workaround could be applied with the Tclxml family as well. The following two procs do that

  proc xml::parseExternalDTDfile {dtd} {  
      set parser [expat -externalentitycommand xml::ExtEntityResolver \
	-baseurl "[file dir $dtd]" -paramentityparsing always]

      set dummyxml "<?xml version='1.0'?>
      <!DOCTYPE dumm SYSTEM \"[file tail $dtd]\">
      if {[catch {$parser parse $dummyxml} errmsg]} {
	  $parser free
	  error $errmsg
      $parser free

  # Callback
  proc xml::ExtEntityResolver {base systemId publicId} {
      set dtdfile [file join $base $systemId]
      if {[catch {set fd [open $dtdfile]}]} {
	  return -code error \
	    -errorinfo "Failed to open external entity $dtdfile"
      return [list channel $systemId $fd]

It's not clear to me, what exactly you mean with 'DTD parsing'. Every XML parser (even the 'only' well-formdness checking ones) have to parse at least the internal subset to some degree. And tDOM (as well as at least some of the tclxml parsers) has a couple of event handlers for the declarations inside both the internal and the external subset.

But its one thing, to be able to get enough information out of the DTD to be able to decide if it is allowed to insert or remove a certain element, which attributes with which values are allowed etc. and another thing, to preserve the internal structure of a DTD over a edit (especially edititing the DTD itself) and save cycle - think about parameter entities and conditional sections.


1. (bd) No, no, Rolf, I must have been unclear there. The issue addressed by these two procs concerned the openHook which applies a parse command upon opening a file in XML mode. The point is that if it is a DTD file (I mean an external entity subset) this does not work. Hence the workaround. I'll rename the proc xml::checkExternalDTDfile to avoid any confusion.

Here is a quick list of what I think XML mode should provide

(bd 03-02-27)

(rde) notes: This is a very ambitious list.

Some ideas for XML mode from another editor (SlickEdit):

XML/XSLT/DTD Features (new in version 7)

This is one thing I was wishing for before. Now my life is complete ;-) The new features, only a few of which I'm using so far (I'm eager to try the XSLT stuff, but haven't yet) are great. It's the simple things like syntax indenting and tag completion. For example, if you start an element, then add some nested elements (and assuming you are tabbed in one or more levels now), and then type "</" it will auto-complete the closing tag for the proper level you're at. That seems minor, but it's a nice time save and ensures you've not made any syntax errors.

Also, it processes the DTD on the fly and thus provides auto-completion (or whatever it's called) facilities for all available elements and attributes based on that DTD.

What's also nice is that they have a facility where you can tell SlickEdit to use a local copy of a DTD so that it doesn't go out and do an HTTP request for the DTD (say if you're not on the net while editing or whatever). Super easy to set up. This is also handy if you are doing DTD development and want to have your local copy using your modified DTD until you update the real location.

Retrieved from
Page last modified on January 23, 2006, at 02:07 PM