Friday, April 2, 2010

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.

6 comments:

ashmind said...

It seems it is April 2 today, so I am a bit confused.

Robert Jeppesen said...

The purity of xsl is appealing, but actually using it is not, as you point out.

Sending these transformations to the client would present a huge security hole. You are unlikely to use all properties of your entity for a given view, so unless you add a transform on server side as well, you are sending unneeded data, and possibly sensitive data.

Unknown said...

Not nearly as inspiring as your other posts.

Jafar Husain said...

Robert: good point about protecting sensitive data. I also agree in many cases doing transformations on the client could increase bandwidth costs.

ashmind and DataMan: I'd appreciate more constructive criticism. I don't pretend to be an expert - just another developer with an opinion. If Pretty XSL is a bad idea I'd love to know why.

Thanks

ashmind said...

Ok, I didn't intend to be sarcastic, I just wanted to be sure the post is serious before writing a long reply.

Now, the long reply: first, XSL sucks. I worked with it a lot, and while some of the worse things are artifacts of XSL in .NET being 1.0 (and to have great tooling you would have to use it), it is still nowhere near a good templating engine.

Even if we focus on it being view and forget complex logic, just implementing a basic datetime formatting in XSL is, well, unfriendly. Implementing grouping in XSL 1 is extremely tedious. And this is only the tip of the iceberg.

Now, for the question of pretty XSL (which at least solves the question of <> overload). This language is not really that different from existing ASPX. So how is it better than ASPX?

Being a standard? But there is already a very similar standard (XQuery).

Being supported on browser level? But browser developers and standartists already worked hard to produce a data+style solution using (X)HTML+CSS, adding alternative detailed solution for the same goal does not look like something realistic.

Another point is, that it is completely possible to do it all today, since ASP.NET MVC supports different view engines, including XSL engine that is already built. You can also build a PXSL engine, and you can serve model in XML and view as XSL.

From what I saw, I think that Spark is nearest to the perfect hmtl View template engine (however that is a personal opinion).

Jafar Husain said...

ashmind: Thanks for expanding. I'll admit that there are a lot of things I don't love about XSL. Your point about date/time formatting is well-taken - I've felt this pain myself. I wasn't aware that grouping was so difficult though because it's never really come up.

"But browser developers and standartists already worked hard to produce a data+style solution using (X)HTML+CSS, adding alternative detailed solution for the same goal does not look like something realistic."

XSLT is orthogonal to XHTML+CSS. Can you clarify what you meant by this comment?

You point out that it's completely possible to change MVC to support XSLT but I said as much in my post. I'm really just curious why the practice isn't more widespread. That said you make good points about the deficiencies of XSL.

Spark sounds interesting. I'll take a look at it.

About Me

My photo
I'm a software developer who started programming at age 16 and never saw any reason to stop. I'm working on the Presentation Platform Controls team at Microsoft. My primary interests are functional programming, and Rich Internet Applications.