Parte 6. I linguaggi di codifica

6.1 I linguaggi: dichiarativi e procedurali

L’esigenza di produzione di testi in formato elettronico ha condotto all’elaborazione di molteplici sistemi orientati alla creazione e manipolazione di testi, che vanno dai word-processor ai più sofisticati sistemi di desktop publishing (che consentono di controllare tutto il processo di produzione, composizione e formattazione dei testi a fini editoriali).

Diremo che i sistemi di text processing si possono dividere in due classi: i sistemi di tipo WYSIWYG (What You See Is What You Get) e i sistemi basati su markup language.

I primi sono programmi che sfruttano le sempre maggiori potenzialità grafiche offerte dagli elaboratori per tentare di rappresentare sul video esattamente ciò che apparirà poi sulla carta stampata. Il problema sostanziale di questi sistemi è che pur agevolando notevolmente il lavoro dell’utente, proponendosi come mezzo rapido ed amichevole anche all’operatore meno esperto (consentendogli di interagire con la macchina tramite l’interfaccia grafica, e cioè manipolando direttamente la rappresentazione visibile sullo schermo), legano l’elaborazione del testo ad un determinato programma, rendendo quindi alquanto problematica la portabilità tra ambienti software diversi. Impiegando cioè, al fine della rappresentazione del testo, dei caratteri di controllo invisibili, immessi dentro il file di testo, rendono il file leggibile esclusivamente dal sistema che l’ha generato. E’ la macchina che inserisce direttamente il markup, la codifica, non l’utente, che non necessita quindi di conoscere i comandi a memoria. I sistemi di questo tipo non si rivelano dunque come i più adatti alla codifica scientifica di un testo.

Esistono anche programmi che non si interessano dell’aspetto che il documento assume sul video, per concentrarsi invece sul risultato finale. I file destinati a questo tipo di programmi sono composti dal testo che si vuole realizzare e da una serie di istruzioni che indicano al device di output (normalmente la stampante) quello che deve fare. Se, da un lato, questi programmi rendono complessa l’operazione di elaborazione del testo, dall’altro, utilizzando file scritti con un normale editor (e quindi in plain ASCII o formato “solo testo”), rendono più agevole la trasportabilità dei prodotti.

Questi markup language, detti in italiano linguaggi di marcatura o di codifica del testo, si basano su un insieme di istruzioni facente parte, appunto, di un vero e proprio linguaggio orientato alla descrizione dei fenomeni di strutturazione, composizione, impaginazione del testo stesso. I comandi si configurano come sequenze di caratteri ASCII visibili, e vengono immessi dentro il file del testo, secondo una determinata sintassi, immediatamente accanto alla sequenza di caratteri a cui si riferiscono e cioè “marcando” direttamente i blocchi di testo cui intendono assegnare una determinata funzione.

Il termine markup, impiegato nell’ambito della codifica del testo in formato elettronico, deriva dalla designazione, nella stampa tipografica tradizionale, di quell’insieme di simboli, indicazioni, annotazioni aggiunte dall’autore o dall’editore su di un manoscritto o su di un dattiloscritto per istruire il tipografo o il compositore relativamente a come trattare, dal punto di vista grafico, il testo: impaginazione, scelta dei caratteri da impiegare, spaziature, a capo ecc....

E’ possibile distinguere due diverse classi di linguaggi di markup, che differiscono per il tipo di comandi impiegati all’atto dell’operazione di codifica ovvero per la semantica delle istruzioni utilizzate: markup specifico e markup generico.

Il primo tipo consiste di un insieme di istruzioni operative che indicano localmente la struttura tipografica e compositiva della pagina, le spaziature, l’interlineatura, le caratteristiche dei font, modificando questi parametri direttamente per le porzioni di testo cui si riferiscono. Questo tipo di marcatura è anche detta procedurale in quanto indica alla macchina le procedure di trattamento cui deve sottoporre la sequenza di caratteri al momento della stampa.

Si tratta dei primi linguaggi di marcatura, ideati con l’obiettivo di occuparsi essenzialmente dell’aspetto tipografico del testo. Non accettando ancora l’ottica del WYSIWYG, era necessario individuare una serie di istruzioni locali che consentissero alla periferica di generare il documento nella forma tipografico-compositiva desiderata. Sono questi i linguaggi orientati sul documento più che sul testo, da intendersi secondo le caratteristiche in precedenza descritte.

Sostanziali si rivelano quindi i limiti di un markup di tipo procedurale. In un documento testuale la composizione del manufatto rappresenta la realizzazione della struttura astratta (logica) del testo, la quale costituisce un bagaglio informativo essenziale ai fini di una corretta comprensione del testo stesso. Indispensabili le divisioni di un testo in sezioni o capitoli, che coordinano l’intreccio testuale ed indicano al lettore il ritmo narratologico. In una codifica procedurale queste informazioni vengono inevitabilmente perdute in quanto non rappresentate e si rivela dunque necessario, per accedere ad esse, conoscerne esattamente la composizione tipografica. In più si presentano limiti anche di carattere pratico: un linguaggio di codifica procedurale comporta uno stretto legame con il software di trattamento del testo che è in grado di interpretarlo, limitando dunque la portabilità del testo codificato tra ambienti diversi. Inoltre le istruzioni di formattazione di un testo di questo tipo vengono fissate una volta per tutte: se si intende alterare l’aspetto stampato di un testo è necessario modificare tutte le istruzioni di codifica.

Proprio a causa di questa serie di limitazioni si è rivelata indispensabile l’elaborazione di un nuovo tipo di linguaggio che consentisse essenzialmente la rappresentazione della struttura astratta del testo. Sono stati così creati i cosiddetti linguaggi di markup generico dove i simboli di codifica non vengono più impiegati come istruzioni di formattazione, di impaginazione, ma come indicatori di struttura.

I linguaggi basati su un generic markup sono costituiti da un insieme di marcatori (tag) che, immessi nel testo, indicano non le caratteristiche fisiche, ma la funzione assolta dal blocco di testo cui si riferiscono. A ciascun blocco viene associato un marcatore che lo definisce come titolo, paragrafo, nota, citazione ecc., senza preoccuparsi di come tali elementi del testo appariranno fisicamente.

Poiché consentono di dichiarare a quale tipo di struttura appartiene una qualsivoglia porzione della fonte, questi linguaggi vengono anche definiti linguaggi dichiarativi.

