PROGETTAZIONE DI TECNOLOGIE FLESSIBILI PER LA PRESENTAZIONE DI … · 2018. 10. 8. · tra un...

ALMA MATER STUDIORUM

UNIVERSITÀ DI BOLOGNA

FACOLTÀ DI SCIENZE MM.FF.NN.

Corso di Laurea in Informatica

Materia di tesi : Programmazione

PROGETTAZIONE DI TECNOLOGIE

FLESSIBILI PER LA PRESENTAZIONE DI

INFORMAZIONI TESTUALI

Tesi di Laurea di Relatore

RENATO CARUSO Chiar.ma Dott.ssa ANTONELLA CARBONARO

Sessione I

anno accademico 2003–2004

Alla mia famiglia

Indice

1 Introduzione 3

1.1 Obiettivi e motivazioni generali . . . . . . . . . . . . . . . . . 3

1.2 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Il Progetto 6

2.1 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Personalizzazione dell’informazione . . . . . . . . . . . . . . . 7

2.3 Wapforum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Palmari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Analisi del progetto . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Tecnologie utilizzate 14

3.1 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 HTML (HyperText Markup Language) . . . . . . . . . . . . . 15

3.3 Css (Cascading Style Sheets) . . . . . . . . . . . . . . . . . . . 15

3.3.1 Css 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2 Css 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 XML (Extensible Markup Language). . . . . . . . . . . . . . . 18

3.4.1 DTD (Document Type Definition) . . . . . . . . . . . 20

3.4.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.3 XPath (XML Path Language) . . . . . . . . . . . . . . 21

3.4.4 XSLT (Extensible Stylesheet Language Transformations) 21

1

INDICE 2

3.4.5 WML (Wireless Markup Language) . . . . . . . . . . . 23

3.4.6 DOM XML (Document Model Object XML) . . . . . . 23

3.5 WAP (Wireless Markup Language) . . . . . . . . . . . . . . . 24

3.6 3.8 Php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Sviluppo del progetto 26

4.1 Struttura e sintassi di un documento xml . . . . . . . . . . . . 26

4.1.1 Struttura logica . . . . . . . . . . . . . . . . . . . . . . 26

4.1.2 Il prologo . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3 Dichiarazione XML . . . . . . . . . . . . . . . . . . . . 28

4.1.4 Dichiarazione del tipo di documento . . . . . . . . . . 28

4.1.5 L’elemento document . . . . . . . . . . . . . . . . . . . 29

4.1.6 Struttura fisica del linguaggio XML . . . . . . . . . . . 31

4.1.7 Gli elementi . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.8 Gli attributi . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.9 Documenti ben-formati (Well Formed) . . . . . . . . . 36

4.1.10 Struttura dei fogli di stile . . . . . . . . . . . . . . . . 37

4.1.11 Le pagine WML . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Sintassi php . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 Php e html . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Le variabili GET e POST . . . . . . . . . . . . . . . . 45

4.2.4 Codici e funzioni principali . . . . . . . . . . . . . . . . 47

4.2.5 Visualizzazione in base al client . . . . . . . . . . . . . 52

Conclusioni 62

Bibliografia 62

Capitolo 1

Introduzione

1.1 Obiettivi e motivazioni generali

Uno dei principali utilizzi di Internet è sicuramente quello di reperire in-

formazioni. Attualmente quest’operazione non è sempre agevole in quanto

risulta complicato raggiungere realmente gli obiettivi prefissati.

A tale proposito, l’introduzione del Semantic Web potrebbe rappresentare

un notevole passo avanti: questo strumento dovrebbe garantire un recu-

pero intelligente delle informazioni desiderate, migliorando la qualità di una

ricerca.

Lo strumento principale per integrare la semantica nel web tradizionale

è costituito dalle annotazioni, che rappresentano un sistema per descrivere il

contenuto di una risorsa web. Esse sono in grado di stabilire delle relazioni

tra un oggetto esistente e la classe di un’ontologia, attraverso la dichiarazione

di triple (oggetto, concetto, attributi) in linguaggi basati sull’XML (RDF,

DAML+OIL).

Nello sviluppo di questo lavoro si dimostra come utilizzare ciò che abbi-

amo descritto precedentemente, al fine di sfruttare “tecnlogie flessibili” per

un certo tipo di dati.

Questo ha portato due requisiti fondamentali:

• la condivisibilità

3

1.1. OBIETTIVI E MOTIVAZIONI GENERALI 4

• la specificità

Il primo esprime la necessità di rendere un’annotazione accessibile all’in-

tero web, evitando di inserirla direttamente all’interno della risorsa. Essa

può essere soddisfatta servendosi di tecnologie per l’accesso remoto alle sot-

tostrutture di un documento web. In particolare, sono stati individuati due

nuovi linguaggi basati sull’XML che permettono di eseguire quest’operazione:

XPath e XPointer.

Il secondo requisito tenta di risolvere uno dei limiti allo sviluppo del

Semantic Web legato all’eterogeneità delle risorse annotabili. Esse, infatti,

potrebbero essere piccoli frammenti di informazione (semplici pagine web)

oppure documenti più complessi (articoli on-line, libri), differenziati sia da

un fattore dimensionale sia da uno strutturale. Una possibile soluzione può

essere quella di annotare le sottostrutture di un documento, come capitoli,

sezioni, paragrafi, considerandole come risorse indipendenti. Tale metodo,

ottenuto scomponendo la risorsa in entità di dimensione progressivamente

inferiore, permette di migliorare la rilevanza di un’annotazione, e definire in

modo più specifico l’argomento del frammento di testo considerato.

Il sistema proposto è dotato di un deposito esterno di dati nel quale

esse vengono memorizzate in modo indipendente dalla risorsa, garantendone

la condivisibilità. Ogni singola risorsa è collegata alla relativa annotazione

specificando una coppia (URI, XPath). L’aspetto innovativo è costituito

dal fatto che tale deposito è organizzato secondo una struttura tassonomica,

che permette alle applicazioni di sfruttarne molte delle sue caratteristiche

per migliorare le performance di una ricerca. Lo strumento che soddisfa la

specificità di un certo tipo di dati è garantito da un sistema che frammenta in

modo logico una risorsa di tipo testuale in entità di livello progressivamente

inferiore, attraverso la sintassi XPath.

Il sistema è dotato di funzioni di ricerca in grado di sfruttare le poten-

zialità offerte dalle annotazioni semantiche.

Il risultato finale è costituito da un insieme di frammenti rilevanti che

verranno concatenati ed inseriti in un’unica pagina.

1.2. STRUTTURA DELLA TESI 5

Il progetto reale ha portato a sviluppare un’architettura facilmente realiz-

zabile con le tecnologie semantiche attuali ma, allo stesso tempo, sfruttabile

per possibili sviluppi futuri. Per questo è stata concepita una struttura mod-

ulare, in grado di offrire un sistema scalabile e integrabile con altri servizi

per fornire risultati di alta qualità.

1.2 Struttura della tesi

Nei primi capitoli questo lavoro fornirà una panoramica sulle tecniche e i

linguaggi utilizzati nel Semantic Web, con lo scopo di introdurre i concetti

fondamentali di questa nuova visione.

In seguito, si farà riferimento alle tecnologie attualmente disponibili per

accedere alla struttura di un documento e si proporrà un sistema modulare in

grado di eseguire ed elaborare, in modo automatico, annotazioni per diversi

client.

Capitolo 2

Il Progetto

In questo capitolo si illustrano le motivazioni che ci hanno spinto a fare questo

proegetto, si parlerà anche delle leggi e dei criteri a cui bisogna attnernersi per

garantire l’accessibilità, dei vari dispositivi tecnologici; dello stato dell’arte,

ed infine analizzeremo ilprogetto.

2.1 Motivazioni

Il Web si evolve ad una velocità inedita per qualsiasi altro media tradizionale.

L’evoluzione tecnologica porta con sè anche un cambiamento dei costumi e

delle abitudini. La realizzazione di siti Web non si sottrae a questa regola e

nel corso dei mesi muta peculiarità e strumenti di utilizzo. Uno dei motivi

principali che ci ha spinto alla realizzazione di questo progetto risiede nel

tentativo di poter visualizzare un sito Web in vari modi diversi senza farne

perdere i contenuti e i servizi che il sito offre.Col nostro lavoro abbiamo cerca-

to di venire incontro a molte esigenze dei vari tipi di utenza, infatti abbiamo

cercato di sviluppare un sito che sia in grado di essere visualizzato da parte

di tutti, normodotati, disabili e utenti che si connettono con un palmare o

un cellulare WAP, per quanto riguarda quest’ultimo aspetto abbiamo solo

sviluppato il codice ma non abbiamo avuto modo di testarlo, quindi non ne

garantiamo la funzionalità. Oltre a garantire la visualizzazione per mezzo di

6

2.2. PERSONALIZZAZIONE DELL’INFORMAZIONE 7

strumenti comuni come un normale Pc, si è cercato di facilitare anche l’in-

terpretazine delle nostre pagine ad alcuni software e dispositivi particolari

