Compound Headaches
I’m going to hit this topic with a few posts (including the last one on LaTeX) because it comes up everywhere one looks: should everything be broken down into semi-independent parts? In other words, does componentization make things better, or just messy?
Jon Udell writes about the difficulties in giving presentations using what are traditionally web formats as his data. The “problem” is that you have an XHTML file with your content, a CSS file with styling information, a JavaScript file with data manipulation logic, and binary files with images, video, and sound. What a mess! You’ve either got to shepherd all these files yourself, or deal with archiving/unarchiving them around each transfer. The fun part about this situation is that “good design” in this day and age mandates a separation of data from presentation and business logic. Hooray!
The hope with separation is that components may be developed, debugged, and reused individually. By minimizing coupling between the elements that comprise the whole, one is able to more easily control the system because it is, inherently, less complex. The obvious example is that we’re all used to saving an image file independent from the web page we found it embedded in. This is made easier by the fact that the embedding is very loose, and is in fact an artefact of the final presentation; the data itself is not at all coupled.
Yet this facade separation is sometimes misleading. If I am the sole author of a web page, how much do I really gain by separating styling information from my content? The fact is that those two documents are not really completely independent. The style sheet I made is going to refer to class and id names that I decided on for the document I was authoring; those identifiers are not globally meaningful. In fact, my style sheet is only useful, without modification, for a document that uses the same identifiers.
Despite this limitation in the reusability of the components I am generating, I, as a lone document author, still benefit from compartmentalizing the various aspects of the document I wish for people to see. Even though there is an unavoidable coupling between all my source documents in their vocabularies, I am able to manage that coupling and create other text markup that uses the same terminology to identify semantically similar document sub-structures, or structures that are intended to be stylistically similar. That is, I can use the same CSS file to style a number of individual XHTML pages. Similarly for JavaScript, while it includes some terms that are essentially unique to the CSS and XHTML documents with which it was originally paired, by separating code elements out from the rest of the document I am better able to copy just the JavaScript part of one page over to the directory for another page. I may still need to edit the code to reflect different element ids or class names, but I am able to extract one aspect of the original document with much greater ease than if it had been embedded in the same file, or, worse, interspersed among the XHTML elements of the document.
As I mentioned, I will return to this issue in another post soon, but let me leave with this: Apple got this right. I think the correct solution here is to provide multiple views of the same data, much as Mac OS X does with .app files/directories. Most users can treat .app file system entries as the executable applications themselves. They can be moved, copied, and launched. Developers, or those of a curious disposition, can equally easily treat those same .app file system entries as directories and inspect the many files that make up an application. This is what I really want from a compound web page format: separate files that can be viewed and worked with as one atomic unit when that is desirable, but that remain separate entities for when that is desirable. In this solution, the problem turns out not to be one of compound documents, but of smart file hierarchy presentation and manipulation.