Diremo quindi che mentre un linguaggio basato su di uno specific markup (o linguaggio procedurale) si concentra essenzialmente sul documento, un linguaggio basato su di un generic markup (o linguaggio dichiarativo) si concentra sul testo. 

Marcando elementi appartenenti alla struttura astratta del testo, un generic markup language risulta dunque assolutamente indipendente dai diversi device; questo però non esclude la possibilità che venga usato anche per ottenere un determinato output del documento. E’ cioè possibile marcare dichiarativamente anche aspetti grafici della pagina (salti-pagina, spazi bianchi, rientri ecc.) [1] . Se quindi il linguaggio scelto si configura come piuttosto potente, sarà possibile rappresentare il testo, e cioè i suoi elementi, a vari livelli; si potranno cioè costruire molteplici modelli del testo e, in più, sarà consentito impiegare un testo trattato con un linguaggio di codifica dichiarativa per qualsiasi tipo di trattamento informatico. Non essendo cioè tali linguaggi dedicati a nessuna particolare applicazione, se si è stati in grado di dichiarare tutto ciò di cui si necessita, il testo potrà essere analizzato dal punto di vista morfologico, lessicografico, narratologico.

6.2 SGML – Standard Generalized Markup Language [2]

Tra i linguaggi che impiegano una codifica di tipo dichiarativo, lo Standard Generalized Markup Language (l’SGML) è sicuramente il più noto e quello che ha assunto una peculiare preminenza, divenendo lo standard ISO ufficiale per la creazione di testi in MRF. L’SGML è oltretutto il linguaggio dotato di maggiore influenza nell’ambito del settore umanistico, grazie soprattutto alle DTD (Document Type Definition) prodotte dalla TEI (Text Encoding Inititive).

SGML nasce, essenzialmente, con l’obiettivo di imporsi come schema linguistico standard a livello internazionale nell’ambito della codifica di fonti testuali o documentarie e superare quindi quella moltitudine di sistemi di codifica sviluppatisi negli ultimi vent’anni; obiettivo, questo, primario per consentire quell’interscambio di documenti in formato elettronico tra ambienti hardware e software differenti e garantirne quindi l’assoluta portabilità.

Scendendo nello specifico del funzionamento dell’SGML, diremo che questo linguaggio si basa su di un markup generico orientato alla descrizione della struttura logica di un testo piuttosto che della sua forma grafica [3] . L’SGML si fonda sull’idea che un documento sia dotato di una organizzazione astratta o logica definibile tramite una configurazione strutturale rigidamente gerarchica. La struttura astratta di un qualsiasi documento corrisponde cioè ad un grafo ad albero in cui: a ciascun nodo dell’albero corrisponde un elemento (e cioè ogni partizione logica della fonte); ai rami uscenti da ogni nodo corrispondono le relazioni [4] tra elementi e sotto-elementi ad un dato livello; alle foglie corrispondono gli elementi finali non strutturali (generalmente i caratteri del testo) [5] .  

Fondandosi su di una codifica di tipo dichiarativo, l’SGML consente di definire (o di dichiarare), in modo assolutamente personale ed autonomo, un insieme di marcatori (tags) che adempiano al compito primario dello standard, che consentano cioè di fare il markup della struttura logica di un testo. Questo gruppo di marcatori, più precisamente, individua una classe di documenti testuali che presentano le medesime caratteristiche strutturali [6] .

Tali marcatori si presentano sottoforma di stringhe di caratteri ASCII; il markup viene aggiunto all’inizio e alla fine di ogni partizione logica del testo, e cioè di ogni oggetto informazionale dotato di una propria funzione logica, vale a dire di ogni elemento.

Ogni elemento testuale viene individuato e descritto tramite ricorso ad un nome convenzionale, scelto dal codificatore (p.e. p per paragrafo, n per nota ecc.) e quest’ultimo viene racchiuso tra due delimitatori posti all’inizio dell’elemento e da altri due delimitatori posti alla fine dello stesso; l’elemento viene quindi rappresentato tramite una tag di apertura ed una di chiusura. Per le tag, la sintassi di SGML ci suggerisce una forma grafica simbolica che possiamo decidere di rispettare o meno (parentesi ad angolo, o delimitatori, racchiudenti il nome dell’elemento, cioè l’identificatore dell’elemento, come tag d’apertura: <e>; stesse parentesi ma con l’identificatore preceduto dal simbolo / per la tag di chiusura: </e>).

Più esattamente diremo che SGML è dotato di una sintassi astratta (abstract syntax), che spiega come operare il markup di un documento testuale; esistono cioè regole che istruiscono l’utente su come aggiungere i marcatori ad un documento [7] , senza però considerare le specifiche stringhe di caratteri impiegate a tal fine: l’SGML non costringe cioè all’uso di particolari caratteri in qualità di delimitatori, semplicemente spiega solo i ruoli dei vari delimitatori. E’ la sintassi concreta (concrete syntax) che attribuisce a quei delimitatori eventuali simboli impiegabili a tale scopo. Lo standard fornisce in questo caso un aiuto offrendo un esempio di sintassi concreta, detta sintassi concreta di riferimento (reference concrete syntax); essa lega la sintassi astratta a specifici caratteri [8] . Vengono inoltre suggeriti i criteri per definire la sintassi concreta delle varianti (variant concrete syntax), che consente di modificare a proprio piacimento quei simboli individuati come delimitatori nella sintassi concreta di riferimento [9] . 

Per questo è lecito affermare che l’SGML più che un linguaggio è un metalinguaggio che fornisce esclusivamente le regole necessarie all’edificazione di infiniti linguaggi di codifica di testi. Ciascuno di tali linguaggi si configura come un peculiare modello di testo o, più esattamente, di un insieme di testi, elaborato sulla base delle esigenze del trattamento automatizzato cui si intende sottoporre la fonte e quindi in base a quello specifico punto di vista assunto sull’oggetto di analisi. 

Essendo lo scopo principale di ogni operazione di trasposizione di un testo in MRF il garantire la massima portabilità dell’oggetto creato, si rivela necessaria l’assoluta condivisione del codice, con cui è stata effettuata l’operazione di codifica del testo, da parte di tutti gli utenti. Questa prerogativa viene appunto raggiunta dichiarando esplicitamente tutti gli elementi che sono presenti in quello specifico testo, dai caratteri alfabetici ai marcatori impiegati all’atto della codifica, e le combinazioni tra i suddetti elementi.