usati dalle perosne disabili, come ad esempio i lettori di schermo la tastiera

e la stampante braille. L’obbiettivo primario dell’intero lavoro è quello di

progettare diversi template destinati a browser differenti;per esempio possi-

amo avere una versione del sito che utilizza tecnologie relativamente nuove

(quali style sheets, Dynamic HTML) destinata a sistemi di fascia alta (Opera

5, Mozilla/Netscape 6 e Internet Explorer 5/6), una versione in HTML old

fashion per sistemi di fascia bassa (Netscape 4.x e Internet Explorer 3/4),

una versione text-only priva di immagini per l’accesso tramite screen reader

o browser testuali (Lynx), realizzare template specifici palmari.E tutte le ver-

sioni attingeranno agli stessi contenuti, che non dovranno più essere copiati

manualmente all’interno di ciascun file HTML,che sono composte da template

vuoti, riempiti dinamicamente con i contenuti appropriati solo nel momento

in cui l’utente richiede l’accesso a una determinata pagina Web.I contenuti

vengono raccolti e organizzati in un database che automatizza la gestione

e la pubblicazione sul web server all’interno di pagine template dinamiche.I

contenuti sono riutilizzabili e modificabili a piacimento.I contenuti vengono

organizzati per permettere ricerche, categorizzazioni e matching automatici.

Prima di illustrare bene il progetto facciamo una panoramica sull’acces-

sibiltà in generale, e sugli strumenti che rendono accessibile un sito Web.

2.2 Personalizzazione dell’informazione

La questione della personalizzazione dei siti Web è venuta fuori solo di recente

all’attenzione dell’opinione pubblica internazionale. In effetti finora abbiamo

assistito allo sviluppo e alla diffusione dell’utilizzo di Internet:tecnologia nuo-

va che dà la possibilità di esplorare cose che riguardono tutto lo scibile umano.

Col tempo ci si inizia a porsi la questione delle possibilità reali del mezzo e

degli usi utili nonchè dei servizi che può fornire. Di conseguenza se Internet

diventa sempre più uno dei mezzi principali di scambio di notizie di infor-


mazioni diventa inevitabile riflettere sui vincoli di accesso al mezzo. Chi non

ha problemi di accessibilità deve capire che questo non significhi che se un

sito sia accissibile per lui è accessibile per tutti. Bisogna tener conto an-

che delle persone che a causa di forze moggiori possono essere impossibilitati

ad usare gli strumenti di navigazione standard.Infatti la Camera dei Depu-

tati nella seduta dello scorso 26 maggio ha dato il via all’iter parlamentare

del disegno di legge sull’accessibilità degli strumenti informatici presentata

e promossa dal Ministro dell’Innovazione Lucio Stanca. L’Accessibilità pro-

pone soluzioni per permettere agli utenti disabili di accedere ai contenuti e

ai servizi in Internet aggirando o rimuovendo tali ostacoli.Possiamo dividere

i problemi di accessibilità in quattro categorie[20, 10, 18, 11, ?]:

1. disabilità fisiche/sensoriali:non vedenti, ipovedenti(persone che possiedono

un residuo visivo, oscillante tra 1/10 e 3/10), daltonici, non udenti ,

utenti con difficolatà motoria nell’uso di mouse e tastiera;

2. disabilità cognitive: scarso apprendimento problemi di lettura e com-

prensione dei testi;

3. barriere tecnologiche: connessione lenta plug-in assenti(java flash etc.);

4. situazioni particolari:l’utente è occupato in altre attività e non può

usare i normali strumenti di input e/o output.

Si può notare che dalla classificazione fatta l’accessibilità non riguarda so-

lamente gli utenti che sono colpiti di disabilità; ma anche tutti quelli che

dispongono di strumenti un pò vecchi o tecnologicamente avanzati come i

PDA.Per limitare questi problemi è necessario realizzare le pagine Web in

particolar modo quelle delle pubbliche amministrazioni seguendo determi-

nate regole, giungendo a ridurre completamente o il più possibile le cosid-

dette barriere Web, che non consentono un libero accesso alle informazioni.

A questo proposito il W3Consortium(ente internazionale preposto alla stan-

dardizzazione dei linguaggi di programmazione del Web in particolar modo


l’HTML) attraverso il progetto WAI(Web Accessibilty Initiatives)ha propos-

to de dei criteri volti a promuovere il massimo grado di fruibilità del Web da

parte delle persone disabili.Il principale documento prodotto da questo or-

ganismo ad uso di chi produce pagine web sono le Web Content Accessibility

Guidelines 1.0 che risale al 1995 di cui esiste anche una traduzione italiana6;

ad Agosto del 2002 è stata rilasciata la bozza del documento relativo alle

Web Content Accessibility Guidelines 2.0 che, una volta approvate, andranno

ad aggiornare la versione la 1.0. Bisogna sottolineare, tuttavia, che linee gui-

da sono una specifica del W3C, un consorzio internazionale no-profit e non

un ente legislativo, pertanto, non avendo valore normativo, possono essere

adottate anche solo in parte, a seconda del livello di accessibilità che si vuole

raggiungere nella costruzione di un sito. È comunque necessario tenere sem-

pre in considerazione i Principi di Progettazione Universale. Il concetto di

Progettazione Universale ha origine in architettura e nel design dei prodotti,

dove la capacità di soddisfare un più grande numero di utenti dipende dalla

possibilità di mettere in pratica certi principi. I progettisti che applicano il

principio della progettazione universale realizzano prodotti che sono concepi-

ti sin dalla fase di progetto per essere usati da tutti gli individui, compresi

quelli con disabilità. L’applicazione del principio di progettazione universale

può presentare dei limiti e, in alcuni casi, porre vincoli alla creatività. Nel

caso dei siti web, i vincoli riguardano le modalità di attuazione delle varie

soluzioni tecniche, piuttosto che il contenuto e l’estetica dei documenti, per

cui non si traducono in limitazioni della possibilità espressiva. I principi

qui elencati sono molto generali ma si mettono in pratica in specifiche ap-

plicazioni nei vari campi dell’attività umana, come ad esempio quello dello

sviluppo delle interfacce uomo macchina, HCI (Human-Computer Interac-

tion) come pure quello delle interfacce utente dei programmi di navigazione

per Internet.Per costruire un sito accessibile bisogna rispettare le 14 linee

guida specificate dal WAI descritte nella versione 1.0, ogni linea guida è as-

sociata a uno o più punti di controllo che descrivono come applicare quella

linea guida a particolari aspetti delle pagine Web [17]:

2.3. WAPFORUM 10

1. Fornire alternative equivalenti al contenuto audio e visivo.

2. Non fare affidamento sul solo colore.

3. Usare marcatori e fogli di stile e farlo in modo appropriato.

4. Chiarire l’uso di linguaggi naturali.

5. Creare tabelle che si trasformino in maniera elegante.

6. Assicurarsi che le pagine che danno spazio a nuove tecnologie si trasformi-

no in maniera elegante.

7. Assicurarsi che l’utente possa tenere sotto controllo i cambiamenti di

contenuto nel corso del tempo.

8. Assicurare l’accessibilità diretta delle interfacce utente incorporate.

9. Progettare per garantire l’indipendenza da dispositivo.

10. Usare soluzioni provvisorie.

11. Usare le tecnologie e le raccomandazioni del W3C.

12. Fornire informazioni per la contestualizzazione e l’orientamento.

13. Fornire chiari meccanismi di navigazione.

14. Assicurarsi che i documenti siano chiari e semplici.

2.3 Wapforum

WAP[19, 13] nasce nel 1997 dalla costituzione di un gruppo no-profit, chiam-

ato WAP Forum, costituito da Unwired Planet (oggi Openwave) e i tre gran-

di colossi internazionali Ericsson, Motorola e Nokia. L’intento primario del

WAP Forum, che oggi conta più di cento associati, fu quello di mettere a

2.4. PALMARI 11

punto un nuovo standard comune, le cui specifiche fossero utilizzabili da tut-

ti senza pagare licenze d’uso. Tale standard è stato denominato Wireless

Application Protocol (WAP).

2.4 Palmari

[13, 19],Miniaturizzando ancora di più i componenti dei notebook ed eliman-

done altri non ritenuti necessari (es. tastiera, hard disk), si è cos̀ı arrivati a

costruire i computer palmari, utilizzabili al limite anche con una sola mano.

Il risultato che si è ottenuto è un computer con peso e dimensioni ridotti,

a metà strada tra l’agenda elettronica e un notebook. I computer palmari

si dividono in due famiglie: quelli con tastiera, detti anche PDA (Personal

Digital Assistant) o PC Companion, in alcuni casi vicini come prestazioni

ai notebook, ma che hanno bisogno di essere appoggiati ad un pur piccolo

piano di lavoro per poterci lavorare con una certa precisione.

2.5 Stato dell’arte

Facendo delle ricerche sulla rete abbiamo constatato che ancora molti siti che

offrono dei servizi sia informativi che di altro genere non risultono essere ac-

