Introduzione

All'incirca nel 1990, Tim Berners-Lee sviluppò tre specifiche che formarono la base del progetto World Wide Web: l'HyperText Markup Language (HTML) fu sviluppato come un formato di documento per il Web; gli Universal Resource Locators (URL) furono aggiunti per rappresentare i collegamenti tra i documenti; e l'HyperText Transfer Protocol (HTTP) fu sviluppato per trasferire i documenti tra le macchine su Internet [Berners-Lee 1999]. Sia le specifiche che le implementazioni furono rese liberamente disponibili dal CERN.

Il Web rapidamente prese slancio. Con l'uscita del browser Mosaic del National Center for Supercomputing Applications (NCSA) nel 1993 [Andreessen 1993a], gli utenti all'improvviso ebbero un browser attraente per navigare un insieme di documenti collegati tra loro in continuo aumento. Con un numero crescente di utenti, sempre più autori furono attratti dal Web, e il contenuto proliferò.

All'inizio l'HTML era un semplice formato di documento strutturato con tag di marcatura aggiunti tra le stringhe di testo per indicare il ruolo del testo. Per esempio, una stringa di testo poteva essere marcata come un paragrafo, mentre un'altra stringa come un collegamento cliccabile. Gli elementi nel primo HTML erano logici piuttosto che presentazionali. Per esempio, l'HTML avrebbe marcato del testo come un titolo ma non avrebbe descritto come il titolo doveva essere rappresentato. La presentazione del testo – inclusi quale font, colore e dimensione da usare – era principalmente stabilito dal browser.

Struttura contro presentazione

Gli ambienti scientifici come il CERN valorizzano la logica, la struttura e il contenuto più che l'estetica, le immagini e lo stile. Questo senso della struttura si riflette nell'HTML. Ogni paragrafo è marcato come tale e ai titoli viene dato un livello numerato per indicare la loro collocazione nella struttura del documento.

Quando il Web cominciò ad attrarre l'attenzione al di fuori degli ambienti scientifici, gli autori cominciarono a lamentarsi del fatto di non avere abbastanza influenza sull'aspetto delle loro pagine. Una delle domande più frequenti degli autori nuovi al Web era come poter cambiare i font e i colori degli elementi. Questo passaggio tratto da un messaggio inviato alla mailing list www-talk [www-talk] all'inizio del 1994 [Andreessen 1994a], da il senso della tensione esistente tra autori e sviluppatori di browser In questo capitolo ho citato un messaggio inviato ad una mailing list per la comunità degli sviluppatori, e lo farò molte volte nei capitoli successivi. Le mailing list erano fondamentali per tenere insieme la comunità del Web nei primi anni, e gli archivi ipertestuali delle mailing list si ampliarono rapidamente nei primi anni '90. Oggi, dieci anni dopo, questi archivi forniscono uno sguardo interno di valore al web design e allo sviluppo web. :

Infatti, per me è stata una constante fonte di piacere durante lo scorso anno sentirmi continuamente dire, da orde (letteralmente) di persone che – tenetevi forte, ci siamo – volevano controllare il layout dei loro documenti in modi che sarebbero banali in TeX, Microsoft Word, e ogni altro comune ambiente di eleborazione testuale,: "Spiacente, sei fregato."

L'autore del messaggio era Marc Andreessen, uno dei programmatori del browser NCSA Mosaic. In seguito divenne co-fondatore di Netscape, che soddisfò le richieste degli autori introducendo tag presentazionali nell'HTML. Il 13 ottobre 1994, Netscape annunciò [Andreessen 1994b] la prima versione beta del loro browser. Il browser Netscape supportava un insieme di nuovi tag HTML presentazionali (per esempio CENTER per centrare il testo) e altri sarebbero seguiti in breve.

Livelli di astrazione

Aggiungendo tag presentazionali all'HTML, il linguaggio si evolse dall'essere un linguaggio di marcatura astratto e strutturato dove gli autori marcavano le differenti regole logiche del testo (paragrafi, intestazioni, elenchi e così via) in un concreto linguaggio di presentazione dove l'enfasi è posta sulla presentazione della forma finale dei documenti (font, colori e layout).

Nella tradizionale pubblicazione cartacea, il lettore riceve un prodotto di forma finale. Ogni lettera sulla pagina stampata ha una posizione fissa, forma, dimensione e colore che non possono essere cambiate dal lettore. I documenti elettronici, tuttavia, sono prodotti non finiti che devono essere assemblati prima di poter essere presentati al lettore umano. Nel processo di assemblaggio – meglio noto come formattazione – vengono fatte molte scelte sulla presentazione del documento. Per esempio, il browser deve selezionare i font e i colori da usare quando presenta il documento su uno schermo a colori. Il livello di eleborazione richiesto da un documento elettronico varierà a seconda del formato di documento usato. Come tali, i documenti elettronici sono simili ai mobili: alcuni mobili giungono pre-assemblati, mentre altri vengono comprati in scatole e il proprietario deve eseguire l'assemblaggio finale. Se un formato di documento richiede molta eleborazione, si dice che ha un alto livello di astrazione. Se il formato di documento richiede poca eleborazione, si dice che ha un basso livello di astrazione.

Determinare il giusto livello di astrazione è una parte importante dello sviluppo di un formato di documento. Se il livello di astrazione è alto, il processo di authoring e il compito di formattare il documento divengono più complessi. L'autore deve far riferimento a concetti astratti non-visibili. Dal lato della ricezione, il browser deve trasformare oggetti astratti in oggetti concreti e questo compito è più complesso se gli elementi sono altamente astratti. Il beneficio di un alto livello di astrazione è che il contenuto può essere riutilizzato in molti contesti. Per esempio, un'intestazione può essere presentata a grandi lettere su fogli stampati, e con voce più forte in un sistema di letture vocale del testo.

Di contro, un basso livello di astrazione renderà il processo di authoring e di formattazione più facili (fino a un certo punto). Gli autori possono usare strumenti orientati al WYSIWYG (What You See Is What You Get), e il browser non deve eseguire trasformazioni estese prima di presentare il documento. L'inconveniente di usare formati di documento orientati alla presentazione è che il contenuto non è facilmente riutilizzabile in altri contesti. Per esempio, può essere difficile rendere disponibili documenti orientati alla presentazione per un dispositivo con una diversa dimensione dello schermo, o per una persona con menomazioni visive.

Quando si trasformano i documenti da un formato ad un altro, vi è la possibilità che i due formati siano su diversi livelli di astrazione. In generale, è possibile trasformare documenti da un livello di astrazione più alto ad uno più basso, ma non il contrario. La scala di astrazione viene introdotta in questa tesi come un modo per misurare il livello di astrazione.

HTML presentazionale

L'introduzione dei tag presentazionali in HTML fu un passo indietro nella scala d'astrazione. Diversi nuovi elementi (per esempio BLINK) avevano senso solo per particolari dispositivi di output (come viene visualizzato il testo lampeggiante su un sistema di sintesi vocale?). I creatori dell'HTML volevano che tale linguaggio fosse utilizzabile per molte impostazioni ma i tag presentazionali minacciavano l'indipendenza dal dispositivo, l'accessibilità e il riutilizzo del contenuto.

Lo sviluppo dell'HTML verso un linguaggio orientato alla presentazione cambiò anche l'equilibrio di potere tra autori e utenti. I documenti strutturati devono essere formattati dal browser prima della presentazione, e – in una certa misura – il processo di formattazione può essere influenzato dall'utente. Tuttavia, quando il browser riceve un documento nella sua forma finale, il processo di formattazione è completo è non può più essere influenzato dall'utente.

Gli autori web avevano chiesto più influenza sulla presentazione del documento e accolsero di buon grado questo sviluppo, ma vi era anche una resistenza nella comunità del Web. Molti erano consapevoli del fatto che il Web aveva il potenziale per realizzare pubblicazioni personalizzate dove il lettore aveva il controllo – piuttosto che l'editore –. Il contenuto dovrebbe essere selezionabile secondo le preferenze del lettore, e il media e la forma di presentazione dovrebbero anch'essi essere una scelta del lettore. Trasformando l'HTML in un linguaggio di presentazione c'era il rischio di perdere i gradi di libertà necessari a realizzare un modello di pubblicazione incentrato sull'utente.

Fogli di stile

