Bear Patrol
Now the more credulous amongst you are probably thinking “My god, bears are attacking Matthew’s screen!” but before you rush in to save me I’d like to explain these images. These two screenshots demonstrate the same menu being displayed as XHTML and then as XUL (respectively). The XHTML version comprises of XHTML+JavaScript whereas the XUL version creates native toolbar widgets across the top of the page. This is produced with an XML Pipeline Processor based around XML, filter plugins, and XSLT. These XML Pipelines (a.k.a. XML chains) are comparable to specialised Unix Pipes:
“A set of processes chained by their standard streams, so that the output of each process feeds directly as input of the next one. Filter programs are often used in this configuration. The concept was invented by Douglas McIlroy for Unix shells and it was named by analogy to a physical pipeline.”
- Wikipedia
Source data is generated (typically by reading a file) and this is passed through a series of conversion stages (XSLT or STX) and the end result is whatever remains. Much like Unix Pipes themselves much of the value of XML Pipelines comes from having discrete components that are easily composed into more complex conversion chains.
(thanks to Apache Cocoon for the image)
XML Pipelines are a popular approach to multi-format publishing and they’re a natural fit to the problem of HTML abstraction as discussed in the previous blog post.
Introducing, PilferPage…
PilferPage will be a series of XML Pipelines and XSLT/STX stylesheets that convert an abstract page definition into HTML4, HTML5, RSS, Atom, XSL-FO, XUL, XAML, Flash/Flex, JSON (for serializing data), and so on.
There are a couple of benefits to the XML Pipeline approach,
- Any modern language can benefit from them (the abstraction doesn’t favour Python, Ruby, PHP, C#…);
- This would also allow any existing framework to change their output to be PilferPage, and then benefit from the abstraction;
- XML is a natural fit for GUIs, as shown by modern GUI languages such as HTML5, XAML, XUL, Glade(GTK). Semi-structured data suits markup, and markup makes the relationship between components more clearly expressed through node hierarchy.
- Many developers already know XSLT.
So, in the coming weeks I’ll start opening up for debate the design of PilferPage. We’ll try to talk about commonalities between all the formats and see about writing XSLT that will convert PilferPage to these formats.
“Change happens and nothing prepares you better than having your gooey in XML than tied to one vendor’s GUI API in a single language be it Java, C# or whatever else comes along. If the DTD/schema changes you can use XSLT to automatically convert old XUL files to new ones.”
- LUXOR Interview
XML GUIs marginalize the “single language” in the same way that databases marginalize the languages reading from them by abstracting data. This PilferPage abstraction does mean coding to an open standard (it will be open source) but with XSLT that allows developers to leave – to any of the output formats – they shouldn’t feel captive or as if they’re coding in a proprietary environment.
In the next post, we’ll talk about commonalities in page layout (3 columns + header/footer or something more flexible?).
Update (2nd December): Why the name PilferPage? It’s a tedious story, so skip ahead to the next paragraph for the short version. In 2002 I started some weblog software called PHPilfer which was named after some misinformative speeches by Microsoft’s Steve Balmer about how open source was intellectual property theft (he was referring to the propagating nature of the GPL). The name PHPilfer was about ridiculing the notion that any license could cause infringement of intellectual property, or that Open Source was any more “infectious” than proprietary software (try selling a modified Microsoft Office and see whether the copyright holder asserts their license rights to restrict your modifications, for example). PHPilfer was easy to administer, entirely themeable, had pretty URLs, and MetaFilter took some ideas from it. Ultimately though it was mediocre software and I stopped writing PHPilfer in 2004, which was a pity because I liked the name.
PilferPage is about straddling a useful subset of many UI languages and building upon their shared commonalities. It should be about taking the best ideas and reusing common knowledge about good UI XML design. So, again, the name PilferPage is a joke about IP only this time it’s about pointing out the overlap between UI languages, how they’re stealing from each other, and how we’re going to do that too.
November 26th, 2007 at 3:35 pm
Hi again…
You might want want to add planet.nztech.org to your “allow” list for linked images…
–Phil.
November 26th, 2007 at 3:42 pm
Fix0red
December 1st, 2007 at 10:21 pm
Why is it called PilferPage? Does the motivation for the name originate from Pilferage, i.e., petty theft or stealing cargo? I don’t understand it.
At any rate, I agree that XML Pipelines are incredibly useful, yet underutilized in practice due to the amount of plumbing required to realize that usefulness. My first inspiration for XML Pipelines came when reading Sam Ruby’s blog posts about Planet Venus as a “river of news” feed reader. In particular, his blog post Genshi Filters for Venus (http://www.intertwingly.net/blog/2007/04/14/Genshi-Filters-for-Venus) was the first one where the value of an XML Pipeline woke me up. I didn’t understand what Sam Ruby was saying at first. It must’ve taken me 6 months to get it: It’s the model UNIX Pipes has been missing for complex event processing / stream event processing. Where UNIX Pipes stops at merely coroutines, the XML Pipeline picks up. Come to that, UNIX Pipes don’t provide the same level of data independence as the XML Pipeline. The benefit of robust data serialization is clear: The ability to identify and break off arbitrary nodes, re-purposing at will. Semi-structured is better than unstructured.
I’ve linked your blog (Entry #3) on the Andromeda Project mailing list, since the presentation layer of Andromeda is undergoing improvement and reconsideration. GUI API agnosticism for free would be ideal, as it would allow developers to take advantage of opportunity costs and the very fact it is agnostic could mean greater interoperability than Andromeda already possesses. Currently, Andromeda supports Joomla templates, and thus there are thousands of layouts freely available as well as an extra thousands more for a fee. Essentially, the goal should be to turn the front-end into a commodity, allowing more time for higher margin services. Being platform agnostic is a step in the right direction, but the end goal must be to make commodities out of the complements to those higher margin services. Hopefully, Andromeda developers can then simplify their cost estimates to customers.
Keep us informed.
December 2nd, 2007 at 12:29 pm
Hi Z-Bo, I’ve just updated the story with some info about the name.
Yeah, as you say there aren’t many easy-to-use frameworks that support XML Pipelines and that’s made it hard on developers. I think there’s been a problem over the years articulating their usefulness, which means that programmers haven’t thought of their web software as a component that consumes and publishes structured data.
Right now PilferPage is vapourware but I should get some time this week to put up some ideas for debate. So hang around and make sure that I don’t skew the language into a niche — it should be as generalised as possible.
I hadn’t read Sam Ruby’s post before, thanks for the link
I’ll probably point that out next time I’m trying to explain this stuff.
December 2nd, 2007 at 2:24 pm
I first started liking UNIX Pipes when I wrote a scheduler simulation for my Operating Systems course in college a few years ago. The teacher didn’t specify how the program had to produce the output of the simulation. At the time, I also decided learning XML would be fun, in particular the XSL standards stack, especially XSLT. My experiment resulted in writing what you may call a producer (the scheduling simulation) fed XML output into a consumer (a pretty printing program that accepts an XSLT document and piped input). I provided an XSLT document in the configuration directory. By default, the consumer would dump the output to the console via standard out. However, I created one other XSLT document that was designed to dump an XHTML document containing the simulation results in a neatly formatted table element.
I thought it was an ingenius first project for XML. The people I talked to about the idea before starting the project told me it was a horrible idea, and my professor agreed with them: I got 10 points taken off on the assignment because she called it a usability nightmare.
She just didn’t understand what I had done, and why it was so brilliant, if unfamiliar. She couldn’t see how if this was a “real” program, how useful this would be. In particular, if the user ran the program with a -v, -vv, -vvv, &c verbosity switch. Although I did not add support for logging to the program (diagnostic information was not required), I could have easily done so by adding a decorator that put diagnostic information about atomic data elements. Truth be told, though, at the time I wasn’t really aware about the consequences of my actions, and it was just the idea of “Hey! Let me learn XML in an Operating Systems course!” that happened to work out well.
December 2nd, 2007 at 2:37 pm
I meant to say “I first started liking the XML Pipeline when [...]“, not “UNIX Pipes”. I had been using UNIX Pipes and liked them well before that course.
July 24th, 2008 at 7:34 pm
[...] a blog post about the commonalities between file-format features. The goal is to have one file, a Pilferpage, that can be dynamically converted into HTML, XUL, ODF, XSL-FO, Flex, CALS2, DocBook, CSV, but to [...]