PXSL Tools 1.0: Your ticket out of XML Hell

Tom Moertel — Mon, 17 Dec 2007 22:33:00 -0500

XML is fine for representing document-like things, but when it’s twisted to represent build recipes, configuration files, and little programming languages, it opens the gates to XML Hell. Once the gates are opened, the demons of cargo-cult thinking are loosed upon the world, where they are free to trick innocent programmers into working with grotesquely twisted XML documents – something no human mind was designed to comprehend. Ensnared, these programmers are slowly drawn into the depths of XML Hell, from which their lamentations echo across the universe.

When the demons of cargo-cult thinking come for you, don’t be ensnared! Instead, be prepared – with PXSL – the Parsimonious XML Shorthand Language (pronounced “pixel”).

What’s PXSL? It’s a luxurious, thermonuclear smoking jacket that you can slip on using a convenient preprocessor. Use it whenever you see grotesque XML on the horizon. Within PXSL’s plush (and stylish) protection, you can create all the nasty, twisted XML that may be demanded of you, but you need not descend into XML Hell to do it. Instead, you can work from the comfort of a well-stocked lounge, where clarity and conciseness are always on tap.

For example, here’s a snippet from an XSLT stylesheet, in the original XML:

<xsl:template match="/">
  <xsl:for-each select="//*/@src|//*/@href">
    <xsl:value-of select="."/>
    <xsl:text>&#10;</xsl:text>
  </xsl:for-each>
</xsl:template>

And here’s the same snippet, written in PXSL:

template /
  for-each //*/@src|//*/@href
    value-of .
    text <<&#10;>>

Isn’t that refreshing?

Why PXSL?

There are lots of XML shorthands available. (The PXSL FAQ lists about ten of them.) So why choose PXSL? Here’s why:

PXSL lets you intermix PXSL and XML syntax in one document. Feel free to use whichever syntax works best for each portion of your documents. (See the PXSL documentation for some examples.)
PXSL is customizable with application-specific shortcuts. (The PXSL snippet above, for example, uses XSLT shortcuts. Again, the PXSL documentation has examples.)
PXSL has a powerful macro system that lets you build complicated document structures safely and conveniently. (Read about macros in the PXSL documentation. For an advanced example of what you can do with PXSL macros, see this article on refactoring XSLT one-offs into clean, maintainable code.)

Also, PXSL is battle tested. It was first released in 2003 and has been saving people from XML Hell since. People who try it seem to like it:

I think PXSL could do wonders for soothing my irrational hatred for all things XML. —kowey
Impressive… I converted some of my files from XML to PXSL and the readability was much improved. —chris
Quite aside from the fact that XSLT is finally somewhat readable, the fact that you’ve added a serious macro system means that some serious scripting of XML can occur. I’m very impressed. —invisible

The next time you’re headed for XML Hell, why not give the venerable PXSL a try? You might just find that you like it, too.

This public service announcement was brought to you in celebration of the 1.0 release of the pxsl-tools package. The PXSL-to-XML compiler pxslcc is written in Haskell and uses the cross-platform Haskell Cabal build/package system to let you use PXSL just about anywhere.

Bloglines doesn't handle inter-element white space properly

Tom Moertel — Tue, 11 Sep 2007 12:51:00 -0400

If you’re reading my blog via Bloglines, you may have noticed that some of my posts look terrible, especially when they contain code snippets. I am sorry for that, but it’s not my fault. Bloglines doesn’t handle white space properly.

Here’s the more detailed explanation. When you request one of my feeds in, say, Atom format, you get back a bunch of XML that contains the most-recent posts from my blog. Each post is represented as lovingly crafted HTML, escaped per the Atom specs. When Bloglines gets its hands on this very same HTML, it attempts to scrub it nice and clean – get rid of any naughty bits, you know. And there’s nothing wrong with that. Except when the scrubbing goes horribly, horribly wrong. Which is exactly what happens when Bloglines encounters perfectly legitimate markup that represents syntax-highlighted code snippets.

What does Bloglines do then? It strips out all of the significant white space, turning each block of code into a single, mile-long, unbreakable line of NoSpaceText that forces your web browser to expand the page until it is wide enough to enshroud a small solar system. Then you are forced to scroll forever to read each line of the text column. Ugg.

More specifically, each syntax-highlighted code block is represented in HTML as a preformatted (PRE) text block. Each word in that block is wrapped in a SPAN element whose class attribute indicates the word’s role in the original source code. Keywords get one class, identifiers another, and so on. For example, the code “import List” might be represented as follows:

<span class="kwd">import</span> <span class="name">List</span>

But when Bloglines gets its hands on that markup, it strips out the whitespace between the SPAN elements:

<span class="kwd">import</span><span class="name">List</span>

Thus the markup renders as “importList” when it hits your web browser. Now imagine the same space-denuding bad behavior applied to all of the inter-element white space in a full-length block of code. That’s right, what you end up with is a single, insanely long LineOfUnbreakableText that your web browser chokes on. Again: Ugg.

The folks at Bloglines have had similar problems in the past, most of which have been fixed. I hope they fix this particular problem soon, too.

Until that time, however, you might want to consider other feed readers.

Tom Moertel's Weblog: Tag xml

PXSL Tools 1.0: Your ticket out of XML Hell

Why PXSL?

Bloglines doesn't handle inter-element white space properly