cissibili,secondo i criteri stabiliti del W3c nelle linee giuda del WAI.Inoltre ci

sono anche moltissimi siti che non possono essere visualizzati con strumenti

di navigazione diversi da un pc,quindi l’utente viene penalizzato poichè non

potrà usufruire del servizio a cui aveva fatto riferimento.Partendo da questi

presupposti abbiamo progettato un sito che potesse essere accissibile a qualsi-

asi tipo di utenza, venedo incontro a queste necessità sia per quanto riguarda

le nuove tecnologie palamri e cellulari Wap che persone che hanno bisogno

di un certo tipo di visualizzazione a causa di problemi legati a qualche tipo

di disabilità sia essa visiva o legata ad altri aspetti ad esempio l’epilessia

o la schizzofrenia. Facendo dei test con due tipi di palmari uno avente il

sistma operativo Palm-Os e l’altro,Windows-CE abbiamo potuto constatare

2.6. ANALISI DEL PROGETTO 12

che molti siti non vengono visualizzati poichè questi siti non sono stati pen-

sati per essere visualizzati da browser che non supportono alcuni plug-in.

Nel nostro lavoro abbiam cercato di risolvere anche questo aspetto di acces-

sibilità, che come spiegherò nel dettaglio nel prossimo paragrafo.Anche per

quanto riguarda un altro tipo di tecnologia ci sono non pochi problemi per la

visualizzazione di pagine web sto parlando dei cellulari Wap; infatti le pagine

per essere visualizzate con questi strumenti devono essere implementate con

il linguaggio WML un linguaggio che non è molto usato dai Webmaster, ora

il problema non si pone più perchè la tecnologia Wap va scomparendo per

far posto a quella UMTS.

2.6 Analisi del progetto

Dopo aver fatto delle premesse sui vari aspetti che riguardono l’accessibilità

dei contenuti nel Web, e aver parlato delle tecnologie con le quali si può

accedere alla visualizzazione di siti Web; in questo paragrafo si farà una

panoramica del lavoro di tesi svolto. La tesi quindi consiste nell’aver svilup-

pato un SCP (Semantic Collaborative Portal), cioè un sistema di visualiz-

zazione di una banca dati di articoli presi dai quotidiani più letti nel nostro

Paese, che sono: la Repubblica, il Giorno, il Corriere della Sera, il

Sole 24 ore, la Stampa e la Gazzetta dello Sport.

Abbiamo fatto una base dati XML con articoli classificati secondo vari

criteri ad esempio sezione: sport, spettacoli, interni, cronaca, esteri, politica;

testata e con altri dati caratteristici (autore, data, titolo, sottotitolo, soprati-

tolo, abstract, testo, foto, etc.). Abbiamo implementato un’interfaccia PHP

che recupera i dati dalla base dati e li espone agganciandoli ai relativi fogli

XSL in base alle caratteristiche del client (il piu’ possibile determinate dalla

User-Agent). I fogli XSL sono suddivisi in 4 gruppi:

1. interfaccia bella,

2. interfaccia accessibile per disabili,

2.6. ANALISI DEL PROGETTO 13

3. interfaccia accessibile per palmari,

4. interfaccia accessibile per cellulari WAP.

L’interfaccia ha una home page con alcuni articoli (testata, autore, data,

titolo e abstract con link all’articolo completo), i link alle varie sezioni e

una funzione di ricerca su tutte le sezioni; le pagine delle varie sezioni sono

simili alla home page avendo alcuni articoli della sezione (testata, autore,

data, titolo e abstract con link all’articolo completo), sempre i link alle varie

sezioni oltre che alla homa page e una funzione di ricerca sulla sezione. C’è

anche una pagina per i risultati delle ricerche strutturata come una serie di

link all’articolo completo. I criteri di ricerca sono stati implementati con

XSLT e PHP.

Quali articoli compaiono nelle varie sezioni(cioè quelli che vengono recu-

perati dal codice PHP per restituire l’XML giusto che poi viene agganciato

all’XSL corretto) e come compaiono(colore di sfondo,posizione dell’eventuale

foto,solo titolo o titolo con abstract ect.) viene deciso dal caporedattore, il

quale accede ad una pagina in cui c’è un form col quale può scegliere le varie

impostazioni desrcitte prima, una volta compilato il form, i dati passano

tramite il modulo PHP al file di impostazione XML e le modifiche verrano

salvate, quindi il sito si aggiornerà secondo i criteri scelti dal caporedattore.

Inoltre abbiamo usato la potenzialità dei CSS1, e CSS2; fondamentali per

rendere la visualizzazione del sito accessibile a quasi tutte le tipologie di uten-

ti che sono colpiti da disabilità, infatti con i CSS2 si permette di ottimizzare

per varie piattaforme la conversazione dei contenuti dei documenti.

Capitolo 3

Tecnologie utilizzate

Di seguito si illustreranno in maniera molto semplice e concisa linguaggi e

tecnologie usate per l’elaborato della tesi. Iniziamo col descrivere cos’è il

Web Semantico per descrivere le funzionalità e le potenzialità della nostra

applicazione.

3.1 Semantic Web

Il Semantic Web è stato ideato da Tim Berners-Lee [3], già inventore del

WWW, dell’HTTP e dell’HTML. Può essere considerato un web di seconda

generazione come è facilmente comprensibile dalla definizione che lo stesso

Berners-Lee ne fornisce:

“Il Semantic Web è un’estensione del web attuale in cui le informazioni

sono strutturate con un senso compiuto, rendendo migliore la cooperazione

tra le persone e i computer.”

In altre parole, rappresenta un metodo per aggiungere intelligenza alle

risorse disponibili in rete e sfruttarla per migliorare le caratteristiche del web

tradizionale.

Lo scopo iniziale del WWW era proprio quello di fornire uno strumento

di comunicazione per gli umani ma facilmente sfruttabile anche dalle mac-

chine. Purtroppo la seconda di queste speranze non è ancora stata realizzata,

14

3.2. HTML (HYPERTEXT MARKUP LANGUAGE) 15

e un’enorme mole di dati disponibili all’uomo non può essere analizzata e

rielaborata dalle macchine.

L’introduzione del Semantic Web dovrebbe proprio garantire la strut-

turazione del web in un formato facilmente processabile e leggibile dalle

macchine (Figura 3.1). L’obiettivo principale è quello di proporre tecnolo-

gie per lo scambio globale dell’informazione, riducendo lo sforzo dell’utente

umano e sfruttando le potenzialità delle macchine.

Le applicazioni future del Semantic Web potranno riguardare diversi

campi. Per fare tutto ciò si può pensare, nel nostro caso, ad una seguente

formula:

“Semantic Web = HTML + CSS + XML + XSL + PHP ”

riguardante tutto il Web dinamico e prendendo in considerazione moltepli-

ci tecnologie che più avanti andremo ad analizzare.

Esso sarà utile nel commercio elettronico in quanto faciliterà la comuni-

cazione fra cliente e venditore, garantendo l’uniformità del mercato. Potrà

potenziare gli attuali motori di ricerca, aggiungendo tutti i vantaggi derivanti

dall’introduzione della semantica.

3.2 HTML (HyperText Markup Language)

HTML [1] è il linguaggio usato in Internet per i documenti ipertestuali, i

più diffusi, che possono essere veramente multimediali contenendo al loro

interno altri documenti di varia natura. In realtà nei file HTML non vi è un

documento nel documento, ma un riferimento ad altri documenti. Il browser

provvederà quindi ad includere nella visualizzazione di un documento HTML

anche i documenti cos̀ı collegati, per la gran parte si tratta di immagini.

3.3 Css (Cascading Style Sheets)

CSS non è un qualcosa di sè stante, ma lavora in abbinamento al linguaggio

HTML; possiamo pensarlo come un semplice meccanismo per aggiungere

3.3. CSS (CASCADING STYLE SHEETS) 16

Figura 3.1 � Architettura client-server

dello stile ad una pagina in HTML.

Più precisamente un foglio di stile è un set di regole stilistiche che de-

scrivono come un documento HTML verrà presentato all’utente.

Visto in quest’ottica, HTML viene usato per descrive la struttura del

documento e le sue varie parti incurandosi del suo aspetto, di come verrà

presentato al lettore che dovrà leggere il documento.

CSS in seguito descrive come gli elementi della pagina HTML verranno

presentati al lettore del documento stesso.

Usando CSS il Designer può specificare la presentazione della pagina

HTML in maniera indipendente dal contenuto; in questo modo ottengo una

separazione dei compiti fra produzione di un documento e sua presentazione

al mondo Word Wide Web. Questa tecnologia inoltre gode di un ulteriori

proprietà: è molto flessibile in quanto fornita di un meccanismo capace di

3.3. CSS (CASCADING STYLE SHEETS) 17

propagare un determinato aspetto presentazionale su tutte le pagine che il

Web Designer vuole siano interessate, cosicchè una modifica di presentazione

fatta in un unico file si ripercuote a tutti i documenti che ne fanno riferi-

mento; questa è una proprietà molto potente perchè permette di semplificare

notevolmente il lavoro di revisione e mantenimento delle pagine di un sito

