Entries classified under xml

Kid 0.6 is available.

This is a feature release with some pretty important enhancements including Template Inheritence, Match Templates (kind of like XSLT's), cElementTree support, and a refined Python API. Quite a bit of time was spent on the documentation as well.

The Release Notes have more information on everything that has changed.

Kid is an XML based template language for Python that merges the best of Zope's TAL, PHP, and XSLT into a single coherent package. It was created to provide a simple method of generating dynamic, well-formed XML documents using familiar concepts from popular text templating languages.

Download

http://lesscode.org/dist/kid/

Release Notes

http://lesscode.org/doc/kid/0.6/notes.html

Project Information

http://lesscode.org/projects/kid/

Yahoo! launched a Web Services interface today. I'm gushing with joy over their decision to follow proven web architecture and select a simple REST model over a more complex WS-* model. Let's take a look at an item pulled from their FAQ:

Q: Does Yahoo! plan to support SOAP?

Not at this time. We may provide SOAP interfaces in the future, if there is significant demand. We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services.

Get used to that answer. You won't ever hear it from the evil tool vendors but you can be damn sure you'll be hearing it from the smart service providers that really are looking to court developers.

Also, it was extremely cool to serendipitously stumble across mine own How I explained REST to my wife article after passing from Yahoo!'s Constructing REST Requests page to Wikipedia's REST page.

I had a very small number of complaints related to basing Kid on ElementTree. This came in two forms:

1. SAX and DOM are “standard” and while ElementTree is a drastically improved system for processing XML in Python, it doesn't matter because everyone already knows SAX/DOM.

2. “libxml2 is teh rawk!”

First, if Python's W3C DOM standard based xml.dom package were a movie, it would be called Elf, staring xml.dom. It's the episode of Little House on the Prairie where Alien asks Michael Landon for permission to marry his daughter. It does not belong here!

Next, in terms of pythonicness, libxml2 is almost worse than xml.dom but you at least get something for it: they don't even have a word to describe this level of “fast” and it comes along with XPath, RelaxNG, XSD, XML-Base, XInclude, and XSLT. My issue with libxml2 is just that it's a bad dependency for a project like Kid that wants to be able to run on cheap web space with bare-bones Python support. There are a lot of hosting providers that aren't going to have libxml2 or the option of compiling from source.

I went with ElementTree because it's simple, pythonic, and fast enough. I also had a feeling we'd be seeing more development around ElementTree, which brings us nicely to why I'm posting.

Some days the Powerbook gets more attention than the wife and so she snoops over my shoulder and starts asking a bunch of questions about whatever is on the screen. She doesn't really care, this is just the cue to shift my attention over to her. I usually do just that and say something like, Oh, this is some interesting stuff but nothing you would care about.

But on this day I decided that I would play along a bit and see how far I could take her into my world before she ran away screaming in terror.

This is the second post in response to cross-breading ZPT and XSLT. I'd like to dig into how I'd like templating to work in Kid and Leslie opens the door for me:

... maybe this is the sort of thing Ryan's thinking about-- I wonder how hard it would be to hack this into Kid? It would give only a subset of XSLT's capabilities in trade for simplicity, and would only offer the pull approach, but it would give XML-pipelining to a ZPT-ish technology.

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.

So this is pretty crazy. I'm messing around with ElementTree (which has been nothing less than perfect) and trying to get it to act like a xml.dom.pulldom/XmlTextReader style pull-parser. But I'd like to be able to assemble a chain of generator producing/consuming functions (or other callable) so that the file can be read, parsed, filtered/mutated, encoded, and written all incrementally.

Check it out:

import sys
import pulltree    # that's what I'm working on :)

def upper_filter(source):
    for (ev, item) in source:
        if ev == pulltree.CHARACTERS:
            item = item.upper()
        yield (ev, item)

reader = pulltree.reader(sys.stdin)
filter = upper_filter(reader)
writer = pulltree.writer(filter, sys.stdout)

for (ev, item) in writer:
    pass

C-z

$ echo "<hello>world</hello>" | python test_filter.py 
<hello>WORLD</hello>

That felt good. More functional than a chain of SAX XMLFilters, almost as efficient, and muuuuch perdier.

Something like this might work someday soon:

import urllib2
from pulltree

XINCLUDE = '{http://www.w3.org/2001/XInclude}include'

def xinclude_filter(source):
    events = iter(source)
    for (event, item) in events:
        if event == pulltree.START_ELEMENT and elm.tag == XINCLUDE:
           href = item.attrib['href']
           for woot in pulltree.reader(urllib2.urlopen(href))
               yield woot
           pulltree.eat(elm, events) # eat events to the end of the element
        yield (ev, elm)

Granted, that's as basic an XInclude processor could be and still be useful but you get the point.

I've been searching for the perfect Python based XML template language. I was happy to find TAL (and specifically, SimpleTAL) a while back but, although neither of us wants to admit it, we've been growing apart for some time now. I spent last week looking for options and, after careful consideration and planning (read: beer and a nap), decided to just build the XML template language I really wanted.

There's at least four billion and nine text based template languages for Python but there aren't a lot of options that fit nicely into the XML tool-chain. Or, if they do fit nicely into the XML tool-chain, they don't fit nicely with Python.

My dreamboat XML template language would combine the pythonicness and simplicity of PTL, the templating features and pipeline-ability of XSLT, and the terseness of Zope's TAL. I'm building it, it's called Kid, and I'm making good progress to be honest.

But I have this overwhelming NIH feeling so I've decided the best thing to do is to run through the current set of tools and take a professional, objective look at why each isn't getting it done for me (i.e. make fun of minor flaws and limitations until I feel better about myself). Herewith, a look at the good and the bad in the Python XML templating space...