>(7?@A&)(%CB4DE&/(-3F=G@%CHJILK Introduzione all’XML, Gianpiero Granatella

  

eXtensible Markup Language

Fonti

XML Pocket Reference, R. Eckstein, O’Reilly eds.

 "!$#% %'&)()! * +-,.(/*0"+21435(76589+:(-%<;.= >(7?@A&)(%CB4DE&/(-3F=G@%CHJILK

Introduzione all’XML, Gianpiero Granatella

 "!$#% %NMOMPMQ+R*!5(7,58S=F!4=G@S+T?@.DJ%U510%VU41B4DE&)DQW4WYX+ "DE&

Kickstart XML Tutorial, Crash course XML

 "!$#% %NMOMPMQ+7M[Z *?@4@.&\* +T?@.DJ%>B4D]&%

XML W3C school

 "!$#% %NMOMPMQ+T6584@5? (>(78A* +-?@SDJ%C^;A&/&/_F=G848 T%a`A&7@4@.=-%b cX bd%e6A15(7,589+2FD

(approfondimento) Guidelines for using XML for Electronic Data Interchange, M. Bryan, 1998.

XML, Corso di programmazione, H. Deitel, P. J. Deitel, T. R. Nieto, T. M. Lin, P. Sadhu, Apogeo editore, 2002¹.

Browser che supportano XML:

Mozilla 1 o versione superiore Netscape 7 o versione superiore Opera 6 o versione superiore

Internet Explorer 6 (o versione superiore) per Windows Internet Explorer 5 (o versione superiore) per Macintosh

Lo sviluppo tecnologico relativo alle reti e il crescente sviluppo della distribuzione di hardware per la comunicazione sempre più sofisticato (personal computer ma anche palmari e telefoni dalle funzioni via via più complesse) ha reso necessaria la definizione di standard per lo scambio di documenti e informazioni. Da molti anni le organizzazioni per la standardizzazione lavorano alla definizione di linguaggi di scambio. Già nel 1986 l’International Organization for Standardization (ISO) produsse SGML (Standard Generalized Markup Language), un linguaggio finalizzato a consentire l’identificazione del ruolo che i vari brani di informazione hanno nei documenti scambiati, delle informazioni che debbono essere inserite nei documenti scambiati e di quali programmi vanno utilizzati per interpretare correttamente le informazioni scambiate. Tutto ciò prima che nascesse il world wide web e si moltiplicassero siti e portali. La complessità di tale proposta ne ha tuttavia limitato l’utilizzo per diversi anni, fino alla definizione di una versione semplificata, XML (eXtensible Markup Language), avvenuta nel 1996 ad opera del W3C (WWW Consortium) a seguito di un’iniziativa di Jon Bosak (Sun Microsystems).

XML può essere visto sia come un linguaggio di interscambio di dati sia come un linguaggio per la definizione di linguaggi (meta-linguaggio). Probabilmente il successo che ha avuto come

1^fhg-gjikl-lRmnmnmpo\qidrstru0vw7udto\xhryzlNvw{| wlj}}~€lqvvtsqdg wlG‚ƒg2„†…tuhg w a questo link trovate il codice degli esempi ontenuti nel libro.

”™”™š›› šœš›› 

linguaggio di scambio dipende dal suo essere essenzialmente un meta-linguaggio. Per fare un esempio, WML (Wireless Markup Language, utilizzato per la comunicazione via WAP) è scritto in XML. Anche RDF e, di conseguenza, DAM+OIL (i linguaggi per il Semantic Web che vedremo) sono realizzati in XML.

XML consente di definire delle strutture dati indipendenti dalla piattaforma, che possono essere elaborate in modo automatico. Consente inoltre di definire propri tag. XML non consente di specificare come le informazioni vanno presentate (visualizzate). A questo scopo è necessario definire opportuni fogli di stile. Al momento è possibile definire fogli di stile o utilizzando il linguaggio XSL (eXtensible Stylesheet Language) oppure i CSS (Cascading Style Sheets).

Differenza fondamentale rispetto ad HTML: HTML è un linguaggio piatto, nel senso che non consente di strutturare parti di un documento identificando delle relazioni fra le medesime, cosa che XML entro un certo limite consente.

Documenti XML

Un documento XML è costituito da tre parti, che possono essere contenute in tre file diversi:

1. una Document Type Definition (DTD): è l’insieme delle regole che definisce la struttura dei dati, ovvero per la definizione degli elementi, degli attributi e delle loro correlazioni (la DTD definisce un vero linguaggio con un proprio vocabolario e regole sintattiche). Le DTD sono contenute alternativamente nel documento XML vero e proprio oppure in un file di testo con estensione dtd;

2. un foglio di stile: specifica le regole secondo le quali un documento deve essere visualizzato da un applicativo (browser, word processor, …);

3. il documento XML vero e proprio: i dati, organizzati secondo la struttura definita dalla DTD.

I veri e propri documenti XML sono contenuti in file di solo testo con estensione xml.

Si osservi che definire un linguaggio è conveniente qualora si intenda utilizzare tale linguaggio per strutturare più documenti XML veri e propri. Come nel caso dell’HTML i dati possono alternativamente essere scitti in file oppure essere generati dinamicamente da applicativi quali i sistemi per la gestione di banche dati.

Panoramica

A prima vista, un osservatore esterno che conosce l’HTML non troverà l’XML sorprendente. Anzi dal punto di vista dell’organizzazione dei dati (quel che sopra è stato chiamato “documento XML vero e proprio”) la prima osservazione è che i due linguaggi si somigliano. Infatti anche in questo caso si fa uso di tag, con la notazione ormai solita: <TAG> testo </TAG>. La differenza principale è che mentre in HTML i tag sono predefiniti, in XML ogni utente può definire i propri tag. Quindi i nomi dei tag sono variabilissimi, per esempio <capitolo> oppure <cliente>. Un’altra differenza (più subdola) è che mentre HTML è case-insensitive, XML è case-sensitive. Ciò significa che in XML il tag <UTENTE> è diverso dal tag <Utente> o dal tag <uTEntE>; al contrario in HTML maiuscole e minuscole non hanno alcuna rilevanza (per quel che riguarda i nomi dei tag). In secondo luogo l’XML è molto più preciso dell’HTML riguardo la chiusura dei tag: ad ogni <TAG> corrisponde

ª¯ª¯°±± °²°±± ³

sempre una chiusura </TAG>. Possono essere definiti tag vuoti ma la loro sintassi è diversa, si indicano così: <TAG/>.

Per fare un esempio, un brano di un documento XML potrebbe essere:

´ µ.¶Y·A¸º¹$»A¼¾½A¿

µ.¼»4Àº·.¿SÁYÂ.».¸9ÃYÂ.»Sµ9Ä.¼»4Àº·.¿

µÅ.».ÃS¼»4Àº·.¿SÆz»Y¹9¹.ÂAµ9ÄÅ.».ÃS¼»4Àº·.¿

µÅ.»9ÇzÂ9ÅS·.¿YÈ É¾ÊSËnÊSËSµ9ÄÅ.»9ÇzÂ9ÅS·.¿

µ9Ä.¶Y·A¸º¹$»A¼¾½A¿

µ.¶Y·A¸º¹$»A¼¾½A¿

µ.¼»4Àº·.¿$Ìz¼9¼¾½Aµ9Ä.¼»4Àº·.¿

µÅ.».ÃS¼»4Àº·.¿SÍYÂ9½4¼¾Å4ξÂAµ9ÄÅ.».ÃS¼»4Àº·.¿

µÅ.»9ÇzÂ9ÅS·.¿YÈ ÉpÏ$ËYÏ$ËSµ9ÄÅ.»9ÇzÂ9ÅS·.¿

µ9Ä.¶Y·A¸º¹$»A¼¾½A¿

´

Si può intuire da questo esempio che per consentire a un applicativo di utilizzare i dati in questione, inviare i soli dati etichettati non è sufficiente: non è possibile che l’applicativo preveda tutti i possibili tag, tutte le possibili strutture e tutti i possibili formati perché non c’è limite alla varietà.

D’altro canto i tag personalizzati aggiungono un quid informativo: in qualche modo specificano il ruolo che un brano di informazione ha all’interno del documento.

I vari tag (<persona>, <nome>, …) sono definiti nella DTD del documento, che può essere memorizzata su un file a parte oppure inclusa nel documento XML.

Come nell’HTML i commenti sono parentesizzati con <!-- e -->.

In generale un documento XML è diviso in tre parti: un prologo, un corpo e un epilogo. Il corpo del documento XML contiene dei dati strutturati in un albero. L'albero è espresso da un elemento radice che contiene tutti gli altri elementi e i dati del documento. Tutto ciò che precede l'elemento radice costituisce il prologo del documento, ciò che lo segue l'epilogo. Il prologo di un documento è molto importante: in esso sono contenute direttive utili ai programmi che utilizzeranno il documento. In particolare un documento XML comincia con :

µºÐÑ.ÀÓÒÕÔY·A¸º¹.Â.»A¼zÖØ×ËÚÙhÛØ×AÐ5¿

Questa specifica indica appunto che quello che segue è un documento XML e riporta la versione del linguaggio XML utilizzata. Qualora il documento utilizzi tag definiti in una DTD esterna (ovvero memorizzata su di un altro file) occorre indicare ai programmi che leggono i dati che la struttura dei medesimi è definita altrove. In questo caso viene inserita in <?xml ... ?> anche l'indicazione:

standalone=”no”:

µºÐÑ.ÀÓÒÕÔY·A¸º¹.Â.»A¼zÖØ×ËÚÙhÛØ×ܹ$Ýz½4¼Çz½9Ò.»A¼Y·.ÖØ×¼»p×AÐ5¿

Occorrerà quindi aggiungere al prologo l'informazione relativa a dove è memorizzata la DTD. A tal fine si utilizza <!DOCTYPE ... >:

µ[ÞÉnßYà$á.âã9äå·nÒS·5Àº·$¼Ý9»

æ

¸Y½.ÇzÂ9ÅS·èç âÓç4ánäAé ê4ë9Â9ÒS·

æ

Å.»A¼

æ

ÉnáSÉìÙíÇ9Ý9Çp× ¿

úÿúÿ


“elemento_radice” è l'elemento che deve essere utilizzato come radice dell'albero in cui i dati sono strutturati, SYSTEM è una parola riservata del linguaggio, “file_con_DTD.dtd” indica la posizione occupata dal nome del file in cui la DTD è memorizzata. Vedremo più avanti una forma più generale di <!DOCTYPE ... >. Supponiamo, per esempio, che l'elenco di persone riportato sopra sia una descrizione del personale di una certa ditta e che i tag usati per descrivere le persone siano definiti nel file “people.dtd”; il file XML completo avrà la seguente forma:

  ! "$#&%! ')(*+-,*.! -/ 10

3254768)9:-;.<>= )?*.@BA:A+97<C DE=@=?@F#G,.(.,/ 0

= )?*.@0

= )?*0

-+ 0)H.?*..*.I-+ 0

-JK@-+ 0)H7*.I-JK@-+ 0