I fogli di stile furono proposti come alternativa all'evoluzione dell'HTML da linguaggio strutturale a linguaggio presentazionale. Il termine foglio di stile viene usato nella pubblicazione tradizionale come un modo per assicurare consistenza [Chicago 1993] nei documenti. Nel processo di pubblicazione tradizionale, un manoscritto è accompagnato da un foglio di stile che serve da resoconto corrente delle regole di stile e di uso del linguaggio adottate da un particolare manoscritto [Brüggemann-Klein&Wood 1992].

Negli anni '80 la pubblicazione cambiò drasticamente con l'introduzione dei personal computer per l'uso nella preparazione dei manoscritti. La pubblicazione elettronica offriva strumenti per semplificare tutte le fasi della pubblicazione, dalla progettazione, all'editazione e alla strampa. Nella pubblicazione elettronica, il termine foglio di stile venne a significare un insieme di regole su come presentare il contenuto, piuttosto che regole su come scrivere il contenuto. I fogli di stile sarebbero stati specificati dal designer e inviati al compositore prima della stampa. Di solito avrebbero descritto il layout visivo di un documento incentrato sul testo, inclusi i font, i colori e lo spazio bianco.

In questa tesi, il termine foglio di stile si riferisce ad un insieme di regole che associano proprietà stilistiche e valori a elementi strutturali in un documento, ossia esprimendo come presentare un documento. I fogli di stile di solito non contengono contenuto, sono collegabili dai documenti e sono riutilizzabili. Questa definizione consente che il termine venga usato per la pubblicazione elettronica dentro e fuori il Web.

I fogli di stile erano disponibili sui sistemi di pubblicazione elettronica sin dal 1980 (si veda il capitolo 2 e 3). Combinati con i documenti strutturati, i fogli di stile offrivano un late binding [Reid 1989] di contenuto e presentazione dove contenuto e presentazione sono combinati dopo che la fase di progettazione è completa. Questa idea attrasse gli editori per due ragioni. Per prima cosa, si poteva raggiungere uno stile consistente attraverso un insieme di pubblicazioni. Secondariamente, l'autore non doveva preoccuparsi della presentazione della pubblicazione ma poteva concentrarsi sul contenuto.

Alcuni autori trovarono liberatorio non doversi preoccupare di dettagli presentazionali nel processo di progettazione [Cailliau 1997]. Tuttavia la maggioranza degli autori finì con l'usare sistemi di progettazione che enfatizzano la presentazione piuttosto che la struttura [Sørgaard 1996].

WYSIWYG – un modello in gara

WYSIWYG – What You See Is What You Get – è un modello in gara per la progettazione di documenti. Le applicazioni WYSIWYG aggiornano costantemente una presentazione della forma finale. Man mano che l'autore digita sulla tastiera, lo schermo è aggiornato per riflettere il layout di pagina che risulterebbe se il documento venisse stampato in quel momento.

Invece del late binding tra presentazione e contenuto, usato dai documenti strutturati e dai fogli di stile, il WYSIWYG offre un instant binding [legame istantaneo, N.d.T.]; tutte le operazioni di editazione risultano nelle istantanee modifiche visive fino alla presentazione finale. Questo approccio si ha nei documenti in cui gli autori enfatizzano la presentazione finale – di solito un documento stampato – piuttosto che la marcatura logica.

Diverse applicazioni provano a combinare il concetto di documenti strutturati con l'editing WYSIWYG, fra cui FrameMaker di Adobe [FrameMaker], Microsoft Word [MS-Word] e Amaya del W3C [Amaya]. Di solito queste applicazioni offrono all'autore diverse visuali del documento di cui una è WYSIWYG e altre che sono più strutturali. Questo rende possibile scrivere documenti strutturati con un tool WYSIWYG. Tuttavia c'è un rischio associato all'uso di strumenti WYSIWIG: consentono anche gli autori di eseguire modifiche puramente presentazionali che possono non essere relazionabili con la struttura del documento.

Caratteristiche del Web

La ricerca ha dimostrato che quando i documenti sono progettati con la copia stampata come obiettivo finale è difficile motivare gli autori a lavorare su un livello logico piuttosto che su uno visuale [Sandahl 1999]. Con l'affermazione del Web, tuttavia, aumentano le possibilità per il riutilizzo del contenuto. Invece di stampare e distribuire i documenti su carta, i documenti web sono trasferiti elettronicamente sul computer dell'utente. Lo spostamento verso la distribuzione elettronica dei documenti ha diverse caratteristiche chiave che influenzano sia il processo di progettazione che i linguaggi di stile.

• Il late binding diviene later binding: sul Web, i documenti sono trasmessi in forma elettronica sul computer dell'utente. Il late binding fra contenuto e presentazione della pubblicazione elettronica diviene later binding sul Web. Il binding [legame, N.d.T.] non ha più luogo nel luogo di pubblicazione ma, piuttosto, nel computer dell'utente. Questo aumenta la libertà di presentazione ma pone anche una nuova sfida di esecuzione, poichè il binding ha luogo quando l'utente è in attesa. Ancora: l'autore non è presente per assicurarsi che la presentazione sia corretta.
• La pubblicazione incetrata sulla carta diviene incentrata sullo schermo: Prima dell'avvento del Web, gran parte dei documenti elettronici finivano come documenti stampati. Erano editati ed elaborati su schermi di computer ma, assai spesso, il tipo di media finale era la stampa. Sul Web, la maggioranza degli utenti vede i documenti sullo schermo.
• Un output singolo si trasforma in output multipli: Sebbene gli schermi siano il tipo di media principale sul Web, esistono molti altri tipi. Gli autori non conoscono il tipo di dispositivo di output che verrà usato da un utente. Non c'è più una sola presentazione di forma finale, ma ve ne sono molte. Perciò è importante che i fogli di stile possano descrivere presentazioni per dispositivi di output multipli.
• Il controllo dell'autore diviene influenza condivisa tra autore e utente: Poichè il legame tra contenuto e presentazione ha luogo sul computer dell'utente, le influenze provenienti da fonti diverse possono essere combinate per formare una presentazione. Data questa libertà, sembra ragionevole che l'utente – come l'autore – dovrebbe poter influenzare la presentazione. Diventano possibili presentazioni basate sui bisogni e le preferenze dell'utente. Ciò si distingue da altri ambienti di pubblicazione, dove gli autori hanno il controllo completo della presentazione.
• Documenti autonomi divengono collegati ipertestualmente: Il Web è un grande insieme di documenti collegati ipertestualmente e l'informazione precedentemente espressa come riferimenti testuali può ora essere espressa come ipercollegamenti attivi.
• La distribuzione sicura diviene incerta: Le risorse web sono distribuite su molti computer interconnessi e la possibilità che una risorsa non sia disponibile è considerevole. Un altro cambiamento sta nel fatto che è più probabile che il Web fallisca rispetto ai sistemi di pubblicazione tradizionali. È naturale rendere disponibile il foglio di stile sul Web, ma la risorsa può non essere sempre disponibile per l'utente.

Così, con l'introduzione del Web, il campo dei fogli di stile si è spostato dall'essere uno strumento per gli autori nel processo di progettazione all'essere uno strumento per il riutilizzo del contenuto dopo la sua generazione. I fogli di stile sul Web sono potenzialmente più importanti di quelli della pubblicazione incentrata su carta poichè la possibilità del riutilizzo del contenuto è maggiore. Come la natura dei fogli di stile è cambiata dalla pubblicazione cartacea a quella elettronica, così la natura dei fogli di stile è cambiata nuovamente per la pubblicazione web.

Meccanismi del foglio di stile per il Web

Una rozza forma di fogli di stile fu inserita nel primo WWW client implementato sulla macchina NeXT al CERN. Tuttavia, non fu scritta alcuna specifica per i fogli di stile e non fu proposta alcuna sintassi per un linguaggio di stile; si considerò un problema di ciascun browser decidere come far visualizzare le pagine agli utenti.

I potenziali benefici dell'uso di fogli di stile sul Web sono significativi. Un meccanismo di foglio di stile ben sviluppato fornirebbe agli autori un vocabolario stilistico più ricco rispetto all'evoluzione possibile dell'HTML. Ancora: l'HTML rimarrebbe un linguaggio di marcatura strutturato che funziona su un'ampia gamma di dispositivi.