Talora però lo stesso codice di base, cioè il character set, non è condiviso fra applicazioni diverse. Ipoteticamente sarebbe possibile progettare una tabella alternativa all’ASCII standard [10] , ma è sicuramente più conveniente limitarsi ad indicare eventuali caratteri (entity) che non fanno parte dell’ASCII, ma che verranno impiegati all’atto della codifica; caratteri che possono essere raffigurati pur non comparendo su di una normale tastiera ASCII. Sarà sufficiente scrivere l’entità di riferimento facendola precedere dall’e commerciale (&) e seguire dal punto e virgola (;) per istruire il programma a riconoscervi un’entità [11] .

Per entità si intende precisamente ogni sequenza arbitraria di bit, da una stringa di caratteri ad un intero file, indipendentemente dall’estensione dell’oggetto cui l’entità fa riferimento. E’ questa la possibilità offerta da SGML di incorporare nel documento codificato ogni tipo di file. La capacità di rappresentare entità attraverso una stringa di caratteri ASCII per descrivere un simbolo può anche essere utilizzata in altro modo, ossia per rappresentare informazioni poste altrove. Questo risulta utile, per esempio, per fare riferimento a parti esistenti del documento, ad una tabella o ad una figura, cioè per incorporare altri file all’interno del documento codificato. La stringa di caratteri impiegata in qualità di entità potrebbe anche essere un’abbreviazione che verrebbe estesa per intero in fase di output. Ci si potrebbe allora limitare alla sola abbreviazione descrivendola come entità (per esempio &SGML;), da sciogliere poi in fase di visualizzazione del testo (con Standard Generalized Markup Language).

L’elenco delle entity utilizzate sarà contenuto in un’apposita tabella, esplicitamente dichiarata. Tale tabella prende il nome di DTD, Document Type Definition. In essa si presenterà, oltre all’elenco delle entità impiegate, la struttura astratta del testo, specificata definendo gli elementi che la costituiscono, eventuali attributi, le relazioni intercorrenti tra gli elementi e si assegnerà ad ogni elemento un singolo marcatore.

Come premesso, lo standard non fornisce alcuna prescrizione relativamente alla tipologia, alla quantità o al nome dei marcatori, ma si occupa esclusivamente di fornire precise regole sintattiche, necessarie a definire un insieme di marcatori all’interno di una DTD: è attraverso tali regole che sarà consentita la definizione di un linguaggio di codifica adeguato per una determinata classe di documenti testuali.  

Più precisamente nella DTD sono elencati e definiti tutti gli oggetti necessari all’elaborazione di un adeguato linguaggio di codifica:

i marcatori per gli elementi presenti nel testo (elements) o presenti in una certa classe di documenti (p.e. testo t, introduzione i, capitolo c, paragrafo p, nota n, ecc.);

la descrizione del contenuto di ogni elemento (content model), quindi quali altri elementi possono apparire all’interno di un altro elemento, con quale ordine e con quale frequenza (un paragrafo potrà contenere parole e le parole potranno contenere lettere....);

i marcatori per gli attributi (attributes) assegnabili ad un qualsivoglia elemento (un titolo potrà essere caratterizzato dalla propria resa grafica [p.e. grassetto corsivo], una nota dalla sua posizione all’interno della pagina);

i simboli per le entità (entity) che possono occorrere all’interno del documento e che possono rappresentare caratteri non esistenti nel code set impiegato alla codifica oppure che si riferiscono a file esterni o ancora che prevedono lo scioglimento di una stringa del docuemento.

E’ chiaro che è possibile sviluppare una propria nuova DTD atta a descrivere quel peculiare tipo di documento che si intende codificare, ma è certamente più economico, e ovviamente meno difficoltoso, fare riferimento ad una DTD già esistente e quindi pubblicamente disponibile. In entrambe i casi comunque imprescindibile è una perfetta conoscenza della sintassi e delle regole che l’SGML prescrive per la descrizione della struttura di un documento testuale.

E’ la DTD quindi uno degli elementi fondanti di SGML, ed è la DTD che raccoglie la maggior parte delle dichiarazioni di markup previste dallo standard. Nulla che non sia stato esplicitamente dichiarato può essere incluso in un documento. E’ dunque da tenere in considerazione che le cosiddette markup declarations sono tredici, ma non tutte rientrano nella DTD; tra di esse, assolutamente essenziale è la dichiarazione SGML.

Per questo è essenziale sottolineare che un documento SGML, e cioè un testo codificato in SGML, non è semplicemente un oggetto costituito da partizioni logiche descritte dai tag introdotti, ma è un oggetto diviso in tre parti distinte: la dichiarazione SGML, la DTD e l’esemplare del documento.

E’ la dichiarazione SGML (SGML declaration) che raccoglie l’informazione relativa al set di caratteri impiegato (nella DTD e, ovviamente nel documento testuale) e alla sintassi concreta. Ogni sistema sul quale gira SGML possiede una dichiarazione SGML, assolutamente indispensabile per conoscere i parametri impiegati all’atto della codifica.

Per ciò che inerisce l’uso del set di caratteri, SGML propone, nella sintassi concreta di riferimento, l’ISO 646 [12] , comune nel mondo anglofono. Questo standard è sufficiente per molteplici impieghi. Tuttavia viene considerato insufficiente nella maggior parte dei paesi che usano lingue differenti dall’inglese, in quanto potrebbero esigere non solo lettere accentate, ma anche alfabeti completamente diversi. Viene quindi fornita l’opportunità di specificare nella dichiarazione SGML un altro set di caratteri che si intende utilizzare. E’ sicuramente significativo optare infatti per l’altro standard ISO, l’8859-1, ASCII a 8 bit, noto come ISO-Latin, dove il numero 1 si riferisce ai caratteri propri dell’Europa occidentale. Optando per questo character set la necessità di ricorrere a riferimenti di entità per le lettere accentate viene a cadere, in quanto esse fanno parte del set ISO-Latin.

Se però, come rilevato, l’esigenza di rappresentare caratteri o simboli speciali estranei si verifica di rado, è consigliabile limitarsi ad impiegare i riferimenti di entità (dichiarati nella DTD), senza affidarsi ad un set di caratteri differente.

