Monday, 26 July 2004
Dictionary as API?
There are two interesting things going on here. First of all, XMLFragment basically gives up on modelling the complexity of XML in the language, instead punting to XPath. I think that’s a reasonable choice; it’s arguably more intuitive and simple than anything you could do with an object model or similar approach (unless you modify the language itself, as E4X did, and even then, the footprint is pretty big). By leveraging an existing standard, XMLFragment minimises the amount that developers have to learn to use it, and maximises the chances that they’ll be able to reuse that knowledge elsewhere. Neat.
This will live or die on performance, of course, but there are some pretty fast XPath engines out there (e.g., libxml2) to plug into the back end.
The other intriguing thing is XMLFragment’s use of dictionaries. Ninety-nine out of a hundred developers would have made this an object or a set of function calls; instead, Kimbro Staken has us treating XML as a data structure. This is a subtle but important difference with echoes of RESTfulness; by making it into an addressable data structure, instead of an opaque object that you pass arguments to, the focus is on the data, rather than the processor. This approach should also make it easy to layer in things like a generic dictionary caching mechanism.
Without using the code (that’s another hint, Kimbro; can we please have it as a separate library?), it’s hard to say how well this approach will work. One other interesting way to use this techique, however, might be for a Web client library, e.g.,
web = UriResolver() mnot = web['http://www.mnot.net/'] # GET mark = mnot.replace("mnot", "Mark") web['http://www.mnot.net/'] = mark # PUT del web['http://www.mnot.net/old'] # DELETE bob = WebRepresentation("<new_user>bob</new_user>", "text/xml") web['http://www.mnot.net/userCreator'](bob) # POST
There are a lot of details to work out here, of course, but I must say I like the feel of using a dictionary here.