A Modest Proposal: Pretty XSL

I’ve got a question for the authors of the popular MVC frameworks: What’s with all the custom view languages?  ASP.NET MVC uses ASPX files for their views.  Rails uses Ruby of course.  MonoRail has its own NVelocityViewEngine which has a python-like syntax.  Of course these frameworks allow you swap out these view engines.  However in my experience developers tend to default to using the one that ships with the framework.

Why not use XSL? 

The technical benefits of using XSL are compelling:

1. Use Less Bandwidth

Every major browser is capable of XSL transformations on the client.  After the XSL and CSS files have been cached by the browser an application server becomes responsible only for sending data and managing any application state.  This translates to massive bandwidth savings.

2. Enforce Model/View Separation

When it comes to view languages smarter is not better.  The more powerful a view language, the easier it is to inadvertently blend concerns.  XSL is a dumb language that is pure by design.  It’s like a technical straightjacket, sending a clear message to current and future developers about exactly what type of tasks are allowed to be performed.

3. W3C Standard

‘Nuff said.

4. Great tooling.

Some .NET developers may be unaware that it’s possible to step through XSL transformations in Visual Studio.  The experience is roughly on par with stepping through C# code in an ASPX.

Syntax Matters

Given all these benefits why do so many developers choose a different view language?  Here’s my theory: XSLT is ugly.  Anyone who has used XSL knows that its signal-to-noise ratio is abysmal.  Therefore propose a solution: The W3C should create PXSL (“Pretty Extensible Stylesheet Language”).  PXSL is a hypothetical non-XML language that compiles into XSL.  A stripped down version of Windsor’s NVelocityEngine or something similar could easily be compiled into XSL.

#foreach($person in $people)
#beforeall
       <table>
               <tr>
               <th>Name</th>
               <th>Age</th>
               </tr>
#before
                  <tr
#odd
                       Style='color:gray'>
#even
                       Style='color:white'>

#each
                       <td>$person.Name</td>
                       <td>$person.Age</td>

#after
                  </tr>

#between
                  <tr><td colspan='2'>$person.bio</td></tr>
#afterall
       </table>
#nodata
       Sorry No Person Found
#end

Some might think such an endeavor trivial or misguided.  I disagree.  There’s a relevant precedent to consider here.  Turtle (Terse RDF Triple Language) is a non-XML language for describing XML RDF graphs that has been submitted to the W3C.  Although it hasn’t yet been accepted as a standard it enjoys great tooling support and is widely used.  Although it is no more or less expressive than RDF it’s practical syntax is so compelling that it has found a foothold in the industry.

Use XML Where it Makes Sense

Whenever a new technology is introduced we hear a lot about its supposed benefits.  Some of these benefits pan out and some don’t.  One of the touted benefits of XML was that it was supposed to be human-readable.   While definitely an improvement on binary, many XML formats (ex. SOAP) are so complex that sifting through them in a text editor is very difficult in practice.  To increase productivity we are increasingly hiding XML from developers with designers, code generators, and configuration utilities. XML is a very mature data interchange language but there’s no reason to force developers to work with it directly.  A little syntax goes a long way.