-J.,.J@0L4/M)"7N@"@.I-J.,.J@0

.I= )?*0

= )?*0

-+ 0O7K@.I-+ 0

-JK@-+ 0)H7K-7..I-JK@-+ 0

-J.,.J@0L4/M)"7N.N.I-J.,.J@0

.I= )?*0

= )?*0

-+ 0@P.*+?J.*.I-+ 0

-JK@-+ 04?RQ.K.I-JK@-+ 0

-J.,.J@0L4/M)"7N-M+.I-J.,.J@0

.I= )?*0

= )?*0

-+ 067--)(7.I-+ 0

-JK@-+ 0-A..+-)(.I-JK@-+ 0

-J.,.J@0L4/M)"7NS7.I-J.,.J@0

.I= )?*0

.I= )?*.@0

In generale in DOCTYPE più che un semplice nome di file si utilizza un'URL:

Documenti ben formati e documenti validi

Prima di passare a una descrizione della struttura delle DTD, è opportuno introdurre i concetti di documento valido (rispetto a una DTD) e di documento ben formato. Un documento è valido quando rispetta le regole espresse dalla DTD. Un documento si dice invece ben formato quando rispetta le generiche regole di scrittura di un documento XML, che sono:

1. i valori degli attributi devono essere racchiusi fra doppi apici 2. i tag devono sempre essere chiusi

