Document Type Definition (DTD) e analisi sintattica di XML

Linguaggi e tecnologie per il Web
Corso di Laurea in Ingegneria Informatica e Automatica
Sapienza Università di Roma
a.a. 2017/2018

XML

Parte 2:
Document Type Definition (DTD) e cenni su XML Schema

Luigi Dragone, Riccardo Rosati

Document Type Definition (DTD) e analisi sintattica di XML

Il tipo di documento (DTD)
Dichiarazioni di elementi e content model
Relazione tra DTD e ECFG
Esempi di DTD
Dichiarazioni di entità e di attributi
Limitazioni di DTD
Introduzione a XML Schema

Forma di un documento XML

Un documento XML è costituito da:

un prologo (opzionale), costituito da
- una dichiarazione XML
- una DTD (Document Type Definition)
un'istanza di documento, contenente
- testo libero
- elementi
- attributi
- entità
- ...

Funzione del DTD

Un documento XML ben formato può avere una struttura arbitraria:

elementi di nome arbitrario
attributi arbitrari in qualunque elemento
elementi organizzati in modo arbitrario

Sono utili, ma poco più utili di testo non strutturato.

Serve un meccanismo per imporre struttura ad un documento:

elementi ammessi
attributi ammessi
stutturazione degli elementi
definizione di nuove entità (interne ed esterne)

Dichiarazione di tipo di documento (DTD)

Un DTD specifica quali sono le strutture ammesse per l'istanza di documento:

specifica il tipo del documento, ovvero il tipo dell'elemento radice
contiene tre insiemi di dichiarazioni:
- di tipi di elemento
- di attributi
- di entità

L'insieme di tipi di elemento in un DTD viene detto vocabolario.

Dichiarazioni in XML

In XML tutte le dichiarazioni hanno la forma:

<!OGGETTO-DICHIARATO ... >

Esempi:

<!DOCTYPE ... >
 <!ELEMENT ... >
 <!ATTLIST ... >
 <!ENTITY ... >
 <!NOTATION ... >

Dichiarazione di tipo di documento

Un documento XML può contenere una DTD.