Per ciò che inerisce la sintassi concreta, diremo che lo standard ISO prescrive che nella dichiarazione SGML, con riferimento alla sintassi astratta, si rendano noti gli effettivi caratteri impiegati per i nomi e le parole chiave, impiegati per indicare, ad esempio, di aprire la tag iniziale (start tag open - STAGO: <), di chiudere la tag iniziale (tag close - TAGC: >) o di aprire la tag finale (end tag open - ETAGO: </). Per aiutare l’applicazione di SGML, e fare in modo che l’utenza impiegasse essenzialmente la medesima sintassi concreta, lo standard ha previsto una sorta di sintassi concreta di default, definita in ISO 8879, che prende il nome di sintassi concreta di riferimento [13] .

Sarà poi nella DTD che verranno specificati i nomi dei vari elementi, e cioè gli identificatori, eventuali loro attributi, le relazioni tra gli elementi, i riferimenti di entità e quindi tutte le strutture necessarie al fine di codificare il documento.

Ogni DTD, o il riferimento alla DTD, sarà poi inserita nella dichiarazione del tipo di documento (la document type declaration o doctype declaration, da non confondere con la stessa DTD, che è invece l’abbreviazione per document type definition) che ci fornirà un’informazione essenziale e cioè con quale tipo di documento stiamo lavorando.

Per concludere, l’esemplare del documento (document instance) è il documento vero e proprio che contiene il testo nella sua globalità e i riferimenti alla DTD.

Ogni file di testo comincerà quindi dichiarando quale tipo di documento contiene e a quale DTD fa riferimento. Questo verrà fatto in un’apposita zona dell’intestazione del file, chiamata appunto doctype declaration, che costituisce la prima istruzione presente in un file SGML. Senza questa dichiarazione, i programmi non saprebbero quali tag sono impiegati nel documento e quali regole sintattiche in esso vigono, e quindi non sarebbero in grado di leggerlo.

La DTD di riferimento è generalmente esterna rispetto al file codificato ma potrebbe anche essere inserita all’interno dello stesso file, anche se risulta sicuramente più economico conservarla a parte. Quando la DTD è  interna, la doctype declaration riporta solo il nome della DTD e le singole dichiarazioni all’interno, nell’internal DTD subset, usato soprattutto quando solo alcune dichiarazioni vogliono essere specificate o quando la DTD è breve. La forma è la seguente:

<!DOCTYPE  nome_DTD
[ dichiarazione1
   dichiarazione2
    ....................
 ]>

Quando invece la DTD è interna, la doctype declaration può presentarsi in due forme differenti:

<!DOCTYPE  novella.dtd SYSTEM “c:/sgml/testi/novella.dtd”>

         Dove <! (se ovviamente ci si conforma alla sintassi concreta di riferimento) è il simbolo di apertura della doctype declaration; DOCTYPE è la parola chiave che indica il tipo di dichiarazione che si sta esplicitando; novella è il nome della DTD; SYSTEM è la parola chiave che indica che la DTD è esterna rispetto al file sul quale si sta lavorando (porla esternamente è semplicemente una scelta dettata da un criterio di economia) ma si trova nello stesso computer; c:/sgml/testi/novella.dtd è il percorso che consente di rintracciare il file in cui è contenuta la menzionata DTD (novella.dtd); > è il simbolo che indica la chiusura della dichiarazione.

         <!DOCTYPE TEI.2 PUBLIC "-//TEI//DTD TEI Lite 1.6//EN"

 Dove, a differenza della precedente, la DTD non deve essere ricercata all’interno di un preciso percorso ma è richiamata tramite l’indicazione di un identificatore pubblico (PUBLIC IDENTIFIER) comunemente noto; ovviamente la DTD potrà essere conservata in una qualsiasi zona esterna rispetto al file.

Dopo questa dichiarazione seguirà una dettagliata descrizione del documento di cui si sta realizzando la versione elettronica, realizzata seguendo le specifiche regole sintattiche previste dallo standard e conformandosi a quanto esplicitato nella DTD.

L’SGML si configura dunque come un potente strumento per progettare linguaggi di codifica testuale completi e formalmente consistenti, in grado di supportare numerose operazioni di text processing pur mantenendo, attraverso il riferimento ad un dato document type, di cui ogni singolo documento in formato elettronico rappresenta un esemplare, la massima portabilità.

6.3 La Text Encoding Initiative (TEI) [14]

L’esigenza avvertita in campo informatico umanistico di rispondere adeguatamente ai problemi di rappresentazione informatica del materiale testuale e documentario ha condotto alla definizione di una serie di raccomandazioni, accettate a livello internazionale, per la rappresentazione dei testi in MRF; tali direttive garantiscono la validità scientifica della codifica e, soprattutto, l’intercambiabilità e la portabilità dei testi in formato elettronico.

A partire dal 1987 le tre maggiori associazioni mondiali di studiosi di scienze umane attraverso metodologie informatiche, la Association for Computers and the Humanities (ACH) la Association for Computational Linguistics (ACL) e la Association for Literary and Linguistic Computing (ALLC) hanno avviato un progetto internazionale per sviluppare un modello di codifica normalizzato che mettesse ordine nell’intricata congerie di modelli e linguaggi di rappresentazione dell’informazione testuale in formato elettronico. Questo progetto è stato denominato Text Encoding Initiative (TEI) e ad esso hanno attivamente collaborato un gruppo di studiosi provenienti da differenti paesi.

La finalità della TEI è di definire uno standard di codifica, specificatamente orientato alla gestione dei dati umanistico-letterari, e realizzare una normalizzazione dei formati di memorizzazione dell’informazione testuale, al fine di consentire l’interscambio dei documenti [15] . Per conseguire tali obiettivi i progettisti della TEI hanno assunto come linguaggio di base per la descrizione dei documenti l’SGML e come set di caratteri quello suggerito dalla stessa sintassi concreta di riferimento dello standard e cioè l’ISO 646. Il lavoro delle commissioni a partire dal 1989 ha condotto alla realizzazione di una vasta e complessa Document Type Definition, le cui caratteristiche sono state per la prima volta presentate nella pubblicazione uscita nel 1994 col titolo Guidelines for Electronic Text Encoding and Interchange (TEI P3). La struttura della DTD è stata in seguito rivista, ma la versione a tutt’oggi disponibile può considerarsi quella definitiva.

I principi che hanno orientato la commissione di sviluppo della TEI nel definire la struttura della DTD sono basati sui fondamenti teorici dell’SGML, ovvero sulla predilezione per un markup di tipo dichiarativo piuttosto che procedurale.

Il modello descrittivo dei testi previsto dalla TEI si fonda su di una sostanziale formalizzazione delle convenzioni vigenti nell’ambito dell’organizzazione strutturale dei documenti testuali, convenzioni che sono state codificate fino al punto di divenire un vero e proprio schema argomentativo (trattasi della divisione in parti, capitoli, paragrafi ecc.).