3. aperture e chiusure dei tag non devono intersecarsi (es. <nome> Anna <cognome></nome>

Rossi </cognome> è sbagliato! Ricordate quanto abbiamo già visto per HTML)

-•5-•
–——–˜–——™

I sistemi che verificano la correttezza (sintattica) dei documenti XML sono detti parser. A seconda che tali strumenti verifichino la correttezza del documento rispetto alla DTD indicata oppure rispetto alle generiche regole sintattiche di XML solamente, vengono detti parser validanti o parser non-validanti.

Document Type Definition

La DTD contiene la definizione della struttura dei dati di uno o più documenti. Quando si parla di struttura dei dati di un documento si assume che il documento possa essere ricorsivamente scomposto in parti (per esempio un libro può essere scomposto in capitoli, che possono essere suddivisi in sezioni e così via); in certi casi i vari elementi devono rispettare un particolare ordine di precedenza (per esempio le voci di una rubrica telefonica potrebbero prevedere il nome di una persona come primo elemento, seguito dal numero di telefono e magari dall’indirizzo).

La strutturazione dei documenti XML avviene attraverso la definizione di tutti gli elementi che possono denotare il documento e delle loro inter-relazioni, in altri termini la DTD di un documento contiene le definizioni dei tag e della struttura attesa dei dati.