Web.

Inoltre CSS mette in piedi un meccanismo noto con il termine a cascata

(cascading) per cui e’ possibile incorporare nel documento differenti fogli di

stile, tale caratteristica è in grado di distinguere e scegliere fra più possibili

aspetti presentazionali che possono rispecchiare la volontà di visualizzare a

video di un documento in un certo modo da parte del Web Designer, del-

l’utente o dalle opzioni del Browser, risolvendo eventuali conflitti, in base a

regole gerarchiche facendo prevalere uno stile sull’altro.

3.3.1 Css 1

Le specificazioni fornite da CSS1 sono un semplice bilanciamento fra il real-

izzare un semplice controllo di stile sul Web e le richieste dei Web Designer.

CSS1 è in grado di intervenire su :

• Proprietà dei font

• Proprietà quali il colore ed il background

• Proprietà sulla formattazione del testo (Spaziatura fra caratteri, tutto

il testo minuscolo, ecc... )

• Proprietà di posizionamento assoluto e relativo (CSS-P), e sulle Box

Propreties.

• Proprietà di visualizzazione (quali ad esempio di liste, di immagini, di

formattazione orientata ai Box, ecc...).

3.4. XML (EXTENSIBLE MARKUP LANGUAGE). 18

3.3.2 Css 2

CSS2 semplifica il Web Authoring ed il mantenimento dei siti Web; è stato

costruito sopra le specifiche di CSS1 e a parte poche eccezzioni, ne conserva

la piena compatibilità.

CSS2 supporta specifici dispositivi Media-Type con i quali gli autori

possono presentare i loro documenti su Browser visuali, dispositivi audio,

stampanti, dispositivi braille, e altri.

Le nuove specifiche inoltre supportano un miglior posizionamento dei

contenuti nella pagina Web, nuovi fonts scaricabili, accorgimenti per l’in-

ternazionalizzazione, contatori e numeratori automatici ed infine alcune pro-

prietà relative all’interfaccia utente.

3.4 XML (Extensible Markup Language).

XML [26, 24, 5, 6, 7] è oggi considerato come il linguaggio del futuro nelle

applicazioni web e non solo, in quanto può essere utilizzato per definire

documenti di qualsiasi tipo e formato.

Il linguaggio per eccellenza, che è considerato la base dell’World Wide

Web è HTML (Hypertext Markup Language), il quale consente di creare

pagine di informazione formattate in grado di raggiungere tramite internet

un numero di utenti in continuo aumento. Lo scopo principale per cui è

stato realizzato HTML è la visualizzazione contenuti testuali e grafici e per

questo motivo esso prende in considerazione soprattutto il modo in cui le in-

formazioni vengono presentate agli utenti sulla rete e non il tipo e la struttura

di tali informazioni.

Proprio per questo motivo è stato sviluppato, da parte di un gruppo di la-

voro coordinato dal W3C, (Web Consortium), il linguaggio XML, (Extensible

Markup Language).

XML è un linguaggio di markup aperto e basato su testo, che fornisce

informazioni di tipo strutturale (o sintattico) e semantico relative ai dati


veri e propri. È un metalinguaggio, che permette a gruppi di persone o ad

organizzazioni di creare dei linguaggi personalizzati di markup specifici per i

tipi di informazione che devono trattare.

Per molte applicazioni infatti gli esperti hanno già creato linguaggi di

markup specifici come ad esempio il Channel Definition Format, (CDF),

il Mathematical Markup Language, (MML), utilizzato per definire espres-

sioni matematiche, il Chemical Markup Language, (CML), usato per definire

formule chimiche, e molti altri. XML nasce dall’esigenza di portare nel

Web lo Standard Generalized Markup Language (SGML), il linguaggio in-

ternazionale per la descrizione della struttura e del contenuto dei documenti

elettronici di qualsiasi tipo, non contiene però tutte le funzioni complesse che

SGML possiede. Per questo XML si caratterizza per la semplicità con cui è

possibile scrivere documenti.

L’utilizzo di XML permette di superare il grosso limite attuale del Web

che risiede nelle limitazioni del linguaggio HTML, cioè la dipendenza da

un tipo di documento HTML, singolo e non estensibile, quindi dipendente

dal tipo di visualizzatore utilizzato. Infatti se ci poniamo il problema di

visualizzare i vari tipi di documenti esistenti per il Web, ci accorgiamo che

ne esistono numerosissimi dai formati più svariati, ad esempio i documenti

Word o quelli HTML, dei quali inoltre ne esistono varie versioni.

Pensare di tradurre tutti questi possibili formati che chiamiamo (di orig-

ine) in tutti i possibili formati di destinazione è impensabile.

La strada da percorrere è di avere un unico formato di origine, al quale

applicare dei metodi standard semplici ed efficaci per la traduzione nei cor-

rispondenti formati di destinazione.

Come primo approccio si potrebbe pensare di usare come formato stan-

dard HTML, ma non va bene, in quanto se pur ricco di funzioni non ha

attualmente la caratteristica di un formato universale; per esempio non è in

grado di esprimere la complessità dei documenti Word e non prevede molte

possibilità, tra le quali per esempio la scrittura di spartiti musicali o le formule

chimiche.


È inoltre uno standard di tipo proprietario infatti la sua sintassi contiene

tag predefiniti e non è possibile quindi descrivere tag personalizzati.

Come secondo approccio si può pensare di usare come formato per es-

primere i nostri documenti origine SGML, che in realtà è nato come formato

standard e neutrale per esprimere vari tipi di documento.

3.4.1 DTD (Document Type Definition)

I documenti XML che sono scambiati tra agenti software raramente con-

tengono markup arbitrari non vincolati. Al contrario, questi documenti

seguono una struttura comune condivisa da molti documenti XML in un

certo dominio.

Il DTD (Document Type Definition) [5] contiene le regole che definiscono

i tag usati nel documento XML, ovvero definisce la struttura del documento.

Esso, infatti, specifica gli annidamenti e le combinazioni permesse di elementi,

attributi e cos̀ı via. Il DTD può essere un file esterno oppure può essere

specificato direttamente all’interno del documento XML.

3.4.2 XML Schema

Per consentire sia al software che riconosce XML sia agli umani, di sapere

quale contenuto ci si aspetta in un determinato scenario, si richiede che queste

strutture comuni siano documentate in una formato comprensibile sia alla

macchina che all’uomo. E’ questa la motivazione primaria dietro a XML

Schema [5, 9] il quale permette di definire un vocabolario XML che può essere

utilizzato per descrivere documenti XML facendo uso della sua stessa sintassi.

Nonostante XML Schema offra un numero di vantaggi sui DTD, come l’uso

dei namespace e la definizione di tipi, il suo ruolo è essenzialmente lo stesso:

definire una grammatica per i documenti XML.


3.4.3 XPath (XML Path Language)

Un’espressione XPath [8] è un percorso di posizione (location path), costituito

da più passaggi di posizione (location step), i quali sono separati da barre

trasversali ( / ). Queste espressioni possono essere paragonate ai percorsi

utilizzati ad esempio nel prompt del dos per passare da una directory ad

un’altra.

Un tipico percorso che fa riferimento ai dati dello studente contenuti in un

documento XML può essere il seguente: /student/indirizzo/via dove la barra

iniziale orienta la ricerca verso il nodo radice student per poi scendere al nodo

figlio indirizzo che a sua volta contiene l’elemento figlio via. Ogni passaggio

di posizione viene considerato il contesto di quello/i che lo precedono, per

cui /student considera l’elemento student nel contesto del nodo radice del

documento ( / ). Il nodo che definisce il contesto viene detto nodo di contesto.

3.4.4 XSLT (Extensible Stylesheet Language Transfor-

mations)

Perché un documento XML non sia solo un insieme di contenuti senza alcu-

na particolare formattazione è necessario trasformarlo in un’altra forma per

essere utilizzabile.

Lo standard più diffuso per effettuare questo tipo di trasformazioni è il

linguaggio XSLT, il quale si appoggia ad un altro linguaggio, XPath, che

consente di individuare parti specifiche di un documento XML, consentendo

inoltre di rimodellare il contenuto dei documenti per adattarlo a quasi tutti

gli ambienti di destinazione ( Figura 3.2 ).

Il concetto più importante di XSLT è quello della trasformazione di una

struttura in un’altra, ciascuna delle quali viene detta albero. Gli alberi

definiti in XSLT sono due: l’albero del sorgente e quello del risultato.

Una trasformazione XSLT non fa altro che trasformare un albero del

sorgente (il documento XML), in un albero del risultato (ad esempio in una

pagina HTML).


Una cosa importante da notare è che l’albero del sorgente non viene

modificato durante una trasformazione ma viene soltanto ristrutturato.

Per effettuare una trasformazione è necessario sapere quali parti del-

l’albero del sorgente devono essere recuperate in modo tale che appaiano

nell’albero del risultato e quindi identificarle nel foglio di stile.

Le parti dell’albero del sorgente sono dette nodi e devono essere individ-