La predilezione per una codifica di tipo dichiarativo è stata rispettata nella maggior parte dei casi, pur considerando che essa talora implica un apporto assolutamente soggettivo dello studioso-codificatore, che necessita di interpretare la funzione delle varie componenti strutturali tipografiche, o manoscritte, per essere in grado di impiegare in modo adeguato i marcatori per gli elementi previsti nella DTD della TEI. Tuttavia sono previsti anche marcatori di tipo procedurale, utilizzabili quando la scelta di una codifica di tipo dichiarativo introdurrebbe seri problemi interpretativi, o quando le necessità dell’indagine automatizzata richiedono una forte aderenza del testo elettronico al suo originale cartaceo. Sono anche previste molte strutture adeguate alla codifica di fenomeni testuali complessi, quali la trascrizione di fonti manoscritte, la pratica ecdotica, l’analisi linguistica e strutturale del testo, la creazione di corpus, nonché la realizzazione di complesse strutture ipertestuali.

La TEI definisce uno schema di carattere generale, essenzialmente orientato all’ambito umanistico, ma non rigido. E’ infatti da rilevare come gli elementi previsti dalla TEI e definiti nella DTD siano oltre quattrocento, come molte caratteristiche strutturali di un testo possano essere agevolmente sottoposte a differenti tipi di codifica, infine come lo schema preveda possibilità di modifiche locali e di estensioni, per adeguarsi ad eventuali esigenze di memorizzazione testuale. Al fine di raggiungere questi obiettivi, e cioè consentire un universale applicabilità, si è optato per una divisione della DTD in molteplici frammenti, ognuno impiegabile a seconda della tipologia testuale da indagare (testo in prosa, testo poetico, testo drammatico, fonte manoscritta) o a seconda degli scopi di ricerca (codifica a fini editoriali, a fini di analisi linguistica, tematica, ecc.). L’utente che attua la codifica ha dunque la possibilità di riferirsi al frammento che lo interessa, includendo, all’inizio del documento elettronico, opportune dichiarazioni.

E’ stato, a questo scopo, elaborato un sottoinsieme della TEI, denominato TEI lite, che dovrebbe consentire la diffusione del progetto di codifica, senza impegnare l’utenza ad apprendere lo schema nella sua interezza. Trattasi infatti di una versione semplificata dell’intero schema di codifica definito dalla TEI, che permette di facilitare la realizzazione di testi in formato elettronico, senza richiedere lo studio dell’intera DTD e consentendo quindi la creazione di documenti TEI-compliant, cioè compatibili con l’intero schema.

Scendendo nello specifico, diremo che ogni testo codificato conformemente alle specifiche della TEI è costituito da due parti: un TEI header (codificato con l’elemento <teiHeader>), contenente le informazioni editoriali concernenti il documento elettronico, e un TEI text (codificato con l’elemento <text>) contenente la trascrizione codificata del testo in versione integrale.

Ogni TEI header consta di quattro parti, una delle quali deve necessariamente ricorrere in ogni testo codificato secondo le raccomandazioni della TEI, ed è l’elemento <fileDesc>, mentre le altre tre, <encodingDesc>, <profileDesc>, <revisionDesc>, sono opzionali.  Diremo che nella “testata” della TEI sono raccolte tutte le informazioni utili in sede di descrizione bibliografica del testo elettronico e del suo esemplare originale di riferimento. Queste notizie possono definirsi come metadata, cioè meta-informazioni o informazioni su informazioni.    

L’elemento <fileDesc> raccoglie tutte le notizie editoriali relative alla descrizione del testo elettronico. E’ una sorta di frontespizio elettronico in cui vengono raccolte tutte le informazioni bibliografiche relative al documento in oggetto. Il primo elemento è il titolo dell’opera [16] (il cui marcatore è <titleStmt>) generalmente accompagnato dal nome dell’autore della versione elettronica del testo (la cui tag corrispondente è <principal>) che viene graficamente rappresentato come un sottelemento del titolo [17] . Secondo elemento sono le note sulla pubblicazione elettronica (<publicationStmt>): il nome dell’editore o della casa editrice, eventualmente l’indirizzo, i dati relativi al distributore, lo status dell’opera (generalmente indicato solo se la versione elettronica si trova ancora in fase di preparazione) e cioè se  la versione elettronica del documento è disponibile per la consultazione o meno. Il terzo elemento (<sourceDesc>) del <fileDesc> è relativo alla descrizione bibliografica del testo o dei testi originali impiegati per realizzare la versione elettronica (dai quali cioè è derivato il formato elettronico dell’opera).

Dopo l’elemento <fileDesc>, la TEI header include l’elemento <encodingDesc>. Il proposito di questo elemento è di definire le metodologie impiegate all’atto della codifica, cioè di specificare metodi e principi che hanno sovrinteso alla trascrizione elettronica del testo.

Segue l’elemento <profileDesc>, il cui obiettivo è di consentire di fornire una dettagliata descrizione degli aspetti non-bibliografici del testo, per esempio, nel caso dei manoscritti, il tipo di scrittura impiegata, la presenza di una o più mani scriventi.

Per concludere, l’ultimo elemento del <fileDesc> è il <revisionDesc>, il cui scopo è di fornire informazioni relative alla storia delle modifiche e delle revisioni che il documento elettronico ha subito.   

Come affermato in precedenza, ogni documento conforme alla TEI deve essere costituito da due elementi: un TEI header che, come descritto, fornisce informazioni bibliografiche e non relative al documento e un TEI text che è il testo vero e proprio. L’elemento text si divide, a sua volta, in quattro elementi: <front> (opzionale), <body> (obbligatorio), <group> (obbligatorio) e <back> (opzionale).

<Front> e <back> sono necessari qualora il documento riporti delle informazioni, all’inizio o alla fine del testo vero e proprio (per esempio un indice o un titolo nella pagina), delle quali si necessita operare una codifica. <Body> è l’elemento che introduce il corpo del testo. <Group> è da impiegarsi nel caso di una serie di testi facenti parte della medesima pubblicazione, ognuno dotato della propria individualità (ognuno con un proprio front, body e back) [18] .

