1.1 - La memoria e la biblioteca
1.2 - Da Ramelli a Berners-Lee
2.1 - La confusione tra ipertesto e World Wide Web
2.2 - La teoria ipertestuale
2.3 - Il link
2.4 - La struttura e la rappresentazione
2.5 - I linguaggi di Markup
2.5.1 - Il Markup e il Web
3.1 - La crisi del Web è la crisi di HTML
3.2 - I link scomparsi
3.3 - La perdita di distinzione fra struttura e rappresentazione
4.1 - XML: La struttura
4.1.1 - XML: Well-Formed e Valid Document
4.1.2 - XML: Il DTD
4.1.3 - XML: Gli elementi
4.1.4 - XML: Gli attributi
4.1.5 - XML: Le entità
4.1.6 - XML: Namespace
4.2 - XSL: La rappresentazione
4.3 - XLL: I nuovi collegamenti
5.1 - Il panorama del Software
5.2 - Cosa è possibile fare oggi
5.3 - Demo
5.4 - L'eloquente caso dei motori di ricerca
5.5 - Link per approfondire
| La comunicazione è certamente un'esigenza tipica
dell'uomo ma le potenzialità della sua diffusione sono
assolutamente legate alle innovazioni tecnologiche,
secondo una dinamica che vede in quella la domanda e in
queste la risposta. E' quindi la diffusione delle
innovazioni tecnologiche legate ai processi comunicativi
a porre il problema della proliferazione della conoscenza
e parallelamente quello della complessità della sua
gestione. Non è una questione di oggi, legata alla
telematica e al computer, anche se sicuramente queste
tecnologie le riportano all'ordine del giorno, ed alcune
testimonianze lo evidenziano in modo suggestivo. Nel
tempo la memoria e la biblioteca, sono state le risposte
organizzative studiate dall'uomo per rispondere alle
esigenze di conservazione della cultura orale prima,
basata sul manoscritto e sul libro a stampa poi. Bisogna
capire le nuove tecnologie, in particolare che cosa
offrono di nuovo, per poter capire come posono cambiare
in prospettiva le modalità della comunicazione e della
sua conservazione. L'ipertesto in fondo altro non è che
un nuovo modo di organizzare le informazioni, il
patrimonio della comunicazione, un modo figlio di una
esigenza antica e di una tecnologia innovativa. La memoria è stato il primo archivio della conoscenza, legato alla cultura della comunicazione orale e simboleggiata nel nostro immaginario da Omero, il poeta che non scrisse. Fu la scrittura, su rotolo o libro, a metterla in crisi e ad imporre un nuovo modo di conservare un patrimonio che la nuova tecnologia sembrava rendere immenso con il suo potere di superare i limiti umani del tempo: la biblioteca nuovo serbatoio della memoria umana dominò incontrastata da Alessandria d'Egitto ad ogni angolo della terra conosciuta attraverso due millenni fin quando l'invenzione della stampa a caratteri mobili non sconvolse un sistema che sembrava perfetto nella sua cristallizzazione. Una mole di carta scritta, prima impossibile solo da immaginare si riversò sui banchi degli studiosi, nelle borse dei viandanti, negli scaffali di molte case; improvvisamente colto non era più chi aveva avuto il privilegio nella sua vita di leggere dieci, venti libri ma soprattutto, per la prima volta la conoscenza poteva essere confrontata e per la prima volta poteva sorgere nella mente di chi leggeva una nuova esigenza, quella di passare da un testo ad un altro, costruendo ponti oltre che sinapsi. Si cominciò a camminare mentre si studiava, per prendere, posare, riprendere e più la stampa affinava il suo processo produttivo moltiplicando per mille i testi disponibili, più i lettori cominciavano ad immaginare nuovi modi di raccogliere quel pozzo senza fondo. Nasceva l'arte di classificare i libri, si diffondevano i repertori e, un secolo dopo la vera e propria data di inizio della diffusione del libro a stampa in Europa, in un testo compariva una macchina in grado di permettere la lettura contemporanea di numerosi libri, o meglio il passaggio dall'uno all'altro senza la necessità di uno spostamento. Il testo, del 1588 si intitolava "Le diverse et artificiose machine del Capitano Agostino Ramelli" e la macchina altro non era che una ruota con tanti leggii bilanciati su cui poggiare i libri necessari e tenendoli aperti a piacimento. Azzardando un po' si potrebbe dire che nasceva l'idea dell'ipertesto. |
|
La tecnologia risponde ai bisogni dell'uomo solo a
patto che le condizioni economiche e tecniche lo
permettano, ma ciò che colpisce, oltre alla fervente
immaginazione di Ramelli è la vicinanza, dal punto di
vista dell'esigenza che mette in moto l'idea, tra la sua
macchina e "Memex" che Vannevar Bush mise a
punto nel 1945 e che universalmente è considerata la
macchina per ipertesti prima degli ipertesti. Certo il
tutto è meno ingombrante e basato su supporti più
credibili, ma in fondo alla base di entrambe c'è il
desiderio di poter raccogliere conoscenza in misura
superiore ai limiti del momento e di poterne disporre
senza eccessive dilazioni di tempo. Per Bush, autore del famosissimo articolo "As we may think" il problema non era tanto nell'eccessiva quantità di pubblicazioni, quanto nel mancato progresso tecnologico. Il sistema "Memex" era in grado di archiviare la conoscenza in un modo più preciso permettendo di visualizzare ogni elemento d'informazione digitando il codice mnemonico corrispondente e, ancora più importante, era in grado di registrare le connessioni osservate fra elementi distinti. Egli sottolineava che questo tipo di associazione non lineare di idee è il modo di funzionamento naturale della mente umana, e confidava sulla futura creazione di dispositivi simili in grado di riprodurne in modo efficace le caratteristiche. Visionario Lui ma visionario anche Theodor Holm Nelson che coniò, in un saggio pubblicato nello stesso 1965, il termine "ipertesto": " Lasciate che io introduca il termine "ipertesto" per rappresentare un insieme di materiale scritto o figurato interconnesso in un modo così complesso da non poter essere rappresentato su carta. Esso può contenere sommari o mappe dei suoi contenuti e delle relazioni che vi intercorrono; può contenere annotazioni, note a fondo pagina di coloro che vi hanno lavorato sopra [..] tale sistema correttamente disegnato e gestito, presenta grandi potenzialità nel campo educativo per l'ampia gamma di scelte, per il suo senso di libertà, per la sua presa intellettuale. Un sistema come questo può crescere indefinitamente, includendo gradualmente sempre maggiori conoscenze [..]."iper" : ha il significato di estensione [..], questo prefisso rappresenta l'impossibilità di rappresentare le informazioni contenute attraverso una rappresentazione lineare, come una stringa di testo." Bisognava aspettare il 1989, o meglio l'aumento delle capacità di calcolo e di archiviazione dei computer, perché queste suggestioni potessero essere raccolte dalla tecnologia per diventare realtà nei laboratori del CERN di Ginevra grazie a Tim Berners-Lee che diede il La al World Wide Web con l'intento, inizialmente, soltanto di far circolare le informazioni all'interno di gruppi di lavoro distribuiti geograficamente. Il resto è storia recentissima, l'avvento dei browser, l'enorme diffusione di internet, il successo enorme dell'HTML e il rilancio dell'ipertesto come forma della comunicazione del futuro. |
|
L'ipertesto glogale, così viene spesso definito il
World Wide Web. Certamente questa affermazione non è
completamente sbagliata, ma altrettanto certamente può
essere considerata una forzatura. Un nesso tra le due
cose esiste, anzi due: la diffusione di questa tecnica
per la comunicazione in seguito all'esplosione di
internet come medium di massa e la struttura non lineare
delle informazione nella rete mondiale. D'altra parte
succede spesso che le innovazioni tecnologiche
rivoluzionarie trascinino nella loro scia una serie di
novità che a ben guardare novità non sono; internet è
una realtà molto complessa in cui certamente l'elemento
caratterizzante è il protocollo TCP/IP, che sostiene una
serie di applicazioni tra cui quelle legate al Web, ma
tant'è, per molti internet è il web e il web è
l'ipertesto globale. A dire il vero le statistiche
spiegano senza equivoci questo effetto ottico. Il
protocollo TCP/IP ha quasi trent'anni, i primi
esperimenti di ipertesti sono ancora più vecchi, i
linguaggi di markup sono anch'essi già appesantiti dal
tempo, ma tutte queste tecnologie dovevano aspettare che
qualcosa ne sintetizzasse gli aspetti rivoluzionari
all'interno di un'interfaccia semplice ed intuitiva: il
browser, il motore esplicito dell'esplosione di internet.
La storia di World Wide Web inizia nel maggio del 1990, quando Tim Berners Lee, un ricercatore del CERN di Ginevra presenta ai dirigenti dei laboratori una relazione intitolata "Information Management: a Proposal". La proposta di Berners Lee ha l'obiettivo di sviluppare un sistema di pubblicazione e reperimento dell'informazione distribuito su rete geografica che tenesse in contatto la comunità internazionale dei fisici. Nell'ottobre di quello stesso anno iniziano le prime sperimentazioni.Certamente Berners Lee era fortemente influenzato da tutte le teorizzazioni e le realizzazioni di ipertesti, ma le esigenze del progetto di cui faceva parte erano tali da giustificare un'implementazione solamente parziale. Per alcuni anni, comunque, il World Wide Web resta uno strumento utilizzazto esclusivamente dalla comunità scientifica. L'impulso decisivo al suo sviluppo viene solo agli inizi del 1993, dal National Center for Supercomputing Applications (NCSA) dell'Università dell'Illinois, dove Marc Andressen (che pochi anni dopo fonderà con Jim Clark la Netscape Communication) ed Eric Bina sviluppano una interfaccia grafica multipiattaforma per l'accesso ai documenti presenti su World Wide Web, il famoso Mosaic, e la distribuiscono gratuitamente a tutta la comunità di utenti della rete. Nasce così il World Wide Web, nella forma in cui oggi lo conosciamo, e che ne ha permesso l'enorme diffusione; tutti possono accedere al servizio e saltare da un nodo all'altro con la semplice pressione di un dito della mano, tutti possono sperimentare la potenza della comunicazione ipertestuale, o meglio della sua semplificazione avvenuta in quel laboratorio di Ginevra. |
|
Il termine ipertesto fu coniato nel 1965 da Theodor
Holm Nelson. In realtà la teoria dell'ipertesto, per
quanto ciò possa risultare un paradosso, è piu' vecchia
ancora del termine che ora la descrive. Non è difficile
capire il perchè; per decenni la tecnologia ha inseguito
la fantasia e l'ingegno degli studiosi, rendendo spesso
le innovazioni realizzabili solo molto tempo dopo la loro
intuizione. Nel 1962 Douglas Engelbart iniziò un
progetto per lo sviluppo di un sistema in grado di
aumentare la produttività degli operatori informatici,
liberando il computer dalla schiavitù del calcolo
numerico e dedicando le sue potenzialià anche
all'elaborazione di testi. Per la prima volta si poneva
il problema dell'interazione e quindi del rapporto
efficiente tra uomo e macchina ed in un certo senso
Engelbart raccolse, cercando di realizzare le suggestioni
futuriste catalizzate dal progetto Memex di Vannemar
Bush: organizzazione, rappresentazione e accessibilità
di informazioni strutturate in una enorme mole le
esigenze, files collegati ed interazione per mezzo di un
liguaggio a comandi le risposte in quello che può essere
considerato il primo ipertesto oppure di questo l'ultimo
antenato: NLS, presentato nel 1968 alla Fall Joint
Computer Conference. Sono gli stessi anni in cui proprio
Nelson lancia il suo progetto Xanadu con l'obiettivo di
costruire un sistema in grado di assicurare lo scambio di
documenti in formato elettronico attraverso la
comunicazione tra basi di dati in modo assolutamente
trasparente per l'utente, anni in cui, quindi, diversi
studiosi si pongono il problema della nuova struttura da
dare alla documentazione elettronica.Nella utopica
visione di Nelson, Xanadu era la base di un universo
informativo globale ed orizzontale - da lui definito docuverse
(docuverso) - costituito da una sconfinata rete
ipertestuale distribuita su una rete mondiale di
computer. Il progetto Xanadu, il cui nome deriva dal
misterioso palazzo 'posto magico di memoria
letteraria' immaginato nella poesia del romantico
inglese S. T. Coleridge Kubla Kahn, non è mai
stato realizzato concretamente, malgrado i molti
tentativi a cui Nelson ha dato vita. L' Hypertext Editing System è stato il primo ipertesto realizzato da Andries van Dam nel 1967 nei laboratori della Brown University, grazie ad un contratto di ricerca dell'IBM; il sistema fu presentato come sistema di tipografia in linea a clienti IBM, tra i quali testate importanti quali Time/Life, che trovarono il sistema eccessivamente "futuribile". Anche all'interno della propria università, van Dam incontrò notevoli difficoltà nel permettere che si utilizzassero dei computer per trattare parole, piuttosto che numeri. L'IBM vendette poi il sistema allo Houston Manned Spacecraft Center, dove venne utilizzato per produrre documentazione relativa alle missioni Apollo. Poco dopo, nel 1968, venne realizzato Il File Retrieval and Editing System (FRESS), sia per superare i limiti dell'HES (indipendenza delle periferiche di I/O, uso di link bidirezionali, funzionalità di "undo/redo", ...), sia sotto l'influenza della presentazione del NLS da parte di Engelbart. In seguito furono realizzati diversi sistemi ipertestuali, anche commerciali, tra i quali ricordiamo ZOG/KMS, realizzato nel 1983 e strutturato su menù gestibili con un meccanismo di touch-screen, NoteCards, realizzato nel 1985 presso lo Xerox Parc che aveva un'interfaccia grafica a finestre in cui potevano scorrere testi e immagini e che potevano essere aperte tramite link, Guide, il primo ad avere un certo successo commerciale grazie probabilmente alla disponibilità di tre tipi differenti di bottoni per eseguire link. Il primo (replacement) permetteva la sostituzioni in linea di parti di testo con versioni espanse dello stesso. Il secondo (note) permetteva l'apertura di finestre di pop-up, mentre il terzo (reference) permetteva il salto ad un altro nodo dell'ipertesto ed infine Hypercard, che tra il 1987 e il 1992 fu diffuso gratuitamente dalla Apple sui Macintosh, diventando di fatto l'ipertesto più diffuso prima dell'avvento del Web. |
|
Il link è l'elemento chiave che la tecnologia
informatica ha fornito alla comunicazione permettendo
quel salto reso dal suffisso iper per cui un testo
diventa un ipertesto.Gli studi teorici sull'ipertesto
hanno da tempo definito diverse tipologie di link, tra le
quali è fondamentale ricordare le seguenti: Il link bidirezionale non è il semplice ritorno
indietro di un link unidirezionale bensì un legame
assoluto che permette flussi dall'uno all'altro e
dall'altro all'uno; in pratica una volta stabilita una
relazione tra due elementi si instaura un ponte che
permette il passaggio a prescindere da quale sia il punto
di partenza. |
|
Quando chiunque di noi legge l'indice di un libro da
per scontato che un font più grande, come un
allineamento più a sinistra, indichi un capitolo e un
font minore, o un allineamento più a destra, un
paragrafo. E' un esempio molto evidente di come una
tecnologia di comunicazione, nel tempo, ha definito il
rapporto fra la struttura gerarchica delle informazioni e
la loro rappresentazione visiva; a cosa è solo
apparentemente banale, fino a pochi secoli fa, e quindi
per decine di secoli, il libro, pur essendo
sostanzialmente uguale a come è oggi, non aveva un
titolo e ancora i primi libri a stampa cominciavano
direttamente col testo senza neppure il frontespizio, che
pure non è un titolo come oggi lo intendiamo, bensì una
serie di informazioni come l'autore, il luogo e la data
di edizione e le prime riche del testo vero e proprio.
Eppure per noi è addirittura assurdo pensare ad un libro
sprovvisto di un titolo ben visibile nella prima di
copertina. Quante volte capita, girando tra gli scaffali
di una libreria di notare un libro e in modo
assolutamente naturale di girarlo per leggere sul retro
la sintesi del contenuto e le notizie biografiche
dell'autore. In pratica il libro riporta delle
informazioni strutturate gerarchicamente in modo da
risultare funzionali al loro accesso, e questo a
prescindere dalla casa editrice, dalla tipologia
estetica, dal colore della carta e dal font usato, ovvero
a prescindere dalla loro rappresentazione. Per quanto riguarda i testi elettronici il discorso è essenzialmente lo stesso: esiste un contenuto, la sua struttura e la rappresentazione che di volta in volta si realizza. Nel momento in cui ho bisogno di un'informazione entrano in gioco tuti e tre questi livelli, ma è bene che non si perda di vista come questi siano tra loro diversi anche se vengono sintetizzati in un unico file o in un'unica schermata come un tempo in un unico libro. Se decido di voler leggere qualcosa sull'arte gotica avrò bisogno sicuramente di un contenuto che di quel tipo di arte parla. Ma di arte gotica trattano sicuramente centinaia di testi, per cui, per trovare quello più adatto alle mie esigenze dovrò aiutarmi con la struttura in cui vengono gerarchizzate le informazioni; se desidero leggere qualcosa di generale cercherò probabilmente un testo che riporta nel titolo l'argomento di mio interesse, se cerco una opera specifica apriro tutti i testi possibili per vedere tra i capitoli se qualcuno tratta di quell'opera, oppure, non trovando nulla tra i capitolo potrei arrivare a consultare i paragrafi. In nessuno dei due casi leggerei gli interi testi alla ricerca di ciò che mi interessa, cosa che invece potrebbe diventare utile e necessaria nel caso volessi sapere come per esempio in due paesi diversi viene trattato lo stesso argomento. E' piuttosto evidente come in tutti questi casi l'interesse è per il contenuto ma non è possibile prescindere in una ricerca dagli elementi della struttura di esso. Fin qui, si badi bene la rappresentazione ancora non entra in gioco. Un titolo è un titolo a prescindere dal tipo di carattere usato in una particolare edizione o dal colore; lo stesso vale per i paragrafi, per le sintesi in quarta di copertina e per ogni elemento della struttura di un testo. Può aiutare ad individuarla, anzi il fine della rappresentazione nell'edizione di un testo è proprio quello di favorire la leggibilità, ovvero la percezione della sruttura e del suo rapporto con il testo; certamente serve anche a rendere un testo più accattivante di un altro ma sempre fatti salvi alcuni limiti, quando chiunque di noi legge un indice da per scontato che un font più grande, come un allineamento più a sinistra, indichi un capitolo e un font minore, o un allineamento più a destra, un paragrafo; se un editore invertisse questi criteri renderebbe illeggibile l'indice. Se tutti cominciassero ad utilizzare la grandezza dei font e lo spazio con una valenza esclusivamente estetica, in breve si perderebbe la possibilità di capire, anche se a grandi linee, il contenuto di un testo. Anche se di fronte alla realizzazione di un testo possono sembrare confusi, struttura e rappresentazione di un contenuto sono due cose assolutamente separate. |
|
Il computer è una macchina in grado di trattare
fisicamente soltanto lunghe sequenze binarie; sequenze
talmente lunghe che, con l'aumentare delle potenzialità
dell'hardware, è possibile ormai rappresentare qualsiasi
cosa, superando anche i limiti e spostandosi nel campo
della fantasia, del virtuale. Comunque qualsiasi cosa sia
visualizzata da un monitor, qualsiasi operazione viene
effettuata da un computer passa attraverso una serie di
filtri progressivi che la riducono dal linguaggio umano a
quello della macchina. La produzione di testi non sfugge
a questa regola, e nel tempo è stata risolta
sostanzialmente in due modi, attraverso gli ambienti di
word processing e attraverso i linguaggi di markup.
Nell'ambito di un discorso sull'ipertesto i word
processor assumono un rilievo minore perchè in genere,
essendo sistemi WYSIWYG (What You See Is What You Get)
utilizzano per la rappresentazione dei caratteri di
controllo invisibili proprietari che ne limitano la
portabilità e la riusabilità obbligando ad utilizzare
per la lettura lo stesso software usato per la scrittura.
I linguaggi di markup invece descrivono i meccanismi di
strutturazione e di rappresentazione del testo attraverso
dei linguaggi veri e propri che utilizzano delle
convenzioni spesso standardizzate e quindi utilizzabili
su più sistemi e derivano concettualmente dai sistemi
usati nelle tipografie per "marcare" le
porzioni di testo indicandone le caratteristiche. I
linguaggi di markup possono essere distinti in due
gruppi: La differenza tra i due stà nel meccanismo usato per definire la formattazione del testo ovvero la rappresentazione; i linguaggi di tipo procedurale indicano le procedure di trattamento del testo aggiungendo le istruzioni che devono essere eseguite per visualizzare la porzione di testo referenziata mentre i linguaggi di tipo descrittivo lasciano la scelta del tipo di rappresentazione da applicare al testo al software che di volta in volta lo riprodurrà. I linguaggi del secondo tipo risultano più vantaggiosi perchè, oltre a lasciare il focus della concentrazione sui problemi strutturali di leggibilità, prescindono in fase di lettura dal software con cui sono stati generati, sono in altre parole quelli che permettono di garantire una corretta separazione tra struttura e rappresentazione, che come si è visto, è uno degli aspetti più importanti da tenere in considerazione nella produzione di ipertesti. Tra i linguaggi del primo tipo ci sono lo Script, il TROFF, il TEX, tra quelli del secondo tipo SGML, HTML, XML. |
| L'idea che un formato aperto e standardizzato per il trattamento dei dati permettesse l'enorme vantaggio di scambiare e manipolare documenti strutturati è molto vecchia: risale agli anni sessanta, quando la Graphic Communications Association crea GenCode, ancor prima che l'IBM, per risolvere i problemi legati alla pubblicazione interna di manuali e specifiche di progetti, sviluppa il Generalized Markup Language (GML), basato su una sintassi molto semplice di tag, ovvero di marcatori contenuti tra <> in apertura e </> in chiusura. Agli inizi degli anni ottanta i rappresentanti degli sviluppatori GenCode e GML si uniscono per fornare l'American National Standards Institute (ANSI); il tentativo di standardizzare l'uso di markup per documenti porta nel 1986 a llo Standardized Generalized Markup Language (SGML) pubblicato come ISO 8879. Tra le varie aziende ed organizzazioni ad utilizzare SGML c'era anche il CERN, in Svizzera, dove alla fine degli anni ottanta Tim Berners-Lee, per costruire una applicazione ipertestuale prende da un DTD SGML del centro un assortimeno di tag, aggiungendovi poi l'ormai noto meccanismo di link. Nasce l'ormai arcinoto HTML che diventa il linguaggio di markup per le applicazioni Web nel momento in cui vengono fuori i browser. |
| Spesso le innovazioni tecnologiche rivoluzionarie, dopo un periodo in cui la loro forza sembra sconfiggere ogni dubbio, tendono ad invecchiare sotto i colpi del loro stesso successo. E' chiaro a tutti che non avrebbe senso oggi parlare delle potenzialità di internet e della sua struttura ipertestuale se non partendo dalla diffusione impressionante delle progressive standardizzazioni dell'HTML. Internet è solo un elemento del panorama della comunicazione e d'altra parte il suo successo è un fatto molto più complesso che non può essere spiegato soltanto con la sua struttura comunicativa estremamente potente e duttile al tempo stesso; probabilmente internet prima ancora che un enorme ipertesto è la libertà della piattaforma del protocollo TCP/IP che ha permesso di materializzare per la prima volta il sogno dell'interoperabilità, ma in questa sede si vuole fare un punto della situazione riguardo ai problemi che ormai internet palesa, sulle domande che si pongono alla tecnologia e sulle possibili soluzioni che sembrano individuarsi all'orizzonte. Anche il protocollo IP, forse uno degli standard più longevi della storia dell'informatica, è in corso di revisione e questo è forse l'immagine più evidente del salto che internet ha compiuto nel corso degli ultimi anni, ma il cambiamento che sta avvenendo a livello applicativo è molto più radicale: nuovi servizi premono per entrare ora che la diffusione ha raggiunto un livello tale da far considerare il mezzo come un mercato e nuovi utenti premeranno per essere connessi una volta che quei nuovi servizi saranno fruibili. In questo contesto è evidente come la semplice staticità degli standard fin qui definiti da fattore di successo tenda a diventare sempre più un peso che solo una maggiore duttilità dei nuovi standard può compensare. Per costruire e mettere in rete una pagina sono sufficienti pochissime nozioni e questo ha sicuramente favorito la diffusione perchè ha permesso il riversamento sui vari server sparsi per la terra di una quantità e di una varietà di informazioni che altrimenti non sarebbe stata possibile da immettere; ora però con il progressivo aumento della mole di documenti, la complessità è diventata tale che, quella stessa semplicità che permette a chiunque di diventare "editore" da fattore vincente rischia di diventare fattore che rallenta un ulteriore sviluppo, per il quale è richiesta maggiore affidabilità del mezzo e maggiore duttilità degli standard. I problemi più impellenti sono quello della crisi dei motori di ricerca e quello dell'aumento dei "dead link", i link scomparsi. Chiunque abbia almeno una volta compiuto una ricerca attraverso un motore si è potuto rendere conto che la cosa, a dispetto degli squilli di tromba degli entusiasti, è tutt'altro che banale: da una parte ci sono problemi nel riuscire ad individuare i documenti utili alle proprie esigenze, dall'altra spesso i siti sono costruiti in modo da non rendere molto facile trovare informazioni che si sa con certezza essere su quell'host, dall'altra ancora il rischio che di fronte ad un link che annuncia finalmente un sito pieno di informazioni interessanti, la risposta al click sia solo un messaggio di errore da parte del server. Tutto ciò è dovuto ad alcuni limiti insiti nel linguaggi che ha fatto dilagare il Web, Html, e non è difficile capire perchè. |
|
Il link, si è visto, è l'elemento chiave della
struttura ipertestuale. Da subito HTML attraverso
l'elemento A e il suo attributo HREF ha assicurato la
possibilità di saltare da un punto ad un altro del
documento o dell'intero Web, e già questo dal punto di
vista dell'accesso permette soluzioni infinite, con
l'unico limite della fantasia e del tempo speso dai
creatori di documenti per immaginare e realizzare i
collegamenti. Purtroppo però nel far questo ha
utilizzato solo una delle diverse tipologie di link, la
più semplice, quella del link unidirezionale in due
varianti, il link point to topics e quello point to
point. A proposito del link point to topics le specifice
dicono: "A link has two ends, called anchors, and a
direction. The link starts at the "source"
anchor and points to the "destination" anchor,
which may be any Web resource" (Un link ha due
estremi chiamati ancore ed una direzione. Il link parte
dall'ancora sorgente e punta all'ancora di destinazione,
che può essere una risorsa Web di qualsiasi genere). Per
quanto riguarda poi il link point to point, questo è di
fatto una semplice estensione del precedente: "The
destination anchor of a link may be an element within an
HTML document. The destination anchor must be given an
anchor name and any URI addressing this anchor must
include the name as its fragment identifier."
(L'ancora di destinazione di un link può essere un
elemento interno di un documento HTML. L'ancora di
destinazione in questo caso deve avere un nome ed ogni
indirizzo URI che punta questa ancora deve includere il
nome come identificativo del frammento). Se si pensa alla
varietà e alla duttilità che le diverse tipologie di
link assicurano alle applicazioni ipertestuali si capisce
immediatamente quanto già questa semplificazioni
rappresenti una limitazione per lo sviluppo di ambienti
complessi sul Web. C'è poi il grave problema dei link scomparsi. In questo caso non si tratta di una scelta dello standard quanto piuttosto di un "effetto collaterale" della struttura sintattica dell'elemento <A> in HTML. Questo elemento che indica la porzione di testo che attiva un link ha tra i suoi attributi HREF che è quello che specifica la locazione della risorsa Web di destinazione per mezzo del suo URI (Uniform Resource Identifiers). Questo vuol dire che l'indirizzo della risorsa di destinazione viene riportato esplicitamente nel documento HTML come valore dell'attributo di un elemento e non, come raccomanda la teoria ipertestuale all'esterno di esso, in un database o in un altro documento, ingenerando notevoli problemi di manutenzione. Infatti in caso cancellazione della risorsa di destinazione o anche di semplice modifica del suo path, diventa necessario modificare tutti i documenti che a quella risorsa avevano un riferimento se si vuole evitare di lasciare in giro testi contenenti link scomparsi. Se si considera la complessità e la vastità del Web, in cui spesso i documenti hanno collegamenti anche a risorse su server diversi, amministrati da persone che non sanno neppure chi e come ha costruito quei link, si capisce come anche volendo sarebbe impossibile arginare il problema dei link scomparsi semplicemente con il buon senso di modificare tutti i documenti che si sa essere collegati. Questo problema si può arginare solamente utilizzando nei documenti dei semplici identificativi contenuti fuori dal documento stesso, in archivi che, modificati in seguito ad un cambiamento dell'indirizzo della risorsa, aggiornano immediatamente tutti i collegamenti. |
|
Come si è visto la distinzione tra struttura e
rappresentazione è fondamentale per garantire una buona
fruizione delle informazioni tanto è vero che è alla
base della concezione dei linguaggi di markup di tipo
descrittivo, tra i quali c'è SGML di cui HTML
rappresenta di fatto una applicazione. Questa distinzione
è presente nelle specifiche di HTML ed infatti ci sono
dei tag che immediatamente rimandano a questa
distinzione. Innanzi tutto la netta separazione tra HEAD
e BODY, con le informazioni di supporto inserite nel
primo ma non visibili e il testo inserito nel secondo,
visibile a seconda del tipo di formattazione. A questa
concezione rimanda anche la presenza di una
gerarchizzazione progressiva degli Headings, da H1 più
grande fino ad H6 più piccolo con la differenza di
importanza resa immediatamente visibile dalla progressiva
diminuzione della grandezza del carattere. Il problema
però è che le specifiche non sono rigide e pur non
permettendo per esempio l'annidamento di un heading
superiore dentro uno inferiore, non impongono un
controllo di validazione da parte del browser creando di
fatto l'impossibilità di considerare le informazioni
come strutturate gerarchicamente. Certo probabilmente il
successo di questo linguaggio si deve proprio alla sua
semplicità, e all'assenza nei browser di un meccanismo
di convalida sintattica, ma alla lunga questa
caratteristica è risultata logorante, specialmente
perché molto spesso gli sviluppatori, concentrati sulle
esigenze estetiche hanno usato i tags senza tenere nella
minima considerazione il loro eventuale significato di
gerarchia. In pratica, a forza di usare tags con valenza
di struttura come fossero tags con valenza di
rappresentazione, la differenza, non sancita rigidamente
dalle specifiche, si è persa. D'altra parte inizialmente
HTML prevedeava l'inserimento di tag di struttura, quali
per esempio <P> per il paragrafo e tag di
rappresentazione, tipo <B> per il grassetto nello
stasso file e solo nelle ultime specifiche rilasciate dal
consorzio W3C è stata inserita la possibilità di usare
i fogli di stile (CSS - Cascading Style Sheet) ovvero
file separati nei quali definire la rappresentazione, in
modo di lasciare il documento HTML vero e proprio libero
di recuperare il suo valore di struttura. Tuttora la
rappresentazione può essere definita all'interno del
file HTML e tuttora persistono i problemi legati
all'assenza di vincoli del controllo formale da parte del
browser, ma è chiarissima la sterzata del consorzio
verso il ritorno ad una separazione più puntuale. In questo modo, si perdono molte delle potenzialità dei motori di ricerca, costretti a fare ricerche su tutto il testo a parità di importanza, proprio nel momento in cui la mole dei documenti in rete diventa tale da richiedere un meccanismo più puntuale. La divisione corretta fra rappresentazione e struttura ed un suo controllo formale garantiscono invece a qualsiasi software che analizzi il documento, concentrandosi su quest'ultima, non solo di individuare nel testo eventuali ricorrenze, ma anche di stabilirne la rilevanza in base alla posizione nella gerarchia testuale. Purtroppo però la confusione tra tag di struttura e tag di rappresentazione non permette questa possibilità e obbliga a ricerche che spesso restituiscono migliaia di documenti senza dire nulla della rilevanza del termine invocato all'interno della gerarchia logica di questi. |
|
Rispetto alle esigenze cui internet come nuovo mezzo
di comunicazione di massa deve rispondere, se non
nell'immediato, almeno in prospettiva ci sono quindi
alcuni problemi "tecnici". I più rilevanti
sembrano i limiti di indirizzamento del protocollo IP,
quelli relativi alla banda a disposizione dei vari utenti
sparsi per il mondo e quelli relativi ai limiti dell'HTML
come linguaggio universale per la costruzione di
applicazioni sul Web. I primi due per quanto interessanti
esulano dal contesto di questo lavoro e basta quindi
accennare al fatto che su entrambi i fronti sembra vicino
il momento della soluzione, mentre invece la situazione
dei protocolli o dei linguaggi per applicazioni sul Web,
che ci riguarda più da vicino, e' ben piu' caotica e
sicuramente meno vicina ad una soluzione. Da tempo HTML
non rispondeva alle esigenze degli sviluppatori di
applicazioni Web; da un lato la pressione di richieste
sempre più complesse, aumentata con l'aumento della
penetrazione di internet e dei servizi che si affacciano
sulla rete, dall'altra l'effettiva fattibilità di
applicazioni così complesse sempre più sostenuta dallo
sviluppo dell'hardware e dal crollo dei suoi costi. Un
linguaggio nato sostanzialmente per un publishing
elementare si trovava a dover assicurare potenzialità
impensabili al momento della sua nascita e così, non
potendo, lasciava il campo allo sviluppo di tecnologie
parallele che potessero assicurare in fondo la sua
sopravvivenza. Tra nuovi linguaggi tipo Javascript e
plugin tipo Shockvawe o Acrobat reader in pratica HTML è
diventato pian piano un assemblatore di tecnologie
piuttosto che un linguaggio vero e proprio e questo ha
comportato anche problemi di portabilità delle
applicazioni Web perchè tutte queste nuove tecnologie
non sono standard bensì soluzioni proprietarie più o
meno diffuse che necessitano per essere utilizzate di
software particolari o di particolari versioni di esso.
Tutto ciò è lontanissimo dalla filosofia iniziale ma
anche dalla tendenza, tipica dell'informatica distribuita
che in questo periodo si stà affermando, a costruire
ambienti standard in grado di permettere la costruzione
di applicazioni portabili a prescindere dal sistema
operativo o dal tool di sviluppo. Documenti che per
essere letti necessitano di Explorer o di Netscape e che
nel caso siano visualizzati in modo alternativo risultano
diversi o addirittura illegibili, documenti che
contengono file che obligano a scaricare una miriade di
programmi, siti ottimizzati per certe versioni di browser
e non per altre, documenti che non sono accessibili per
chi ha versioni troppo vecchie; in altre parole il mondo
delle applicazioni Web è diventato una sorta di Babele
in cui solo per orientarsi diventa necessaria una certa
competenza e si sa, le barriere di conoscenza all'entrata
non favoriscono certo la diffusione di una tecnologia. Se
si considera che la diffusione delle tecnologie su rete
vive di circoli virtuosi, si intuisce quanto il problema
sia delicato e rilevante nel momento in cui internet si
candida a diventare mezzo di massa. Dall'altra parte della luna rispetto ai problemi di portabilità, si trovano quelli generati dalla rigidità di HTML, linguaggio di cui un apposito ente, il consorzio W3C, rilascia periodicamente delle specifiche sulle quali vengono progettati i browser e i tool di sviluppo. In questo senso HTML è propriamente un liguaggio laddove invece SGML è più precisamente un metalinguaggio; questo vuol dire che, mentre nel caso di HTML lo sviluppatore è vincolato all'uso dei tag definiti nelle specifiche rilasciate dal consorzio, nel caso di SGML, come di ogni metalinguaggio per mezzo della sintassi definita nelle specifiche può definire i tag a suo piacimento. Nel primo caso ne derivano vantaggi di semplicità perchè l'attività dello sviluppatore si limita alla stesura, spesso attraverso tools WYSIWYG, del testo del documento o in senso più lato del suo contenuto, mentre nel secondo caso derivano vantaggi enormi di duttilità nel trattamento di dati, cosa che in caso di applicazioni Web complesse che comunicano con altre applicazioni o con basi di dati, risulta assolutamente vantaggioso, permettendo la definizione di tag di cui è possibile controllare e vincolare anche il contenuto. Non è d'altra parte un caso che per la creazione di siti dinamici, in grado di interagire con dati, come per esempio un catalogo che permette ordinazioni, sia necessario l'uso di tecnologie esterne alle specifiche HTML, come il caso delle CGI, di Javascript o addirittura di Java. |
|
I metalinguaggi di markup di tipo descrittivo offrono
rispetto ad HTML sostanzialmente tre vantaggi,
l'estensibilità che permette la definizione di set
personalizzati di tag, la salvaguardia degli elementi
strutturali definiti in un file esterno chiamato Document
Type Definition (DTD) e la validazione per la quale ogni
documento passa attraverso un controllo che ne attesta la
conformità alle regole definite nel DTD. Già SGML offre
questi vantaggi, ma in un ambiente diffuso come quello
del Web questo linguaggio è stato considerato inadeguato
a causa della sua eccessiva complessità che ne poteva
frenare la penetrazione. Per questo il World Wide Web
Consortium (W3C) ha optato per la definizione di un
linguaggio che, pur mantenendo tutti i vantaggi descritti
sopra, fosse più semplice e quindi più adatto alla
varietà di sviluppatori di documenazione su internet;
così dopo un'attività durata circa un anno, nel
febbraio del 1998 ha rilasciato la versione 1.0 delle
specifiche di XML, che sta per Extensible Markup
Language. Il progetto prevede la definizione di un gruppo
di specifiche, che raccogli oltre a XML anche quelle per
la gestione dei link (XLL) e per la rappresentazione
(XSL). Piuttosto che di un linguaggio si tratta quindi di un metalinguaggio, ovvero di un linguaggio per la definizione di altri linguaggi o applicazioni, come successo per esempio con Resource Description Framework (RDF) e Channel Description Format (CDF), due linguaggi già ampiamente diffusi sul Web. XML nasce per riportare la realizzazione di documenti per il Web alla normale separazione struttura e rappresentazione dei dati che con il tempo, nella programmazione HTML, si erano confusi. Si occupa infatti esclusivamente della definizione dei tag da usare e della loro strutturazione. Separando la struttura e il contenuto dalla presentazione, lo stesso sorgente, scritto una sola volta, può essere visualizzato in vari modi diversi: scritto su di un monitor come attraverso audio da un cellulare. Questo vuol dire che un documento scritto secondo queste specifiche può essere veicolato attraverso device diversi non necessariamente presi in considerazione all'atto della sua stesura. XML quindi, pur essendo nato propriamente per il mondo Web, ha senso anche fuori da questo, comunque e dovunque qualcuno voglia produrre un documento, a prescindere dal mezzo trasmissivo. Un tool per leggere un documento XML consta di due parti: il Parser che esegue il controllo semantico e gestisce gli errori e il Processor che, utilizzando un altro file in cui è definita la formattazione dei vari tag, visualizza il documento. Già da questa dinamica si capisce come la separazione fra struttura e rappresentazione, che come si è visto è uno degli aspetti chiave della buona costruzione di un ipertesto, sia garantita attraverso la separazione fisica dei dati che governano i due aspetti ed addirittura attraverso la separazione anche dei linguaggi. XML infatti non dice nulla della rappresentazione che può essere gestita attraverso un altro linguaggio: XSL. Il controllo da parte del Parser avviene su due livelli: valutando la conformità del documento al DTD di riferimento prima e, in caso di non conformità eseguendo un altro controllo relativo però alle regole generali della sintassi XML. Proprio per via di questo doppio controllo i documenti possono essere di due tipi, Valid e Well-Formed. Valid sono quelli conformi al proprio specifico DTD, Well-Formed quelli conformi alla sintassi generale. |
|
In XML si possono generare documenti Well-Formed
oppure documenti Valid, diciamo per semplicità Ben
formati e Validi; la differenza stà nella conformità
dei validi ad un DTD specifico e dei ben formati alle
generiche specifiche XML (presenza dei tag di chiusura a
meno di empty element comunque vincolati, differenza tra
maiuscolo e minuscolo e controllo dell'indentamento dei
tag). Questo significa che, mentre per sviluppare un
documento ben formato è sufficiente scrivere il file
XML, nel caso del documento valido è assolutamente
necessario scrivere anche un secondo file, appunto il
DTD. Entrambi i tipi di documento iniziano nella prima
riga con la "Document Type Declaration" che non
ha tag di chiusura per cui per esempio potrebbe essere
del tipo: <?XML version="1.0" standalone="yes" encoding="UTF-8"?>
Come si è visto quindi con la "Document Type Declaration" sostanzialmente si dichiara il riferimento del documento alle specifiche XML e se questo fa riferimento o meno ad un DTD specifico, ovvero se è Valido o semplicemente Ben-Formato. |
|
Il DTD (Document Type Definition) contiene le regole
che definiscono i tag usati nel documento XML, ovvero in
pratica definisce la struttura del documento; per questo
sebbene non sia obligatorio è consigliabile, per
chiarezza, usarlo sempre. XML prevede la possibilità di
definire la struttura del documento non solo in un file
esterno bensì anche al suo interno, pertanto di fatto i
due esempi di file XML che seguono danno lostesso
risultato: <?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8" ?> Nel primo caso il documento fa riferimento per la struttura ad un file esterno (hello.dtd), mentre nel secondo caso il contenuto di questo è inglobato dentro il documento stesso. In ogni caso la Document Type Definition, è contenuta all'interno della "Document Type Declaration", impostata dal tag <DOCTYPE>, e quando ne è inglobata si apre con il carattere "[" e si chiude con il carattere"]". In ogni caso nell' esempio è: <!ELEMENT greeting (#PCDATA)> In questo caso ELEMENT definisce "greeting" come un elemento, che potra' essere quindi usato come tag nel documento e che contiene del testo (PCDATA=Parsed Character Data) |
|
L'elemento è il blocco base del documento XML.
Abbiamo visto come uno dei vantaggi di questo linguaggio
si la possibilità di definire tag propri; questo è
possibile proprio per mezzo della dichiarazione di
elemento, che avviene nel DTD. Nel documento XML
l'elemento è delimitato da un tag di apertura e da un
tag di chiusura o da un tag di elemento vuoto in vaso
appunto di elemento vuoto. <greeting>Hello, world!</greeting> In questo caso abbiamo l'elemento "greeting" che contiene la porzione di testo "Hello, world!". Da notare che, a differenza di HTML gli elementi sono case sensitive per cui <greeting> non ha lo stesso valore di <GREETING>. <linea/> Questi è invece un esempio di elemento vuoto, che va
usato nel caso di elementi che non debbano avere
contenuto ed in cui la barra, a differenza del tag di
chiusura è posta dopo il nome dell'elemento. <!Element [nome_elemento] ([elenco_sottoelementi])> per cui nell'esempio sopra avremo: <!ELEMENT greeting (#PCDATA)> |
|
Gli attributi permettono l'aggiunta all'elemento di
informazioni addizionali. Già HTML prevedeva l'uso di
attributi degli elementi, per esempio nel caso di: <IMG align=center ...> "align" altro non e che un attributo dell'elemento IMG. In linea di massima però l'uso degli attributi in HTML descrive la rappresentazione dell'elemento, e come abbiamo visto, la confusione tra i due livelli, quello della struttura e quello della rappresentazione, in XML non è possibile. In realtà infatti gli attributi degli elementi in XML sono vere e proprie informazioni addizionali ancora della struttura del documento. Poniamo il caso di dover definire un DTD per documenti relativi ad una libreria. Sicuramente l'elemento base è il libro ma i libri possono essere rilegati con copertina dura oppure in brossura; a questo punto la scelta sarà tra la definizione di due elementi distinti, "libro_duro" e "libro_brossura", e la definizione di un unico elemento LIBRO con attributo RILEGATURA che potrà assumere uno tra i due valori "duro" e "Brossura". Nel caso quindi di un edizione rilegato in brossura del "Decameron"avremo quindi nel documento un tag del genere (da notare che il valore di un attributo deve stare necessariamente tra doppi apici): <LIBRO RILEGATURA="brossura">Decameron</LIBRO> Gli attributi vengono dichiarati nell'"attribute list" (<ATTLIST>) che contiene il nome dell'elemento cui gli attributi si riferiscono, il tipo di dati, la lista dei valori degli attributi stessi e il valore di default. In questo caso, nel DTD, dopo la dichiarazione dell'elemento LIBRO si avrà un' "attribute list" del genere: <!ATTLIST LIBRO RILEGATURA (duro|brossura) "duro"> in cui ATTLIST definisce la lista di attributi, LIBRO è il nome dell'elemento cui è riferito l'attributo, RILEGATURA l'attributo, "duro" e "brossura" i due valori che può assumenre e "duro" quello di default. L'attributo deve avere poi dei valori che indicano al parser come comportarsi durante il controllo di conformità: #REQUIRED indica che l'attributo deve avere necessariamente un valore ogni volta che è usato l'elemento, #IMPLIED indica che l'attributo può non avere valore, #FIXED indica che l'attributo può non avere valore ma se ce l'ha deve necessariamente essere quello di default. |
|
Un documento XML non deve necessariamente essere
composto da un solo file, ma può assemblare al suo
unterno pezzi diversi chiamati "entities",
entità, le quali possono contenere sia dati
convalidabili, che sono i markup e tutto quanto è
definito da un markup, sia dati non convalidabili, che
sono quelli cui non è applicabile un markup. Le entità
permettono di creare dei riferimenti a dati esterni, ad
altri documenti, o anche a porzioni di testo , a patto
che ci sia una dichiarazione nel DTD. Le entità possono
essere quindi interne od esterne a seconda di dove
fisicamente si trovano i dati rispetto al documento.
Pertanto nel caso di una dichiarazione del tipo: <!ENTITY decameron "G.Boccaccio, Il Decamerone, Giunti, Firenze, 1987"> all'interno del documento avro' una entità interna, che quindi può essere paragonata ad una vera e propria variabile, mentre in una dichiarazione del tipo: <!ENTITY decameron "./decam.txt"> avrò un'entità esterna, perchè c'è un riferimento ad un file diverso (anche su una macchina remota). In ogni caso il concetto chiave è che dopo la dichiarazione nel DTD l'entità è utilizzabile in tutti i documenti che a quel DTD fanno riferimento, semplicemente per mezzo del suo nome. Molto evidente il vantaggio della costruzione di un documento per mezzo di entità; è possibile infatti così definire la struttura nel DTD, lo scheletro nel documento con la possibilità di riempirlo con contenuti presi dall'esterno. In questo modo anche il contenuto, oltre che la rappresentazione, diventando praticamente un modulo a parte, risulta maggiormente manutenibile. |
|
Essendo XML un linguaggio che si candida a migliorare
lo stato della riusabilità delle applicazioni Web
attraverso un approccio modulare, e chiaro che esiste un
problema di riconoscimento e di collisione. Il parser,
così come il processor deve assolutamente essere in
grado di gestire eventuali ambiguità, il cui rischi è
inevitabilmente insito nell'approccio modulare. Per
questo sono nati i Namespace che permettono la creazione
e l'uso di tag ambigui, ovvero con lo stesso nome, ma in
riferimento a significati ed ambienti diversi utilizzando
costrutti con nomi non equivoci. Si pensi per esempio a
documenti di una rivista in cui la parola
"titolo" a seconda del contesto può
referenziare il titolo di un articolo, ma anche il ruolo
del giornalista all'interno della struttura aziendale. E'
possibile creare due tag, chiamandoli entrambi
<TITOLO>, utilizzandoli poi nel documento senza
correre il rischio che il parser ed il processor li
confondano. Il nome non equivoco si ottiene associando
delle URI ad elementi che fungono da ambiente per cui la
seguente definizione: <X xmlns:edi='http://ecommerce.org/schema'></X> applica l'ambiente "edi", rappresentato dal comando "http://ecommerce.org/schema", all'elemento <X>. La dichiarazione di Namespace si applica all'elemento all'interno del quale c'è la dichiarazione e a tutti gli altri elementi contenuti all'interno di quello a meno di nuova dichiarazione di Namespace. Pertanto nel caso precedente tutto quello che sarebbe indentato dentro il tag <X> farebbe parte del Namespace "edi", mentre nel caso seguente: <bk:book xmlns:bk='urn:loc.gov:books' all'interno del contesto <bk:book> si alternano due Namespace, "bk" e "isbn" ed ognuno vale fintanto che non ne è invocato un altro. |
Si è detto più volte della rappresentazione tra
struttura e rappresentazione tipica di XML. Una volta
definito il DTD, ovvero la struttura del documento, e
quindi messo il parser in condizione di effettuare un
controllo sintattico, è assolutamente necessario
associare al documento stesso un foglio di stile che ne
descriva le regole relative alla rappresentazione. Queste
non devono essere necessariamente univoche, ma devono
poter variare al variare del dispositivo di output o
anche in seguito all'interazione dell'utente. In linea di
massima, non dicendo XML nulla delle regole di
rappresentazione, si potrebbe usare una sintassi
qualsiasi di stile; in effetti, una volta rilasciate a
Febbraio le specifiche di XML, per lungo tempo si è
discusso su quali potessero o dovessero essere i
linguaggi candidati a rappresentare le informazioni
strutturate per mezzo di XML. Le possibilità più
credibili sembravano e sembrano tuttora le
seguenti:
Ognuno di questi linguaggi presenta vantaggi e svantaggi; probabilmente alla fine la spunterà quello che riuscirà ad avere la maggiore penetrazione nell'immediato, cosa non facile da prevedere vista la caoticità che caratterizza in questo ultimo periodo il Web ed in particolare i nuovi linguaggi applicativi. Per quanto riguarda CSS è una tecnologia, rilasciata dal consorzio W3C per HTML, già diffusa e quindi sperimentata e conosciuta, il che è sicuramente un vantaggio notevole. Il suo limite e che non riesce a modificare notevolmente il documento, e quindi è "filosoficamente" un po' lontano dalle intenzioni iniziali dei creatori di XML. DSSSL sulla carta andrebbe bene: è una tecnologia ampiamente definita anche se non altrettanto diffusa. E' il linguaggi di stile di SGML e di questo eredita pregi e difetti, vale a dire la potenza e la difficoltà. Quest'ultima mal si addice ad un ambiente diffuso come quello del Web. Il consorzio W3C ha optato per implementare XML, una semplificazione per Web di SGML, considerato troppo complesso, per cui lo stesso ragionamento sembra doversi fare per DSSSL. Infine XSL, il linguaggio "proprietario" del progetto XML. Sulla carta dovrebbe raccogliere i pregi di CSS e quelli di DSSSL, ovvero unire la semplicità alla potenza. Una prima bozza di lavoro è stata rilasciata solo il 18 agosto del 1998 per cui è abbastanza presto per dare un giudizio, tanto più che nella bozza stessa si invita ad aspettare le prime specifiche ufficiali. Insomma XSL è sicuramente avvantaggiato a vincere la partita ma intanto i pochi software che permettono di visualizzare XML non lo possono utilizzare finchè non sarà definitivo. Infatti le differenze tra le proposte fatte nell'agosto del 1997, su cui si basa sostanzialmente questo documento, e la bozza dell'anno successivo sono notevoli e notevoli potrebbero essere ancora le differenze con le specifiche definitive. In linea di massima il consorzio si stà muovendo su tre livelli: sviluppare XSL, permettere nell'immediato una buona compatibilità con HTML e mantenere un rapporto stretto con DSSSL. I componenti principali di XSL sono:
L'associazione tra un documento XML e un foglio di stile avviene nel prologo del documento per mezzo dell'istruzione "xml:stylesheet", che ha come pseudo-attributi: href (necessario), type (necessario), title (opzionale), media (opzionale), charset (opzionale): <?xml:stylesheet href="stile.xsl" title="Compact" type="text/xsl"?> Nell'esempio al documento si associa un foglio di stile XSL ma la stessa sintassi può essere usata per associare altri tipi di fogli di stile. E' possibile anche associarte al file XML un foglio di style alternativo attraverso l'istruzione "xml:alternate-stylesheet" che mantiene la stessa sintassi. |
|
Con XSL l'output formattato è creato attraverso una
operazione in due tempi: la creazione prima di una
struttura ad albero in cui viene associato ad ogni
elemento lo specifico stile, e l'elaborazione definitiva
di questa struttura ad albero. L'associazione tra gli
elementi e la loro rappresentazione nel foglio di stile,
che rappresenta il primo blocco fondamentale di XSL è
specificato dalle "Construction Rules". Una
Construction Rule consta di due elementi logici, un
Pattern che identifica l'elemento o il gruppo di elementi
del sorgente per cui valgono quelle regole, ed una Action
che specifica l'albero da costruire quando il processor
incontra quell'elemento o uno di quegli elementi. 4.2.1.1 - XSL: Construction Rules: Pattern Il pattern identifica l'elemento del sorgente cui applicare la regola di costruzione, nel modo più semplice con il nome come valore dell'attributo type del tag <target-element>. Una Construction Rule contiene almeno un target element per cui il caso più semplice è il seguente: <target-element type="titolo"/> in questo esempio l'elemento "titolo" viene esclusivamente definito come destinatario della regola, a prescindere dalla sua posizione all'interno del documento, ovvero dovunque si trovi. Oltre al nome il pattern può identificare gli elementi cui applicare la regola anche in modo più complesso, ovvero a seconda del suo contesto specifico in base ai rapporti di ascendenza e discendenza con altri elementi, ad eventuali "wildcard" in questi rapporti,agli attributi, alla posizione rispetto ad elementi fratelli. I rapporti gerarchici vengono definiti per mezzo dell'elemento <element>, il quale ha gli stessi attributi dell'elemento <target-element> ma non indica l'elemento cui applicare la regola, bensì quello che rappresenta il contesto superiore dell'elemento cui applicare la regola. Pertanto a differenza dell'esempio di prima, in questo caso: <element type="capitolo"> la regola viene associata non più a tutti gli elementi "titolo",ma solo a quelli che hanno come ascendente "capitolo". Ovviamente questo permette la definizione di regole rappresentative diverse per lo stesso elemento in base alla sua posizione nella gerarchia struturale del documento. Nel seguente esempio l'elemento "titolo" ha un pattern diverso, e quindi una diversa rappresentazione, a seconda che si trovi indentato dentro l'elemento "capitolo" o dentro l'elemento "paragrafo" <regola> <regola> L'elemento <element> sprovvisto dell'attributi type, che normalmente definisce l'ambito di applicabilità, e l'elemento <any> sono detti wildcard. Il primo permette di associare il "target-element" alla regola qualora questo sia figlio di un elemento qualsiasi figlio a sua volta dell'elemento definito come padre, in un rapporto di terzo livello. Il secondo fa sostanzialmente la stessa cosa con la differenza che il target-element può trovarsi a qualsiasi livello di gerarchia. Ecco due esempi per questi due casi. <element type="capitolo"> <element type="capitolo"> Nel primo esempio la regola è applicabile agli elementi "titolo" figli di un qualsiasi elemento figlio di "capitolo", nel secondo caso è invece applicabile agli elementi "titolo" che siano figli di un elemento che si trova ad un qualsiasi livello di gerarchia rispetto all'elemento "capitolo". E' possibile poi vincolare l'associazione del pattern all'elemento in base al valore assunto da un attributo dell'elemento stesso: <target-element type="capitolo"> In questo caso la regola è applicata solamente agli elementi "capitolo" il cui attributo "numero" abbia valore "primo". Nel caso il valore dell'attributo has-value sia "yes" allora la regola si applica all'elemento a condizione che l'attributo abbia un valore qualsiasi e non si abbia qualora nopn abbia nessun valore. Pertanto nel caso: <target-element type="capitolo"> come si è detto l'applicabilità della regola all'elemento "capitolo" dipende dalla presenza o meno di un generico valore associato al suo attributo "numero". 4.2.1.2 - XSL: Construction Rules: Action Una volta identificati i pattern associati agli elementi viene invocata la seconda parte della Costruction Rule, chiamata Action, al termine della quale viene generata la struttura del "Flow object", ovvero la struttura del documento e insieme le regole per la formattazione. La action comprende due tipi di elementi: flow objects and "XSL processing elements". I flow objects, che XSL deriva quasi direttamenta da DSSSL definiscono la formattazione, mentre i processing element sono elementi di controllo. I flow object sono molto numerosi e tra gli altri i più comuni sono:
Le caratteristiche dei flow object permettono di controllare la presentazione in quest modo: <titolo L'esempio genererebbe un tag titolo spaziato 12 punti sopra e 36 sotto, grande 24 punti e in grassetto. Le caratteristiche dei flow object possono essere ereditate o meno dagli oggetti figli. Gli alti elementi dell'action, i processing elements servono per definire e controllare azioni relative al processo del documento, ovvero contengono informazione sul come applicare le action al pattern. Tra questi i più comuni sono:
|
|
Per mezzo delle "Style Rule", definite dal
tag <style-rule> è possibile attribuira ad un
elemento più di una regola di formattazione. Come le
construction rule, le style rule sono composte da pattern
e action ma la differenza stà nel fatto che non generano
un flow object e che si applicano a cascata su tutti gli
elementi figli. Pertanto in un caso del genre: <style-rule>
all'elemento titolo si applica sempre un colore rosso, a prescindere da dove sia, pewr cui poi nelle successive construction rule non è più necessario definire il colore. |
I Named Style sono dei gruppi di regole definiti da un nome che, richiamato come valore dell'attributo "use" durante la definizione di un action permette l'applicazione a quell'elemento delle regole contenute nel gruppo. Pertando definendo in questo modo il Named Style "gruppo": <define-style
name="gruppo" questo può essere usato se si vuole rappresentare qualche elemento con quelle caratteristiche scrivendo semplicemente: <paragraph use="gruppo"> Le macro, definite per mezzo del'elemento <define-macro> permettono la costruzione di flow object complessi, mentre con <define-script> è possibile associare il risultato di una funzione ed usarlo per gestire dei controlli. |
Anche per quanto riguarda XLL, il linguaggio dedicato
allo sviluppo degli hyperlink XML, la situazione è
ancora lontana dall'essere sufficientemente definita. La
prima bozza è dell'aprile 1997 ed in seguito sono stati
anche redatti i principi generali cui il linguaggio
dovrà rispondere, che si rifanno principalmente ad HTML,
ad Hytime e a TEI. Da subito è stato chiarito come,
sulla base della tipologia del link unidirezionale
affermatasi insieme ad HTML, l'idea fosse quella di
svilluppare tutte le tipologie di link che i sistemi
ipertestuali nel tempo avevano implementato. Il
linguaggio è diviso in due sottogruppi, XPointer e
XLink:
|
|
La Microsoft, tra tutte le Società è quella che
probabilmente sta spingendo maggiormante
sull'acceleratore del progetto XML. In quest'ottica ha
già ha sviluppato due parser XML che si integrano con il
suo browser e una serie di controlli ActiveX dedicati al
trattamento di documenti XML, tra i quali in particolare
MSXML che al momento è forse l'unico software relamente
utilizzabile in rete. Inoltre è stata la prima azienda a
sviluppare una applicazione sulla base delle specifiche
XML. Si tratta di Channel Definition Format (CDF),
il linguaggio su cui si basa il sistema di push integrato
in Explorer. La stessa Microsoft, insieme a Marimba, ha
sottoposto al W3C un'altra applicazione XML, Open
Software Description (OSD), che permette di
descrivere oggetti software scambiati in rete. Anche
Netscape, che inizialmente non aveva dimostrato molto
interesse verso XML, sembra essere ritornata sui suoi
passi. La versione 5 del browser Navigator dovrebbe
contenere un processor in grado di leggere e formattare i
file XML Comunque sembra abbastanza chiaro che la
prospettiva dei software per la navigazione della rete
punta in quella direzione, per cui non è difficile
ipotizzare una piena implementazione di XML nei browser
di entrambe le aziende. In attesa del rilascio di Processor in grado di interpretare in modo nativo documenti XML (vincolato di fatto all'attesa delle specifiche stabili di XSL, il linguaggio relativo alla rappresentazioen sul quale si fonda un browser) ch vuole cominciare a realizzare documentazione con questa tecnologia l'unica soluzione consiste nell'utilizzazione di appositi browser SGML, magari integrati nei tradizionali programmi di navigazione. Attualmente sul mercato esistono sostanzialmente tre Software: Panorama, prodotto dalla SoftQuad, una delle aziende leader nel settore SGML, Multidoc PRO, della finlandese Citec e Jumbo, una applicazione Java usata per Chemical Markup Language, un'applicazione specifica di SGML. Panorama è disponibile in due versioni, una commerciale e l'altra gratuita. La versione commerciale, a sua volta, consiste di due moduli: Panorama Publisher, un browser stand-alone dotato di strumenti per la creazione di fogli di stile e reti ipertestuali tra più documenti; Panorama Viewer, un plug-in per Netscape ed Explorer che può solo visualizzare i documenti (di quest'ultimo viene distribuita una versione di prova, con alcune limitazioni funzionali, sul sito della SoftQuad). La versione gratuita è invece basata sulla release 1 del browser ed è reperibile dal sito Web della OCLC all'indirizzo. Multidoc Pro, è disponibile solo in versione commerciale, ma chi è interessato può scaricarne una versione funzionante per tre settimane presso il sito della Citec. Jumbo è disponibile in versione freeware presso il sito della "Venus". Per quanto riguarda i parser il panorama è molto più variegato. A parte i software che permettono anche la visualizzazione, di cui si è parlato, che ovviamente prima eseguono il controllo formale, esistono in versione freeware molti parser, tra i quali vanno ricordati Sax della "Microstar Software Ltd.", XML for Java da IBM AlphaWorks, TclXML. Infine i tool di sviluppo. Recentemente Microsoft ha rilasciato la prima release di un tool per la costruzione di file XML; si chiama "XML Notepad" ed è disponibile freeware nel sito della società Americana. Anche la "Arbortext", che da tempo produce software per SGML ha implementato un tool di sviluppo "XML Styler", ed infine anche la "Vervet Logic" commercializza un tool, "XML Pro". Entrambi questi ultimi due sono pero' disponibili freeware solo in una versione demo priva di alcune funzionalità fondamentali. |
Al momento non esiste alcun modo per produrre e
pubblicare sul web attraverso XML senza utilizzare
software creato per altre tecnologie. Questo perchè di
fatto non esiste ancora un software XML degno di questo
nome, ovvero un Processor che sia in grado di
visualizzare un file XML secondo quanto espresso nei
principi base del progetto del consorzio W3. Abbiamo
visto però come il panorama del software sia tutt'altro
che desolante, e come sia caratterizzato da una certa
dinamicità. Purtroppo questa dinamicità si sviluppa
sostanzialmente sul lato Parser, ma in fondo questo è
abbastanza ovvio se si considera che la parte
strutturale, che è quella che permette il controllo di
validazione, è l'unica in cui sono state rilasciate
specifiche stabili sulla base delle quali poter
implementare del software. La situazione è quindi tale
per cui chi vuole sperimentare XML, non ha difficoltà a
trovare tools di sviluppo e parser, mentre sicuramente
incontrerà maggiori problemi per quanto riguarda la
visualizzazione del lavoro svolto. In attesa di un
Processor o di un browser che supporti completamente XML
è possibile sostanzialmente seguire tre strade:
Nel primo caso, essendo XML un sottogruppo di SGML, non vi sono problemi per quanto riguarda il parsing e la strutturazione del documento, ma ovviamente il discorso cambia per quanto riguarda l'aspetto della rappresentazione. In altre parole non è possibile utilizzare XSL. Nel secondo caso abbiamo diversi vantaggi, ovvero la compatibilità assoluta con tutto quanto si trova già sul web senza la perdita dei vantaggi che XML assicura e il maggiore controllo della parte relativa alla visualizzazione attraverso l'uso della tecnologia CSS, oltre che la legibbilità attraverso semplice browser; d'altra parte però, pur essendo una moldalità ottima per una fase di passaggio, è pur sempre lontana dalla filosofia di partenza del progetto XML, che prevede l'utilizzo diretto di XML sul web, perchè comunque deve sempre tener conto dei limiti di HTML. La terza possibilità è in pratica uno sviluppo della seconda: infatti richiamando all'interno di un file HTML l'ActiveX MSXML e dandogli gli estremi del file XML e del foglio di stile, si realizza on-line quello che nel secondo caso si realizzava off-line, ovvero, il controllo di validazione, e la costruzione di un file HTML frutto dell'applicazione del foglio di stile (in questo caso si puo' usare XSL che microsoft ha proposto al consorzio). Nella demo che segue viene utilizzato questo metodo per due motivi, perchè non necessita l'installazione e la conoscenza di software oltre ad Explorer e perchè permette di visualizzare i passaggi senza dover ogni volta "pregenerare" i file HTML. |
|
Come si è visto un Processor vero e proprio in grado
di mandare direttamente in output un file XML non esiste
ancora, ed è quindi necessario per il momento
appoggiarsi ad altre tecnologie. In questa demo verrà
utilizzato un ActiveX Microsoft che inserito in una
pagina HTML la compone dinamicamente prendendo come input
file XML e XSL. Per questi va comunque chiarito che la
sintassi XSL utilizzata da questo ActiveX non è quella
delle ultime raccomandazioni del consorzio W3C bensì
quella della proposta dello scorso anno. Va premesso che
l'ActiveX gira esclusivamente su Windows 95 e NT con
Internet Explorer 4.0 o successive release. Nel corso
della demo le sarà possibile visualizzare il risultato
dei singoli passi cliccando il bottone in fondo alla
pagina, ma sara' anche possibile copiare ed incollare via
via le stringhe.Per renderle più visibili, d'ora in poi
userò il colore rosso per le stringhe da copiare e
incollare. Vediamo allora per prima cosa come deve essere usato questo ActiveX per creare la pagina HTML che poi sarà quella effettivamente usata dal browser per visualizzare la demo. L'ActiveX non deve essere installato e va richiamato inserendo nell'HEAD del documento HTML il seguente <OBJECT>: <OBJECT ID="XSLControl"
CLASSID="CLSID:2BD0D2F2-52EC-11D1-8C69-0E16BC000000"
codebase="http://www.microsoft.com/xml/xsl/msxsl.cab"
style="display:none">
</OBJECT>
Questo comando no fa altro che richiamare ed installare automaticamente il file. La prima volta che si lancia il file che contiene l'ActiveX avviene un download che impiega circa 30 secondi. Sia il CLASSID che il codebase sono sempre quelli per cui la cosa migliore è cominciare copiando le stringhe incollandole nel proprio file HTML. A questo oggetto vanno passati due parametri, che rappresentano il file XML da processare e il foglio di stile XSL da usare per la formattazione. Entrambi questi valori sono quindi variabili al variare dei file da utilizzare. In questo daso saranno chiamati "esempio.xml" ed "esempio.xsl", così come il file HTML sarà chiamato "esempio.htm". Tutti e tre, a meno di uso copia e incolla possono perciò essere modificati. Alla fine pertanto l'oggetto sarà così definito: <OBJECT ID="XSLControl"
CLASSID="CLSID:2BD0D2F2-52EC-11D1-8C69-0E16BC000000"
CODEBASE="http://www.microsoft.com/xml/xsl/msxsl.cab"
STYLE="display:none">
<PARAM NAME="documentURL" VALUE="esempio.xml">
<PARAM NAME="styleURL" VALUE="esempio.xsl">
</OBJECT>
L'Activie ha una proprietà "HtmlText" che processa il file XML secondo le definizioni contenute nel file XSL e le trasforma in una stringa HTML. Per attivare questa proprietà va inserita, sempre nell'HEAD del documento la seguente istruzione: <SCRIPT FOR=window EVENT=onload>
var xslHTML = XSLControl.htmlText;
document.all.item("xslTarget").innerHTML = xslHTML;
</SCRIPT>
Infine l'elemento xslTarget definito sopra come destinatario del risultato del processo va inserito nel BODY del documento: <DIV id=xslTarget></DIV> |
|
Abbiamo visto come i documenti XML siano di due tipi,
ovvero ben formati e validi, la cui differenza sta nella
presenza o meno di un DTD. Cominciamo a vedere i primi
passi nella costruzione di un documento ben formato,
ovvero di un documento che, non facendo riferimento ad un
aprticolare DTD, deve semplicemente sottostare alle
regole base della sintassi XML ovvero la correttezza
della dichiarazione, la presenza di un elemento radice, e
la correttezza dgli annidamenti per cui se un elemento
inizia all'interno di un altro, all'interno di questo
deve anche chiudersi. Quello che andremo via via a
costruire sarà un file chiamato "esempio.xml",
lo stesso file che viene preso dal documento
"esempio.htm" come sorgente da processare. Il primo passo è rappresentato dalla dichiarazione che dice al parser e al processor che quel file fa riferimento a quelle particolari specifiche e che determina il richiamo o meno di un DTD. <?xml version="1.0" standalone="yes"?> Al momento le specifiche 1.0 sono le uniche disponibili per cui quello è l'unico valore accettato ma in futuro, se il consorzio rilasciasse versioni successive sarebbe l'attributo "version" a determinarne la scelta. L'attributo "standalone" dichiara in questo caso che il file è "solo" e non rimanda ad alcun DTD. Altra regola rilevante per un documento ben formato è quella che vincola alla presenza di un elemento radice, che rappresenta il padre di tutti gli altri elementi e che non può contenere testo; è qualcosa di paragonabile all'elemento <HTML> di HTML. In questo caso chiamiamolo "RADICE", anche se in realtà è buon uso dare all'elemento radice un nome che sintetizzi il focus del documento. <?xml version="1.0"
standalone="yes"?> </RADICE> A questo punto non rimane che inserire all'interno dell'elemento radice i vari elementi destinati a contenere il testo. Ipotizziamo un documento che elenchi tre libri utilizzando l'autore, il titolo una breve descrizione e il costo. In questo caso sarebbe stato meglio chiamare <ELENCO> l'elemento radice ma non fa niente. Gli elementi da inserire sono 5: innanzi tutto "libro" e dentro di lui 4 figli, "autore", "titolo", "descrizione" e "prezzo". <?xml version="1.0"
standalone="yes"?> <LIBRO> </RADICE> Ovviamente il blocco dell'elemento <LIBRO> e degli elementi suoi figli deve essere ripetuto una volta per ogni libro e Ogni elemento deve essere anche riempito con il testo in questo modo: <?xml version="1.0"
standalone="yes"?> <LIBRO> </RADICE> Non essendo ancora stato costruito il foglio di stile relativo è ancora impossibile visualizzare il file "esempio.htm" se non nella sua struttura. |
| A questo punto bisogna
assegnare una tipologia di formattazione agli elementi
del file "esempio.htm", ad eccezione
dell'elemento radice non viene mai visualizzato, anche se
è necessario. La prima cosa da fare è inserire
l'elemento radice che apre e chiude il file XSL: <RADICE> </RADICE> All'interno di questo ogni elemento che si vuole visualizzare deve essere riconosciuto e associato ad una certa formattazione. Entrambe le operazioni rappresentano la regola associata a quell'elemento e devono essere contenute all'interno del tag <rule>. Iniziando dall'elemento <LIBRO> che non ha contenuto ma che potrebbe essere associato ad una linea di demarcazione possiamo scrivere: <RADICE> <rule> </RADICE> Attraverso l'elemento "target-element" si dichiara quella "rule" come relativa all'elemento associato all'attributo "type", in questo caso LIBRO e poi si associano a questo i tag HTML con i quali si vuole formattare l'elemento. il tag <children/> è strettamente necessario. Con questo tipo di informazioni associate all'elemento LIBRO, per ogni ricorrenza di questo all'interno del file XML ci sarà una riga di demarcazione. Per ogni elemento va poi fatta la stessa cosa, scegliendo il tipo di formattazione che si desidera. Decidiamo di visualizzare l'autore in marrone e un po' più grande del resto del testo, il titolo e la descrizione in blu con quest'ultima più piccola ed infine il prezzo in rosso e con font "italic". Avremo un file del genere: <RADICE> <rule> <rule> <rule> <rule> </RADICE> |
|
Vediamo ora come procedere nella costruzione di un
documeto valido, overo associato ad uno specifico DTD, il
che vuol dire fare riferimento ad una sintassi più
articolata e complessa che prende in considerazione
entità, attributi e altro. Va chiarito innanzi tutto che
ogni documento valido deve anche essere ben formato,
ovvero deve sottostare alle regole generali del
linguaggio XML viste nella prima parte della demo, a
cominciare dalla dichiarazione di tipo del documento che
in questo caso sarà: <?xml version="1.0" standalone="no"?> con standalone che assume il valore "no" perchè al documento è associato un DTD. L'associazione del DTD avviene immediatamente dopo per mezzo del nome che deve necessariamente essere quello dell'elemento radice (nel nostro caso "RADICE") e del path del file. Il tutto attraverso l'elemento DOCTYPE preceduto da "!": <?xml version="1.0"
standalone="no"?> In questo caso quindi si dice al processor che il documento XML va processato e verificato in base alla sintassi contenuta all'interno del file "esempio2.dtd". Per chiarezza va notato come tutti i file relativi a questa seconda parte della demo avranno nome "esempio2" seguito da un'estensione che renda immediatamente leggibile il tipo di file. Nel caso di un documento valido le regole relative alla rappresentazione, come nel caso del documento ben formato si trovano nel foglio di stile, in questo caso "esempio2.xsl" per cui tutto rimane uguale. Lo stesso si può dire del file XML che è di fatto il contenitore delle informazioni e che in questo caso si chiama "esempio2.xml" e per il file HTML che contiene l'ActiveX in grado di processare il tutto, in questo caso "esempio2.htm". L'unica variante stà nel fatto che il documento XML verra' controllato dal parser non più soltanto in base alle poche regole che fanno di un documento un documento ben formato XML, ma in base alle definizioni date nel DTD, nel nostro caso quindi in un nuovo file, "esempio2.dtd" che deve essere creato. Nel DTD deve essere definito ogni elemento che si intende utilizzare nel documento XML. Nel caso del nostro esempio quindi: RADICE, LIBRO, AUTORE, TITOLO, DESCRIZIONE e PREZZO. Bisogna anche fare caso a come si strutturano gerearchicamente i vari elementi ovvero nel nostro caso sarà proprio nel DTD che andremo a dire al processor che RADICE è l'elemento radice che contiene vari elementi LIBRO, composti a loro volta di quattro elementi, AUTORE, TITOLO, DESCRIZIONE e PREZZO. Quindi per prima cosa definiremo l'elemento RADICE: <!ELEMENT RADICE (LIBRO+)> Da notare che la definizione avviene all'interno dei simboli "<" ">" attraverso il tag ELEMENT. Tra parentesi l'elenco degli elementi figli, in questo caso solo uno, LIBRO, seguito da un "+" che indica che possono essere in numero variabile. Va poi definito l'elemento LIBRO: <!ELEMENT RADICE (LIBRO+)> tra parentesi gli elementi figli di LIBRO che vanno poi definiti come elementi destinati a contenere del testo. Questo avviene attraverso la struttura "#PCDATA": <!ELEMENT RADICE (LIBRO+)> Cliccando sul bottone sotto si potrà vedere come, attraverso una struttura diversa, più rigida ma più affidabile, si arriva allo stesso risultato. Questo perchè per il testo e per la sua rappresentazione sono stati usati di fatto gli stessi documenti. Modificando il testo nel file "esempio2.xml" o i criteri di formattazione nel file "esempio2.xsl", si potranno vedere i diversi effetti generati. |
|
In linea di massima il DTD, che concettualmente è
l'area in cui viene definita la struttura del documento,
è un file esterno che come abbiamo visto viene collegato
al file XML. In realtà è possibile effettuare una
seconda scelta, ovvero quella di posizionere il DTD non
esternamente bensì all'interno del documento XML, subito
dopo la dichiarazione. In questo caso non avremo più nel
documento XML una dichiarazione del tipo: <?xml version="1.0"
standalone="no"?> bensì del tipo: <?xml version="1.0"
standalone="no"?> con all'interno delle parentesi quadre tutte le dichiarazioni degli elementi fatte in precedenza nel DTD esterno, ovvero: <?xml version="1.0"
standalone="no"?> |
|
Chiunque intende accedere ad un documento in rete ha
davanti a se sostanzialmente due problemi, da un lato
reperire il documento e dall'altro valutarne la
correttezza. Entrambi i problemi sono tutt'altro che
banali, e più, col tempo aumenta la mole dei documenti
on-line, più la questione si complica perchè le
informazioni di reale interesse tendono a disperdersi nel
caotico mare del web e con loro tende a sbiadirsi anche
la possibilità di individuarne la fonte. Il secondo di
questi problemi, per quanto interessante, si porta dietro
una serie di considerazioni che in questa sede non è il
caso di affrontare, il primo invece ha molto a che fare
con le tecnologie applicative presenti in rete.
Solitamente, a meno di una pre-conoscenza dell'URI del
documento che si cerca, gli utenti iniziano la loro
navigazione da uno dei vari motori di cui la rete si è
dotata. In generale i motori di ricerca possono essere
definiti come dei grandi archivi di dati, che contengono
delle informazioni su un gran numero di pagine Web. Una
prima differenza riguarda il meccanismo attraverso il
quale l'archivio, ovvero il data base, viene popolato.
L'inserimento delle pagine Web negli archivi dei motori
di ricerca, può avvenire in due modi: attraverso la
registrazione manuale in seguito a segnalazione da parte
di un utente, e in modo automatico attraverso un
particolare software, chiamato robot, che visita i vari
siti dispersi nel Web inserendo le nuove pagine ed
aggiornando le informazioni su quelle già censite.
Inoltre alcuni invece di limitarsi ad archiviare le
pagine per permettere delle query, le classificano in
base al contenuto all'interno di una struttura ad albero
in cui via via che si scende si circoscrive l'argomento.
In realtà in questo caso più che di veri e propri
motori di ricerca si tratta di servizi di
"Directory", anche se gli utenti molto spesso
non hanno coscenza della differenza dal momento che anche
questi permettono di richiamare i documenti indicizzati
per mezzo di query. Ultimamente l'enorme diffusione di internet ha reso questi motori enormi ed è nato quindi il problema della visibilità dei documenti nella rete. Ormai non è più sufficiente essere indicizzati da uno o più motori perche' spesso le query restituiscono elenchi di documenti rilevanti assolutamente ingestibili per cui non solo bisogna essere indicizzati ma bisogna anche avere una ottima posizione nel risultato della ricerca che viene restituito all'utente ordinata per importanza. La posizione del documento nella schermata dipende dal valore assegnato dal motore di ricerca al documento rispetto al parametro impostato per la ricerca e non è fissa bensì dipende dal motore di ricerca. Infatti ognuno di questi motori ha un proprio algoritmo in base al quale calcola la percentuale di rilevanza. Diventa pertanto importante conoscere, almeno approssimativamente quali sono i criteri usati per fare questo calcolo. Uso il termine approssimativamente perchè i gestori dei motori svelano malvolentiri il loro segreto nel timore che i webmaster possano utilizzare l'algoritmo per fare "spooffing". Lo spooffing consiste nella creazione di pagine trappola costruite apposta per ingannare il motore e per risultare tra prime posizioni nelle risposte alle query più comuni, e per poi ridirezionare l'utente verso un documento che nulla a che fare con l'argomento richiesto. Vediamo allora come funzionano i maggiori motori di ricerca internazionali e italiani. Yahoo Oltre ad essere il motore di ricerca più
utilizzato Yahoo è attualmente uno dei siti web più
frequentati in assoluto. La sua storia nasce quando due
studenti dell'università di Stanford, Jerry Yang e David
Filo, alla fine del 1993, decisero di impegnarsi nel
catalogare efficacemente la loro lista di bookmarks.
Per fare questo svilupparono quello che possiamo definire
il prototipo di Yahoo, ossia una lista di link suddivisa
per categorie con la descrizione di ogni sito Web. Piano
piano il progetto è cresciuto fino a diventare quello
che è oggi, una azienda che cataloga circa 1.000 siti al
giorno. Quando una categoria diventa troppo grande,
vengono create delle sottocategorie e questo ha permesso,
nel tempo di conservare un archivio molto ben
strutturato. Yahoo che nel frattempo, nel 1995, è stata
acquistata da "Sequoia", una delle maggiori
societa' di "venture capitalism" degli Stati
Uniti, è un fenomeno di portata enorme non solo nel
panorama di internet ma anche in quello dei media in
generale. A fronte di una capitalizzazione, a maggio '98,
di 6 miliardi di dollari ha fatturato lo scorso anno 67
milioni di dollari con un disavanzo di 23 milioni di
dollari; è evidente quindi come sia considerato un perno
nei flussi di comunicazione, tale da giustificare un
investimento così consistente. D'altra parte le ultime
stime gli assegnano una media di 26 milioni di contatti
al giorno, con punte di 40 milioni, numeri superiori
anche a quelli di canali televisivi del peso di MTV o di
giornali come il Time. Altavista E' uno dei gli ultimi motori sbarcati sul web, anche se è il leader quanto a numero di pagine indicizzate (140 milioni) attraverso un software automatico che scandaglia il web a partire dai link presenti sulle pagine già indicizzate; è tra l'altro uno dei più utilizzati fuori dagli Stati Uniti. le ultime stime gli assegnano circa 9 milioni di contatti al giorno anche se probabilmente questo dato sottostima l'effettiva consistenza di questo motore, essendo l'analisi statistica condotta negli Stati Uniti. Nacque come progetto della Digital per dimostrare la velocità elaborativa dei processori Alpha a 64 bit, e fu messo in rete alla fine del 1995. Da allora si è difuso enormemente e ne esiste una versione italiana. Permette ricerche avanzate molto accurate, che oltre ai classici operatore standard, prevede la possibilità di escludere documenti in cui sono molto rilevanti concetti attigui a quello richiesto; questa caratteristica insieme all'enorme numero di documenti indicizzati, lo rende molto adatto per ricerche che partono da una base molto vasta e procedeno per affinamenti successivi. Per quanto riguarda i criteri per la classificazione dei risultati tiene molto in considerazione il "Title" del documento, ma se manca non lo sostituisce, e le occorrenze nella prima parte dello stesso (primi 150 caratteri), che in mancanza del metatag "Description" utilizza come descrizione del sito. Assegna particolare valore ai metatags e considera scorretto, e quindi passibile di esclusione, l'uso delle pagine ponte che dirottano automaticamente su un altro documento, l'uso di testo invisibile perche' dello stesso colore dello sfondo o perchè troppo piccolo. Excite E' uno dei motori più "anziani", essendo sbarcato in rete nel 1995; vanta 55 milioni di pagine indicizzate e circa 13 milioni di contatti al giorno. Anche questo motore, come Yahoo, è frutto dello studio di alcuni studenti dell'università di Stanford, che nel 1993 iniziarono a studiare un sistema per il reperimento di informazioni, arrivano a sviluppare ICE (Intelligente Concept Extraction), una tecnologia semplice e potente in grado di reperire non solo occorrenze delle parole chiave ricercate, ma anche argomenti correlati. Da quello studio nasce Excite, che non è solo un sito che solge servizi di ricerca bensì una rete di siti che include Magellan, un servizio di directory, City.net, una guida turistica, My Excite Channel, un servizio personalizzabile di novità ed informazioni e MailExcite che offre caselle di posta elettronia gratuite, servizio questo che si è poi esteso a quasi tutti i motori di ricerca. Non esiste una versione italiana di Excite. Permette l'uso di operatori standard ma non la ricerca di intere frasi anche se tra apici, e ha la particolarità di utilizzare siti ottenuti in risposta come punti di partenza di query ulteriori per la ricerca di siti simili magari sfuggiti a finiti in fondo alla lista per problemi di ordinazione. Utilizza i metatags per il titolo e la descrizione della risposta con limiti molto ampi (70 caratteri per il titolo e 395 per la descrizione), ma non assegna particolare valore alle parole in esso contenute, limitandosi ad indicizzare in modo piatto l'intero testo. Non esclude le pagine ponte e i caratteri invisibili e aumenta il valore dei documenti linkati da altri presenti nel database; perciò un documento la cui URI risulta spesso in altri documenti ha maggiori probabilità di essere tra le prime posizioni del risultato. Infoseek E' il motore con maggiore anzianità di rete, attivo dal 1994 può contare su un database di 30 milioni di documenti e su oltre 10 milioni di contatti giornalieri. ha una caratteristica assolutamente peculiare che è quella di indicizzare i documenti pochi minuti dopo la segnalazione, contro una media di diverse settimane. Questo fa si che sia però anche il motore più esposto ad operazioni di spooffing per veloci pubblicità, tant'è vero che ultimamente si è dotato di filtri che pero' ne diminuiscono la base di documenti indicizzati; non permette quindi l'indicizzazione di pagine ponte e i caratteri dello stesso colore dello sfondo. Ha la versione italiana e le ricerche di intere frasi sono automatiche. Per definire la percentuale di rilevanza di ogni documento rispetto alla richiesta utilizza un metodo piuttosto articolato che prevede la considerazione dell'occorenza della parola nel titolo, nei metatags, nei primi 200 caratteri del documento, e che tiene in considerazione, assegnadogli una specie di bonus, i documenti che presentano parole rare, ovvero non molto presenti nel database. Valuta anche le occorrenze dell'URI del documento negli altri documenti indicizzati. In assenza di "Title" di un documento utilizza le prime linee del testo. Lycos Lycos, anch'esso attivo già dal 1994, indicizza 30 milioni di documenti e vede la sua home page contattata 9 milioni di volte al giorno. Si caratterizza per l'indicizzazione non solo dei file HTML ma anche di quelli audio e video, il che permette ricerche particolareggiate di suoni ed immagini. Non considera i metatags e il loro contenuto come più rilevante rispetto al testo ed esclude documenti co testo invisibile, si esso dello stesso colore dello sfondo o molto piccolo. Indicizza invece le pagine ponte e permette la ricerca per mezzo di operatori ma non di intere frasi. Hot Bot Hot Bot è uno degli ultimi motori di ricerca comparso sul web. La sua pubblicazione risale al maggio 1996 ad opera di Wired, l'arcinota rivista di informatica. E' secondo solo ad Altavista quanto a pagine indicizzate (110 milioni) anche se è un po' indietro quanto a contatti giornalieri (6 milioni al giorno). La sua ricerca è basata sulla tecnologia Inktomi, sviluppata a Berkley che gli permette di garantire risultati molto precisi non ostante l'enorme base di documenti. Vanta anche un'interfaccia grafica molto semplice per l'esecuzioni di query condizionate da operatori o da altri vincoli (per es. l'etensione del file). Considera i metacaratteri come campi privilegiati per la richiesta e non indicizza le pagine con testo invisibile. Virgilio Virgilio è un po' l'alter ego Italiano di Yahoo e vanta quasi 300.000 mila contatti giornalieri. E' una directory che raccoglie circa 40.000 siti immessi manualmente e valutati da personale interno, dopo una esplicita richiesta da parte del web master, ad un ritmo di circa 150 al giorno. Offre ovviamente la possibilità di effettuare ricerche per parole chiave e classifica poi i siti rilevanti ordinando alfabeticamente il titolo. Arianna E' il motore di ricerca di Italia on Line, uno dei maggiori fornitori di accesso in Italia. Conta su un archivio di circa 4 milioni di documenti tutti in lingua italiana. Le ricerche sono piuttosto precise perche' richiama anche le varianti linguistiche italiane (per casa restituisce anche documenti che contengono la parola case) e non considera le stop words come per esempio gli articoli. Indicizza l'intero testo ma da maggior rilievo alle parole contenute nel titolo e nei campi dei metatags. Anche soltanto questo breve excursus attraverso i principali motori di ricerca internazionali ed italiani da un'idea della difficoltà di costruire documenti che, in caso di ricerca sull'argomento trattato, si trovino in una posizione accettbile della classifica di quelli rilevanti. Sebbene ogni motore utilizzi un algoritmo caratterizzato in qualche modo, è assolutamente fondamentale la presenza della parola chiave, nell'URI, nel campo <TITLE>, nei <META> Keyword e Description, nei primi 200 caratteri ed'è anche molto importante che il documento sia linkato da altri, vale a dire che non sia isolato nel mare della rete. La sicurezza comunque non c'è intanto perchè usando ogni motore un meccanismo diverso bisognerebbe in teoria costruire una copia del documento per ognuno dei motori dai quali si vuole essere indicizzati e perchè è immediatamente evidente come, a partire dagli algoritmi che guidano la classificazione è possibile creare delle pagine trappola fatte apposta per andare ai primi posti delle risposte alle query a prescindere poi dall'effettivo contenuto del documento. La breve storia di internet è piena di questi episodi, a partire da quello del dirottamento virtuale effettuato nel 1996 da "etoy" un gruppo di ragazzi che attraverso una serie di pagine ponte riderezionavano gli utenti nella home page del loro sito azzerando tramite uno script l'history del browser e facendo comparire una scritta che spiegava il loro gesto. Il gruppo, capace di dirottare in sei mesi circa un milione di navigatori, vinse il premio per la migliore opera d'arte elettronica dell'anno mettendo in luce in modo evidente i problemi dei motori di ricerca e del reperimento in genere di informazioni on-line. Come si è visto alcuni motori escludono dal loro archivio documenti in cui sono presenti tecniche scorrette come quella della pagina ponte che, usando parole chiavi molto comuni devia su siti che nulla hanno a che fare con quegli argomenti, o come quella del testo invisibile. Il testo invisibile, di colore uguale al colore dello sfondo, viene usato per riempire il documento di parole che poi in effetti non vengono visualizzate, o meglio non si vedono, e che ingannano i motori che contano su tutto il testo le occorrenze delle parole richieste. Nonostante tutti i tentativi fatti per arginare questi fenomeni, il problema è di difficilissima soluzione perchè affonda le sue radici nella assolutà liberta di HTML. Da quando è nato, con l'aumentare progressivo dei testi a prescindere dal loro supporto, il problema del reperimento delle informazioni è stato risolto grazie alla strutturazione di un meccanismo di classificazione e ricerca basato sul concetto di metainformazione. Metainformazioni sono quelle usate dai bibliotecari per schedare i libri posseduti dalla biblioteca; grazie proprio alle metainformazioni per cercare un testo non è necessario passeggiare lentamente davanti agli scaffali, ma è sufficiente consultare un cassettino dove i libri sono ordinati in base al titolo, all'autore o al contenuto. In questo caso nel tempo si è stabilito che le metainformazioni rilevanti per garantire l'accessibilità dei testi di una biblioteca sono quelli riportati appunto nelle schede del catalogo. Lo stesso approccio è stato più volte proposto anche per risolvere il problema dell'accesso alla documentazione elettronica. Senza dover necessariamente ricorrere ad un enorme schedario elettronico sarebbe sufficiente standardizzare delle metainformazioni da inserire in ogni documento on-line, in modo da poterle richiamare attraverso un motore di ricerca. In questo caso si riuscirebbe ad unire i vantaggi della ricerca automatizzata a quelli della ricerca strutturata. Questo meccanismo reggerebbe però solo se i browser, in assenza di una corretta strutturazione dei campi relativi alle metaiformazioni, gestissero in qualche modo gli errori. In altre parole sarebbe necessario un controllo di validazione sintattica del documento, necessitè questa più volte messa in luce anche per risolvere altri problemi che pesano sulla comunicazione in rete. Dei Metadati per gestire informazioni non facenti parte del testo ma che del testo danno in sintesi i parametri principali sono stati già elaborati, ma l'unico modo per renderli utilizzabili è quello dell'autodisciplina all'interno di un circuito "chiuso". Nel mare del Web questo approccio è comunque improponibile. Anche per questo molte speranze vengono riposte in XML, che, in quanto metalinguaggio per la costruzione di linguaggi sottoposti a parsing, sembra poter inglobare senza troppi problemi questo tipo di approccio. tramite un semplice riferimento ad un DTD in cui sono definiti i tags relativi alle varie metainformazioni necessarie, automaticamente quel tipo di informazione diventa necessaria e la ricerca diventa molto più semplice. |
| Alcune suggestioni riguardo a
ipertesti e rinascimento in: www.mindspring.com/~jntolva/main.html Un intervento di Umberto Eco sul ruolo delle Biblioteche: www.liberliber.it/biblioteca/testiinhtml/d/debiblio/index.htm Diverse interviste su ipertesti e Web nel sito di "Mediamente: www.mediamente.rai.it/home/bibliote/tematich/index.htm L'edizione Italiana della Guida Internet della Electronic Frontier Foundation: www.liberliber.it/biblioteca/testiinhtml/g/guid_htm/index.htm La versione on-line del libro Internet 98 della Laterza: www.comune.cremona.it/internet/libro/ Un'ottima introduzione alle problematiche dei matadati: www.imsproject.org/metadata/MDintro.html Sui motori di ricerca: searchenginewatch.internet.com Una discreta introduzione in Italiano a SGML: telemat.die.unifi.it/book/Internet/Sgml/indsgml.htm Un enorme elenco di link a risorse relkative a XML: www.cs.caltech.edu/~adam/local/xml.html Un sito interamente dedicato ad XML: www.xml.com L'università di XML: www.xmlu.com Il sito Microsoft su XML: www.microsoft.com/workshop/c-frame.htm#/xml/default.asp Il consorzio W3C: www.w3c.org |