uate tramite dei costrutti definiti dal linguaggio XPath. XSLT identifica i

seguenti tipi di nodi: nodo radice, nodi di elemento, di attributo, di testo, di

istruzioni di elaborazione (o PI, PROCESSING INSTRUCTION ), e infine

nodi di commento e di namespace.

Figura 3.2 � Struttura del Web.


3.4.5 WML (Wireless Markup Language)

WML è un linguaggio di formattazione del testo basato su XML. Esso è

progettato specificatamente per le interfacce utente dei dispositivi mobili

come ad esempio i display dei telefonini, dei pager o dei PDA.

WML è stato progettato specificatamente per i dispositivi aventi partico-

lari caratteristiche: display di piccole dimensioni, limitata capacità elabora-

tiva, banda limitata e alta latenza.

Dispositivi di questo genere sono tipicamente i telefonini mobili, che han-

no un display piccolo (con un numero di righe compreso tra le 4 e le 10 linee)

e supportano l’input da utente tramite il tastierino numerico di scomodo uti-

lizzo, ed i PDA, che tipicamente dispongono di un display più grande (circa

320x300 pixel) e di una tastiera alfabetica e numerica più comoda da usare.

Il WAP Forum è l’ente preposto a fornire le specifiche del linguaggio ed i

successivi aggiornamenti.

3.4.6 DOM XML (Document Model Object XML)

Il DOM è un’interfaccia di programmi applicativi che permette di accedere

dinamicamente alla struttura e aggiornare il contenuto di documenti XML

o HTML. La struttura del documento viene paragonata ad un albero o, per

essere più precisi, ad una foresta.

L’aspetto da sottolineare è che DOM è semplicemente un modello logico

e non impone al documento una struttura ad albero. Esso è progettato

per essere utilizzato con ogni tipo di linguaggio in modo da garantirne una

diffusione più ampia.

In questo lavoro è stata utilizzata l’implementazione PHP, costituita da

una serie di interfacce in grado di manipolare in modo completo ogni elemento

di un documento XML. Fra queste sicuramente la più importante è Node che

gestisce il tipo di dato principale nel DOM, ovvero il nodo.

3.5. WAP (WIRELESS MARKUP LANGUAGE) 24

3.5 WAP (Wireless Markup Language)

Esamineremo ora le differenze tra la comunicazione client-server in una tipica

applicazione Web e quella tra un dispositivo Wap e il server Web.

In una tipica applicazione Web, un utente digita un indirizzo URL nel

browser, il quale invia una richiesta HTTP al server Web. Quest’ultimo inter-

preta la richiesta e determina quali risorse (file, script ecc), deve recuperare

o eseguire.

Ad esempio se l’URL specifica un file, questo viene inviato direttamente

al client, altrimenti nel caso venga specificata una pagina PHP, il server ne

esegue il codice e restituisce il risultato al client.

A differenza del caso precedente, per accedere ad un sito Web da un

dispositivo mobile, è necessario un server intermedio detto Gateway, che

gestisca i messaggi scambiati tra il cellulare e il server Web, e viceversa.

Per accedere ad un sito Web da un dispositivo cellulare basta digitare

l’URL nel browser Wap come nel caso precedente. Quest’ultimo crea una

richiesta dell’URL contenente l’identificativo dell’utente, e la invia attraver-

so il protocollo WSP (Wireless Session Protocol), al server Gateway. La

comunicazione dei dati tra il Gateway e il dispositivo cellulare avviene in

formato binario.

Poichè i dispositivi Wap non possono comunicare con dati in formato

basato su testo (o textbased), a causa della poca banda disponibile, cos̀ı come

avviene nelle comunicazioni sulla rete internet con il protocollo HTTP, viene

utilizzato il protocollo WSP che converte gli Header HTTP (pacchetti di

dati in formato basato su testo), in formato binario, diminuendo cos̀ı anche

la quantità di dati trasmessi. WSP utilizza il protocollo WTP (Wireless

Transaction Protocol) invece di TCP (Transmission Control Protocol), per

trattare le richieste e le risposte tra il server Gateway e il server Web.

Il Gateway interpreta le richieste inviategli dal browser WAP [21, ?] in

formato binario, le traduce in richieste di tipo http (formato testo), e poi

le invia al server Web. Quest’ultimo dopo aver ricevuto tali richieste le

3.6. 3.8 PHP 25

interpreta, determina quale/i risorse deve recuperare o eseguire e invia i

risultati che possono essere dei file o l’output ottenuto eseguendo uno script,

al Gateway.

Ciò che viene restituito al Gateway deve esser nella forma di documento

WML, il quale verrà poi convertito dal Gateway in formato binario per essere

inviato al dispositivo mobile. Quest’ultimo di conseguenza interpreta il codice

WML e visualizza la pagina sul display.

3.6 3.8 Php

Php [16, 12]è un modulo aggiuntivo per web servers che permette di creare

delle pagine web dinamiche. In pratica, una pagina in Php è composta sia

da tag html, sia da parti in codice di programmazione Php. Ogni porzione

di codice viene eseguito prima di essere inviato all’utente che ne fa richiesta.

Per funzionare, Php necessita di un suo motore di scripting (script engine)

che esegue le parti in codice prima che il web server invii la pagina all’utente.

Quando un utente richiede una pagina Php, il motore esegue il codice

contenuto all’interno di quella pagina. Durante l’esecuzione, il codice produce

delle informazioni in formato html. Infine il file (in completo formato html)

viene inviato all’utente. Se proviamo a visualizzare il sorgente di una pagina

in Php si può notare che non vi compare nessuna riga di codice Php.

Il vantaggio è proprio questo: nessun utente esterno, tranne il webmaster,

può accedere al codice e modificarlo. Per l’utente esterno, la pagina in Php

è esattamente uguale a una qualsiasi pagina in Html.

Capitolo 4

Sviluppo del progetto

Di seguito si parlerà della struttura del nostro progetto, attraverso alcuni

esempi di codice e sintassi generale delle tecnologie usate, dei linguaggi di

programmazione e di altri aspetti importanti.

Inoltre a seconda del client, verrà inclusa la visulizzazione dei vari output.

4.1 Struttura e sintassi di un documento xml

Una delle caratteristiche principali di XML [26, 24, 5, 6, 7] è la possibilità

di fornire una struttura ad un documento. Ogni documento comprende sia

una struttura logica, che una fisica. La struttura logica è simile a un modello

che indica quali elementi includere nel documento e in quale ordine, mentre

la struttura fisica contiene i dati effettivi utilizzati in un documento, quali

il testo memorizzato nella memoria del computer, un immagine, un video e

cos̀ı via.

4.1.1 Struttura logica

La struttura logica fa riferimento all’organizzazione delle parti di un docu-

mento; in altre parole indica il modo in cui viene creato un documento in

contrapposizione al contenuto del documento stesso. Un documento XML è

26

4.1. STRUTTURA E SINTASSI DI UN DOCUMENTO XML 27

Figura 4.1 � Struttura di un documento XML.

costituito da dichiarazioni, elementi, istruzioni di elaborazione e commenti.

Alcune componenti sono essenziali altre sono opzionali.

4.1.2 Il prologo

Il primo elemento strutturale di un documento XML è un prologo iniziale,

costituito da due componenti principali anch’esse opzionali: la dichiarazione

XML e la dichiarazione del tipo di documento.


4.1.3 Dichiarazione XML

La dichiarazione XML identifica la versione delle specifiche XML a cui è

conforme il documento. Sebbene la dichiarazione XML sia un elemento

opzionale, deve sempre essere inserita in documento XML. Il documento

inizia con una dichiarazione XML di base:

L’indicazione 1.0 specifica la versione dello standard XML alla quale è

conforme il documento XML stesso. Una dichiarazione XML può inoltre

contenere una dichiarazione di codifica (encoding) e una dichiarazione di

documento autonomo (standalone), nel seguente modo:

La dichiarazione di codifica identifica lo schema di codifica dei caratteri,

ad esempio UTF-8 o EUC-JP. Schemi di codifica diversi assegnano formati

di caratteri o linguaggi diversi.

La dichiarazione di documento autonomo, specifica se il documento XML

contiene al suo interno una DTD (standalone=Yes), o se la DTD è un

documento esterno (standalone=No), al quale ci si riferisce attraverso la

dichiarazione del tipo di documento che analizzeremo di seguito.

4.1.4 Dichiarazione del tipo di documento

La dichiarazione del tipo di documento è costituita da codice di markup che

indica le regole grammaticali o la definizione del tipo di documento DTD

per una particolare classe di documenti. Questa dichiarazione può anche es-

sere diretta a un file esterno che contiene tutta o parte della DTD e deve

essere visualizzata dopo la dichiarazione XML e prima dell’elemento Docu-

ment. Le seguenti stringhe di codice aggiungono una dichiarazione del tipo

di documento alle righe di codice precedenti:


Vediamo che oltre alla parola chiave !DOCTYPE, bisogna specificare il

tipo di documento, che non è altro che un identificatore. La parola chiave

SYSTEM permette al sistema di andare a recuperare il file DTD esterno il

