1 / 13

Linguaggi di schema per XML e modelli astratti di documenti

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. L’ ingegneria dei documenti. Le componenti di un documento Contenuto: informazione allo stato puro (“la mia data di nascita”).

audra
Download Presentation

Linguaggi di schema per XML e modelli astratti di documenti

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related