All’interno dell’elemento <body> ci saranno ovviamente una serie di suddivisioni ulteriori, necessarie a definire la struttura interna del testo indagato; suddivisioni che evidenzieranno la scansione in sezioni <div> di vario livello (div0, div1, div2), in paragrafi <p>se necessario in linee <l>, interruzioni di pagina <pb>, ecc. Saranno necessari marcatori differenti a seconda del tipo di testo codificato; come rilevato la TEI consente infatti di impiegare un set di marcatori ad hoc per la tipologia del testo in esame. Ogni fenomeno può essere infatti codificato: dai nomi di persona ai nomi di luogo, alle indicazioni cronologiche; sono gli obiettivi della codifica che orienteranno verso la scelta del set dei marcatori.

E’ chiaro che la trattazione relativa alla delineazione delle caratteristiche di questa iniziativa non può dirsi sufficiente, in quanto una presentazione complessiva e totale richiederebbe di dedicare alla TEI una pubblicazione a sé stante. Si ritiene di aver comunque presentato quelli che sono gli aspetti più significativi di questo progetto che, per la sua complessità e diffusione, unitamente alla sua origine ed evoluzione in ambito umanistico, è ritenuto essere, da parte degli studiosi di informatica umanistica, il più valido strumento di codifica per la creazione di testi elettronici e quindi l’edificazione di banche dati testuali di ampio respiro [19] .

Con una precisazione.

Esiste infatti un limite sostanziale nel modello di codifica proposto dalla TEI, limite che inficia la realizzazione di un modello testuale adeguato alle necessità di analisi e di interpretazione [20] .

Ripartiamo dalla nozione di testo. Si è visto che la forma che l’informazione testuale deve assumere per essere sottoposta a procedimenti di elaborazione automatica è quella della sequenza di caratteri.

La nozione di testo così intesa (sequenza o stringa di caratteri) è molto differente da quella del testo inteso in termini letterari. In ambito informatico, per testo non si intende il materiale letterario nella forma in cui è stato scritto originariamente dall’autore, ma un’informazione codificata in forma di stringhe di caratteri, ossia una rappresentazione dell’informazione che consiste esclusivamente di caratteri. Una simile forma di rappresentazione non cattura, evidentemente, che una piccola parte dell’informazione testuale: al testo inteso come dato costituito dalla sola successione dei caratteri, occorre aggiungere esplicitamente, attraverso l’inserimento di marche o segni convenzionali, tutta l’informazione testuale che non è possibile rappresentare in questa forma.

Abbiamo visto come lo scopo della codifica del testo, e l’obiettivo della TEI, sia esattamente questo: definire attraverso l’ausilio di una serie di marcatori la struttura logica degli oggetti testuali, strutturando cioè i dati testuali come informazione.

Ma se si concepisce la codifica del testo come una rappresentazione di quell’informazione che si aggiunge al testo vero e proprio, e che eccede da esso, allora ci si trova di fronte ad una sostanziale ambiguità: da un lato si intende il testo come oggetto letterario, dall’altro come sequenza di caratteri; così inevitabilmente si scambia il testo con la sua rappresentazione, il testo con il documento.

Questo è ciò che essenzialmente limita il modello computazionale assunto dalla TEI e che nasce dall’ambiguità della nozione di codifica, lasciata sostanzialmente irrisolta.

La forma di rappresentazione e il conseguente modello del testo assunti dalla TEI, se ammettono infatti la possibilità di rappresentare strutture diverse dello stesso testo, non riescono a riunirle in un’unica e coerente forma di rappresentazione.

Ma torniamo al modello del testo assunto dalle norme di codifica stabilite dalla TEI. L’implicita assunzione di questo modello dipende dalla scelta dello SGML come linguaggio base. L’SGML definisce un documento in termini strutturali come una gerarchia ordinata di oggetti di contenuto testuale. La struttura è gerarchica, perché oggetti di tipo diverso sono contenuti l’uno nell’altro, come in uno schema di classificazione in cui classi più generali comprendono classi più particolari, o come in una struttura ad albero; ed è ordinata, perché tra gli oggetti c’è una relazione lineare e dati due oggetti qualsiasi contenuti in un documento si può sempre affermare che l’uno viene prima dell’altro.

Questa nozione di testo non tiene però conto che talvolta lo stesso documento si conforma a diverse strutture sovrapposte, le quali non possono essere inserite nella stessa struttura gerarchica di modo che la sua elaborazione varia a seconda della particolare struttura considerata; né può tenere in considerazione il fatto che esistono relazioni strutturali di tipo non gerarchico. Assumendo l’SGML come base per la definizione delle norme e dei linguaggi di codifica, la TEI assume implicitamente questo modello strutturale come modello fondamentale di rappresentazione del testo e vincola di conseguenza la forma di rappresentazione del testo ad una struttura di dati affatto particolare, che non permette di riunire in una singola rappresentazione coerente modelli strutturali diversi e alla quale non pare così applicabile un modello computazionale pienamente adeguato alle necessità dell’analisi e dell’interpretazione del testo.

La struttura del testo nella TEI viene dunque identificata con quella particolare struttura della sua forma di rappresentazione che meglio si presta alle necessità della manipolazione dei documenti; ma il vantaggio dell’elaborazione automatica consiste proprio nello svincolare la rappresentazione del testo dal modello strutturale del documento stampato.

6.4 HTML – Hyper Text Markup Language

Naturalmente il numero di DTD esistenti, definizioni di set di marcatori ad hoc per ogni corpus documentario dotato delle medesime caratteristiche strutturali, sono molteplici e l’optare per l’una o per l’altra significa aver individuato il proprio modello della fonte in oggetto. L’HTML è la DTD divenuta ufficiale nell’ambito della produzione di ipertesti, cioè di documenti navigabili a tutt’oggi disponibili sul web. L’HTML è quindi un prodotto SGML, nasce cioè nel rispetto delle specifiche della sintassi dello standard. Naturalmente essendo una DTD di SGML il set di marcatori proposti non è modificabile e l’utente-codificatore non può skippare verso un set differente, deve quindi conoscere il significato e il valore dei codici proposti dall’HTML e su questa base produrre la propria pagina web. I limiti insiti in questo linguaggio hanno condotto, di necessità, all’elaborazione di un linguaggio diverso, che consentisse la diffusione dei testi su Internet, a tutt’oggi lo strumento per eccellenza ai fini della distribuzione dell’informazione strutturata. 

6.4.1 I limiti dell’HTML