La DTD deve precedere il primo elemento (l'elemento radice).

Le dichiarazioni nella DTD possono essere:

interne al documento stesso
<!DOCTYPE esempio [
<!ELEMENT esempio (#PCDATA)> ]>
esterne al documento in un altro file
(locale o specificato da un URI)
<!DOCTYPE esempio SYSTEM "esempio.dtd">
esterne con un DTD subset interno

DTD - Esempio

<!DOCTYPE TechRepDip [

 <!ELEMENT TechRepDip (Intestazione, Sezione+, Bibliografia?)>
 <!ELEMENT Intestazione (Numero, Data, Titolo, Autore+, Sommario?)>
 <!ELEMENT Data (Giorno?, Mese, Anno)>
 <!ELEMENT Autore (Cognome, Nome+)>
 <!ELEMENT Sezione (TitoloSezione, Testo?, Sezione*)>
 <!ELEMENT Bibliografia (VoceBiblio)+>
 <!ELEMENT Numero (#PCDATA)>
 ...
 <!ELEMENT VoceBiblio (#PCDATA)>

 <!ATTLIST Sezione id ID #REQUIRED
 num NMTOKEN #IMPLIED
 stato (finale | provvisorio) "finale" >

 <!ENTITY DIS "Dipartimento di Informatica e Sistemistica">
 <!ENTITY SEZIONE1 SYSTEM "sezione1.xml">
 <!ENTITY SEZIONE2 "<Sezione>Ancora da scrivere.</Sezione>">
]>

Documenti XML validi

Un documento XML viene detto valido se:

è ben formato, ovvero rispetta tutti vincoli imposti da XML
contiene una dichiarazione di tipo di documento
è conforme alla DTD

Osservazione: lo spazio bianco non è rilevante (di norma)

Dichiarazioni di tipo di elemento

Sintassi di una dichiarazione di tipo di elemento:

<!ELEMENT nome-elemento content-model>

Il content model specifica la struttura degli elementi di nome nome-elemento.

content model è un'espressione regolare costruita su:

i tipi di elemento
#PCDATA (Parsed Character Data), che rappresenta del testo libero (senza etichette)

Ci sono delle limitazioni nell'uso di #PCDATA nel content model che vedremo più avanti.

Forma del content model

Operatori usati nel content model sono quelli delle espressioni regolari:

sequenza, indicata con (a,b,...,h)
alternativa, indicata con (a | b | ... | k)
opzionalità, indicata con a?
ripetizione zero o più volte, indicata con a*
ripetizione una o più volte, indicata con a+

(dove a,b,... indicano un generico content model)

Istanze di documento conformi ad un DTD

Un'istanza di documento è conforme ad un DTD se può essere generata a partire dal tipo di elemento iniziale applicando le produzioni (ovvero le dichiarazioni di tipo di elemento) del DTD.

l'applicazione di una produzione consiste nel considerare una parola w del linguaggio (sui terminali e tipi di elemento) definito dal content model , generare per ogni simbolo in w la parte di istanza di documento corrispondente e infine concatenare le parti così ottenute;
ogni volta che viene applicata una produzione la parte di istanza di documento generata viene racchiusa tra le etichette iniziale <E> e finale </E> del tipo di elemento E che compare nella parte sinistra della produzione.

Grammatiche context free estese (ECFG)

Le ECFG sono estensioni delle CFG:

hanno lo stesso potere espressivo delle CFG
(definiscono la stessa classe di linguaggi)
permettono di scrivere una grammatica in forma più compatta
le produzioni hanno una forma più generale, che fa uso di espressioni regolari:
- parte sinistra: è un nonterminale (come per le CFG)
- parte destra: è un'espressione regolare su terminali e nonterminali (invece che una semplice sequenza)

Derivazione di frasi nelle ECFG

Per derivare (generare) una frase del linguaggio:

si parte dal simbolo iniziale
si applicano le produzioni espandendo i nonterminali
l'espansione di un nonterminale secondo una produzione avviene in due passi:
1. si effettua l'espansione del non terminale sostituendolo con la parte destra di una regola (che in generale è un'espressione regolare)
2. si sostituisce l'espressione regolare con una parola del linguaggio generato da essa generato
ci si ferma quando non ci sono più nonterminali da espandere

Relazione tra DTD e ECFG

Un dichiarazione di tipo di elemento corrisponde ad una produzione di una ECFG:

il nome dell'elemento corrisponde al nonterminale nella parte sinistra
il content model corrisponde all'espressione regolare nella parte destra

Il tipo di documento specificato nella DTD corrisponde al simbolo iniziale della grammatica.

Da un punto di vista astratto una DTD è una ECFG.

Relazione tra DTD e ECFG (2)

La DTD (vista come grammatica) genera l'insieme di documenti validi.

Importante differenza tra ECFG e DTD:

nelle ECFG: quando si applica una produzione si sostuisce in modo opportuno
nelle DTD: ogni applicazione di una produzione genera anche una coppia di etichette (che racchiude la parte di documento generata dalla produzione)

Le etichette nel documento "dicono" quali produzioni sono state applicate.

Motivazione: analizzatori sintattici semplici ed efficienti

Relazione tra DTD e ECFG - Esempio

DTD:

<!DOCTYPE S [
 <!ELEMENT S (A, B+)>
 <!ELEMENT A (#PCDATA)>
 <!ELEMENT B (#PCDATA)>
]>

S => <S> AB+ </S> => <S> AB </S>
=> <S> <A> a </A> B </S>
=> <S> <A> a </A> b </S>

ECFG:

S -> AB+
A -> a
B -> b

S => AB+ => AB => aB => ab

ECFG con marcature:

S -> <S>AB+</S>
A -> <A>#PCDATA</A>
B -> #PCDATA

DTD e grammatica context free estesa

I terminali della grammatica sono #PCDATA,
I nonterminali della grammatica sono i tipi di elemento
le dichiarazioni di tipo di elemento corrispondono alle produzioni della grammatica.
I documenti etichettati sono le stringhe generate dal linguaggio
I documenti etichettati hanno una struttura ad albero determinata dalle etichette

Analisi sintattica

Una conseguenza importante del fatto che ogni istanza di documento conforme ad un DTD contiene le etichette derivanti dall'applicazione delle produzioni, è che il linguaggio (comprese le etichette) generato da un DTD è un linguaggio LL(1).

la parte sinistra della produzione che è stata applicata per generare una determinata sottostringa è univocamente determinata dall'etichetta iniziale (basta un lookahead pari a 1);
non è possibile la ricorsione sinistra a causa della presenza delle etichette;
il linguaggio generato dal content model è un linguaggio regolare, quindi è LL(1);
la parte di sottostringa generata da un content model può essere univocamente determinata in base all'etichetta finale corrispondente all'etichetta iniziale.

I documenti XML sono alberi

L'annidamento degli elementi definisce in modo esplicito una struttura ad albero:

<Mail>
<From> <Address> Dante@dsn.fi.it </Address> </From>
<To> <Address> Beatrice@pitti.fi.it </Address>
 <Address> Virgilio@spqr.rm.it </Address>
</To>
<Subject> Appointment </Subject>
<Body> Why don't we meet at disco.inferno at
 midnight. Tell also Caronte. Cheers,
 - D.A.
</Body>
</Mail>

Il Document Object Model

Ad ogni documento XML corrisponde una struttura ad albero:

ad ogni elemento corrisponde un nodo interno
al testo libero corrispondono le foglie
i figli di un nodo (elemento) sono gli elementi o il testo in esso contenuti
il modello ad albero può essere esteso anche ad attributi, commenti, istruzioni di processamento, ...

Definito in modo standard dal Document Object Model

fornisce un'API per manipolare i nodi dell'albero
introduce un livello di astrazione tra il documento XML e l'applicazione che lo deve processare

DTD - Esempi

Negli esempi che seguono:

assumiamo che il documento contenga sempre la dichiarazione di tipo di documento:
<!DOCTYPE ESE SYSTEM "esempio.dtd"> (che fa riferimento al file esterno esempio.dtd)
mostriamo solo:
- il contenuto del file esempio.dtd
- l'istanza di documento, ovvero l'elemento radice

DTD - Esempi (1)

<!ELEMENT ESE (#PCDATA)>

Il tipo dell'elemento radice deve essere il tipo di documento.

<ESE>questo documento e` valido</ESE>

Documenti non validi:

<boh>questo documento NON e` valido</boh>
<ese>XML e` case sensitive</ese>

DTD - Esempi (2)

<!ELEMENT ESE (#PCDATA)>

A #PCDATA deve corrispondere solo testo senza elementi annidati. Il testo può anche essere vuoto

<ESE>questi documenti sono validi</ESE>
<ESE></ESE>
<ESE/>

Documento non valido:

<ESE>questo documento NON e` valido</ESE>

DTD - Esempi (3)

<!ELEMENT ESE (P1, P2)>
<!ELEMENT P1 (#PCDATA)>
<!ELEMENT P2 (#PCDATA)>

Elemento che contiene una sequenza fissata di altri elementi.

<ESE> <P1>questa e` la prima parte</P1>
<P2>questa e` la seconda parte</P2> </ESE>
<ESE> <P1/> <P2>la prima parte e` vuota</P2> </ESE>

Documenti non validi:

<ESE> <P1>manca P2</P1> ____ </ESE>
<ESE> <P2/> <P1>ordine sbagliato</P1> </ESE>
<ESE> <P1/> <P2/> <P2>un solo P2</P2> </ESE>
<ESE> NO testo libero <P1/> <P2/> </ESE>

DTD - Esempi (4)

<!ELEMENT ESE (IN, S*)>
<!ELEMENT IN (#PCDATA)>
<!ELEMENT S (#PCDATA)>

Elemento che occorre zero o più volte.

<ESE> <IN>intro</IN> <S>sez1</S> <S>sez2</S> </ESE>
<ESE> <IN>senza sezioni</IN> </ESE>

Documenti non validi:

<ESE> <S>intro ci deve essere</S> </ESE>
<ESE> <S>solo dopo intro</S> <IN/> <S>sez1</S> </ESE>

DTD - Esempi (5)

<!ELEMENT ESE (IN, S+)>
<!ELEMENT IN (#PCDATA)>
<!ELEMENT S (#PCDATA)>

Elemento che occorre una o più volte.

<ESE> <IN>intro</IN> <S>sezione unica</S> </ESE>
<ESE> <IN>intro</IN> <S>sez1</S> <S>sez2</S> </ESE>

Documenti non validi:

<ESE> <IN>almeno una sezione</IN> _____ </ESE>
<ESE> _____ <S>intro ci deve essere</S> </ESE>
<ESE> <S>solo dopo intro</S> </IN> <S>sez1</S> </ESE>

DTD - Esempi (6)

<!ELEMENT ESE (IN?, S+)>
<!ELEMENT IN (#PCDATA)>
<!ELEMENT S (#PCDATA)>

Elemento opzionale.

<ESE> <IN>intro</IN> <S>sez1</S> <S>sez2</S> </ESE>
<ESE> <S>senza introduzione</S> </ESE>

Documenti non validi:

<ESE> <IN>intro</IN> <IN>intro unica</IN> <S/> </ESE>
<ESE> <IN>almeno una sezione</IN> _____ </ESE>
<ESE> <S>solo dopo intro</S> </IN> <S>sez1</S> </ESE>

DTD - Esempi (7)

<!ELEMENT ESE (IN?, (A1 | A2))>
<!ELEMENT IN (#PCDATA)>
<!ELEMENT A1 (#PCDATA)>
<!ELEMENT A2 (#PCDATA)>

Una tra più alternative.

<ESE> <IN>intro</IN> <A1>alternativa 1</A1> </ESE>
<ESE> <IN>intro</IN> <A2>alternativa 2</A2> </ESE>
<ESE> <A1>senza introduzione</A1> </ESE>

Documenti non validi:

<ESE> <IN>serve una delle 2</IN> _____ </ESE>
<ESE> <IN/> <A1>al piu` una delle 2</A1> <A2/> </ESE>
<ESE> <IN/> <A1>qui solo testo <A2/> </A1> </ESE>

DTD - Esempi (8.1)

<!ELEMENT ESE (TI, S1+)>
<!ELEMENT TI (#PCDATA)>
<!ELEMENT S1 (TI?, S2*)>
<!ELEMENT S2 (#PCDATA)>

Elementi annidati a un numero fisso di livelli.

<ESE> <TI>esempi xml</TI>
 <S1> <TI>sez 1</TI>
 <S2>sez 1.1</S2>
 </S1>
 <S1> <TI>sez 2 ha solo titolo<TI> </S1>
 <S1> <S2/> </S1>
 <S1/>
</ESE>

DTD - Esempi (8.2)

<!ELEMENT ESE (TI, S1+)>
<!ELEMENT TI (#PCDATA)>
<!ELEMENT S1 (TI?, S2*)>
<!ELEMENT S2 (#PCDATA)>

Documenti non validi:

<ESE> <TI>manca sez. liv. 1</TI> _____ </ESE>
<ESE> _____
 <S1> niente testo direttamente in S1
 <S2>sezione 1.1</S2>
 <S2>sezione 1.2</S2>
 <S2> <TI>solo testo in S2</TI> </S2>
 </S1>
</ESE>

DTD - Esempi (9)

<!ELEMENT ESE (TI, S+)>
<!ELEMENT S (TI?, (S+ | TXT))>
<!ELEMENT TI (#PCDATA)>
<!ELEMENT TXT (#PCDATA)>

Elementi annidati a livelli arbitrari.

<ESE> <TI>esempi xml</TI>
 <S> <TI>tit sez.1</TI> <TXT>testo 1</TXT> </S>
 <S> <TI>tit sez.2</TI>
 <S> <TXT>testo sez.2.1</TXT> </S>
 <S> <TI>titolo sez.2.2</TI>
 <S> <TXT>testo sez.2.2.1</TXT> </S>
 </S>
 </S>
</ESE>

DTD - Esempi (10)

<!ELEMENT ESE (TI, S+)>
<!ELEMENT S (#PCDATA | COM | S)*>
<!ELEMENT TI (#PCDATA)>
<!ELEMENT COM (#PCDATA)>

Un elemento può contenere testo misto ad altri elementi (elemento a contenuto misto).

<ESE> <TI>esempi xml</TI> <S>sezione 1</S>
 <S> sezione 2 <S>sezione 2.1</S>
 <COM>commento in sez. 2</COM>
 altro testo di sezione 2
 <S> sezione 2.2 <S>sezione 2.2.1</S>
 <COM>sez. 2.2.2 vuota</COM> <S/> </S>
 </S>
</ESE>

Elementi a contenuto misto

#PCDATA ed altri elementi non possono essere combinati in modo arbitrario nel content model.

L'unica possibilità di combinarli è:

<!ELEMENT elem (#PCDATA | elem1 | ... | elemk)*>

Un elemento di questo tipo viene detto a contenuto misto:

il suo contenuto è una sequenza arbitraria di testo libero ed elementi di tipo elem1,...,elemk
non posso imporre una struttura più precisa alla combinazione di questi elementi

Uso scorretto di `#PCDATA` nel content model

Un content model che contiene #PCDATA ed altri elementi e non ha la forma vista prima è scorretto.

<!ELEMENT ESE (TI, #PCDATA)>
<!ELEMENT ESE (TI?, #PCDATA)>
<!ELEMENT ESE (TI, (#PCDATA | S*))>
<!ELEMENT ESE (TI, (#PCDATA | S)*)>
<!ELEMENT S (#PCDATA | COM | S)+>
<!ELEMENT COM (#PCDATA)+>

Elementi con contenuto `EMPTY`

Un elemento può essere forzato ad avere contenuto vuoto:

<!ELEMENT elem EMPTY>

Un elemento dichiarato EMPTY può comparire solo con l'etichetta di elemento vuoto.

<!ELEMENT VUOTO EMPTY>
<!ELEMENT E1 (#PCDATA)>

Corretto:

Scorretto:

<VUOTO> deve essere vuoto </VUOTO>
<VUOTO></VUOTO>

Uso di elementi con contenuto `EMPTY`

Non sono inutili in quanto aggiungono informazione al documento:

attraverso attributi associati all'elemento

<IMG src="colosseo.gif"
 align="left"
 height="50"
 width="30"/>
attraverso la presenza stessa dell'elemento
  di HTML

Elementi con contenuto `ANY`

Si può usare il contenuto ANY per specificare che il contenuto di un elemento è una sequenza di testo ed elementi qualsiasi:

<!ELEMENT elem ANY>

Tutti gli elementi che compaiono in un elemento con contenuto ANY devono essere stati dichiarati.

<!ELEMENT TUTTO ANY>
<!ELEMENT E1 (#PCDATA)>
<!ELEMENT E2 (#PCDATA)>

Corretto:

Scorretto:

<TUTTO> <E3>non dichiarato</E3> </TUTTO>

Entità

Un documento XML:

da un punto di vista logico: è suddiviso in elementi.
da un punto di vista fisico: può essere memorizzato su più file

Un'entità è un'unità di memorizzazione contenente una parte di un documento XML:

l'unità che contiene la dichiarazione XML, la DTD e l'elemento radice è l'entità documento
l'elemento radice e i sottoelementi possono contenere riferimenti ad altre entità

Uso delle entità

definire abbreviazioni usate comunemente nel documento
suddividere il documento in più parti, memorizzate separatamente
suddividere la DTD in più parti e renderla modulare

Dichiarazioni e riferimenti ad entità

entità interne: il cui valore è definito nel documento stesso (specie di macro)
<!ENTITY nome-entita "testo">
entità esterne: il cui valore è accessibile tramite un'URI
<!ENTITY nome-entita SYSTEM "URI">

La nozione di Uniform Resource Identifier (URI) generalizza quella di Uniform Resource Locator (URL), separando la risorsa dalla sua locazione.

Riferimento ad un'entità nel documento: &nome-entita;

Entità - Esempi

Dichiarazioni nel DTD:

<!ENTITY DIS "Dip. di Informatica e Sist.">
<!ENTITY SEZIONE1 SYSTEM "sezione1.xml">
<!ENTITY SEZIONE2 "<Sezione>Da scrivere.</Sezione>">

Riferimenti nell'istanza di documento:

Presso il &DIS; vengono studiati i linguaggi
per dati semistrutturati, come illustrato nelle
due sezioni seguenti.
&SEZIONE1;
&SEZIONE2;

Processamento di entità

entità parsable, il cui valore è testo ben formato
- se contiene un'etichetta iniziale deve contenere anche la corrispondente etichetta finale
- le entità interne devono essere parsable
entità non parsable, il cui valore è arbitrario
- non vi si può far riferimento nel testo
- possono comparire solo come valori di attributi di tipo ENTITY

Un processore XML sostituisce tutti i riferimenti alle entità parsable con il loro valore prima di passare il documento all'applicazione.

Entità parametro

Sono entità che si possono usare nel DTD (non nell'internal DTD subset).

<!ENTITY % Text "CDATA">
<!ENTITY % coreattrs
"id ID #IMPLIED
class CDATA #IMPLIED
title %Text; #IMPLIED
..." >

Riferimento ad un'entità parametro: %nome-entita;

È permesso solo nel DTD.

Usi delle entità parametro

modularizzare il DTD
suddividerla su più file

Uso di un DTD esterno

<!ENTITY % formule SYSTEM "http://.../formule.dtd">
%formule

Dichiarazioni di attributi

Un elemento può contenere degli attributi nell'etichetta iniziale.

Se il documento è valido tutti gli attributi devono essere stati dichiarati.

Sintassi di una dichiarazione di attributi per un elemento:

<!ATTLIST nome-elemento lista-attributi>

nome-elemento specifica l'elemento per cui si dichiarano gli attributi.
lista-attributi è una lista di specifiche

nome tipo valore-di-default

Specifica di un attributo

nome, da usare nell'etichetta iniziale per assegnargli un valore
tipo, che specifica quali sono i possibili valori che l'attributo può assumere
valore-di-default, ossia cosa fare quando l'attributo non viene esplicitamente assegnato nell'etichetta iniziale

Tipi degli attributi

XML distingue 10 possibili tipi di attributo:

enumerato, ovvero una lista di possibili valori
CDATA: testo senza marcatura (è il tipo più comune);
il testo non può contenere "<'" e """
ID: il valore dell'attributo identifica l'elemento;
ci può essere un solo attributo di tipo ID per elemento
IDREF: il valore dell'attributo è l'ID di un altro elemento

Tipi degli attributi (2)

ENTITY: il nome di un'entità dichiarata nel DTD
permette di collegarsi a dati esterni in forma binaria (ad es. un'immagine)
NMTOKEN: un nome XML corretto
in nomi XML coincidono con gli identificatori Java, JavaScript, ...)
IDREFS, ENTITIES, NMTOKENS: versioni al plurale dei precedenti (valori separati da spazio)
NOTATION: il nome di una notation XML
una notation permette di specificare il formato di dati non-XML e un'applicazione che li processi

Specifica del valore di default

Il valore-di-default può essere

un valore esplicito che viene assunto in mancanza di specifica

<!ATTLIST P align (left|center|right) "left" ...>
#REQUIRED, che obbliga a specificare l'attributo
#IMPLIED, che rende la specifica del valore opzionale
#FIXED "valore-fisso", che fissa l'attributo ad avere un valore fisso (non può essere modificato all'interno del documento)

Dichiarazione di attributi - Esempio

Elemento img di XHTML:

<!ELEMENT img EMPTY>
<!ATTLIST img
 id ID #IMPLIED
 class CDATA #IMPLIED
 title CDATA #IMPLIED
 src CDATA #REQUIRED
 alt CDATA #REQUIRED
 longdesc CDATA #IMPLIED
 height CDATA #IMPLIED
 width CDATA #IMPLIED
 usemap CDATA #IMPLIED
 ismap (ismap) #IMPLIED
 ...
>

Attributi `ID` e `IDREF` - Esempio

<?xml version="1.0">
<!DOCTYPE FAMIGLIA [
 <!ELEMENT FAMIGLIA (PERS*)>
 <!ELEMENT PERS (#PCDATA)>
 <!ATTLIST PERS NP ID #REQUIRED>
 <!ATTLIST PERS PADRE IDREF #IMPLIED>
 <!ATTLIST PERS MADRE IDREF #IMPLIED>
]>

<FAMIGLIA>
<PERS NP="a1">Susanna</PERS>
<PERS NP="a2">Carlo</PERS>
<PERS NP="a3" MADRE="a1">Maria</PERS>
<PERS NP="a4" PADRE="a2">Luca</PERS>
</FAMIGLIA>

Attributi di tipo `ENTITY`

Permettono di riferirsi a dati esterni in forma binaria.

Il valore di un attributo di tipo ENTITY è il nome di un'entità esterna dichiarata nel DTD.

<!ELEMENT IMAGE EMPTY>
<!ATTLIST IMAGE SOURCE ENTITY #REQUIRED>
<!ENTITY LOGO SYSTEM "logo.gif">

Nel documento posso inserire un riferimento all'immagine:

...
<IMAGE SOURCE="LOGO"/>
...

Limitazioni dei DTD

I DTD sono il meccanismo "nativo" di XML per la definizione della struttura dei documenti

Essendo incentrati sui documenti sono poco adatti alla definizione di contenuti fortemente strutturati

I DTD possono essere utilizzati efficacemente per lo scambio di informazioni tra utenti, ma non tra sistemi automatici in quanto non consentono di stabilire con precisione il "tipo" delle informazioni. Storicamente i linguaggi a marcatura nascono come annotazione dei documenti testuali, ed è solo con la diffusione di XML che sono stati adoperati estensivamente per la rapresentazione delle informazioni

Limitazioni dei DTD (2)

La specifica di un DTD non è un documento XML. Ad es.:

<!ELEMENT e (#PCDATA)>

non è una produzione XML ben formata

I meccanismi di estensione e modularizzazione dei DTD sono estremamente limitati (definizioni esterne, entità parametriche)

I DTD non sono completamente compatibili con i namespace

I DTD non permettono di stabilire vincoli di chiave ed integrità referenziale, con l'eccezione degli attributi ID ed IDREF.

Introduzione a XML Schema

XML Schema è un'applicazione XML finalizzata alla definizione della struttura dei documenti XML, compito già svolto dai DTD, in modo più preciso e modulare rispetto a quanto permesso da questi ultimi.

XML Schema prevede la descrizione della struttura di un documento con un secondo documento XML (detto schema)

Analogamente a quanto avviene con i DTD è possibile validare un documento rispetto al proprio schema

Gli schemi XML prevedono la possibilità di creare dei modelli dati fortemente tipati (come linguaggi di programmazione tipo C, Java o linguaggi di specifica tipo DDL SQL) e sono compatibili con i namespace

Introduzione a XML Schema (2)

Gli schemi XML non sono sostitutivi dei DTD, ma i due sistemi devono essere utilizzati in concomitanza (ad es., in XML Schema non è possibile definire le entità)
In generale per i documenti scambiati tra utenti è preferibile utilizzare ancora i DTD, negli altri casi (ad es., strutture dati o basi di dati) gli schemi

L'impiego degli schemi in fase di validazione è molto più dispendioso, in termini di risorse computazionali, rispetto ai DTD (validare solo quando necessario)

Gli schemi XML possono essere utilizzati per il data binding

XML Schema: W3C Recommendation del 2/5/2001

Costrutti di base - Documento semplice

Definizione di un documento contenente un solo elemento di tipo testuale.

<?xml version="1.0"?>
<E>Hello</E>

Costrutti di base - Documento semplice (2)

Lo schema associato è:

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="E" type="xsd:string"/>
</xsd:schema>

Il tag element permette di definire un elemento del documento specificandone nome e tipo.
Nella definizione di uno schema l'elemento associato alla radice del documento (top-level element) è il primo dichiarato.

Costrutti di base - Documento semplice (3)

Per associare un documento (ovvero un'istanza di schema) al proprio schema si utilizzano degli attributi associati al namespace XSI (XML Schema Instance) sul root element, ad es:

<?xml version="1.0"?>
<E xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="schema.xsd">
Hello
</E>

Costrutti di base -Tipi semplici e complessi

In XML Schema si associa agli elementi un tipo (analogamente a quanto avviene nella definizione delle strutture dati dei LdP) che può essere semplice o complesso:

Un tipo semplice è una stringa di testo non contenente altra marcatura.
Un tipo complesso può contenere al suo interno altri elementi (content model)

Un tipo complesso viene definito con il tag complexType

Costrutti di base - Tipi semplici

A differenza dei DTD è possibile specificare il tipo degli elementi semplici.
All'interno dei documenti XML tali elementi sono rappresentati comunque come stringhe, tuttavia è possibile restringere il campo delle stringhe valide (ad es., solo quelle che rappresentano numeri in virgola mobile, oppure numeri interi positivi, oppure date, oppure...).

I tipi semplici supportati sono:

Numeri (ad es., float, double, decimal,int,byte,unsignedInt,postiveInt)
Date (ad es., date, timeInstant,duration,gYear)
Valori XML (ad es., ID, IDREF, ENTITY)
Stringhe (ad es., string, normalizedString)
Booleani (boolean)
URI (uriReference)
Dati binari

Le precisioni dei tipi dato sono quelle di Java.

Costrutti di base - Esempio d'uso dei tipi semplici

<xsd:element name="NOME" type="xsd:string"/>
<xsd:element name="CDL" type="xsd:string"/>
<xsd:element name="DURATA" type="xsd:duration"/>
<xsd:element name="INIZIO" type="xsd:date"/>
<xsd:element name="ARGOMENTO" type="xsd:string"/>
<xsd:element name="PROGETTO" type="xsd:string"/>
<xsd:element name="CREDITI" type="xsd:nonNegativeInteger"/>

Costrutti di base -Estensione dei tipi semplici

Il sistema dei tipi può essere esteso mediante un meccanismo di ereditarientà imponendo restrizioni sui tipi derivati (ad es., mediante espressioni regolari).

Costrutti di base - Esempio di definizione di un tipo complesso

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="CORSO" type="TipoCorso"/>
	<xsd:complexType name="TipoCorso">
		<xsd:sequence>
			<xsd:element name="NOME" type="xsd:string"/>
			<xsd:element name="DOCENTE" type="xsd:string"/>
			<xsd:element name="TUTOR" type="xsd:string"/>
			<xsd:element name="CDL" type="xsd:string"/>
			<xsd:element name="DURATA" type="xsd:string"/>
			<xsd:element name="ARGOMENTO" type="xsd:string"/>
			<xsd:element name="PROGETTO" type="xsd:string"/>
			<xsd:element name="CREDITI" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

Costrutti di base - Esempio di definizione di un tipo complesso (2)

Il documento è formato da un elemento associato al tag CORSO di tipo complesso TipoCorso che contiene una sequenza di elementi di tipo stringa. La definizione DTD "equivalente" sarebbe stata:

<!ELEMENT CORSO (NOME, DOCENTE, TUTOR, CDL, DURATA, ARGOMENTO, PROGETTO, CREDITI)>

Un'istanza del precedente schema è:

<CORSO>
	<NOME>Progetto di Linguaggi e Traduttori</NOME>
	<DOCENTE>Riccardo Rosati</DOCENTE>
	<TUTOR>Luigi Dragone</TUTOR>
	<CDL>Ing. Informatica</CDL>
	...
<CORSO>

Costrutti di base - Cardinalità degli elementi

Analogamente all'impiego delle espressioni regolari per la definizione del content model degli elementi, anche in XML Schema è possibile stabilire le cardinalità minime e massime dei vari elementi con l'uso degli attributi minOccurs e maxOccursche possono assumere un qualasiasi valore numerico intero >=0 oppure unbounded per indicare un numero illimitato.

Se un elemento è opzionale allora il numero minimo di occorrenze è 0.

Costrutti di base - Esempio di cardinalità degli elementi

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="CORSO" type="TipoCorso"/>
	<xsd:complexType name="TipoCorso">
		<xsd:sequence>
			<xsd:element name="NOME" type="xsd:string"/>
			<xsd:element name="DOCENTE" type="xsd:string"/>
			<xsd:element name="TUTOR" type="xsd:string" 
				minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="CDL" type="xsd:string"/>
			<xsd:element name="DURATA" type="xsd:string"/>
			<xsd:element name="ARGOMENTO" type="xsd:string" 
				minOccurs="1" maxOccurs="unbounded"/>
			<xsd:element name="PROGETTO" type="xsd:string" 
				minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="CREDITI" type="xsd:string" 
				minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

Costrutti di base - Esempio di cardinalità degli elementi (2)

<CORSO>
	<NOME>Linguaggi e tecnologie per il Web</NOME>
	<DOCENTE>Riccardo Rosati</DOCENTE>
	<TUTOR>Riccardo Rosati</TUTOR>
	<CDL>Ing. Informatica</CDL>
	<DURATA>60 ore</DURATA>
	<ARGOMENTO>Parsing</ARGOMENTO>
	<ARGOMENTO>HTML</ARGOMENTO>
	<ARGOMENTO>XML</ARGOMENTO>
	<ARGOMENTO>Programmazione Web lato client</ARGOMENTO>
	<CREDITI>6</CREDITI>
<CORSO>

Costrutti di base - Tipi complessi con solo contenuto testuale

Per definire elementi a contenuto testuale, ci sono due casi:

l'elemento da dichiarare non contiene attributi. In questo caso è sufficiente l'utilizzo di tipi semplici, come spiegato in precedenza;
l'elemento da dichiarare può contenere attributi. In quesrto caso è necessario l'uso di un tipo complesso.

Esempio: dichiarazione di un elemento <a> contenente un testo di tipo intero e un attributo <attr> di tipo stringa:

<xsd:element name="a">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:integer">
        <xsd:attribute name="attr" type="xsd:string" />
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>

Costrutti di base - Tipi complessi a contenuto misto

In XML Schema è possibile definire tipi a contenuto misto, ovvero contenenti sia parti testuali che altri elementi (e in modo più potente rispetto al mixed content model della DTD).

Esempio di dichiarazione di elemento <a> contenente sia parti testuali l'elemento :

<xsd:element name="a">
  <xsd:complexType mixed="true">
    <xsd:element name="b" type="tipo1"/>
  </xsd:complexType>
</xsd:element>

Esempio di dichiarazione di elemento <a> contenente sia parti testuali che gli elementi , <c>, <d>:

<xsd:element name="a">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="b" type="tipo1"/>
      <xsd:element name="c" type="tipo2"/>
      <xsd:element name="d" type="tipo1"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Costrutti di base - Tipi complessi con contenuto vuoto

In XML Schema è possibile dichiarare elementi a contenuto vuoto (analogamente al content model EMPTY della DTD).

Esempio di dichiarazione di un elemento <a> vuoto (e senza attributi):

<xsd:element name="a">
  <xsd:complexType/>
</xsd:element>

Esempio di dichiarazione di un elemento <a> vuoto con un attributo attr di tipo intero positivo:

<xsd:element name="a">
  <xsd:complexType>
    <xsd:attribute name="attr" type="xsd:positiveInteger"/>
  </xsd:complexType>
</xsd:element>

Costrutti di base - Composizione di tipi complessi

Un elemento incluso in un tipo complesso può essere a sua volta associato ad un tipo complesso.

In tal modo i tipi possono essere composti, inoltre le definizione di un tipo può essere condivisa tra più elementi (anche se appartenenti a tipi diversi).

Una funzionalità di questo tipo può essere ottenuta con i DTD mediante l'impiego delle entità parametriche, ma risulta di difficile applicabilità.

Costrutti di base - Esempio di composizione di tipi complessi

Ad esempio il docente e gli eventuali tutori possono avere un nominativo ed un recapito.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="CORSO" type="TipoCorso"/>
	<xsd:complexType name="TipoPersona">
		<xsd:sequence>
			<xsd:element name="NOMINATIVO" type="xsd:string"/>
			<xsd:element name="RECAPITO" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="TipoCorso">
		<xsd:sequence>
			<xsd:element name="NOME" type="xsd:string"/>
			<xsd:element name="DOCENTE" type="TipoPersona"/>
			<xsd:element name="TUTOR" type="TipoPersona" 
				minOccurs="0" maxOccurs="unbounded"/>
			...
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

Costrutti di base - Esempio di composizione di tipi complessi (2)

<CORSO>
	...
	<TUTOR>
		<NOMINATIVO>Luigi Dragone</NOMINATIVO>
		<RECAPITO>dragone@dis.uniroma1.it</RECAPITO>
	</TUTOR>
	...
</CORSO>

Costrutti di base - Tipi anonimi

Il tipo di un elemento può essere dichiarato all'interno all'elemento stesso (anonymous type), in tale caso la definizione non può essere condivisa.

Si tratta di un caso analogo all'uso delle classi anonime in Java.

Costrutti di base - Esempio d'uso di tipi anonimi

Ad esempio, il nominativo è suddiviso in nome e cognome:

<xsd:complexType name="TipoPersona">
	<xsd:sequence>
		<xsd:element name="NOMINATIVO">
			<xsd:complexType>
				<xsd:sequence>
					<xsd:element name="NOME" type="xsd:string"/>
					<xsd:element name="COGNOME" type="xsd:string"/>
				</xsd:sequence>
			</xsd:complexType>
		</xsd:element>
		<xsd:element name="RECAPITO" type="xsd:string"/>
	</xsd:sequence>
</xsd:complexType>

Costrutti di base - Esempio d'uso di tipi anonimi (2)

<CORSO>
	...
	<TUTOR>
		<NOMINATIVO><NOME>Luigi</NOME><COGNOME>Dragone</COGNOME></NOMINATIVO>
		<RECAPITO>dragone@dis.uniroma1.it</RECAPITO>
	</TUTOR>
	...
</CORSO>

Costrutti di base - Modalità di composizione di tipi complessi

Il raggruppamento degli elementi all'interno della definizione di un tipo può avvenire in 3 modalità

Sequenza (elemento sequence), equivalente all'operatore , delle espressioni dei content model
In ordine arbitrario (elemento all), simile all'operatore ? delle espressioni dei content model SGML, ma non XML
Alternativa (elemento choice), equivalente all'operatore | delle espressioni dei content model

Costrutti di base - Modalità di composizione di tipi complessi (2)

L'impiego dell'elemento all permette di specificare la presenza di un insieme di elementi indipendentemente dall'ordine. Gli elementi devono essere specificati con cardinalità massime e minime ristrette ai soli valori 0 ed 1.

Ad esempio, nel nominativo di una persona non è rilevante l'ordine del nome e del cognome:

<xsd:complexType name="TipoNominativo">
	<xsd:all>
		<xsd:element name="NOME" type="xsd:string" 
			minOccurs="1" maxOccurs="1"/>
		<xsd:element name="COGNOME" type="xsd:string" 
			minOccurs="1" maxOccurs="1"/>
	</xsd:all>
</xsd:complexType>

Costrutti di base - Modalità di composizione di tipi complessi (3)

<CORSO>
	...
	<TUTOR>
		<NOMINATIVO><COGNOME>Dragone</COGNOME><NOME>Luigi</NOME></NOMINATIVO>
		<RECAPITO>dragone@dis.uniroma1.it</RECAPITO>
	</TUTOR>
	...
</CORSO>

Costrutti di base - Modalità di composizione di tipi complessi (4)

Le scelte alternative possono essere combinate con le sequenze, analogamente a quanto avviene nei content model dei DTD, e specificare un intervallo di cardinalità ammissibili (ripetizioni).

<xsd:complexType name="TipoOrario">
	<xsd:sequence>
		<xsd:element name="DURATA" type="xsd:string"/>
		<xsd:choice minOccurs="1" maxOccurs="unbounded">
			<xsd:element name="LEZIONE" type="TipoLezione"/>
			<xsd:element name="ESERCITAZIONE" type="TipoEsercitazione"/>
			<xsd:element name="SEMINARIO" type="TipoSeminario"/>
		</xsd:choice>
	</xsd:sequence>
</xsd:complexType>

Costrutti di base - Riferimenti ad elementi

Nel caso in cui lo stesso elemento può comparire all'interno di più elementi, è possibile usare l'attributo ref di <xsd:element>. Usando tale attributo al posto dell'attributo name, si fa riferimento alla dichiarazione dell'elemento il cui nome è il valore dell'attributo ref.

Ad esempio, il seguente frammento di schema stabilisce che l'elemento <a> compare nel content model degli elementi , <c>, <d>, senza ripetere più volte la dichiarazione dell'elemento <a>:

  <xsd:element name="a">
    <xsd:complexType>
      ...
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="b">
    <xsd:complexType>
      <xsd:element ref="a">      
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="c">
    <xsd:complexType>
      <xsd:element ref="a">      
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="d">
    <xsd:complexType>
      <xsd:element ref="a">      
    </xsd:complexType>
  </xsd:element>

Costrutti di base - Attributi

La definizione dei tipi complessi ammette la possibilità di specificare i relativi attributi. Analogamente agli elementi anche gli attributi sono fortemente tipati ed è possibile specificare l'obbligatorietà oppure il valore predefinito.

<xsd:complexType name="TipoCorso">
	<xsd:sequence>
		<xsd:element name="NOME" type="xsd:string"/>
	...
	</xsd:sequence>
	<xsd:attribute name="codice" type="xsd:string" use="required"/>
	<xsd:attribute name="homePage" type="xsd:uriReference"/>
</xsd:complexType>

Possono essere definiti anche gruppi di attributi condivisi da più tipi/elementi.

Costrutti di base - Namespace

A differenza dei DTD, gli schemi sono compatibili con i namespace.

L'elemento schema possiede un attributo (targetNamespace) che specifica l'URI del namespace associato agli elementi in corso di definizione. Si deve specificare che gli elementi appartengono a tale namespace, mentre gli attributi in genere non sono associati a nessun namespace.

<?xml version="1.0"?>
<xsd:schema 
	xmlns="urn:dis.uniroma1.it:corso"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
	xsd:targetNamespace="urn:dis.uniroma1.it:corso"
	xsd:elementFormDefault="qualified"
	xsd:attributeFormDefault="unqualified">
	<xsd:element name="CORSO" type="TipoCorso"/>
	...
</xsd:schema>

Costrutti di base - Namespace (2)

L'impiego dei namespace richiede l'uso di un diverso costrutto per referenziare lo schema

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<corso:CORSO xmlns:corso="urn:dis.uniroma1.it:corso"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:dis.uniroma1.it:corso http://www.dis.uniroma.it/schema/corso.xsd">
	...
</corso:CORSO>

L'URI del namespace è indipendente da quella dello schema. Mentre la prima non deve essere mai risolta (ovvero convertita in un indirizzo reale), la seconda deve puntare ad un'istanza del documento contentente lo schema. Si può associare anche ad uno schema un'indirizzo "virtuale" mediante un'URN, in tale caso il parser deve possedere una copia interna dello schema in questione, analogamente a quanto fatto dagli attuali browser web per il DTD di HTML.

Nota: per i costrutti avanzati di XML Schema e per ulteriori dettagli si rimanda ai documenti ufficiali W3C (vedi riferimenti seguenti).

Riferimenti

Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C Recommendation

Tutorial (in inglese) su DTD

XML Schema Part 0: Primer W3C Recommendation October 28, 2004

XML Schema Part 1: Structures W3C Recommendation October 28, 2004

XML Schema Part 2: Datatypes W3C Recommendation October 28, 2004