Linguaggi di schema per XML e modelli astratti di documenti

1. Linguaggi di schema per XML e modelli astratti di documenti Tesi di Laurea di Daniele Gubellini Relatore: Chiar.mo Prof. Fabio Vitali Bologna, 23 marzo 2005

2. L’ ingegneria dei documenti • Le componenti di un documento • Contenuto: informazione allo stato puro (“la mia data di nascita”). • Struttura: risponde alla domanda “dov’è” un dato e conferisce metainformazioni. • Esempio: 01031978 ? • Presentazione: formattazione visiva. • Esempio: 01/03/1978. • Sintassi • XML, markup descrittivo. • Vincoli • Linguaggi di schema: DTD, XML Schema.

3. L’obiettivo • Identificare gli schemi utili e potenzialmente ricchi di significato • Eliminare i costrutti sintattici non necessari nella costruzione di strutture significative. • Definire un linguaggio di schema minimale che permetta l’espressione di tutti e soli gli schemi catalogati.

4. Descrizione Presenza di alcuni frammenti di content model come “(B|C)*” in più dichiarazioni. Aggiungendo un elemento K si avrebbe incoerenza semantica? “(B|C)*” sono logicamente indissolubili o indipendenti? Ripetizione di sequenze. Un’eventuale relazione semantica tra A e B non è rafforzata dalla sintassi. Sequenza di elementi non ripetibili ed elementi ripetibili. T sembra un’informazione unica che dice qualcosa sulla lista di B. Questo fatto non è rafforzato dalla sintassi. Content model DTD <!ELEMENT E1 (X,(B|C)*> <!ELEMENT E2 (Y,(B|C)*> <!ELEMENT E (A,B)*> <!ELEMENT E (T,B*)> Content model DTD inutili: esempi

5. Normalizzazione • Documenti ben ingegnerizzati • Definizione delle dipendenze funzionali: fondamentali per modellare i dati in modo elegante, riutilizzabile e con una semantica precisa e non ambigua. • Normalizzazione: applicata ai contenitori logici che danno profondità e struttura al documento. • Esempio: TeiLight, elemento “div” • ((argument|byline|dateline|docAuthor|docDate|epigraph|head|opener| salute|signed|anchor|gap|index|interp|interpGrp|lb|milestone|pb)*,(((div|divGen),(anchor|gap|index|interp|interpGrp|lb|milestone|pb)*)+|(((eg|bibl|biblFull|ab|l|lg|p|sp|figure|cit|q|label|list|listBibl|note|stage|table),(anchor|gap|index|interp|interpGrp|lb|milestone|pb)*)+,((div|divGen),(anchor|gap|index|interp|interpGrp|lb|milestone|pb)*)*)),((byline|closer|dateline|epigraph|salute|signed|trailer),(anchor|gap|index|interp| interpGrp|lb|milestone|pb)*)*)

6. La soluzione • Adozione di Pattern • Espressione di strutture utili e potenzialmente ricche di significati. • Adozione di wrapper. • Semplificazione della sintassi: DTD-- • Rendere leciti (esprimibili) solo i Pattern. • Conversione di strutture DTD in DTD--.

7. Marker “BR”: <BR/> Record “Persona”: <Persona> <Nome>Daniele</Nome> <Cognome>Gubellini</Cognome> <Indirizzo>C. Italia 19</Indirizzo> <Comune>S.G.Persiceto</Comune> </Persona> Blocco “Testo”: <Testo> Questo è un testo con elementi tipografici come <bold>grassetto</bold> e <ita>italico</ita> oppure <bold><ita>grassetto e italico</ita></bold> <BR/> </Testo> Atomo “Giorno”: <Giorno>23</Giorno> Tabella “Persone”: <Persone> <Persona> <Nome>Daniele</Nome> <Cognome>Gubellini</Cognome> <Indirizzo>C. Italia 19</Indirizzo> <Comune>S.G.Persiceto</Comune> </Persona> <Persona> <Nome>Mara</Nome> <Cognome>Serra</Cognome> <Indirizzo>C. Italia 19</Indirizzo> <Comune>S.G.Persiceto</Comune> </Persona> </Persone> Pattern di design (1/2)

8. Contesto Additivo “Contratto”: <Contratto> ... <Firma>Daniele Gubellini</Firma> ... </Contratto> Firma può apparire ovunque all’interno di Contratto. È possibile limitare ad uno l’occorrenza dell’elemento Firma. Contesto Sottrattivo “Nota”: <Testo> <Paragrafo> Questo è un paragrafo con note. <Nota> Una nota contiene paragrafi <Paragrafo>Una nota può contenere altre note</Paragrafo> </Nota> </Paragrafo> </Testo> Proibisco la presenza di Note all’interno di Note. Pattern di design (2/2)

9. I wrapper • (Studente,(Cellulare|Telefono)*) e (Prof,(Cellulare|Telefono)*) • Strutture logicamente indissolubili: (Studente,recapitiTelefonici) e (Prof,recapitiTelefonici) dove recapitiTelefonici=(Cellulare|Telefono)* • Strutture logicamente separate: (Studente,recapitiTelefoniciStudente) e (Prof,recapitiTelefoniciProf) dove recapitiTelefoniciStudente=recapitiTelefoniciProf=(Cellulare|Telefono)* • Possibile aggiungere a recapitiTelefoniciProf un TelefonoUfficio. • (Domanda,Risposta)* • Rafforzare il legame semantico tra Domanda e Risposta: (FAQ*) dove FAQ=(Domanda,Risposta). • (Titolo,Capitolo*) • Titolo è riferito alla lista dei capitoli: (Titolo,Capitoli) dove Capitoli=(Capitolo*).

10. Il metalinguaggio DTD-- • Espressione di tutte e sole le strutture dei Pattern. • Sintassi • Minimalità sintattica: SCHEMA = ISTANZA. • L’opzionalità del DTD è meno problematica. • Lo schema diventa più espressivo grazie all’astrazione dei Pattern. • Sintassi instance based:scrivere uno schema diventa semplice come scrivere un’istanza. • Literate programming.

11. Marker, Atomo, Record. Tabella “Persone”: <Persone> <Persona> <Nome>Nome</Nome> <Cognome>Cognome</Cognome> <Indirizzo>Via e n.civico</Indirizzo> <Comune>Comune</Comune> </Persona> <dtd:etc/> </Persone> Contesto Additivo “Contratto”: <Contratto dtd:include=“!Firma”> .... <Firma>Daniele Gubellini</Firma> .... </Contratto> Blocco “Testo”: <Testo dtd:type=“T”> Questo è un testo con elementi tipografici come bold <bold dtd:type=“T”/> e ita<ita dtd:type=“T”/>. Può contenere anche linee <BR/>. </Testo> Contesto Sottrattivo “Nota”: <Testo dtd:type=“T”> Questo testo contiene paragrafi <Paragrafo dtd:type=“T”/>e note <Nota dtd:type=“T” dtd:exclude=“Nota” /> </Testo> DTD--: sintassi dei Pattern

12. Tool di conversione • Da DTD a DTD-- • Vengono semplificati e convertiti i DTD in sintassi DTD--. • Test di affinità con il nuovo modello di design. • Spunto critico per una rimodellazione dello schema. • Da istanze/schemi a DTD-- • Unificazione di istanze e schemi DTD-- in un unico schema. • Schemi (A|B). • Da DTD-- a SchemaPath • Tappa intermedia del processo di validazione.

13. Conclusioni • Design basato su Pattern • Abbassa l’incertezza sintattica, permette “visualizzazioni” astratte, forza un design semplice e chiaro, migliora il rapporto tra contenuto e struttura. • Favorisce il processo di normalizzazione. • Autoreferenzialità: la minimalità sintattica risolve in parte il problema dell’opzionalità del DTD. • Semplifica eventuali processi di conversione. • Sviluppi futuri: nuovi pattern? • DTD-- • Linguaggio di schema semplice, basato su XML, di facile apprendimento. • Sviluppi futuri: co-constraints, tipi di dato per Atomo ecc.