XML OF DEATH

[simont]

If you're designing an XML representation of some type of data, and you want a key-value sort of organisation, this is inherently reasonably well supported by XML. If you want to set the key ‘foo’ to the value ‘bar’, you can simply set up your DTD so that it lets you write

<sometagorother foo=bar />

Now occasionally I can understand that you might want to layer your own key-value structure on top of this:

<set key="foo" value="bar" />

because this approach gives you the ability to add extra attributes alongside each key/value pair, which might be useful for all sorts of vaguely sensible reasons: expiry dates, permissions, conditionalisation, you name it. Also it doesn't require you to specify the full set of possible keys in the DTD, which is obviously useful.

However, when I see a third layer of key-value structure on top of even that …

<method name="SetVariable">
    <arg key="name" value="foo" />
    <arg key="value" value="bar" />
</method>

… I really do start to wonder whether someone's brain has been EATEN BY PARASITIC XML MEMES OF DEATH.

Comments

[pm215]

So do you have a recommendation other than XSLT for processing XML? I ask because there's a project in the offing where you feed in some documentation in an XML kind of format and it spits out docbook/html/C headers/any of half a dozen other output formats, and we're wondering whether to do XSLT or something else (eg a program written in some language with DOM bindings which just does this kind of thing programmatically).

[oneplusme.livejournal.com]

To be fair to it, XSLT works pretty well for its intended purpose (it's just a huge memory hog, and the syntax will wear your fingers to the bone). My rant was one of semi-affectionate frustration, if you will...

However, if it starts looking like your problem will be tricky (or hideously long-winded) to solve in XSLT, it's probably best to cut your losses and just code something yourself with a DOM or a SAX parser.