Contesto

Quasi tutti i sistemi di gestione contenuti in produzione oggi salvano HTML, non contenuto. Quando un redattore scrive un testo, finisce nel database già impastato con tabelle di layout, attributi bgcolor, font e larghezze fisse in pixel: la struttura logica del documento e la sua resa grafica stanno nello stesso campo. La conseguenza la conosce chiunque abbia rifatto la grafica di un sito vecchio di qualche anno, o abbia provato a portare lo stesso archivio su un canale per cui non era nato. Non si ripubblica: si riscrive.

Il problema si fa serio quando un’organizzazione deve servire più canali dallo stesso archivio editoriale — il sito web, una versione per dispositivi a banda stretta, un’uscita stampabile, un feed di metadati per altri sistemi. Tenere quattro copie disallineate dello stesso contenuto è la scorciatoia a cui si ripiega quando il CMS non sa fare di meglio.

Architettura

C’è un’alternativa, ed è strutturale. Poggia su standard che oggi sono già Raccomandazioni W3C, non su prototipi da laboratorio. Il contenuto si salva in XML neutro rispetto alla presentazione: un articolo è un articolo, con titolo, corpo, autore, data, e niente che dica come apparirà. La resa per ogni canale è una trasformazione a valle, scritta in XSLT.

XSLT 1.0 è Raccomandazione W3C dal 16 novembre 1999; XSL per intero, comprese le formatting objects (XSL-FO) per l’uscita paginata, è arrivato a Raccomandazione il 15 ottobre 2001. Lo stesso documento sorgente produce così HTML per il browser tramite un foglio XSLT e — con un processore di formatting objects — un PDF impaginato per la stampa, senza mai duplicare il contenuto. La presentazione vive nei fogli di trasformazione; il contenuto resta unico.

A rendere operativa l’idea è la catena di pipeline. Apache Cocoon, la cui versione 2.0 è stata annunciata il 29 novembre 2001, la formalizza come sequenza generatore → trasformatore → serializzatore: un generatore produce eventi SAX da una sorgente, zero o più trasformatori li consumano e ne emettono altri (di solito applicando XSLT), un serializzatore chiude la catena e produce la risposta nel formato richiesto. Pubblicare su più canali si riduce allora a scegliere la pipeline giusta per il canale, invece di tenere in piedi archivi paralleli.

Sui metadati, RDF (Resource Description Framework), Raccomandazione W3C dal 22 febbraio 1999, dà il modello per descrivere i contenuti in modo che altri sistemi possano interrogarli. Insieme al vocabolario Dublin Core — la cui espressione in RDF/XML è diventata Raccomandazione DCMI nel luglio 2002 — l’archivio editoriale si esporta come grafo di asserzioni interrogabile, invece che come pagine HTML da cui raschiare le informazioni a posteriori.

Il nodo critico

Il problema non è la disponibilità degli standard. XML, XSLT, XSL-FO, RDF esistono e sono stabili. Il problema è che separare contenuto e presentazione sposta il costo, non lo cancella. Con il layout incollato dentro il contenuto, ogni pagina è il proprio modello: brutta da mantenere, ma immediata da creare per chi sa scrivere HTML. Con il contenuto neutro, qualcuno deve scrivere e mantenere i fogli XSLT — un lavoro diverso e più raro di quello del redattore medio.

C’è poi un costo d’ingresso editoriale. Un redattore che ha sempre lavorato in un editor visuale «quello-che-vedi-è-quello-che-ottieni» non vuole — e non deve — scrivere XML a mano. Serve uno strato di redazione che produca XML strutturato e valido senza esporre la sintassi, e che sappia rifiutare il contenuto malformato prima che entri nell’archivio. Se quello strato manca, la pulizia del modello a valle viene buttata via da sorgenti sporche a monte. È qui che molte architetture XML eleganti si arenano in produzione: all’interfaccia di redazione, non al motore di trasformazione.

Il terzo nodo è la cache. Una pipeline che applica XSLT a ogni richiesta paga un costo di calcolo per ogni pagina servita. Senza una strategia di caching dei risultati di trasformazione, l’eleganza architetturale si trasforma in collo di bottiglia sotto carico. Cocoon lo affronta apertamente con il caching a livello di pipeline; chi parte da zero deve risolverlo, non aggirarlo.

Implicazioni

Adottare questo modello ha una conseguenza che va oltre la tecnica: il contenuto sopravvive ai canali. Un archivio di articoli in XML neutro si ripubblica su un canale che ancora non esiste, perché aggiungere un’uscita vuol dire scrivere una nuova trasformazione, non migrare i dati. Lo stesso archivio è anche più facile da rendere accessibile: le WCAG 1.0, Raccomandazione W3C dal 5 maggio 1999, premiano proprio la separazione tra struttura logica e presentazione, che in un’architettura così è data per costruzione invece che aggiunta dopo.

La scelta dell’open source qui non è ideologica. Quando l’archivio editoriale di un’organizzazione vive per anni o decenni, la trasparenza del formato di memorizzazione e la possibilità di ispezionare il motore di trasformazione sono garanzie di continuità: il contenuto in XML standard resta leggibile anche se il software che lo gestisce cambia o scompare. È una proprietà che si misura sul lungo periodo, dove pesa più la sopravvivenza dei dati della comodità immediata di un editor. Una messa in pratica di questa architettura — la piattaforma CMOS, sviluppata con il MIUR e l’Università di Firenze — è documentata in un insight di noze: https://www.noze.it/insights/cmos-progetto/.

Limiti

Niente di tutto questo è gratis, né adatto a ogni progetto. Per un sito di poche decine di pagine destinato a un solo canale, l’overhead di una catena XML non si giustifica: l’HTML salvato diretto è più rapido da mettere in piedi e più economico da mantenere. Il modello a pipeline ripaga quando i canali sono molti, l’archivio è grande e longevo, e il contenuto vale più della singola pubblicazione.

Restano questioni aperte che gli standard del 2002 non chiudono. Modellare contenuti molto interconnessi — relazioni, riuso di frammenti, versionamento — non ha una risposta canonica in XSLT 1.0, che è un linguaggio di trasformazione albero-a-albero senza memoria tra documenti. Il workflow redazionale (chi approva cosa, quando un contenuto passa da bozza a pubblicato) è ortogonale alla catena di trasformazione e va costruito a parte. E le prestazioni di XSL-FO per generare PDF su volumi alti restano, a oggi, un terreno da misurare caso per caso più che da dare per scontato.

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

Immagine di copertina: Diagramma del pattern Model-View-Controller: l’utente interagisce con il Controller, che aggiorna il Model (i dati/contenuto) e… — diagramma di RegisFrey, pubblico dominio — https://commons.wikimedia.org/wiki/File:MVC-Process.svg