Context

Almost every content management system in production today saves HTML, not content. When an editor writes a text, it lands in the database already kneaded together with layout tables, bgcolor attributes, fonts and fixed pixel widths: the logical structure of the document and its visual rendering sit in the same field. Anyone who has redesigned a site a few years old, or tried to move the same archive onto a channel it was never meant for, knows the consequence. You do not republish; you rewrite.

The problem turns serious when an organisation has to serve several channels from the same editorial archive — the website, a version for narrow-band devices, a printable output, a metadata feed for other systems. Keeping four out-of-sync copies of the same content is the shortcut you fall back on when the CMS cannot do better.

Architecture

There is an alternative, and it is structural. It rests on standards that are already W3C Recommendations today, not on laboratory prototypes. Content is saved as XML that is neutral with respect to presentation: an article is an article, with a title, a body, an author, a date, and nothing that says how it will look. The rendering for each channel is a transformation downstream, written in XSLT.

XSLT 1.0 has been a W3C Recommendation since 16 November 1999; XSL in full, including the formatting objects (XSL-FO) for paginated output, reached Recommendation status on 15 October 2001. The same source document thus produces HTML for the browser through an XSLT stylesheet and — with a formatting-objects processor — a paginated PDF for print, without ever duplicating the content. Presentation lives in the transformation sheets; the content stays one.

What makes the idea operational is the pipeline chain. Apache Cocoon, whose version 2.0 was announced on 29 November 2001, formalises it as a sequence of generator → transformer → serialiser: a generator produces SAX events from a source, zero or more transformers consume them and emit others (usually by applying XSLT), and a serialiser closes the chain and produces the response in the requested format. Publishing across several channels then comes down to picking the right pipeline for the channel, instead of keeping parallel archives alive.

On metadata, RDF (Resource Description Framework), a W3C Recommendation since 22 February 1999, gives the model for describing content so that other systems can query it. Together with the Dublin Core vocabulary — whose expression in RDF/XML became a DCMI Recommendation in July 2002 — it lets the editorial archive be exported as a queryable graph of statements, rather than as HTML pages information has to be scraped out of after the fact.

The critical knot

The issue is not the availability of the standards. XML, XSLT, XSL-FO and RDF exist and are stable. The issue is that separating content from presentation shifts the cost; it does not erase it. With layout glued inside the content, every page is its own template: ugly to maintain, but immediate to create for anyone who can write HTML. With neutral content, someone has to write and maintain the XSLT sheets — a different and rarer trade than the average editor’s.

There is also an editorial cost of entry. An editor who has always worked in a what-you-see-is-what-you-get visual tool does not want — and should not be made — to write XML by hand. You need an authoring layer that produces valid, structured XML without exposing the syntax, and that can reject malformed content before it enters the archive. If that layer is missing, the cleanliness of the downstream model is thrown away by dirty sources upstream. This is where many elegant XML architectures get stuck in production: at the authoring interface, not the transformation engine.

The third knot is caching. A pipeline that applies XSLT on every request pays a compute cost for every page served. Without a strategy for caching transformation results, architectural elegance turns into a bottleneck under load. Cocoon tackles it openly with pipeline-level caching; whoever starts from scratch has to solve it, not sidestep it.

Implications

Adopting this model has a consequence beyond the technical: content outlives its channels. An archive of articles in neutral XML can be republished to a channel that does not yet exist, because adding an output means writing a new transformation, not migrating the data. The same archive is also easier to make accessible: WCAG 1.0, a W3C Recommendation since 5 May 1999, rewards precisely the separation between logical structure and presentation, which in such an architecture comes by construction rather than as an afterthought.

The choice of open source here is not ideological. When an organisation’s editorial archive lives for years or decades, the transparency of the storage format and the ability to inspect the transformation engine are guarantees of continuity: content in standard XML stays readable even if the software managing it changes or disappears. It is a property measured over the long run, where the survival of the data weighs more than the immediate convenience of an editor. One implementation of this architecture — the CMOS platform, developed with the MIUR and the University of Florence — is documented in a noze insight: https://www.noze.it/en/insights/cmos-project/.

Limits

None of this is free, nor suited to every project. For a site of a few dozen pages bound for a single channel, the overhead of an XML chain is not worth it: HTML stored directly is faster to stand up and cheaper to maintain. The pipeline model pays back when the channels are many, the archive is large and long-lived, and the content is worth more than a single publication.

Open questions remain that the standards of 2002 do not close. Modelling heavily interconnected content — relationships, fragment reuse, versioning — has no canonical answer in XSLT 1.0, which is a tree-to-tree transformation language with no memory across documents. The editorial workflow (who approves what, when content moves from draft to published) is orthogonal to the transformation chain and must be built separately. And the performance of XSL-FO for generating PDFs at high volumes remains, to date, ground to be measured case by case rather than taken for granted.

https://www.w3.org/TR/xslt-10/ https://www.w3.org/press-releases/2001/xsl/ https://xml.coverpages.org/Cocoon20ReleaseAnnounce.html https://www.w3.org/press-releases/1999/rdf/ https://www.dublincore.org/specifications/dublin-core/dcmes-xml/ https://www.w3.org/1999/05/WCAG-REC-fact

Cover image: Diagram of the Model-View-Controller pattern: the user interacts with the Controller, which updates the Model (the data/content) and… — diagram by RegisFrey, public domain — https://commons.wikimedia.org/wiki/File:MVC-Process.svg