The first priority of this site was to provide a home for a set of written documents that didn't quite fit into the mold of blog or wiki. Now that I have assembled a relatively diverse and decently-sized body of work, I am focusing my attention on the site's infrastructure.
This site is currently written and curated by hand. All hypertext documents are valid XHTML™ 1.0, authored in Emacs 22. Files are kept in a Mercurial revision control system. A JavaScript library implementing the Knuth-Liang hyphenation algorithm, written by Mathias Nater, hyphenates justified paragraphs. Aside from a Python script I wrote that generates a graphical site map, and the help of Apache content negotiation and a few rewrite rules, this site is completely static.
Documents are then post-processed with an XSLT stylesheet on the client side. Browsers known to support XSLT include:
There appear to be problems with the way MSIE handles XSLT. Although the majority of my current readers use Firefox and Safari, MSIE still holds the majority stake of installed Web browsers. Although XSLT is an elegant solution to separating content from layout, I will provide pre-processed HTML variants of documents which will fix rendering issues for the affected browsers.
With respect this site's infrastructure, I have considered it important to satisfy the W3C Cool URI recommendations. That is, once you mint a URI, it ought to be accessible for life. I am taking this requirement further by making URIs that are meant to be read by people. Naming things is hard, and I am devising a method of easing the process as much as possible.
The taxonomy of this site is intentionally non-hierarchical, and, while the site is implemented as static files, will remain mostly flat. I am currently evaluating candidate designs for a dynamic faceted taxonomy which will automatically arrange resources in the most useful and unambiguous way possible, while keeping tabs on references, renames and deletions.
My ultimate goal for this site, in addition to being a platform for the publication and discussion of my ideas, is to demonstrate how the visions of the pioneers of hypertext can be dovetailed with the designs of the architects of the Web. As such, I am valuing conceptual integrity rather than focusing on features or integrating with third parties.
In keeping with the original tenets of hypertext, it is important to me to define resources as abstract objects that are serialized into different representations. This distinction would contribute to, among other things, a more fine-grained ability to transclude excerpts, as well as permute resources from one type into another. As such, it is unclear to me at this point whether ancillary resources such as feeds ought to be treated as first-class, or if they should be defined as derivatives of other resources.
It is extremely important to me to comply with Fielding's definition of REST. This states, among other things, that the basic unit of a REST-compliant software system is the resource and that the state of the system is transferred back and forth across the communication channel with each exchange. The aim of this constraint is to probe as well as demonstrate the extent of what can and cannot be achieved through strict compliance to the architectural style. The consequence is that I am not pursuing interactive functionality like commentary or an API until I can define the interaction in terms of this constraint.
The design of the site is intended to resemble a pencil sketch, insofar as it is rough, non-committal, and no more finished than it needs to be to get certain points across. Some may, however, still be inclined to wonder what's up with the layout.
I have managed to recently answer a number of questions concerning what goes under the hood. I am moving forward with the following: