Family Holloway

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.

In the field of programming there’s universal appreciation for abstraction. It’s been beaten into programmers since day zero through the painful experience of changing brittle software full of code duplication and poorly expressed metaphors. Programmers learnt to remove and refactor duplication and to architect beautiful abstractions that identify and reuse commonalities in code.

The programmers were right about abstraction, but most have had a blind-spot when it came to HTML.

In the past few years there’s been increasing interest in the semantics of HTML and debate about interpretations of the HTML 4.01 standard. Menus that were previously in <table>s were moved to <ul>s. Then <table>s were relegated to tabular data and layout was achieved with the <div>ision tag. FAQ lists were expressed as <dl>, <dt>, <dd> and even the archaic <address> tag has been seen a comeback with it’s semantics more clearly defined than ever before. There comes a time however when pawing over the W3C specification will not reveal more semantics and when this particular markup language will not be sufficient for the demands that programmers put upon it.

And the demands are mounting. Pages should be able to be repurposed into syndication feeds (RSS 0.92/2.0, ATOM) which means programmers need article metadata. Interactive forms with validation should be available in HTML 4, HTML 5, Flash/Flex, XUL and XAML (with native controls where possible). Generating PDFs, ODTs and OOXML/DOCs would be nice, and data-tables within pages should be exportable to CSV or ODS.

HTML 4.01 is currently stirring the same kind of doubt in programmers that duplication in source code does. The abstraction in HTML 4.01 is insufficient. It seems wrong to code an application to produce HTML 4.01 when there are commonalities with HTML 5, XUL, Flash/Flex, XAML, etc. A series of tabs could be native in XUL and XAML but emulated with a hack of <div> tags in HTML. A slider control or a date picker could be native in HTML 5 but emulated in HTML 4. A programmer putting slider controls on a page shouldn’t code to a particular output format, they shouldn’t have to care.

Most programmers could easily imagine how an HTML 5 date picker could be automatically converted into HTML 4 and JavaScript but the reverse is not so easily conceivable. All the inconsistent hacks that HTML 4 pages use to emulate date pickers makes a conversion from HTML 4 to HTML 5 impossible for all but contrived and simplistic examples. Converting HTML 4 hacks will be considerably more difficult precisely because HTML 4 lacks standard semantics for expressing these widgets. The 4.xx series of HTML has been with us for so long that perceivably it has been a constant, and applications have been hard-coded to output HTML 4. Any abstraction from HTML 4 was considered over-engineering, widget hacks became common place, and the blind-spot grew.

The proliferation of JavaScript libraries to emulate widgets shows an inherent weakness in HTML 4 but the problem isn’t just in form widgets. Textural content also has limitations in HTML 4, as anyone who knows DocBook or TEI will tell you.

After recognising this problem of abstraction programmers are now looking for higher-level languages that can be converted into lower-level ones such as HTML 4, RSS, PDF, ODT, etc. This conversion may occur server-side with an abstract page definition… perhaps a source in HTML 5, Flex, XUL, or XAML that is converted into output formats such as HTML 4 with JavaScript, HTML 5 with JavaScript, XUL, XAML, RSS, ODT, PDF, and so on.

What would a source format that straddled all these formats look like? Well, the output formats all can represent tables, paragraphs, headings, images, text-boxes, date pickers, hyperlinks and so on. Some features clearly overlap. Beyond that it’s more difficult, and more debatable (do XUL and XAML have features that map poorly to HTML and SVG? Is an abstraction still useful without these features?) so I’ll save that for another blog post.

Of course the devil’s in the details, and the feasibility of straddling a useful subset will only be proven in the semantics chosen. Still, going through the process will be an interesting exercise.

What would wxWidgets for the web look like? Stay tuned…

(Please note: Although I specifically mention HTML 4 as being a poor abstraction or internal data-model for modern applications the same goes for XHTML 1 as they have the same semantics, obviously)