Per questi motivi, molte persone sulla mailing list www-talk [www-talk], che era il luogo di incontro elettronico della prima comunità web, concordarono che il Web avrebbe tratto beneficio dai fogli di stile. Tuttavia, c'era un disaccordo sul fatto che il Web richiedesse o meno un nuovo linguaggio di stile oppure se fosse più adatto uno già esistente, concepito principalmente per la pubblicazione cartacea.

Diversi linguaggi di stile per il Web furono proposti nel 1993 (si veda il Capitolo 4: proposte di fogli di stile per il Web) ma nessuno prese slancio. Ciò era principalmente dovuto alla carenza di supporto nei browser; poichè Mosaic – di gran lunga il browser più popolare dei suoi tempi – non supportò i fogli di stile, gli autori erano poco motivati a scriverli. Ancora: nesssuna delle proposte raggiunse lo stato di stabilità. Un linguaggio di stile di successo per il Web doveva essere abbastanza convincente per essere implementato dagli sviluppatori di browser e per essere usato dagli autori.

CSS

Tre giorni prima che Netscape annunciò il suo nuovo browser, l'autore pubblicò la prima proposta sui CSS (denominata Fogli di stile a cascata per l'HTML – una proposta) [Lie 1994] sul Web. Oltre a descrivere font, colori e layout di documenti – già fatto in precedenza da diverse proposte – i CSS introducevano una nuova funzionalità per tener conto delle differenze di pubblicazione imposte dal Web. Il concetto di cascata consentiva sia agli autori che agli utenti di influenzare la presentazione di un documento:

Lo schema proposto fornisce al browser un elenco ordinato (cascata) di fogli di stile. L'utente fornisce il foglio iniziale che può richiedere un controllo totale della presentazione, ma – più verosimilmente – gestisce l'influenza sui fogli di stile che si riferiscono al documento fornito.

Il negoziato tra i bisogni e i desideri dei lettori e degli autori era una delle principali ambizioni dei CSS. In caso di successo, gli autori avrebbero avuto la loro influenza sulla presentazione e non si sarebbero sentiti costretti a usare l'HTML presentazionale e altri trucchi. I lettori, da parte loro, avrebbero avuto dei documenti in una forma in cui potevano scegliere se accettare la presentazione suggerita dall'autore o specificarne una propria.

In molti casi non vi sarebbe stato conflitto tra autore e lettore. Nessuno dei due, ad esempio, potrebbe voler specificare la presentazione del documento. In questi casi, è importante che il browser abbia un foglio di stile predefinito che descriva la presentazione predefinita dei documenti HTML. I CSS, dunque, definiscono tre fonti possibili per i fogli di stile: autori, lettori e browser. I CSS sono in grado di combinare i fogli di stile da queste tre fonti per formare la presentazione di un documento. Il processo che combina diversi fogli di stile – e risolve i conflitti se questi ricorrono – è conosciuto come cascata.

Lo sviluppo dei CSS

La prima proposta sui CSS fu inoltrata nello spirito del libero scambio di idee su come il Web avrebbe dovuto svilupparsi, e le discussioni ebbero luogo sulle mailing list pubbliche. Un certo numero di persone rispose alla proposta [Bos 1994][Behlendorf 1994][Wei 1994] e la bozza fu ulteriormente sviluppata. Durante il 1995, furono pubblicate circa otto revisioni. L'ultima, del dicembre 1995, fu dichiarata stabile e i produttori di browser furono incoraggiati a usarla come base per le implementazioni [Lie 1996].

Con qualche piccola eccezione, la sintassi della bozza del dicembre 1995 è rimasta stabile e la prima sezione delle specifiche può ancora servire da introduzione ai CSS :

Sviluppare semplici fogli di stile è facile. C'è solo bisogno di conoscere un pò di HTML e la terminolgia di base della pubblicazione desktop. Per esempio, per impostare il colore del testo degli elementi 'H1' sul blu, si può scrivere:

  H1 { color: blue } 

L'esempio consiste di due parti principali: il selettore ('H1') e la dichiarazione ('color: blue'). La dichiarazione ha due parti, proprietà ('color') e valore ('blue').

Le specifiche CSS1 divennero una Raccomandazione W3C [CSS1 1996] nel dicembre 1996. Nel maggio 1998 i CSS2 divennero una Raccomandazione W3C [CSS2 1998]. Il capitolo 6 (Fogli di stile a cascata) descrive lo sviluppo delle Raccomandazioni con più dettagli.

Dieci anni dopo la pubblicazione della prima proposta CSS, tutti i maggiori browser supportano i CSS e la maggioranza della pagine web li usa. Può ancora essere prematuro valutare appieno i CSS e il loro impatto sul Web, ma è possibile studiare lo sviluppo dei CSS e compararlo con altri linguaggi di stile e proposte di linguaggi di stile.

Sommario e conclusioni

Questo capitolo introduce alcuni concetti chiave della tesi. L'HTML fu sviluppato come un semplice formato di documento strutturato per il Web. Poichè gli autori chiedevano più influenza sulla presentazione dei loro documenti, l'HTML cominciò a divenire un linguaggio presentazionale piuttosto che strutturale. Per fermare questo passo indietro nella scala d'astrazione, i CSS furono sviluppati come un linguaggio di stile per il Web. I fogli di stile avevano avuto un ruolo nella pubblicazione elettronica sin dagli anni '80. Sul Web, il campo dei fogli di stile si è spostato dall'essere uno strumento nel processo di progettazione a quello di uno strumento per il riutilizzo del contenuto dopo che il contenuto è stato generato.

La tesi esplora in dettaglio perchè il Web richiede differenti linguaggi di stile rispetto ad altri tipi di pubblicazione, e come tali linguaggi possono essere sviluppati. Prima di ciò, tuttavia, è necessario discutere due altri argomenti. In primis, i documenti strutturati devono essere compresi affinchè i fogli di stile vi siano applicati. In secundis, i linguaggi di stile sviluppati prima dell'avvento del Web devono essere studiati per determinare se si addicono al Web. Questo viene fatto rispettivamente nel capitolo 2 e 3.

Documenti strutturati

I linguaggi di stile e i documenti strutturati sono reciprocamente dipendenti l'uno dall'altro. Senza i fogli di stile, i documenti strutturati non possono essere presentati, e senza i documenti strutturati non v'è nulla da presentare per i fogli di stile. A causa della forte relazione tra i due, è importante comprendere i documenti strutturati quando si studiano i linguaggi di stile. Alcuni sistemi di documento strutturato che hanno influenzato di più i linguaggi di stile sono discussi in questo capitolo.

In un'opera fondamentale intitolata Structured Documents [André, et al. 1989], l'argomento è definito  come:

Un documento può essere descritto come un insieme di oggetti con oggetti di livello più alto formati da oggetti più primitivi. Le relazioni tra oggetti rappresentano le relazioni logiche tra i componenti del documento. Per esempio, il presente documento è descritto come un libro al livello più alto. Il libro è suddiviso in capitoli, ogni capitolo in sezioni, sottosezioni, paragrafi e così via. Tale organizzazione del documento è conosciuta come rappresentazione di documento strutturato.

Un'importante caratteristica della rappresentazione di documento stratturato è che essa ha un certo livello di astrazione. Il livello di astrazione è particolarmente importante quando il documento strutturato è combinato con un foglio di stile per formare una presentazione. Perciò, la prima parte di questo capitolo discute i livelli di astrazione nei documenti strutturati e propone una scala di astrazione per misurare il livello di astrazione nei formati di documento per il Web.

La seconda parte del capitolo descrive i fondamentali sistemi di documenti strutturati, ossia Scribe, LaTex, Open Document Architecture (ODA), Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML); e Extensible Markup Language (XML). Ognuno di questi sistemi è descritto brevemente dal punto di vista storico e tecnico, con speciale rilievo sulle loro relazioni con i linguaggi di stile.

Una terza parte discute la relazioni tra linguaggi trasformazionali e linguaggi di stile sul Web.

Livelli di astrazione

Nel suo libro, Language in Action, Hayakawa [Hayakawa 1940] introduce il concetto di scala linguistica di astrazione. Alla base della scala d'astrazione vi è un oggetto. Come esempio, Hayakawa usa una mucca chiamata Bessie. La mucca è composta di muscoli, ossa, pelle e altre parti biologiche. Come primo gradino salendo la scala, tralasciamo la biologia della mucca ma manteniamo le sue proprietà fisiche – per esempio il suo colore, dimensione e forma – e la chiamiamo Bessie. Bessie è solo una dei molti oggetti che possono essere classificati come mucche. Nella fattoria in cui vive Bessie, ci sono molte altre specie di animali a cui ci si può riferire come bestiame. La salita sulla scala di astrazione può continuare fino alle attività della fattoria e alla sua ricchezza. Il concetto è illustrato nella Figura 1.

