Monday, June 22, 2009

Faux XML

Why do programmers insist that home-brew template languages are always to be preferred over standards, just because?

I recently read this piece from DJangoproject.org:


{% extends "base_generic.html" %}

{% block title %}{{ section.title }}{% endblock %}

{% block content %}
<h1>{{ section.title }}</h1>

{% for story in story_list %}
<h2>
<a href="{{ story.get_absolute_url }}">
{{ story.headline|upper }}
</a>
</h2>
<p>{{ story.tease|truncatewords:"100" }}</p>
{% endfor %}
{% endblock %}

Philosophy

Why use a text-based template instead of an XML-based one (like Zope's TAL)? We wanted Django's template language to be usable for more than just XML/HTML templates. At World Online, we use it for e-mails, JavaScript and CSV. You can use the template language for any text-based format.

Oh, and one more thing: Making humans edit XML is sadistic!






Let's take this example apart:
{% and %} are clearly markup delimiters for instructions. So, "<"="{%" and "%}" = ">".
We trade one character for two, and the two are just as pointy as the XML symbols, a bonus!
But we also have {{ and }}, another pair of delimiters, which also mean start and end, apparently only for property inclusion. So we've traded one XML symbol for for two two pairs pairs of symbols symbols.

Now, we have
{% extends "base_generic.html" %}
and
{% block title %} ... stuff ... {% endblock %}
and
{{ section.title }}

Is it a concern that masochistic code monkeys would compare the cobbling together of yet-another-template syntax with a stable and extensible markup standard such as XML?

No.

As a programmer, I can appreciate a desire for syntactic simplicity, but that hasn't been shown in the DJango template syntax. What has been shown is a parochial syntax closer to the writer's viewpoint than XML. COBOL programmers prefer to program in COBOL. That doesn't make COBOL more "usable" than, say, Python.

That programmers developed their own template syntax for DJango doesn't concern me. It has been done before, and there are distinct technical advantages to using simpler and faster non-XML aware parsers. For instance, no top-level element is necessary, and the tags need not meet XML parsing requirements. No doubt this explains the reference to JavaScript and CSV. I might be more convinced of this rationale if the template syntax didn't itself so closely resemble XML. That the "philosophy" behind the decision abuses terms such as usability and sadism while heaping scorn on XML in the process, is cause for concern. Such ignorance should not be tolerated.

We also have that "</_____"="{ % end_____" . The grammar inside the {% %} delimiters is of the form label parameters where the soundness of the script is only decidable given the semantics assigned to each label. In the example given, we must know that endblock goes with block, and that it serves as the final part of the "block" production in the grammar. Ditto for all of the other instructions. A static analysis of a DJango template requires knowledge of the semantics of the labels, not just the surface syntax as in XML.

Mind you, I'm assuming we want to monkey around with this stuff without a DJango parser. My editing and processing programs now need to know that block is the pair to endblock, for goes with endfor, and so on... something completely unnecessary with an XML syntax, because the tag structure doesn't depend upon an arbitrary mapping of sets of non-identical labels. Yeah, that's trivial. We could just hard-code the set of matching pairs in some way, maybe as a lookup table or as a mangling of the prefix "end" on the instruction label. Still, I have no interest in mucking around with editors to accomodate yet another trivial template syntax. That's just plain masochistic.

"Usable for More than Just XML/HTML"

What-EVER.

XML has shown itself "usable" beyond what any parochial syntax will attain, picking up both good and bad characteristics from a long history of non-programmers estabilishing the theory and practice of generic markup culminating in XML's parent, SGML. As a result of their efforts to improve the usability of markup languages, I can now open XML in a plethora of smart XML editors and gain immediate benefits. Then adding grammar-oriented schemas I gain more usability of my information. Then with XML-aware facilities like XPath/XQuery, XSLT and rule based Schematron schemas I gain even more usability -- all without writing any code.

My schemas can even identify the notations and tell me which of my elements will contain an particular notation. I can send it to a browser-based or RIA platform and monkey around with it in DOM and easily walk the XML template's parsed tree structures with a functional language too. It is all usable now because it is XML.

And it doesn't help me to have a template language that doesn't facilitate correct output. As far as I can tell, none of my current tools understand's Django templates, and they are only applicable to... well... just Django.

I experimented with block-oriented template syntaxes with AWK back in 1994. Mine used $- and -$ as the delimiters, declared blocks, provided named parameters and the composition process was driven by binding the defined blocks to data sources. All well and good... and already done before in the lambda-calculus based languages, of which Lisp and Schema are well-known members. Programmers are constantly reinventing things that have gone before, just for the sake of saying they've invented a new mousetrap.

Having written all that, I don't doubt that I'll be learning some of the finer points of DJango templates, because I'm currently working on a Google Apps Engine project and MVC is the right way to go. I don't doubt that some grain of innovation can be found in the template system. I just think that it is claiming more than is reasonable to say that the syntax is more usable than XML.
Post a Comment