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

{% extends "base_generic.html" %}

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

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

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


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" %}
{% block title %} ... stuff ... {% endblock %}
{{ 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?


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"


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.

Sunday, June 21, 2009

Swimming with Sharks

Dealing with business people can be frustrating, especially when they have their minds fixated dogmatically upon a fixed price and that elusive single solution. As noted by the aphorism, teaching pigs to sing just wastes your time and annoys the pig.

Why would a client seek a fixed-price contract with a vendor, when it is clear that:
  • the vendor offers to deliver less quality and value than is obviously available on the market, and/or

  • the vendor arranged the contract such that the client retains no ownership over the assets that were developed and

  • availability of the vendor to perform at a certain level of support or maintenance is not stipulated anywhere and

  • the costs associated with future enhancements and stabilizing maintenance are not fully under the client's discretion but are prejudiced by lack of disclosure of key information, that is, the vendor takes no fiduciary responsibility

Individually, the answer might be "ignorance", and the solution would be for the client to exercise due diligence. We should also understand that clients are vendors themselves, and may also use contracts as a weapon to gain advantage. A client who acts in a predatory manner should not be surprised to learn they are swimming with sharks. It is predatory to use a fixed-price contract as a way to avoid having to think about requirements or assume any of the risks associated with a development. A client with this strategy should not be surprised when at the very end of the process the strategy has worked against them. Sharks tend to swim with sharks.

Friday, June 19, 2009

Making Horses Think

I put myself into a situation a few years ago while volunteering for a non-profit. As a member of the organization, I had tried to be an instructor and a collaborator on their Web site strategy, at a time when they were neither interested in collaboration nor had the capacity to understand issues of ownership, service, and maintenance. I personally invested thousands of dollars of my time to demonstrate the feasibility of using a database-driven site to manage their marketing programs, using a popular open source CMS to ensure that the system was open and could be worked on by others.

Yet the CMS was discarded and a contract summarily awarded to an ISV to deliver a "Web site" based on the concepts I had introduced. The ISV was all too willing to give a fixed price while asking no difficult questions, and proceeded to construct a closed-source CMS under the pretense of Web site development. In the end, the customer's disinterest in taking ownership worked against them, and they paid several thousand dollars for a low-quality site over which they now hold little real control. The ISV is now holding them a virtual hostage for simple content changes to the site.

You can lead a horse to water, but you cannot make them think: Sometimes pain is the best instructor.

Friday, June 12, 2009

The "Web 2.0", or, What is the Next Big Thing

For a lot of what Web Designers do, it is all about sales and marketing. Not that it is a bad thing, but the focus is almost entirely upon the appearance and "skinning" of a plain-old-HTML site. When server-pages platforms came along, they added databases to the mix, and they've finally entered the mainstream after what -- about seven years? Still, the tendency is still to format, layout, paint: branding.

Even with SEO/SEM, with an increasing recognition that content, not aesthetics, determines the search quality of the site (again, this is taking years), people are still thinking in terms of sales and marketing. It is all about drawing traffic from search engines to be told about commercial product or service.

That is not all the Web 2.0 is about.

Ok, I've used a term that's all about marketing hype, at least, it was a few years ago. But things have changed. The Web has depth to it, not just surface branding. It is easy to overlook those depths, since the surface Web is a pervasive marketing medium. The depth was always there from the beginning, it was just forgotten for a while.

JavaScript directed behavior and late-bound client-server XML/JSON data exchange (aka AJAX) is available today, in both heavyweight and lightweight tool chains. It is time institutions, whether commercial businesses, non-profits, or government entities, consider the impact of performing real work in the Deep Web.

Thursday, June 4, 2009

Another thought on Google Wave

A Wave is a first-class object representing a communication over time. One effect of promoting one's own communicative events to components of a first class object, is that your task-switching to re-organize and re-contextualize the communication should drop. The machine is doing the organizing for you.

But a second, less obvious side-effect is that the number of temporary communicative threads you engage in on a daily basis, and the number of established communication pipelines you are a part of -- and thus the number of discussions you expect to monitor and expect to participate in -- will be exposed and countable. This should cause a major shift in work habits as many people become conscious of the number of communication streams they have either been ignoring, or have assumed they could reasonably manage. Right now with email we do everything asyncronously and allow the past communications to be forgotten and the structure of the conversation to drift and fade out. With Wave, it is less easy to tune out the structure of the conversation because it is a first-class construct.

So, I may have dozens of people and developer lists emailing me. But if I pull up dozens of Waves and try to monitor all of them as a synchronous activity it will be obvious that some of these communications are sucking down my real productive time. And when a manager can put a metric on what is perceived to be unproductive time, you can bet habits will shift to optimize the metric downward. Imagine now getting this error: "Access Denied: Wave Quota Reached. Please see your System Administrator".

Wednesday, June 3, 2009

Thoughts on Google Wave

The efficiency of communicating in a way that allows your team to build concrete document artifacts as a direct consequence of that communication, comprises a lower-energy state for workers into which they must fall.

In Wave, the idiom of interleaved communication threads becomes a "first class" structure, capturing both my ownership of a reply and its relative sequence in the discussion. Unlike email and forums where one sees sausage stuffing of the replied-to bodies with every reply, Wave repetition is minimized except to replicate information to clients. Governments and institutions with requirements for auditing and security will, I think, look at this as a good thing because it will allow conversations to be traced much more rigorously; I would bet it won't be long before customary governance rules require something like Wave and deprecates email services. That is, I suspect this will wipe out email, news, and I.M, both legally and technically.

An XML Conference for Summer 2009

A friend of mine organizes events and is setting up an XML conference right here in Raleigh, at the McKimmon center. As a training resource, such conferences are a pretty good deal just for the training alone.

Here's the blurb:

ANN: Give us two days, we'll give you a knowledge boost

THIS is THE XML conference you will want to attend this year! Presentations are carefully selected,highly technical, marketing fluff free, and presented by real users and technology experts. The presenters cover beginning-through-advanced topics, and provide the information you need to survive -- even THRIVE -- in today's job MARKET.

The Summer XML 2009 Conference
July 27-28, 2009
NCSU Jane S. McKimmon Conference Center
Raleigh, North Carolina USA
A great value at $495... Pay in 1, 2, or 3 payments...easier on the wallet
or corporate budget.

Schedule and more information online: . Once you check out the schedule, you will want to be here!

Look forward to seeing you in sunny Raleigh this July! Learn from our speakers, network with a great crowd, share knowledge, visit vendors, and get a great return on your investment with us.

Kay Whatley
Conference Producer/Production Manager
Above and Beyond Learning Corp.
PHONE: 1.919.269.5414