cui nome è stato specificato tra i doppi apici.

4.1.5 L’elemento document

L’elemento Document (detto anche tag radice), contiene tutti i dati di un

documento XML, inclusi tutti i sottoelementi annidati e le entità esterne. È

paragonabile al tag

del linguaggio HTML. Può essere considerato simile anche all’unità C:

del computer.

Tutti i dati del computer sono memorizzati in questa singola unità, in

cui le cartelle e le sottocartelle, contengono le singole parti di dati in una

struttura logica e di semplice gestione.

Nel seguente esempio scriviamo delle stringhe di codice che aggiungono

all’esempio precedente un elemento Document, in questo caso l’elemento rac-

coltadati, e il nome del file DTD nella dichiarazione del tipo di documento

(ad esempio database.dtd) :

Aeroporto

Cronoca


Caratteristica molto importante in un documento XML è l’annidamento,

cioè il processo che consente di incorporare un oggetto o un costrutto all’in-

terno di un altro come nell’esempio precedente. Un documento XML può ad

esempio contenere elementi annidati e altri documenti. Ogni elemento secon-

dario, cioè un elemento diverso dall’elemento Document risiede interamente

all’interno del relativo elemento principale, cos̀ı :

XML segue regole di struttura rigide: ogni volta che un tag viene aperto

deve venir chiuso

dopo che tutti i tag aperti successivamente siano stati a loro volta chiusi.

Inoltre come abbiamo detto più volte, XML non ha marcatori predefiniti,

perciò non è possibile distinguere a priori tra tag singoli e tag accoppiati. Per

esempio in HTML abbiamo marcatori come hl che sono sempre accoppiati,

ma ne esistono altri, come img che non hanno bisogno di essere accoppiati.

Per questo motivo, in XML tutti i tag devono essere accoppiati.

Il linguaggio XML supporta anche un collegamento per elementi vuoti, il

tag di elemento vuoto. Questo tag unisce i tag di apertura e di chiusura per

un elemento senza alcun contenuto. Viene utilizzato un formato speciale:

NOMETAG/. In questo caso la barra segue il nome del tag, il che non è

possibile nel linguaggio HTML.


4.1.6 Struttura fisica del linguaggio XML

La struttura fisica di un documento XML è costituita da tutto il contenuto

del documento stesso. Le unità di memorizzazione definite entità, possono

essere parte integrante del documento o possono essere esterne.

Ogni entità è identificata da un nome univoco e da un contenuto specifico

che può essere costituito da un singolo carattere all’interno del documento o

da un file esterno di grandi dimensioni.

In termini di struttura logica di un documento XML, le entità vengono

dichiarate nel prologo e viene loro fatto riferimento nell’elemento Document.

Dopo aver dichiarato la DTD, l’entità può essere utilizzata in un punto

qualsiasi del documento.

Un riferimento di entità indica all’elaboratore di recuperare il contenuto

di un’entità, come stabilito dalla dichiarazione di entità, e di utilizzarla all’

interno del documento.

Un documento XML è costituito, oltre che dagli elementi visti preceden-

temente, da elementi, attributi, entità e commenti.

4.1.7 Gli elementi

Gli elementi sono indicati nel documento XML come i tag di HTML, tra

parentesi angolari

< >

e a differenza di HTML, possono essere personalizzati, attribuendogli nomi

qualsiasi.

Ogni tag aperto deve essere chiuso con le parentesi angolari e la barra (

/ ), seguita dal nome dell’elemento.

La sintassi per definire un elemento è la seguente:

testo (opzionale)


Per esempio definiamo un elemento di tipo INFO:

XML è molto più rigoroso di HTML, infatti mentre in quest’ultimo è possibile

omettere i tag di chiusura per alcuni elementi per esempio

, ,

in XML ciò provocherebbe un errore da parte dell’analizzatore del docu-

mento.

Come si può notare dall’esempio precedente all’interno dei due tag è

possibile inserire del testo, il cui tipo dipende dalla definizione del tipo di

contenuto. Quest’ultimo può essere di due tipi:

PCDATA, Parsed Character Data, ossia dati carattere che possono essere

analizzati dall’analizzatore sintattico, e CDATA, Character Data, cioè dati

considerati come testo. La definizione del tipo di contenuto si trova nella

dichiarazione del tipo ELEMENT della DTD. Nel caso in cui tra i due tag

non vi sia alcun testo, (ecco perché la scritta testo(opzionale) tra i due tag),

l’elemento viene detto vuoto o empty.

Oltre al normale testo gli elementi possono contenere riferimenti a dati

binari o a character data, (cdata). I dati binari assumono la forma di file

esterni, quali immagini e altre applicazioni. Di contro i file di testo possono

contenere character data, che possono essere costituiti da riferimenti ad entità

esterne o caratteri di testo standard.

Le sezioni di testo identificate come CDATA sono elaborate dall’analiz-

zatore XML come informazioni di caratteri di semplice testo, e non come

markup. Ciò consente di visualizzare del testo di markup di esempio all’in-

terno del testo visibile del documento.

Nella creazione degli elementi inoltre, bisogna tenere presenti le varie

regole di assegnazione dei nomi agli elementi.


Il nome di un elemento può essere costituito da qualsiasi combinazione

di lettere, numeri, punti, trattini e caratteri di sottolineatura. Essi possono

iniziare con un qualsiasi di questi elementi, ma non è possibile inserire spazi

nel nome dell’elemento, in quanto lo spazio viene utilizzato come separatore

per identificare la transizione da un elemento ad un attributo.

Un esempio di elementi sintatticamente corretti è il seguente:

invece il seguente elemento è sintatticamente errato:

perché vi è uno spazio tra l’elemento e il numero 1.

4.1.8 Gli attributi

Gli attributi consentono di associare valori a un elemento, senza che siano

considerati parte del contenuto dell’elemento stesso. Ad esempio osserviamo

un comune elemento HTML e l’utilizzo di un attributo:

Microsoft Home Page

In questo caso l’elemento Anchor indicato dal tag

contiene un attributo denominato HREF.

Il valore dell’attributo è http://www.microsoft.com. Mentre il valore

non viene mai visualizzato dall’utente, l’attributo contiene importanti in-

formazioni relative all’elemento e fornisce la destinazione dell’ancora.

Questo formato del nome e del valore mostra il modo in cui sono utilizzati

gli attributi nel linguaggio XML.

La sintassi per definire un attributo è la seguente:


• I nomi degli attributi possono contenere qualsiasi lettera o numero, il

punto o il carattere di sottolineatura, (è possibile usare i due punti ma

essi sono riservati ai namespace).

• I valori degli attributi devono essere racchiusi sempre tra le virgo-

lette(””), a differenza di quanto accade in HTML nel quale vengono

omesse.

• Non sono ammessi più attributi con lo stesso nome in un unico elemen-

to.

Come si può notare le regole non sono moltissime. Un altro aspetto

importante è che uno stesso attributo può essere utilizzato in un numero

illimitato di elementi ad esempio:

(elemento document o elemento radice)

Aeroporto

Cronaca

(elemento document o elemento radice)

Aeroporto

Cronaca

.....

(chiusura dell’elemento radice)

Affinché gli attributi possano essere definiti devono essere dichiarati nella

DTD, tramite una dichiarazione di tipo

La mancanza di tale dichiarazione comporta un errore da parte del processore

XML.


4.1.9 Documenti ben-formati (Well Formed)

Un documento XML è considerato valido se segue tutte le regole, sia strut-

turali che grammaticali.

Un documento valido è conforme quindi anche a tutti i limiti di validità

relativi ad XML. L’elaboratore dovrà comprendere i limiti di validità delle

specifiche XML e verificare possibili violazioni all’interno del documento.

Se l’elaboratore trova un errore, deve comunicarlo all’applicazione XML.

Dovrà inoltre leggere la DTD, convalidare il documento e riportare qualsi-

asi violazione all’applicazione XML. Dato che questi controlli possono richiedere

tempo e occupare larghezza di banda e poiché la convalida non sempre è nec-

essaria, il linguaggio XML supporta la nozione di documento ben formato o

Well Formed.

Anche se ben formato significa che è necessario seguire alcune regole, non

è richiesto la stessa rigidità dei limiti di validità. Il concetto di documento

ben formato è relativamente nuovo in XML.

Un documento XML ben formato è più facile da leggere per un program-

ma ed è pronto per la distribuzione in rete.

Più specificatamente, i documenti ben formati hanno queste caratteris-

tiche:

• Tutti i tag di apertura e di chiusura corrispondono.

• I tag vuoti utilizzano una sintassi XML speciale.

• Tutti i valori degli attributi sono racchiusi tra virgolette.

• Tutte le entità sono dichiarate.

Quindi, un documento XML valido rispetta i tag e le norme di annida-

mento impostate nella DTD del documento, mentre un documento XML ben

formato viene strutturato in modo appropriato per l’utilizzo da parte di un

computer.


4.1.10 Struttura dei fogli di stile

Cos̀ı come i documenti anche i fogli di stile contengono come prima istruzione

