Leslie de 0xDECAFBAD talks a bit about cross-breading ZPT and XSLT and mentions Kid along the way. This is the first in a series of response posts.

More than once, I've wished that XSLT was as simple as ZPT (i.e. less verbose and intrusive, more document centered), and I've wished that ZPT had some of the features of XSLT (i.e. ability to be used as a transforming filter).

This is pretty much the exact thing going through my head when I decided to start in on Kid. The first half, the TAL/ZPT feel, is already quite visible in the Kid Language Reference. The second part, constructs for transformation, is what has been eating my brane for the past month or so. I'd like to expound on that a bit but first I want to get through a couple of other things Leslie mentioned that I've spent some time wondering about myself:

This strikes me as such an obvious idea that someone has to already have done it and possibly rejected it for good reason.

Here's my take on this: XSLT people value XSLT's programming language neutrality. Baking in support for a specific language would mean doing it in a manner that is language agnostic. XSLT 1.1 (abandoned) was to provide a programming language neutral mechanism for adding XPath extension functions. This proved to be fairly difficult and I think this may have led to general apathy in the XSLT crowd for mixing XSLT with more traditional programming languages. A little bit later XSLT was proven Turing complete. XSLT people stopped thinking about making things simpler since anything was technically possible and started looking to XSLT 2.0 to provide the types of ease-of-use features you would get with a programming language.

And then there's XQuery. From a recent conversation on xml-dev, I'm getting the feeling that XQuery may become a general purpose programming language that is extremely XML aware. I've not spent much time on XQuery or XSLT 2.0 because casual reads through the early specs left a bad taste in my mouth as they both seemed waaaaaaaayy more complex than anything I would ever consider working with - especially in a Python environment.

But in some senses, the idea of mixing a general purpose language with XSLT has been tried and proven somewhat useful. Also, libxml2/libxslt has a fairly straight-forward method for writing XPath extension functions. Still, this seems like a duct-tape solution that just masks XSLT's complexity and limitations in limited scenarios. XPath extension functions are a bit like putting a pillow over your head right before someone rockets a cannonball at your face. They make things a bit easier but you're still in a lot of pain. IMO, you need to start fresh valuing simplicity over completeness but keeping in mind the concepts that make XSLT attractive.