Un esempio simile di livelli di astrazione può essere trovato nel campo delle reti di computer. Nel 1983, la International Standards Organization (ISO) sviluppò un modello di network chiamato Open Systems Interconnection (OSI) Reference Model che definiva una struttura per le comunicazioni tra computer. L'ISO/OSI Reference Model ha sette strati, ciascuno dei quali ha un diverso livello di astrazione. I sette strati sono: fisico, collegamento dati, rete, trasporto, sessione, presentazione e applicazione.

Credo che il concetto di una scala di astrazione sia utile quando si valutano i formati di documento. L'altezza di un certo formato di documento sulla scala determinerà la complessità della formattazione del documento all'atto della presentazione. Poichè la formattazione di un documento è specificata da un foglio di stile, il livello di astrazione è una caratteristica decisiva per il successo dei fogli di stile.

La natura verticale di una scala corrisponde al modo in cui si descrivono i livelli di astrazione come alti o bassi. Le caratteristiche tipiche dei formati di documento che sono alti sulla scala di astrazione sono:

• L'informazione ha bisogno di elaborazione per essere presentata. Per esempio, per rendere visivamente un documento HTML le parole devono essere divise in righe, i font devono essere selezionati, e i caratteri devono essere convertiti in glifi rasterizzati.
• L'informazione può essere elaborata e presentata in molti modi diversi. Presentare un documento visivamente è solo una tra diverse possibilità; le altre comprendono la resa acustica e il braille.
• L'informazione è rappresentata in modo compatto. Rappresentare un carattere con una codifica a otto bit è più compatto che rappresentare un'immagine dello stesso carattere.

Di contro, i documenti scritti in formati che sono bassi sulla scala di astrazione richiedono meno elaborazione per essere presentati, hanno meno flessibilità nella presentazione e sono meno compatti.

Un'altra importante osservazione è che è generalmente possibile trasformare i documenti su livelli più bassi nella scala, ma è molto più difficile fare il contrario [Lie&Saarela 1999]. Per esempio, i browser web grafici – in collaborazione col sistema a finestre – rasterizzano i documenti HTML in pixel e perciò spostano l'informazione in basso sulla scala di astrazione. Il software Optical Character Recognition (OCR) cerca di salire la scala trasformando le immagini in testo, ma i sistemi OCR funzionano solo sotto determinate condizioni e sono inclini agli errori. Similmente, è impossibile progettare un algoritmo che converta i documenti scritti in un linguaggio Turing-complete a causa del problema dell'arresto [Connolly 1994a].

Nel contesto dei formati di documenti web, credo che si possano usare i seguenti criteri per determinare i gradini nella scala di astrazione:

• Il testo è leggibile dall'uomo? Ossia, se il documento viene presentato ad un lettore umano, lui/lei sarà in grado di leggere il documento?
• Il testo è leggibile dalla macchina? Ossia, il formato ha una nozione di caratteri numerati o rappresenta il testo come immagini – nel qual caso il testo non è disponibile?.
• L'ordine logico del testo è preservato? Ossia, i documenti scritti in tale formato hanno una nozione dell'ordine logico di lettura del contenuto?
• Il documento è scalabile? Ossia, si può zoomare il documento senza introdurre artefatti visibili?
• Il riflusso è possibile? Ossia, si può far rifluire il testo in righe, colonne e pagine di differenti dimensioni?
• Si possono rappresentare le regole dei vari elementi testuali? Per esempio, l'autore può marcare parte del testo come un'intestazione, un paragrafo, o come il nome di una variabile in un programma di computer? Essere in grado di distinguere tra queste regole è importante. Quando si rendono disponibili i documenti in braille, per esempio, parte del testo dovrebbe essere contratta (per esempio le intestazioni), mentre altre parti non dovrebbero esserlo (per esempio i nomi di variabili) [Lorimer 1996].
• Il formato è indipendente dal dispositivo? Ossia, i documenti scritti nel formato dato possono essere resi su diversi dispositivi (per esempio stampanti, schermi, stampanti braille e sintetizzatori vocali) oppure sono concepiti per un solo tipo di dispositivo?
• Il formato contiene semantica per una specifica applicazione? L'HTML è un generale formato di documento che non cerca di descrivere la semantica di più campi specialistici, per esempio la matematica e la chimica, e perciò non contiene semantica per una specifica applicazione. I formati che la contengono tendono ad essere più alti nella scala di astrazione.

La tabella 1 mostra le relative posizioni dei vari formati di documento sulla scala di astrazione. Alcune note alla tabella:

• GIF [GIF 1990] e PNG [PNG 1996] sono formati di immagine bitmap piuttosto che formati di documento, ma le immagini sono spesso usate per rappresentare documenti. La trasmissione dei fax è un esempio comune fuori del Web.
• PDF [Adobe 1993] è un formato di documento sviluppato dalla Adobe Systems. PDF è un formato orientato alla presentazione e non ha, per esempio, alcuna nozione di paragrafi ed intestazioni. Molti utenti lo hanno scoperto quando hanno provato a copiare il contenuto da documenti PDF suddivisi in diverse colonne. Quando si seleziona il testo, la selezione si estenderà su colonne multiple e perciò mischierà il testo preso da diverse parti del documento nella stessa selezione. Versioni recenti di PDF hanno introdotto una funzionalità per mantenere la struttura logica del documento in PDF [Adobe 2001].
• XSL-FO si riferisce a un documento che consiste in oggetti di formattazione come definito nella Raccomandazione XSL [XSL 2001]. XSL-FO è discusso più avanti in questo capitolo.
• XML [XML 1998], in cui sono scritti diversi formati emergenti, è anch'esso incluso nella tabella e si riferisce a documenti pubblicati usando vocabolari XML privati dove la semantica non è universalmente conosciuta.
• La classificazione dell'HTML è basata su uno scenario ideale in cui l'autore fa uso di elementi semantici e non altera l'ordine di lettura degli elementi usando caratteristiche come il posizionamento o le tabelle. Si può osservare come la maggioranza dei documenti HTML non segue queste convenzioni.
• MathML è una raccomandazione W3C per la notazione matematica [MathML 1998].

Dopo aver stabilito la scala di astrazione come strumento di misurazione dei formati di documento strutturato, la sezione seguente discute i sistemi di documento strutturato in dettaglio.

Sistemi di documento strutturato

A partire dal 1980, ci fu un'attiva comunità di ricerca nel campo della pubblicazione elettronica e dei documenti strutturati. La comunità pubblicò i suoi risultati nel corso delle conferenze sulla Electronic Publishing, nel periodico Electronic Publishing – Origination, Dissemination and Design [Electronic Publishing], e la Cambridge University Press pubblicò una serie di libri sull'argomento. Richard Furuta elenca molte delle opere importanti in Important papers in the history of document preparation systems: basic sources [Furuta 1992].

I ricercatori erano per lo più d'accordo sui benefici dei formati di documento neutrali rispetto al produttore, per facilitare lo scambio di documenti. I benefici dei documenti strutturati erano anch'essi ben compresi. Vi erano, tuttavia, diversi approcci ai documenti strutturati, e furono sviluppati formati in gara tra loro. Questa sezione descrive e discute quattro di loro.

Una linea di sviluppo cominciò alla fine degli anni '70, quando Brian Reid sviluppò Scribe [Reid 1980]. Scribe precorse il concetto di documenti strutturati ed introdusse una distinzione tra marcatura logica e modelli presentazionali nel processo di progettazione. La filosofia di Scribe fu portata avanti da LaTeX di Leslie Lamport, rilasciata nel 1985 [Lamport 1986]. LaTeX è un pacchetto macro incluso nel programma TeX di Donald Knuth e serve da formattatore a basso livello [Knuth 1984].

Open Document Architecture (ODA) è un insieme di standard ISO per facilitare lo scambio elettronico di documenti [ODA]. I documenti ODA possono rappresentare sia la rappresentazione logica che presentazionale di un documento.