la dichiarazione XML

Un tipico foglio di stile XSLT contiene un elemento radice che è identificato

dalla seguente sintassi:

dove:

• version, indica la versione della specifica XML a cui il foglio di stile è

conforme

• altre dichiarazioni di namespace, rappresenta la possibilità di aggiun-

gere dei namespace, oltre a quello predefinito indicato nella seconda

riga della sintassi precedente.

Questi namespace devono tener conto dei requisiti dell’elaboratore XSLT

ed eventualmente dell’elaboratore che deve produrre l’output. Alcuni dei

namespace più utilizzati sono:

• xmlns=http://www.w3.org/TR/REC-HTML40 il quale indica che gli

elementi del foglio di stile deve essere conformi ad HTML versione 4.0.

• xmlns=http://www.w3.org/1999/xhtml questo namespace è utilizzato

per indicare che il foglio di stile è conforme alla specifica XHTML 1.0.


• xmlns:wml=http://www.wapforum.org/xmlns/wml viene utilizzato per

trasformare XML nel linguaggio WML (WIRELESS APPLICATION

PROTOCOL), il linguaggio utilizzato nella telefonia cellulare. Utiliz-

zato anche per il nostro progetto.

Questo è un esempio di foglio di stile un po più complesso per il nostro

progetto:

mostra.php?val=&var=1


4.1.11 Le pagine WML

Le pagine o documenti WML sono strutturate in deck. Ogni deck consiste di

una o più cards, che sono le unità di visualizzazione sul browser, quelle che

per il dispositivo WAP sono le pagine vere e proprie.

Ogni deck inizia e termina con

.. .

e ogni card con

. . .

Quando il browser WAP accede ad un deck, lo legge interamente, e la

navigazione al suo interno è fatta senza bisogno di scaricare nuovi dati dal

server. Una volta che il deck è scaricato dal browser, tutte le sue cards

rimangono staticamente all’interno della sua memoria, finchè non si accede

ad un altro deck o si forza un reload.

I deck devono avere una dimensione massima, per assicurare la compati-

bilità tra vari dispositivi cellulari, in quanto questi hanno memorie di diversa

capacità. Ecco un esempio di deck che contiene al suo interno due card:

. . .

. . .

L’elemento card può avere uno o più attributi (o proprietà), di cui solo id

è indispensabile, in quanto definisce il nome stesso della card, indispensabile

per poterla utilizzare e richiamare, pertanto risulta necessario, deve essere

univoco e deve essere composto da una sola parola.


La difficoltà nel nostro progetto è stata di non avere una pagina WML ma

un documento XML, cosi da potergli applicare un foglio di stile e generare

un documento con sintassi WML.

Di seguito riporto una parte del codice:

’]]>’

’]

]>’

(con questo tag diventa un documento WML)


. . .

che genera :

’<?xml version="1.0"?>’

’/p>

PUBLIC"-//WAPFORUM//DTD WML

1.1//EN""http://www.wapforum.org/DTD/wml_1.1.xml">’

4.2. PHP 42

4.2 Php

La principale peculiarità del web dinamico è la possibilità di variare i con-

tenuti delle pagine in base alle richieste degli utenti.

Questa possibilità si materializza attraverso i meccanismi che permet-

tono agli utenti, oltre che di richiedere una pagina ad un web server, anche

di specificare determinati parametri che saranno utilizzati dallo script php

per determinare quali contenuti la pagina dovrà mostrare. Come esempio,

possiamo immaginare una pagina il cui scopo è quello di visualizzare le carat-

teristiche di un certo tipo di dato, prelevandole da un database nel quale sono

conservati. Nel momento in cui si richiama la pagina, si dovrà specificare il

4.2. PHP 43

codice del dato che deve essere visualizzato, per consentire allo script di

prelevare dal database i dati appropriati e mostrarli all’utente.

4.2.1 Sintassi php

Si tratta dei tag

Le variabili sono alcuni dei componenti fondamentali di qualsiasi linguag-

gio di programmazione, in quanto ci consentono di trattare i dati del nostro

programma senza sapere a priori quale sarà il loro valore. Possiamo immag-

inare una variabile come una specie di contenitore all’interno del quale viene

conservato il valore che ci interessa, e che può cambiare di volta in volta.

In PHP possiamo scegliere il nome delle variabili usando lettere, primo

carattere del nome deve essere però una lettera o un underscore (non un

numero). Dobbiamo inoltre ricordarci che il nome delle variabili è sensibile

all’uso delle maiuscole e delle minuscole:

di conseguenza, se scriviamo due volte un nome di variabile usando le

maiuscole in maniera differente, per PHP si tratterà di due variabili distinte!

Nello script PHP il nome delle variabili è preceduto dal simbolo del dollaro

($).

PHP [16, 12] ha una caratteristica che lo rende molto più flessibile rispet-

to ad altri linguaggi di programmazione: non richiede, infatti, che le vari-

abili vengano dichiarate prima del loro uso. Possiamo quindi permetterci di

riferirci ad una variabile direttamente con la sua valorizzazione:

$a = 5;

$a = 9;

$b = 4;

$c = $a * $b;

print $z;

4.2. PHP 44

Vediamo un altro esempio:

$a = 74; $b = 29; $risultato = $a + $b;

print $risulato;

$colori =array(’bianco’, ’nero’, ’giallo’, ’verde’, ’rosso’);

print$ colori[2]; //stampa ’giallo’

4.2.2 Php e html

PHP è un linguaggio la cui funzione fondamentale è quella di produrre codice

HTML, che è quello dal quale sono formate le pagine web. Siccome però

PHP è un linguaggio di programmazione, abbiamo la possibilità di analizzare

diverse situazioni (l’input degli utenti, i dati contenuti in un database) e di

decidere, di conseguenza, di produrre codice HTML condizionato ai risultati

dell’elaborazione. Questo è, in parole povere, il Web dinamico.

Quando il server riceve una richiesta per una pagina php, la fa analizzare

dall’interprete del PHP stesso, il quale restituisce un file contenente solo il

codice che deve essere inviato al browser (in linea di massima HTML, ma

può esserci anche codice JavaScript, fogli di stile css eccetera).

Dunque, come si realizza la produzione di codice HTML?

La prima cosa da sapere è come fa PHP (inteso come interprete) a ri-

conoscere il codice php contenuto nel file che sta analizzando. Il codice php

infatti deve essere compreso fra appositi tag di apertura e di chiusura, che

sono i seguenti:

Pagina di prova in PHP

4.2. PHP 45

4.2.3 Le variabili GET e POST

Ora non ci occuperemo di come vengono salvati o recuperati i dati da un

database, ma del modo in cui PHP li riceve dall’utente. Esistono due sistemi

per passare dati ad uno script: il metodo GET e il metodo POST.

Il metodo GET consiste nell’accodare i dati all’indirizzo della pagina richi-

esta, facendo seguire il nome della pagina da un punto interrogativo e dalle

coppie nome/valore dei dati che ci interessano. Nome e valore sono sepa-

rati da un segno di uguale. Le diverse coppie nome/valore sono separate dal

segno ’&’.

Quindi, immaginando di avere la pagina prova.php che mostra le carat-

teristiche di un dato passandole il codice (val) e la categoria(pos) del dato

stesso, diciamo che, per visualizzare i dati del prodotto 7 della categoria 2,

dovremo richiamare la pagina in questo modo:

La stringa che si trova dopo il punto interrogativo, contenente nomi e val-

ori dei parametri, viene detta query string. Quando la pagina prodotto.php

viene richiamata in questo modo, essa avrà a disposizione, al suo interno, le

variabili

$_GET[’val’] (con valore ’7’) e \$_GET[’pos’] (con valore ’2’)

4.2. PHP 46

Il metodo POST viene utilizzato con i moduli: quando una pagina HTML

contiene un tag

uno dei suoi attributi è method, che può valere GET o POST. Se il metodo

è GET, i dati vengono passati nella query string, come abbiamo visto prima.

Se il metodo è POST, i dati vengono invece inviati in maniera da non essere

direttamente visibili per l’utente, attraverso la richiesta HTTP che il browser

invia al server.

I dati che vengono passati attraverso il metodo POST sono memorizzati

nell’array

$_POST

Anche questo array, come

$_GET

è un array superglobale. Quindi, per fare un esempio attraverso un piccolo

modulo:

4.2. PHP 47

Questo modulo contiene semplicemente una casella di testo che si chiama

’nome’ e una checkbox che si chiama ’nuovo’, il cui valore è definito come

’si’. Poi c’è il tasto che invia i dati, attraverso il metodo POST, alla pagina

elabora.php. Questa pagina si troverà a disposizione la variabile

$_POST[’nome’]

contenente il valore che l’utente ha digitato nel campo di testo; inoltre, se è

stata selezionata la checkbox, riceverà la variabile

$_POST[’nuovo’]

con valore ’si’. Attenzione però: se la checkbox non viene selezionata

dall’utente, la variabile corrispondente risulterà non definita.

4.2.4 Codici e funzioni principali

L’introduzione appena descritta servirà per spiegare come funziona il nostro