L’attuale stadio evolutivo delle tecnologie di gestione della documentazione in formato elettronico ha notevolmente contribuito a migliorare l’efficienza e la fruibilità del materiale in MRF; l’avvento delle reti e quindi di un sistema di interscambio delle informazioni di dimensioni mondiali, il Word Wide Web, ha condotto ad una sempre più consistente diffusione di dati strutturati. Tuttavia questa modernissima architettura soffre di alcuni limiti che inficiano l’ottimizzazione del suo operare. La causa sostanziale di tali limiti risiede nel cuore del Web, vale a dire nel linguaggio HTML.

Il primo gruppo di limiti riguarda essenzialmente l’incapacità di questo linguaggio di fornire un’adeguata rappresentazione dell’informazione. La rappresentazione e la codifica dei dati sono il fondamento di un sistema di gestione dell’informazione. L’HTML impone in questo senso pesanti restrizioni. In primo luogo è un linguaggio di rappresentazione non modificabile, quindi chiuso; questo significa che non è concesso al codificatore di intervenire personalmente laddove lo ritenga necessario: l’autore potrà solo scegliere entro un numero predefinito di elementi, capaci di descrivere solo taluni fenomeni testuali e non avrà la facoltà di esplicitarne di diversi, anche se la struttura del testo lo richiederebbe, o di qualificarli in modo differente.

In secondo luogo HTML è un linguaggio scarsamente strutturato, dotato di una sintassi poco potente, incapace di descrivere fenomeni complessi o informazioni altamente organizzate; ne consegue che non può essere utilizzato come sistema di interscambio per contenuti informazionali particolarmente elaborati come potrebbe essere un record di una base di dati. A tutto questo si aggiunge una spiccata predilezione per marcatori stilistici più che strutturali, cioè una codifica improntata alla descrizione dell’aspetto fisico del documento piuttosto che alla struttura logica del testo.

Un secondo limite dell’HTML è riguarda la definizione dei link ipertestuali. Questo linguaggio di codifica prevede infatti, in un costrutto ritenuto ipertestuale, il solo link unidirezionale: sia l’origine che la destinazione devono essere cioè esplicitate nei rispettivi documenti. Un sistema ipertestuale dovrebbe invece essere corredato da una serie di collegamenti ipertestuali, corrispondenti alle molteplici relazioni semantiche che si potrebbero definire tra gli elementi di un documento (link bidirezionali, link che puntano su sezioni strutturali di un documento di destinazione e non su una singola stringa, link sequenziali che identificano una serie di documenti fra loro correlati, ecc.).

Da questi limiti, che potremmo definire di natura rappresentazionale, ne derivano altri di natura operativa, riguardanti cioè il rapporto autore-sistema e lettore-sistema e quindi la loro facoltà di interagire con il documento codificato.

Innanzitutto la possibilità di un controllo più elastico da effettuarsi sull’aspetto del documento, che risulta invece alquanto rigido e limitato. Questo significa che una pagina Web deve essere progettata per un output dotato di caratteristiche predefinite, con il rischio quindi di non ottenere i medesimi risultati, visibili su un determinato schermo, quando li si prova a riprodurre su di un altro dispositivo di visualizzazione o nell’output si carta.

Inoltre HTML non consente di generare viste differenziate sul medesimo documento, facoltà talora necessaria alle esigenze di un ipotetico lettore (per esempio ottenere diverse versioni linguistiche a partire da un unico documento multilingua).

La limitata consistenza strutturale ostacola la creazione automatica e dinamica di indici e sommari. Per lo stesso motivo sono notevolmente ridotte efficienza, efficacia e globalità della ricerca di informazioni sul Web. I motori di ricerca si muovono secondo un information retrieval full-text, che non prende in considerazione la struttura del documento, ma restituisce riferimenti a documenti interi.

Succede poi sovente di rintracciare una pagina sul Web che è ovviamente solo una porzione di una più vasta collezione; spesso accade di trovare un link ad un indice, ad una home page, o altri riferimenti utili a raggruppare un insieme di dati relativi al medesimo contenuto informativo ed appartenenti al medesimo autore, o comunque inerenti lo stesso soggetto d’indagine. Accade che all’atto della stampa sia necessario operare su ogni singolo file HTML. Ci sarebbe invece un modo migliore per esprimere le interrelazioni sussistenti tra un set di pagine, in modo che possano essere processate come un unico file strutturato. Dovrebbe essere possibile aggiungere metadata (informazioni su di un’informazione, informazione quindi comprensibile dalla macchina, o meglio, l’insieme di dati che descrivono una o più risorse informative sotto un certo aspetto) alle pagine Web, e raggiungere quindi l’obiettivo della notifica delle mutue relazioni sussistenti tra le singole pagine.

Per concludere, a rendere ancora più complessa la situazione, sono intervenuti anche i browers, Netscape e Microsoft, che hanno iniziato l’infelice pratica dell’introduzione di loro proprie e individuali “extensions” al linguaggio HTML. Questo ha condotto gli autori di pagine Web a giungere a pesanti compromessi, al fine di rendere le loro pagine accessibili all’utenza, pur volendo impiegare le ultime features introdotte dai browser vendors. La conseguenza inevitabile è stata la realizzazione di siti inadeguati. Gli autori devono comprendere che il Web non è realmente Word Wide se essi scelgono di utilizzare “extensions” non universalmente supportate.

Per superare questi limiti si è tentata una generalizzazione del supporto sul Web ad SGML, il linguaggio standard da cui deriva lo stesso HTML, un’applicazione particolare dello standard ISO. L’obiettivo è stato quello di modificare la stessa architettura del Web per consentire di usare anche altre applicazioni SGML, oltre a quella universalmente nota, l’HTML. Questo consentirebbe la distribuzione di documenti in MRF con formato SGML, garantendo un potere di controllo dell’autore sulla struttura delle informazioni pubblicate; ogni editore potrebbe utilizzare il linguaggio di codifica più adeguato alle sue necessità, a cui poi associare uno o più fogli di stile, sovrintendendo così alla presentazione dei documenti pubblicati.

Per superare questi ostacoli si è deciso quindi di sviluppare un sottinsieme semplificato di SGML, appositamente pensato ai fini della creazione di documenti sul Web. Questo linguaggio è stato denominato XML, Extensible Markup Language.

6.5 XML – Extensible Markup Language [21]

La codifica SGML dei testi elettronici offre una serie di consistenti vantaggi dal punto di vista del trattamento informatico.