Lo Standard Generalized Markup Language (SGML) [SGML 1986] e il suo predecessore GML fu sviluppato da Charles Goldfarb e dai suoi colleghi durante gli anni '70 e '80 [Furuta, et al. 1982]. SGML divenne uno standard ISO nel 1986.

Questi sei sistemi (Scribe, LaTeX, ODA, SGML, HTML e XML) sono descritti in questa sezione. Prima di discutere ciascuno di essi, può essere utile elencare le ambizioni e i traguardi percepiti dei sei sistemi. si veda la Tabella 2.

Per una tassonomia più formale dei formati di documento, si veda The Origin of (Document) Species [Khare&Rifkin 1998].

In aggiunta ai traguardi elencati nella Tabella 2, tutti i sistemi hanno ispirato autori e programmatori nel vedere i benefici dei documenti strutturati.

Le discussioni dei vari sistemi di documento strutturato riportate di seguito non seguono uno schema rigido. I sistemi variano molto per quanto riguarda la loro comprensione, il loro uso, e l'informazione attualmente disponibile su ciascuno di essi. L'obiettivo primario delle descrizioni non è quello di effettuare un'analisi comparativa, quanto piuttosto quello di discutere gli aspetti di questi linguaggi che l'autore trova interessanti nel contesto dei fogli di stile.

Scribe

Il sistema Scribe fu sviluppato alla fine degli anni '70 da Brian Reid alla Carnegie-Mellon University [Reid 1980]. Scribe è importante per aver precorso l'approccio strutturato alla progettazione. Incoraggia gli autori a lavorare con oggetti logici predefiniti, e gli autori di solito producono documenti nella loro forma finale senza dover specificare alcuna formattazione.

Il sistema Scribe è cambiato nel corso degli anni. La discussione in questo capitolo si basa su Scribe come descritto nello Scribe Introductory User's Manual del 1980 [Reid&Walker 1979]. La descrizione cerca di dare uno sguardo generale su Scribe, e non tutte le caratteristiche sono discusse.

Un semplice documento

Un documento Scribe può essere notevolmente semplice:

@Make(Text)
@Device(Diablo)
@Heading(Comrades and Strangers)

L'esempio di cui sopra usa tre concetti chiave di Scribe: tipi di documento, comandi, e ambienti di formattazione. La prima riga sceglie un particolare tipo di documento (Text) da un insieme di diversi tipi di documento. La seconda riga è un comando che specifica che il documento deve essere stampato su uno specifico dispositivo. La terza riga specifica che una data stringa (Comrades and Strangers) è l'intestazione del documento.

Tipi di documento

Un installazione di Scribe avviene con un database di tipi di documento. La documentazione di Scribe elenca 11 diversi tipi di documento: Text (predefinito), Article, Report, Manual, Thesis, Brochure, Guide, Letter, Letterhead, ReferenceCard, e Slides. Un documento Scribe di solito inizia selezionando il tipo di documento da usare:

@Make(Thesis)

Ci si aspetta che l'amministratore di sistema modifichi il database per adattarlo a esigenze locali. Per esempio, i requisiti di formattazione di una dissertazione variano da un'università all'altra, e le differenze possono essere tenute in conto nel tipo di documento Thesis. In teoria, gli autori possono scrivere le loro dissertazioni senza pensare ai requisiti di formattazione e concentrarsi piuttosto sul contenuto.

I tipi di documento influenzano sia il modello di contenuto che la presentazione di un documento. Per esempio, il tipo di documento Thesis consente che siano usati TitlePage e altri ambienti:

@Make(Thesis)
@Device(Diablo)
@Begin(TitlePage)
  @TitleBox(Comrades and Strangers)
  @CopyrightNotice(Michael Harrold)
@End(TitlePage)

Per gli autori è possibile modificare sia il modello di contenuto che la presentazione dei loro documenti, ma ciò è scomodo. Scribe incoraggia ad usare una modalità dove l'amministratore locale mantiene il controllo – e la responsabilità – per e su i vari tipi di documento usati nell'organizzazione.

Comandi Scribe

In aggiunta al contenuto stesso, un file sorgente Scribe contiene comandi Scribe. Essi corrispondono a quello che conosciamo come marcatura nella terminologia SGML/HTML/XML. Ci sono circa 35 comandi. Possono essere divisi in cinque gruppi principali:

• Comandi di classificazione: @Begin e @End sono usati per marcare l'inizio e la fine degli ambienti, e @Make è usato per dichiarare un tipo di documento.
• Comandi di variabile: Per gestire contatori (@Set, @Tag), riferimenti incrociati (@Ref), e variabili di tipo stringa(@String, @Value) che possono ampliarsi, per esempio, nella data e nel nome utente.
• Comandi visivi: Per marcare interruzioni di pagina (@NewPage), aggiungere spaziatura verticale (@BlankSpace), gestire interruzioni di tabulazione (@Tabset, @TabDivide, @TabClear) o cambiare stile (@Style) o font (@SpecialFont).
• Comandi per il contenuto fuori dal flusso: Per etichettare un determinato contenuto fuori dal flusso, per esempio note a piè di pagina (@Foot), intestazioni correnti (@PageHeading) e piè di pagina (@PageFooting).
• Comandi di sistema: Per importare altri file (@Import), specificare il dispositivo di output (@Device), e mandare in output un messaggio alla console (@Message).

La classificazione in gruppi è fatta dall'autore.