codice per la realizzazione del progetto.

La prima funziona che si trova nell’indice è:

\$browse = getenv("HTTP_USER_AGENT");

if (preg_match("/MSIE/i","\$browse")){

header ("Location: web/sitoweb.php");

}

elseif (preg_match("/Netscape/i","$browse")){

header ("Location: web/sitoweb.php");

4.2. PHP 48

}

/// Gestione palmari Pocket PC && WINDOWS

elseif (preg_match("/MSPIE/i","\$browse")){

header ("Location: palmare/sitopalmare.php");

}

elseif (preg_match("/Windows CE/i","\$browse")){


}

elseif (preg_match("/PalmSource/i","\$browse")){


}

/// Gestione cellulari

elseif (preg_match("/nokia/i","\$browse")){

header ("Location: cellulare/sitocellulare.php");

}

grazie a questo codice riusciamo a capire il tipo di client che fa la richiesta

al server o meglio con

\$browse = getenv("HTTP_USER_AGENT");

viene restituito dal server un certo tipo di informazioni utili al client.

Una seconda funziona è la trasformazione di un documento xml, tramite

xsl, in html:

4.2. PHP 49

$xh = xslt_create();

// Process the document

if (xslt_process($xh, ’sample.xml’, ’sample.xsl’, ’result.xml’)) {

readfile(’result.xml’);

print "\n";

} else {

print "error code is " . xslt_errno($xh);

}

xslt_free(\$xh);

?>

Una terza funzione importante è il passaggio della variabile per il diverso

tipo di client con il passaggio di una var col metodo GET:

Con la stringa

4.2. PHP 50

$var = ($HTTP_GET_VARS[’var’]);

$stile = "xsl/palmare/stile$var.xsl";

riusciamo ad ottenere lo stile giusto creato da noi in xsl.

Un’ultima funzione, la più impegnativa, è data dalla figura di un capore-

dattore (figura 4.10) che si preoccupa di far scegliere all’utente il tipo di

navigazione che vuole fare all’interno del progetto e in che modo vuole venga

visualizzata (figura 4.11).

Codice 4.1:

4.2. PHP 51

$value) {

$stringa .= "\r\n\r\n";

$stringa .= "\r\n";

$stringa .= "\r\n";

$stringa .= "\r\n";

$stringa .= "\r\n\r\n";

}

$stringa .= "\r\n";

$filename = "../apache/o.xsl";

.

.

.

4.2. PHP 52

?>

Una volta passato al caporedattore i valori inseriti nel modulo, il codice

4.2 crea, scrivendolo come stringa, un foglio xsl apposito per la visualizzazione

dall’utente scelta.

4.2.5 Visualizzazione in base al client

Arriviamo alla visualizzazione vera e proprio dei diversi tipi di client.

Nel caso si tratta di un palmare, cioè viene rsetituita una stringa che fa

match con

(preg_match("/MSPIE/i","\$browse"))

(preg_match("/Windows CE/i","\$browse"))

(preg_match("/PalmSource/i","\$browser"))

la visualizzaizone sarà del tipo (figura 4.2, figura 4.3, figura 4.4).

Nel caso si tratta di un PC, cioè viene restituita una stringa che fa match

con

(preg_match("/MSIE/i","\$browse"))

(preg_match("/Netscape/i","$browse"))

(preg_match("/Opera/i","$browse"))

(preg_match("/Mozilla/i","$browse"))

la visualizzaizone sarà del tipo (figura 4.5, figura 4.6, figura 4.7).

Nel caso si clicca sul collegamento sito accessibile si avrà la seguente

visualizzazione (figura 4.8, figura 4.9):

Nell’ultimo caso, i telefonini, si avrà una visualizzazione del tipo (figura

4.12, figura 4.13) con codice:

(preg_match("/nokia/i","$browse"))

(preg_match("/ericsson/i","$browse"))

anche se noi abbiamo avuto un po di problemi per la visualizzazione del

nostro progetto su cellulari.

4.2. PHP 53

Figura 4.2 � Visualizzazione palmare (a).

4.2. PHP 54

Figura 4.3 � Visualizzazione palmare (b).

4.2. PHP 55

Figura 4.4 � Visualizzazione palmare (c).

4.2. PHP 56

Figura 4.5 � Web (a).

Figura 4.6 � Web (b).

4.2. PHP 57

Figura 4.7 � Web (c).

Figura 4.8 � Accessibile (a).

4.2. PHP 58

Figura 4.9 � Accessibile (b).

4.2. PHP 59

Figura 4.10 � Caporedattore.

Figura 4.11 � Trasformazione del caporedattore.

4.2. PHP 60

Figura 4.12 � Wml (a).

4.2. PHP 61

Figura 4.13 � Wml (b).

Conclusioni

Come si è già stato accennato nel capitolo introduttivo, per garantire lo

sviluppo del Semantic Web è necessario che l’intera comunità web unisca gli

sforzi per creare sistemi validi atti a rendere semanticamente accessibile un

insieme sempre maggiore di informazioni. I tentativi per facilitare quest’op-

erazione sono stati molteplici, ma solo una piccola parte di essi, o addirittura

nessuno, ha raggiunto realmente un’ampia realizzazione. Questo fallimento

non è dovuto ad un cattivo approccio (la maggior parte degli esperimenti si

è rilevata utile e ben testata): la motivazione principale è da ricercarsi nella

mancanza di una vera e propria applicazione efficiente, ossia talmente valida

da sbaragliare le altre. Un altro aspetto che ha rallentato lo sviluppo del

Semantic Web è la mancanza di un sistema scalabile, in grado di integrare la

semantica nel web attuale senza precludere futuri sviluppi. Il sistema propos-

to cerca di risolvere questi problemi, proponendo un prototipo interamente

basato sugli standard esistenti e concepito con una struttura modulare in

grado di permettere successive espansioni e modifiche. La validità dell’ap-

proccio è stata testata attraverso alcune prove, le quali hanno evidenziato i

vantaggi che si possono ottenere dal sopracitato sistema. Questo lavoro non

ha la presunzione di rappresentare una soluzione perfetta e definitiva, sem-

plicemente vuole costituire un piccolo passo in avanti verso una direzione che

sembra essere molto promettente. In futuro, infatti, si potrebbero realizzare

algoritmi di frammentazione più efficienti, in grado di scomporre una risorsa,

anche differente da un semplice documento testuale, in modo intelligente.

62

Bibliografia

[1] B. Bos and H. Wium Lie. CSS, http://www.w3.org/TR/1999/REC-CSS1-19990111.

[2] K.I. Aardal, S.P.M. van Hoesel, A.M.C.A. Koster, C. Mannino, and A. Sassano.

Models and solution techniques for frequency assignment problems. Technical report,

Konrad-Zuse-Zentrum fur Informationstechnik, December 2001.

[3] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific American,

May 2001.

[4] B. Bos, H. Wium Lie, C. Lilley, and I.Jacobs. CSS, level 2 Recommendation -

http://www.w3.org/TR/1998/REC-CSS2-19980512/.

[5] D. Box. Essential XML, beyond markup. Addison-Wesley, 2000.

[6] T. Bray and J. Paoli. Extensible Markup Language (XML) -

http://www.w3.org/TR/REC-xml.

[7] World Wide Web Consortium. XML Linking Language (XLink)Version 1.0., W3C

Recommendation.

[8] World Wide Web Consortium. XML Path Language (XPath)Version 1.0 W3C

Recommendation.

[9] D. C. Fallside. XML Schema Part 0: Primer - http://www.w3.org/TR/xmlschema-0.

[10] http://i dome.giallo.it/docs/pagina.phtml?

[11] http://www.aib.it/aib/cwai/WAI trad.

[12] http://www.apache.org.

[13] http://www.cemonster.com/.

[14] http://www.constile.org/.

[15] http://www.html.it.

[16] http://www.php.net.

63

BIBLIOGRAFIA 64

[17] http://www.w3.org/TR/REC smil.

[18] http://www.w3.org/WAI/Resources/WAI UA-Support.

[19] http://www.wapforum.com.

[20] http://www.webaccessibile.org.

[21] MobileWAP. Introduzione al WAP - http://www.mobilewap.com.

[22] Sofia Postai. Il mestiere del Web. Hops, 2003.

[23] Sofia Postai. Siti che funzionano. Hops, 2004.

[24] Bonnie SooHoo. XML tutorial - http://webreview.com/pub/2000/08/04/feature/index04.html.

[25] S.U. Thiel, S. Hurley, and D.H. Smith. Frequency assignment algorithms. Technical

report, Radiocommunications Agency Agreement, April 1997.

[26] J. Veen. XML, Metadata for the rest of us, - http://www.hotwires.lycos.com/.

PROGETTAZIONE DI TECNOLOGIE FLESSIBILI PER LA PRESENTAZIONE DI … · 2018. 10. 8. · tra un...

Documents

Transcript of PROGETTAZIONE DI TECNOLOGIE FLESSIBILI PER LA PRESENTAZIONE DI … · 2018. 10. 8. · tra un...