Un elemento è definito utilizzando la sintassi:

<!ELEMENT nome_elemento regola>

nome_elemento identifica un nuovo tag ed è una sequenza di caratteri che inizia con una lettera o un

“_” (underscore) e può poi contenere lettere, cifre, trattini, punti. Nel caso in cui si usino i namespace è anche possibile utilizzare “:” ma vedremo questo aspetto più avanti nelle lezioni.

Nel caso più semplice la regola può valere alternativamente: ANY oppure #PCDATA. ANY è una parola chiave che indica che fra <nome_elemento> e </nome_elemento> può essere contenuta qualsiasi cosa, ovvero possono essere contenuti sia dati (tipicamente del testo; “PCDATA” sta per parsed character data) sia altri elementi. Se anziché ANY si utilizza #PCDATA non potranno essere contenuti altri elementi.

š-›œ@Ÿž1 ¡£¢

¤3¥{¦.§.¦¨-¦.©@ª¬«­® ¯)°±?²´³-©µ¶

¤3¥{¦.§.¦¨-¦.©@ª¬±-°+· ­ ¸Ž¹º-»+¼@³ª³~½¶

¤3¥{¦.§.¦¨-¦.©@ª¿¾°À@±-°+· ­ ¸Ž¹º-»+¼@³ª³~½¶

¤3¥{¦.§.¦¨-¦.©@ª¿¾°.ÁÂ.¾@­ ¸Ž¹º-»+¼@³ª³~½¶

Con riferimento ai tag utilizzati sopra, <persona> dovrà avere associata come regola ANY mentre nome potrebbe avere associato un semplice #PCDATA.

Questi sono solo i casi di regola più semplici: regole che non ci permettono di strutturare i dati ma in generale le regole sono proprio utilizzate per strutturare l’informazione definendo un modo in cui gli elementi sono composti di altri elementi.

Ï-Ô5Ï-Ô
ÕÖÖÕ×ÕÖÖØ

La DTD riportata sopra non correla in alcun modo gli elementi definiti: per nessun motivo siamo tenuti a descrivere una persona in termini di nome, cognome e codice. Se però osserviamo l’uso inteso di tali elementi , come esemplificato in:

ÙÚÛÜ Ý)Þß?àá

Ùß-Þ+â Ûá@ãäÞÜ.åäÞ@Ù.æß-Þ+â Ûá

Ù-çÞå@ß-Þ+â Ûá@èÞÝ.ÝäÙ.æ-çÞå@ß-Þ+â Ûá

Ù-çÞ.éä.ç@Ûáêë?ì@í7ì@í@Ù.æ-çÞ.éä.ç@Ûá

Ù.æÚÛÜ Ý)Þß?àá

ci accorgiamo che nome, cognome e codice dovrebbero essere le componenti in cui è strutturata l’informazione relativa a persona. Se potessimo esprimere questa correlazione potremmo anche realizzare applicativi che controllano il modo in cui sono descritti i dati, verificando che la struttura intesa sia rispettata. In generale è possibile strutturare un elemento utilizzando sequenze di altri elementi, che possono ricorrere anche più volte. Nel caso di persona, per indicare che l’informazione relativa a una persona è strutturata nella sequenza di nome, cognome e codice si indica:

Ù3î{ï.ð.ïñ-ï.ò@ó¬ÚÛÜ Ý)Þß?à ôkß-Þ+â ÛFõöçÞå@ß-Þ+â ÛFõöçÞ.éä.ç@Û÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¬ß-Þ+â Û ôŽøù-ú+ë@ûóû~÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¿çÞå@ß-Þ+â Û ôŽøù-ú+ë@ûóû~÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¿çÞ.éä.ç@Û ôŽøù-ú+ë@ûóû~÷á

La strutturazione può avere più livelli ed essere di vario tipo. Consideriamo, per esempio, il documento che contiene informazioni relative a Giorgio Rossi, Anna Bianchi ed eventuali altre persone. Ora che sappiamo come strutturare l’informazione relativa ad un singolo individuo, possiamo pensare di regolamentare la struttura dell’intero documento dichiarando che esso è costituito da una sequenza di persone. A differenza dal caso precedente non è però prevedibile il numero delle persone i cui dati saranno contenuti nel documento. In parole povere il nostro documento sarà una sequenza di un numero imprecisato di persone (zero, una o più). A tal fine la DTD vista sopra dovrà essere arricchita aggiungendo un nuovo elemento (sia esso elenco):

Ù3î{ï.ð.ïñ-ï.ò@óüÛ7ý@Û)ß?çÞ ôkÚÛÜ Ý)Þß?à7þ?÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¬ÚÛÜ Ý)Þß?à ôkß-Þ+â ÛFõöçÞå@ß-Þ+â ÛFõöçÞ.éä.ç@Û÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¬ß-Þ+â Û ôŽøù-ú+ë@ûóû~÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¿çÞå@ß-Þ+â Û ôŽøù-ú+ë@ûóû~÷á