La documentazione Scribe descrive i comandi come non-procedurali. Tuttavia, alcuni comandi possono essere considerati come procedurali, soprattutto @BlankSpace e @NewPage. In un approccio strutturato, le interruzioni di pagina sono unite a elementi strutturati (per esempio un'intestazione) piuttosto che all'uso di un comando separato. Scribe supporta anche l'approccio strutturato attraverso l'Attributo di ambiente Pagebreak.

Similmente, i comandi @Style e @SpecialFont, che sono usati per impostare preferenze stilistiche e dei font, possono essere messi in dubbio poichè non sono uniti a elementi strutturati.

Un altro comando facilmente contestato è @Device, usato per specificare il dispositivo di stampa per l'output. Gli autori web non sapranno mai in anticipo quale dispositivo di stampa ha l'utente (se ne ha uno). Tuttavia Scribe era usato soprattutto con la carta come forma finale, e includere comandi come @Device è una scelta pragmatica.

Ambienti di formattazione

I comandi usati più di frequente in Scribe sono @Begin e @End che, rispettivamente, marcano l'inizio e la fine degli ambienti di formattazione. Un ambiente di formattazione corrisponde all'incirca ad un elemento nella terminologia SGML/HTML/XML, e i comandi @Begin e @End corrispondono ai tag. Gli ambienti di formattazione sono anche detti ambienti di formattazione nominati o semplicemente ambienti. Ecco un semplice frammento tratto dalla documentazione di Scribe. La citazione è tratta da Oscar Wilde: The Soul of man under Socialism, 1895:

@Begin(Quotation) 
On mechanical slavery, on the slavery of the machine, 
the future of the world depends.
@End(Quotation)

Al testo all'interno dell'ambiente Quotation viene dato uno spazio extra su tutti i lati. Il testo può anche essere posto negli ambienti con una sintassi abbreviata:

@Quotation(On mechanical slavery, on the slavery of the machine, 
the future of the world depends.)

Gli ambienti possono essere annidati l'uno dentro l'altro:

@Quotation(On mechanical slavery, on the slavery of the @i[machine], 
the future of the world depends.)

L'esempio di cui sopra mostra come differenti coppie di caratteri possono essere usate nei delimitatori. I delimitatori esterni usano i caratteri (), mentre quelli interni [].

Tutti i sistemi Scribe offrono un'insieme comune di ambienti ad uso degli autori. Si veda la Tabella 3.

Tenendo a mente l'importanza avuta da Scribe nella promozione della marcatura logica, è da notare come circa la metà degli ambienti abbiano regole presentazionali piuttosto che logiche.

Non tutta la struttura in un documento Scribe deve essere marcata esplicitamente. Scribe è in grado di identificare i paragrafi dallo spazio bianco nel documento sorgente. Si consideri questo esempio:

@begin(enumerate)
The first item of three.

The second item. 

The last item.
@end(enumerate)

L'elenco numerato risultante consiste di tre voci. L'ambiente Multiple può essere usato per sovrascrivere l'individuazione automatica della struttura:

@begin(enumerate)
The first item of three.

@begin(multiple)
The second item. 

The second item has two paragraphs.
@end(multiple)

The last item.
@end(enumerate)

Un beneficio dell'individuazione automatica della struttura è che la marcatura nei documenti sorgente può essere minimizzata.

Cambiare e aggiungere ambienti

Come detto in precedenza, il database di tipi di documento e di ambienti di formattazione di Scribe è gestito dall'amministratore di sistema. Tuttavia, un autore può anche cambiare o aggiungere ambienti per adattarli ai suoi bisogni. Ecco un semplice esempio:

@Modify(Description, Leftmargin 0.5in, Indent -0.5in)

In questo esempio, il margine sinistro e l'indentazione dell'ambiente Description vengono cambiati. Il comando @Modify deve comparire all'inizio del documento. Possono essere definiti anche nuovi ambienti:

@Define(InsetHead=Subheading, Leftmargin 0.5in)

In questo esempio, viene creato l'ambiente InsetHead. Esso copia tutte le proprietà da Subheading tranne che per il margine sinistro. Gli ambienti possono anche essere creati da zero. La documentazione lo sconsiglia, ma specifica la forma generale: :

@Define(Newname, <list of attribute-value paris>)

Ancora: la documentazione elenca un insieme di circa 40 proprietà che definiscono la presentazione degli ambienti.

In effetti, la definizione di ambienti in Scribe comprende sia i fogli di stile che la Document Type Definition (DTD) di SGML.

Scribe nel contesto

Scribe precorse la distinzione tra struttura e stile e consentì agli autori di scrivere documenti senza pensare alla loro formattazione. Il database di tipi di documento ed ambienti di formattazione è gestito dall'amministratore di sistema, ma gli autori che vogliono modificare gli ambienti o aggiungerne di propri sono liberi di farlo. Come tale, Scribe offre il meglio dell'HTML (c'è un insieme predefinito di tag e di convezioni sulla loro presentazione), dei CSS (c'è un insieme predefinito di convenzioni presentazionali che possono essere modificate), e dell'XML (possono essere creati nuovi elementi). Scribe può così essere stato un'ispirazione migliore per l'HTML che per SGML. Bisogna anche notare che Scribe fornì questa funzionalità più di 15 anni prima di divenire disponibile agli autori sul Web.

Scribe non è più disponibile per l'uso da parte degli autori, ma il suo impatto storico sullo sviluppo dei documenti strutturati è significativo. Non ci sono riferimenti a Scribe nello sguardo d'insieme del W3C sui sistemi che hanno influenzato lo sviluppo dell'HTML [W3C 2003], ma gli sviluppatori di SGML si riferiscono a Scribe [Goldfarb 1991] il che è un'influenza indiretta. Il più grande traguardo di Scribe può essere stato la sua influenza su LaTeX. Leslie Lamport, creatore di LaTeX, cita Scribe nella prima edizione Lamport rimosse il riferimento a Scribe nella seconda edizione del suo libro per ragioni legali. Scrive del suo libro: Ho rimosso ogni riferimento a Scribe nella seconda edizione del libro su LaTeX perchè fui informato che la persona che comprava Scribe da Brian Reid avrebbe gradito trovare qualcuno da citare in tribunale per aver infranto il brevetto o il diritto di autore di Scribe. Mi dispiaceva di non poter ringraziare Brian, ma non volevo sfidare le sorti legali. [Lamport 1986]. [Lamport 2003]

Fondamentale per LaTeX è l'idea dello stile del documento che determina come il documento debba essere formattato – un'idea rubata dal sistema di formattazione testuale Scribe di Brian Reid.

LaTeX è discusso nella prossima sezione.

LaTeX

Il sistema di composizione automatica TeX fu sviluppato da Donald Knuth per la creazione di bellissimi libri [Knuth 1984]. Il suo lavoro inziò alla fine degli anni '70 e TeX divenne il formato preferito per la pubblicazione scientifica negli anni '80. Sviluppato da un matematico, TeX ha speciali caratteristiche per la formattazione della matematica ma il suo modello di formattazione si adatta a molti tipi di documenti. TeX è stato usato principalmente in ambienti dove la carta è la destinazione finale. I comandi in TeX di solito descrivono relazioni spaziali tra gli elementi e sono così presentazionali. Ecco un semplice frammento TeX:

{\narrower\smallskip\noindent
This paragraph will have narrower lines than surrounding paragraphs.
\smallskip}

Molti dei comandi in TeX sono macro che vengono ampliate in comandi base dall'interprete TeX. TeX permette agli utenti di creare le loro macro, e sono stati pubblicati diversi pacchetti macro per TeX. LaTeX è uno di questi pacchetti macro che permette agli autori di creare formati di documento strutturato.

L'autore di LaTeX, Leslie Lamport, era un utente Scribe che voleva rendere LaTeX una sorta di Scribe per TeX [Lamport 2003]. Molte delle caratteristiche in LaTeX furono copiate da Scribe ma, durante lo sviluppo, alcune caratteristiche di Scribe furono eliminate e vennero introdotte nuove funzionalità. Ecco un semplice frammento LaTeX:

\documentclass{book}
  \title{Comrades and Strangers}
  \author{Michael Harrold}
\begin{document}
  \maketitle
  \chapter{Red Carpet in Paradise}
\end{document}

La prima riga nell'esempio dichiara che il documento diventerà un libro. Altre classi di documento includono: report, lettera, articolo e slide. La scelta della classe del documento influenzerà la presentazione finale del documento, così come il tipo di elementi disponibili (o ambienti come LaTeX e Scribe li chiamano). Per esempio, l'elemento chapter, usato più avanti, è disponibile in un libro ma non in un articolo. Le successive due righe dichiarano il titolo e l'autore della pubblicazione. La prima parte del codice – fino all'inizio del documento – è chiamata preambolo ed è simile all'elemento HEAD nell'HTML.

Il corpo del documento è contenuto nell'ambiente document. Il comando \maketitle è un modo comune per iniziare i documenti; a seconda della classe del documento e della meta-informazione dichiarata nel preambolo, verrà generato un titolo consono. L'ultimo elemento nell'esempio è un'intestazione di capitolo.

Ci sono molte similarità tra Scribe e Latex:

• Come in Scribe, le funzionalità di LaTeX possono essere suddivise in tre gruppi: classi di documento (chiamati tipi di documento in Scribe), comandi e ambienti (chiamati anche ambienti di formattazione in Scribe).
• Molti dei nomi di ambiente sono gli stessi: enumerate, itemize, quotation, description, verbatim, center, flushleft e flushright.
• Entrambi i linguaggi sono legati ad uno specifico formattatore e non si sono candidati per la standardizzazione.
• Sia Scribe che LaTeX forniscono un insieme di base di classi di documento e ambienti che possono essere estesi dagli amministratori locali di sistema o dagli autori.
• Le ambizioni dei due sistemi sono quasi le stesse: dovrebbe essere possibile progettare documenti strutturati senza dover descrivere la loro presentazione, mentre si ha ancora la stampa su carta come obiettivo finale.

Ci sono anche notevoli differenze tra i due sistemi:

• La sintassi è differente; LaTeX usa differenti delimitatori rispetto a Scribe.
• LaTex dà accessso ai comandi TeX. Questo rende possibile controllare la formattazione di un documento a un livello molto basso, ma rende anche difficile – se non impossibile – convertire documenti LaTex in altri formati.

LaTeX è stato un sistema di progettazione di grande successo ed ha avuto molto seguito principalmente negli ambienti accademici. Per il suo successo, LaTeX ha probabilmente fatto molto più per i documenti strutturati di ogni altro linguaggio, eccetto l'HTML.

Standard Generalized Markup Language (SGML)

Come è stato detto nella precedente sezione, lo Standard Generalized Markup Language (SGML) non è un formato di documento. SGML è invece un sistema usato per creare nuovi formati di documento. In altre parole, SGML non è – a dispetto del suo nome – un linguaggio di marcatura in sè, ma è usato per definire altri linguaggi di marcatura.

La prima bozza di lavoro di SGML fu pubblicata nel 1980 [SGMLUG 1990] e SGML divenne uno standard ISO nel 1986 [SGML 1986].

SGML è basato su GML (Generalized Markup Language) che fu sviluppato da IBM dall'inizio fino alla metà degli anni '70 [Furuta, et al. 1982]. In [SGMLUG 1990] vengono descritte le persone e le motivazioni dietro GML:

Insieme con Edward Mosher e Raymond Lorie [Charles Goldfarb] inventò lo Generalized Markup Language (GML) come un mezzo per permettere l'editazione del testo, la formattazione, e sistemi di distribuzione dell'informazione per condividere i documenti

GML divenne disponibile per l'uso generale nel 1978 [Furuta, et al. 1982]. Un documento GML appare leggermente differente da un documento SGML poichè esso non usa le ora familiari parentesi angolari per definire i tag. Ecco un semplice frammento da [Furuta, et al. 1982]:

:body.
:h2.The Formatting Problem
:p.In order to discuss formatters and their functions...

Uno dei creatori di GML, Charles Goldfarb, continuò il lavoro che portò a SGML [SGMLUG 1990]:

Dopo il completamento di GML, Goldfarb continuò la sua ricerca sulle strutture del documento, creando concetti aggiuntivi, come brevi riferimenti, processi di collegamento e tipi di documento correnti, che non erano parte di GML ma che in seguito furono sviluppati come parte di SGML.

È da notare come nessuna delle caratteristiche di SGML citate sopra siano state usate. Uno di essi, la caratteristica LINK (descritta di seguito), fu motivata dal bisogno di competere con ODA offrendo un modo per unire informazioni presentazionali ai documenti.

SGML è uno standard complesso e va oltre l'àmbito di questa tesi dare uno sguardo d'insieme di tutte le sue caratteristiche. Di seguito è riportata la descrizione di tre caratteristiche che sono interessanti nel contesto dei fogli di stile; tutte e tre le caratteristiche possono portare potenzialmente informazioni di stile.

Document Type Definition (DTD)

Una Document Type Definition (DTD) è un insieme di regole che definiscono la sintassi di un linguaggio di marcatura. Le DTD sono di centrale importanza per SGML e tutti i linguaggi di marcatura basati su SGML hanno una DTD che descrive gli elementi, gli attributi, le entità – e la relazione tra di essi. Ecco un semplice frammento dalla DTD dell'HTML4:

<!ELEMENT UL - - (LI)+>

Nell'esempio, si dichiara che l'elemento UL richiede un tag di apertura e di chiusura (rispettivamente, i due trattini), e il modello di contenuto è impostato su (LI)+. Il modello di contenuto descrive che tipo di contenuto è consentito all'interno dell'elemento dichiarato. Nell'esempio, il segno più indica che gli elementi UL possono contenere uno o più elementi LI. Il frammento che segue aggiunge più informazioni sull'elemento LI:

<!ENTITY % inline "A | #PCDATA">
<!ELEMENT LI - O (%inline)*>

La prima riga dell'esempio dichiara un'entità riferita alla seconda riga: l'elemento LI deve avere un tag iniziale, ma il tag finale è facoltativo. L'elemento LI contiene contenuto in riga, che – secondo la prima riga – sono elementi A o #PCDATA. #PCDATA sta per contenuto testuale. In HTML4, il modello di contenuto per LI è leggermente più complesso.

La DTD è anche usata per dichiarare attributi sugli elementi.

La DTD dell'HTML4 usa nomi di entità come heading, inline e block per raggruppare vari elementi. Questi nomi, tuttavia, non hanno un significato vero e proprio; dal punto di vista di SGML essi sono stringhe casuali. Tuttavia, nelle menti dei creatori della DTD, i nomi hanno un significato che reca in sè sia regole logiche che informazioni presentazionali.

Sebbene per concezione originaria le DTD recano informazioni solo ad un livello sintattico, si possono facilmente aggiungere informazioni presentazionali. Per esempio, questa sintassi estesa descriverebbe il modello di contenuto, insieme con le informazioni sui font preferiti:

<!ELEMENT UL - - (LI)+ 11pt sans-serif>

Il sistema Scribe, discusso in precedenza, usa questo approccio quando definisce nuovi ambienti. Ancora: la proposta di fogli di stile SSP, discussa nel capitolo 4, combina informazioni sintattiche e presentazionali.

Istruzioni di elaborazione

Una Istruzione di elaborazione (PI, Processing Instruction) è un costrutto sintattico di SGML che può essere usato per mantenere le informazioni su come il documento dovrebbe essere elaborato, inclusa la sua formattazione. In un messaggio a www-talk [Connolly 1994b], Dan Connolly propose di usare le istruzioni di elaborazione per descrivere la formattazione dei documenti HTML:

Suggerisco di introdurre un intero insieme di istruzioni di elaborazione, cosicchè le persone possono marcare la formattazione dei loro documenti senza influenzarne la struttura. Per esempio, invece dell'elemento <BR>, suggerirei un'istruzione di elaborazione <? linebreak>, e un'entità &br; come forma abbreviata.

SGML impone poche restrizioni sul contenuto delle istruzioni di elaborazione, e sono possibili un'ampia gamma di istruzioni di elaborazione:

<? the next element should be green  >
<? background=white >
<? p { color: black } >

Una raccomandazione W3C descrive come si possono usare le istruzioni di elaborazione per collegarsi ai fogli di stile dai documenti XML. Si veda la sezione su XML più avanti.

LINK

Le specifiche SGML definiscono due tipi di caratteristiche LINK: LINK impliciti e LINK espliciti. I secondi sono poco compresi, e la discussione in questa sezione riguarda solo i LINK espliciti.

Come le istruzioni di elaborazione, la caratteristica LINK fu aggiunta per coadiuvare l'elaborazione dei documenti SGML. Proprio come le istruzioni di elaborazione, uno degli usi della caratteristica LINK è quello di aggiungere informazioni di formattazione ai documenti SGML. Vi sono, tuttavia, diverse differenze tra i due:

• I LINK sono posizionati in dichiarazioni link separate ed esterne, invece di essere inseriti nel documento.
• I LINK definiscono l'elaborazione di un determinato elemento, invece di essere solo un segnaposto per qualsiasi informazione di elaborazione.

Lo scopo principale del meccansimo LINK è di aggiungere attributi agli elementi. Ecco un semplice estratto da una dichiarazione LINK:

<!LINK #INITIAL  table [ ALIGN="right" ]>

La dichiarazione LINK di cui sopra aggiungerà l'attributo ALIGN="right" a tutti gli elementi table.

Un esempio leggermente più avanzato mostra come i LINK possono essere usati per aggiungere attributi in modo contestuale:

<!LINK #INITIAL  ul  #USELINK uldef
                    ol  #USELINK oldef>
<!LINK uldef     li  [ mark="bullet" ]>
<!LINK oldef     li  [ mark="digit" ]>

Si consideri questo semplice documento:

<UL>
  <LI>number unknown
    <OL>
      <LI>number one
      <LI>number two
    </OL>
</UL>

Quando la dichiarazione LINK di cui sopra viene applicata al precedente documento, produce il seguente documento:

<UL>
  <LI mark="bullet">number unknown
    <OL>
      <LI mark="digit">number one
      <LI mark="digit">number two
    </OL>
</UL>

Come si può vedere dall'esempio precedente, la caratteristica LINK possiede qualcuna delle proprietà di un linguaggio di stile (ossia sintassi e selettori, come descritto nel capitolo 3). Ancora: la caratteristica LINK è un meccanismo generico che può essere usato per distribuire ogni sorta di informazione fintanto che l'informazione può essere rappresentata in attributi. Tuttavia, la caratteristica LINK manca della nozione di formattazione. Per esempio non vengono proposti proprietà, valori o un modello di formattazione. Perciò, la caratteristica LINK non può essere considerata come un linguaggio di stile.

SGML nel contesto

SGML è uno degli standard che ha più influenzato il Web, e sia l'XML che l'HTML devono molto del loro sviluppo a SGML. SGML portò con successo importanti problematiche, quali la progettazione dei documenti, la conservazione e lo scambio dei formati, all'attenzione delle comunità della tecnologia dell'informazione. In particolar modo, SGML mise in evidenza:

• la marcatura logica, piuttosto che la marcatura procedurale;
• che la conservazione dell'informazione e lo scambio dei formati devono essere separati dal software e dall'hardware, per far si che i dati sopravvivano ai sistemi di computer.

Tuttavia, al di fuori di una ristretta comunità, SGML non ebbe mai il successo che i suoi sostenitori speravano. L'autore crede che vi siano diverse ragioni per questo:

• Lo standard SGML divenne troppo complesso. Il SGML handbook, che è una versione commetata dello standard SGML, ha 664 pagine numerate [Goldfarb 1991]. Sebbene esso includa tutorial e altri testi non essenziali, può essere indicativo della complessità di SGML. Solo un ristretto gruppo di esperti sono in grado di capire nella loro interezza le specifiche SGML. Oltre a non essere compreso, molte delle sue caratteristiche avanzate non furono supportate dalle implementazioni.
• SGML risolse solo in parte i problemi per cui i suoi utenti cercavano delle soluzioni. Esso può definire con successo i linguaggi di marcatura, ma poche persone lo fanno realmente. Piuttosto, gli autori hanno bisogno di un vocabolario di elementi e modi per includere la grafica. SGML non cercò di risolvere questi problemi.
• Mancanza di un linguaggio di stile. Quando SGML divenne uno standard ISO nel 1986, non erano disponibili linguaggi di stile standard per formattare i documenti SGML. La Formatting Output Specification Instance (FOSI; si veda il capitolo seguente) divenne presto disponibile na fu considerata una soluzione temporanea in attesa del Document Style Semantics and Specification Language (DSSSL). Ci vollero circa 10 anni prima che DSSSL fu completato nel 1996. Una soluzione semplice basata su una DTD estesa o una sintassi PI, come discusso in precedenza, possono anche aver reso i documenti SGML più facili alla presentazione.

Può essere prematuro dare un giudizio su SGML, ma l'autore crede che il successo maggiore di SGML è stato quello di aver inspirato HTML e XML.

HyperText Markup Language (HTML)

Le specifiche HTML sono, insieme con le specifiche HTTP e URL, uno dei mattoni fondamentali del Web. L'HTML ha avuto un impatto a lungo raggio sul modo in cui il contenuto elettronico viene progettato, conservato, trasmesso e elaborato. La progettazione dell'HTML è probabilmente uno dei motivi principali del successo del Web.

Questa sezione discute la progettazione e lo sviluppo dell'HTML in riferimento ai fogli di stile.

L'originale progettazione dell'HTML

L'origine dell'HTML è descritta nel documento W3C Some early ideas for HTML [W3C 2003]:

[Nel 1989] molte persone usavano TeX e PostScript per i loro documenti. Pochi usavano SGML. Tim capì che c'era bisogno di qualcosa di più semplice per tenere testa sia ai semplici terminali che alle workstation X Windows ad alta risoluzione grafica. L'HTML fu concepito come una soluzione molto semplice, da coniugarsi con un protocollo di rete molto semplice come l'HTTP.

Infatti, la progettazione originale dell'HTML era semplice. La prima descrizione dell'HTML disponibile pubblicamente fu un documento chiamato HTML Tags [Berners-Lee 1991a], annunciato e commentato in uno dei primi messaggi [Berners-Lee 1991b] sulla mailing list www-talk nell'ottobre 1991. Mi riferisco a questo documento come a HTML-0. Descrive 22 elementi che costituiscono la progettazione iniziale dell'HTML. In ordine di apparizione gli elementi sono: TITLE, NEXTID, A, ISINDEX, PLAINTEXT, XMP (descritto indirettamente), LISTING, P, H1, H2, H3, H4, H5, H6, ADDRESS, HP1, HP2, DL, DT, UL, MENU e DIR. 13 di questi elementi esistono ancora nell'HTML4 [HTML4 1997], 3 sono stati deprecati (ISINDEX, MENU, DIR), e 6 sono stati rimosssi (NEXTID, PLAINTEXT, XMP, LISTING, HP1, HP2).

È da notare che HTML-0 non includeva alcun elemento presentazionale. Ossia, HTML-0 consisteva solo di elementi logici. Questa fondamentale scelta di progettazione è confermata in una comparazione tra la caratteristica rich text di MIME [Borenstein 1994] e l'HTML [Berners-Lee 1992a]:

Comparando il rich text di MIME e l'HTML, vedo che mancano gli attributi BOLD e ITALIC di formattazione dei caratteri, ma d'altro canto mi accorgo che il nostro modo di trattare i livelli logici di intestazione e le altre strutture è molto più potente e ha dimostrato di fornire una formattazione più flessibile su piattaforme differenti che si riferiscono esplicitamente in modo parziale alle dimensioni dei font. Ciò deriva da tutti quei sistemi che usano di preferenza stili nominati per la formattazione esplicita, LaTeX o altre macro invece di TeX, ecc, ecc.

I fogli di stile vengono citati una volta in HTML-0 nella descrizione dell'elemento P:

Questo tag indica un nuovo paragrafo. La sua esatta rappresentazione (indentazione, interlinea, ecc.) non è qui definita, e può essere una funzione di altri tag, fogli di stile ecc.

Così, il concetto di fogli di stile era conosciuto allo sviluppatore HTML. La libreria di programma libwww [Nielsen&Lie 1994] che era una implementazione di HTTP e HTML liberamente disponibile al CERN, supportava i fogli di stile lato-client. Ossia, i fogli di stile erano inseriti nel client per supportare la presentazione dei documenti HTML e non erano considerati come risorse da mettere sul Web. Come tali, i fogli di stile giocarono un ruolo minore nell'iniziale progettazione del Web.

Questo punto di vista è supportato dal fatto che non vi erano discussioni sui fogli di stile nella mailing list www-talk fin dal suo inizio nell'ottobre 1991 finchè Robert Raisch non fece la sua proposta ( RRP, discussa nel prossimo capitolo) nel giugno 1993 [Raisch 1993a].

Struttura contro stile

Sebbene i fogli di stile in sè non fossero discussi su www-talk, il termine stili venne usato poche volte nel contesto dello sviluppo HTML. In un messaggio a www-talk, Berners-Lee sostenne che una struttura annidata sarebbe stata preferibile alla struttura relativamente superficiale che HTML-0 offriva [Berners-Lee 1991b]:

Nello scrivere un nuovo parser generico, mi chiedevo se l'oggetto testuale conserverà la struttura annidata di un documento. Attualmente, il documento è una sequenza lineare di stili: non si possono avere elenchi all'interno di elenchi, ecc. Idealmente, dovrebbe essere in grado di gestirlo - sebbene sia più difficile per uno scrittore umano gestirlo mentre formatta il documento. Preferirei infatti, invece di <H1>, <H2> ecc. per le intestazioni [esse provengono dalla AAP DTD], avere un elemento annidabile <SECTION>..</SECTION>, e un generico <H>..</H> che a qualsiasi livello all'interno delle sezioni produrrebbe il livello richiesto di intestazione.

Questo problema è riproposto in un altro messaggio otto mesi dopo [Berners-Lee 1992b]:

Così se cerchiamo di ottenere un HTML annidabile, che sarebbe più chiaro per quelli che apprezzano la ricorsività, dovremmo avere un editor ipertestuale che renda visibile la struttura. Non ho abbastanza esperienza per sapere se coloro che forniscono l'informazione reale (ad esempio segretari) avrebbero familiarità nel generare elementi annidati – forse gli stili sono utili per conservare l'attuale 'metafora dell'intefaccia utente' degli elaboratori testuali.

Queste affermazioni sostengono che gli elementi in HTML non dovrebbero in generale essere annidati, anche se le strutture annidabili sono più chiare. Uno degli argomenti contro gli elementi annidabili è che essi non si combinano con una sequenza lineare di stili. Berners-Lee fa queste affermazioni dopo aver implementato un parser e formattatore HTML della libreria libwww [Nielsen&Lie 1994]. Il conflitto avvertito tra elementi annidabili e stile è probabilmente dovuto ai limiti nell'implementazione. I CSS in seguito affrontarono questo problema introducendo i selettori contestuali.

HTML e SGML

Come i fogli di stile, SGML era conosciuto agli sviluppatori di HTML ma ricopriva un ruolo minore, nel senso che HTML-0 non era formalmente specificato nei termini di SGML. In un certo senso, HTML-0 era incompatibile con SGML [Berners-Lee 1991b]:

<PLAINTEXT> è usato per indicare che il resto del file è di fatto solo ASCII. Annulla completamente il parsing SGML. Per ora è una soluzione di ripiego, finchè non avremo la negoziazione del formato di documento.

Berners-Lee non incoraggiava gli sviluppatori di browser a usare rigidi metodi formali nell'elaborazione di documenti HTML [Berners-Lee 1993c]:

Appoggio completamente Marc nella sua decisione di far lavorare al meglio