In primo luogo, potendo un file SGML essere compilato ricorrendo esclusivamente a stringhe di caratteri ASCII stampabili, esso è facilmente portabile su ogni tipo di piattaforma hardware e software. Inoltre un testo codificato secondo il formato SGML può essere impiegato per differenti scopi, variabili secondo il trattamento computazionale cui sottoporre la fonte (stampa su carta, presentazione multimediale, indagine ed analisi effettuata tramite specifici software, elaborazione all’interno di una base di dati) consentendo di evitare il ricorso a conversioni tra formati spesso incompatibili. Infine la natura altamente strutturata di un documento SGML si presta allo sviluppo di complesse applicazioni (aggiornamento di database o creazione di strumenti di information retrieval contestuali).

L’adozione di una tecnologia come SGML sul Web risolverebbe molti dei problemi che ne limitano le enormi potenzialità. Tuttavia SGML è dotato di una complessità tale da renderne alquanto complessa l’implementazione. Per questa ragione il W3C (Word Wide Web Consortium), ha optato per la realizzazione di una versione semplificata dello standard ISO che ha condotto allo sviluppo dell’XML.

XML è dunque un sottinsieme di SGML semplificato ed ottimizzato specificamente per applicazioni in ambiente Word Wide Web. Le caratteristiche dell’XML sono quindi molto simili a quelle dell’SGML (sia per quanto riguarda i principi di codifica che per quello che concerne le specifiche della DTD) [link al file definizioniXML.doc]. Si tratta dunque di un vero metalinguaggio, che permette di specificare molteplici classi di linguaggi di marcatura, e non una semplice applicazione SGML come HTML (che si configura come uno dei possibili linguaggi di codifica conformi alla sintassi SGML).

La grande novità che caratterizza XML, in antitesi a HTML, orientato alla descrizione della struttura fisica del documento e della rappresentazione “visiva” dello stesso, è la propensione alla descrizione delle informazioni testuali in un formato leggibile e comprensibile dall’utente, prescindendo dalle indicazioni relative a come i dati devono essere visualizzati. XML è  un database-neutral e un device-neutral format; solo in un secondo momento i dati codificati in XML potranno essere indirizzati a differenti devices, usando l’Extensible Style Sheet Language (XSL). Essendo XML extensible, rispetto a HTML (che prevede il solo utilizzo di prefissati set di elementi) il suo utilizzo eliminerà il bisogno da parte dei produttori di browser di aggiungere specifici tag HTML incompatibili (le “extensions” di cui si diceva).

Questo è possibile perchè XML è un metalinguaggio impiegato per realizzare altri linguaggi specifici, denominati anche “vocabolari”. Ogni vocabulary può essere costruito mediante il ricorso ad una DTD  che fornisce le regole necessarie alla definizione degli elementi e della struttura del nuovo linguaggio [22] .  

Dunque anche un singolo documento XML valido, un singolo esemplare di documento conforme a XML, deve essere associato ad una DTD che ne specifica la grammatica. Tuttavia a differenza di SGML, XML consente la distribuzione anche di documenti privi di DTD, documenti well-formed, dotati di una sintassi più rigida rispetto a quella di un documento SGML (per esempio è sempre obbligatorio inserire i marcatori di chiusura negli elementi non vuoti). Per questa ragione alcune delle più complesse caratteristiche di SGML, che ne accrescono la complessità computazionale, sono state eliminate in fase di realizzazione del nuovo progetto del Consortium. Sono state dunque introdotte novità nella sintassi, giungendo ad una consistente riduzione della complessità di implementazione di un browser XML e facilitando di molto l’apprendimento del linguaggio. La semplificazione poi non comporta alcuna incompatibilità: un documento XML valido è sempre un documento SGML valido; ne deriva che il passaggio e quindi la trasformazione di un’applicazione o di un documento SGML in uno XML è una procedura quasi sempre automatica.

In termini opposti alla tendenza ora dominante nell’ambito delle recenti tecnologie Web, XML è orientato alla descrizione della struttura del testo e non alla rappresentazione visiva del documento. Un file HTML riflette il privilegio accordato alla rappresentazione della struttura del documento ma non ad un altrettanto adeguata descrizione della struttura dei dati. Un markup HTML si limita a fornire informazioni necessarie a comprendere come gli elementi testuali sono disposti all’interno della pagina, ma non fornisce alcuna informazione utile a comprendere il significato degli elementi codificati, in quanto ogni singolo tag non apporta nessuna nozione relativa al blocco di testo cui è affiancato. Quando un documento HTML viene processato dal browser, la semantica viene ignorata, la macchina non comprende quale tipo di informazione deve essere resa, il contenuto informazionale del testo non è oggetto di indagine.

Viceversa una codifica XML presta attenzione non all’aspetto degli elementi testuali, cioè alla loro distribuzione fisica, ma al contenuto di ogni singola partizione; esprime quindi, tramite il ricorso a marcatori alfabetici, il significato della stringa di caratteri cui il tag è associato. Diremo che XML focalizza la codifica sulla semantica e sulla struttura dei dati, mantenendo altresì l’ordinamento gerarchico che sovrintende l’organizzazione degli elementi della fonte. Ne deriva un assoluto parallelismo con la distribuzione dei record all’interno di una base di dati.

L’insieme delle specifiche del progetto XML permette dunque di creare, gestire, manipolare e mantenere applicazioni ipermediali complesse in rete. XML si configura dunque come un potente metalinguaggio in grado di superare quella molteplicità di limitazioni di una delle più note applicazioni SGML, HTML. La possibilità di introdurre tag custom per codificare ogni tipo di fenomeno testuale o di elemento documentale fa di XML uno strumento innovativo. Senza dimenticare che l’attenzione accordata all’analisi della struttura dei dati, con la possibilità fornita all’utente di comprendere il significato delle componenti testuali grazie all’utilizzo personalizzato dei marcatori, costituisce una imprescindibile potenzialità di XML. L’essere XML un sottinsieme di SGML, compatibile con HTML, consente spesso di non dover ricorrere all’elaborazione di nuovi tool per la gestione e la manipolazione dei documenti codificati secondo le specifiche del W3C; molteplici parser e conversion tool nati per HTML e SGML funzionano in modo ottimale anche con XML.

La progressiva implementazione delle specifiche del W3C rappresenta un salto evolutivo nell’architettura del web; il fatto che l’industria delle tecnologie Internet, ed in particolare le aziende leader del settore, Microsoft e Netscape, l’abbiano accolto e supportato consente di pensare in termini positivi ad un futuro salto definitivo di XML nel Word Wide Web.