Ù3î{ï.ð.ïñ-ï.ò@ó¿çÞ.éä.ç@Û ôŽøù-ú+ë@ûóû~÷á

il simbolo * (asterisco) indica una sequenza eventualmente vuota, costituita da un numero imprecisato di persone. Se si vuole indicare che la sequenza non può essere vuota (per il nostro esempio: l’elenco deve contenere almeno una persona) si utilizza il simbolo + (più) anziché *. Se invece l’elemento può occorrere al più una volta (quindi 0 oppure 1) si utilizza il simbolo ? (punto interrogativo).

L’elemento più astratto (quello definito in termini di altri elementi ma che non è utilizzato all’interno di nessuna regola; nell’esempio proprio elenco) è detto radice. È necessario che in una DTD sia definito sempre un elemento radice.

Oltre ai simboli visti le regole possono contenere anche l’operatore | (oppure) che indica un’alternativa. Supponiamo, per esempio, che il campo codice sia opzionale nella definizione di persona. Potremmo, per esempio, scrivere:

$&%('*)*',+'*-/.1032,46587,9;: <*< 97>=62@?BAC7CD/97>=62@?BAC7*EGF*A/2IH JK< 97>=62@?BAC7CD/97>=62IH*HL

Che si legge: un elemento persona è strutturato in un nome, seguito da un cognome, seguito da un codice oppure da un nome seguito da un cognome. Le parentesi tonde sono utilizzate per dare maggiore granularità alla sintassi definita.

Si osservi che le regole per definire una certa struttura non sono necessariamente uniche, tornando al caso precedente è possibile definire anche la seguente regola, equivalente a ((nome, cognome, persona) | (nome, cognome)):

$&%('*)*',+'*-/.1032,46587,9;: < 97>=62@?BAC7CD/97>=62@?BAC7*EGF*A/23MHL

Le regole più compatte sono generalemente più efficienti, anche se non sempre sono altrettanto significative (a livello intuitivo). In entrambi i casi quelli che seguono sono usi corretti dell’elemento <persona> in un file .xml:

$C032,46587,9;:,L

$C97>=62CL8NG9*9;:,$*OC97>=62CL

$AC7CD/97>=62CL/P3F*:>9;A>Q;F,$*OAC7CD/97>=62CL

$*OC032,46587,9;:,L

$C032,46587,9;:,L

$C97>=62CL/)/R;A*:,$*OC97>=62CL

$AC7CD/97>=62CL/SG735*5CF,$*OAC7CD/97>=62CL

$AC7*EGF*A/2CL*TVUGW/XVWCU/T*$*OAC7*EGF*A/2CL

$*OC032,46587,9;:,L

Questo invece è un uso errato:

$C032,46587,9;:,L

$C97>=62CL8NG9*9;:,$*OC97>=62CL

$C97>=62CL8+I:843F*:,$*OC97>=62CL

$AC7CD/97>=62CL/P3F*:>9;A>Q;F,$*OAC7CD/97>=62CL

$*OC032,46587,9;:,L

Infatti secondo la definizione che abbiamo dato, l’entità <nome> deve comparire una e una sola volta nella specifica di una persona.

Utilizzando i costrutti introdotti è possibile scrivere regole anche molto complesse. Per esempio, supponendo che a, b, c e d siano elementi definiti nella DTD potremmo scrivere la regola: ((c, (a, b)*) | (d, d, c+)), a, c, c).

Gli elementi vuoti (tag vuoti) sono definiti utilizzando la parola chiave EMPTY:

$&%('*)*',+'*-/.1Y[Z\^] _`]>a;]\^]YcbdZe',+f/.Cg3L

Fino ad ora abbiamo sempre utilizzato DTD esterne, tuttavia nel caso di DTD che non intendiamo utilizzare per descrivere il contenuto di più documenti XML è possibile inserire la DTD direttamente nel prologo del documento, all'interno della direttiva <!DOCTYPE ...>. L'esempio 2 mostra un caso d'uso. Si osservi come la specifica 'SYSTEM “url_della_dtd”' sia sostituita dalla DTD medesima inserita fra parentesi quadre.

~ €/ƒ‚d„…‡†

ˆ6‰ŠC‹IŒŽ3,6‘C’C“,”G•—–˜š™œ›—–‘8žGŸ>” GŸ*ŒC“,”3C•—–
¡3‘3–,‰d¢

ˆ&£¤V¥3¦8§C¨©*ª13’*«//ž*žGŸ ¬

ˆ&£(ª*­*ª,®ª*¯/§°3’*«//ž*žGŸ ±žG’Cž*“GŒC“š²³Œ*’G‘8žGŸ´[’>”Vµ*/ G’/8”žG’¶²(·V8·;Ÿ83Ÿ/¸V’C“,”3I¹¢

ˆ&£(ª*­*ª,®ª*¯/§ºžG’Cž*“GŒC“ ±»G©¦>¤/¼G§C¼½¹¢

ˆ&£(ª*­*ª,®ª*¯/§¾Œ*’G‘8žGŸ´[’>”Vµ*/ G’/8”žG’ ±’>”Vµ*/ G’/8”žVC¿—¹¢

ˆ&£(ª*­*ª,®ª*¯/§1·V8·;Ÿ83Ÿ/¸V’C“,”3 ± ·;ŸG‘*‘8“/¿—¹¢

ˆ&£(ª*­*ª,®ª*¯/§¾’>”Vµ*/ G’/8”žV ±»G©¦>¤/¼G§C¼½¹¢

ˆ&£(ª*­*ª,®ª*¯/§1·;ŸG‘*‘8“ ±»G©¦>¤/¼G§C¼½¹¢

À ¢

ˆ/3’*«//ž*žGŸ,¢

ˆVžG’Cž*“GŒC“/¢º’>”I‘CŸ*Œ*ŸCžGŸÁˆ*ÂVžG’Cž*“GŒC“/¢

ˆŒ*’G‘8žGŸ´[’>”Vµ*/ G’/8”žG’,¢

ˆ’>”Vµ*/ G’/8”žVC¢º’>” G’>;’*ŸÁˆ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢Ã·“>‹;“* *“CG“Ĉ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢º«//žC3’C“GŒC“Ĉ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢¾‘,/ GŸ>”“Ĉ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢°“GŒ*’C“Ĉ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢ºŸ*«//ž*“Ĉ*Â’>”Vµ*/ G’/8”žVC¢

ˆ’>”Vµ*/ G’/8”žVC¢¾‘CŸ*Œ/Ãˆ*Â’>”Vµ*/ G’/8”žVC¢

ˆ*ÂŒ*’G‘8žGŸ´[’>”Vµ*/ G’/8”žG’,¢

ˆC·V8·;Ÿ83Ÿ/¸V’C“,”3C¢

ˆC·;ŸG‘*‘8“/¢ºŒ*Ÿ>;Ÿ8°Œ¶Å³’>”*;’C G’*Ÿ¶²B’*ŒÆ‘,/ GŸ>”“°°’*ŒŽ·“>‹;“* *“CG“/ˆ*ÂC·;ŸG‘*‘8“/¢

ˆC·;ŸG‘*‘8“/¢Ã·3VŒ*Ÿ8°’*Œ1«//žC3’C“GŒC“Ĉ*ÂC·;ŸG‘*‘8“/¢

ˆC·;ŸG‘*‘8“/¢ºŸ*Ç*Ç//ž*žGŸ8°«//žC3’C“GŒC“š²È·“>‹;“* *“CG“°º‘,/ GŸ>”“Ĉ*ÂC·;ŸG‘*‘8“/¢

ˆC·;ŸG‘*‘8“/¢°žGŸ8µ3Œ*’*Ÿ8°Œ¶Å³’>”I‘CŸ*Œ*ŸCžGŸ,ˆ*ÂC·;ŸG‘*‘8“/¢

ˆC·;ŸG‘*‘8“/¢‹6‘C«C“GŒ*Ÿ8°Œ/3,G ,ÉV°’>”1É*”Êų’>”I‘CŸ*Œ*ŸCžG’/,3ŸÁˆ*ÂC·;ŸG‘*‘8“/¢

ˆC·;ŸG‘*‘8“/¢Ã3,6‘CŸ8Ä“GŒ*’C“°°Ÿ*«//ž*“š²Ë‘CŸ*Œ*Ÿ81Ì‹6‘C«C“GŒ*Ÿ8Cˆ*ÂC·;ŸG‘*‘8“/¢

ˆ*ÂC·V8·;Ÿ83Ÿ/¸V’C“,”3C¢

ˆ*Â/3’*«//ž*žGŸ,¢