XML Schema. Si avvicinano i Mondiali di calcio. La federazione. ai Mondiali di calcio di Massimo Ruocchio

Transcript

1 F O C U S Vediamo cos è e come Schema si utilizza Schema Schema, il linguaggio standard introdotto dal W3C per creare schemi di validazione per documenti. Un semplice esempio può essere di grande aiuto ai Mondiali di calcio mruocchio@programmers.net di Massimo Ruocchio È laureato in matematica ed è certificato Oracle come Application Developer. Si occupa di analisi, progettazione e sviluppo di applicazioni software in ambiente relazionale Oracle ed Tamino. Si avvicinano i Mondiali di calcio. La federazione mondiale (FIFA) chiede alle 32 nazionali qualificate di trasmettere l elenco dei calciatori selezionati per partecipare alla manifestazione. Le informazioni richieste sono le seguenti: nome della Nazione; nome, cognome, nazionalità e numero di tessera FIFA del commissario tecnico; nome, cognome, età, numero di maglia, club d appartenenza di ogni calciatore convocato. I dati devono essere inviati in formato. Per evitare problemi in fase di ricezione dei dati bisogna superare due ostacoli: prima di tutto il formato utilizzato dalle 32 federazioni qualificate deve essere unico, poi bisogna fare in modo che ogni federazione possa verificare che i propri dati rispettino tutte le regole a dispetto di eventuali errori di compilazione del documento. Per ovviare a questi due possibili problemi la FIFA elabora uno schema in cui sia chiaro quali dati devono essere inviati e quali regole questi dati devono rispettare. Lo schema, da inviare a tutte le federazioni, è esso stesso un documento, rispetta gli standard enunciati dal World Wide Web Consortium (W3C) ed universalmente riconosciuti, consente alle federazioni di verificare autonomamente che i dati che si stanno per inviare sono corretti. Esistono molti strumenti software che consentono di verificare automaticamente la validità di un documento rispetto ad un certo schema. Lo schema è redatto secondo gli standard di Schema. Breve genesi di Schema 46 I dati inviati devono rispettare alcune regole: 1. ci deve essere un solo commissario tecnico; 2. ci devono essere esattamente 23 calciatori; 3. i numeri di maglia devono essere compresi tra 1 e 23; 4. due calciatori non possono avere lo stesso numero di maglia; 5. il nome della nazione può essere solo uno dei 32 nomi in inglese delle nazionali qualificate. Schema è uno strumento piuttosto giovane, le specifiche per la sua creazione sono state pubblicate nel febbraio del Nel Riquadro 1 è riportato il paragrafo Purpose delle specifiche di Schema tratto da [10]. Dopo due anni di lavoro si è giunti, il 2 maggio 2001, alla redazione della versione definitiva di Schema che è diventato una Raccomandazione del W3C. Ma l esigenza di convalidare i documenti prodotti è nata insieme all. Prima di Schema era utilizzato uno standard denominato Document Type Definition (DTD). DTD, che è supportato da tutti i tool per lo sviluppo in ambiente, ha alcuni difetti

2 che rendono complesso il suo utilizzo. I tre difetti principali di DTD sono: FIGURA 1 La struttura del nostro schema in Spy non è esso stesso un linguaggio, e dunque un documento DTD non può essere scritto e modificato con lo stesso strumento con cui si scrivono i documenti (a meno di non utilizzare per entrambi un comune editor di testo); non gestisce i tipi di dato, dunque non è possibile sapere se le singole informazioni siano da interpretare come numeri o stringhe ecc ; non gestisce in alcun modo i namespace, utili per la standardizzazione dei nomi dei tag utilizzati. Il maggior difetto di Schema è sicuramente la sua complessità, soprattutto in considerazione del fatto che lo strumento è nato per semplificare le cose rispetto a DTD. Ma la complessità di Schema può essere molto attutita utilizzando uno dei tanti strumenti grafici per la redazione di schemi. Ormai sono molti i produttori di software che mettono a disposizione un ambiente completo per lo sviluppo in. In Figura 1 è riportata a titolo d esempio una schermata di Spy. Torniamo ai mondiali di calcio Cominciamo a scrivere il nostro schema. Come detto uno schema è esso stesso un documento quindi, tanto per cominciare, scriviamo: <?xml version= 1.0 encoding= UTF-8?> <xs:schema xmlns:xs= Schema > </xs:schema> La prima riga è la solita, valida per ogni documento. L elemento radice di uno schema è <xs:schema>, dove xs: è il prefisso da utilizzare per far riferimento ai tag definiti nel namespace standard di Schema definito dal W3C. Rileggendo i dati da gestire con il nostro documento ci accorgiamo che vanno richiesti nome e cognome sia del commissario tecnico sia dei calciatori. In casi come questo è possibile definire un nuovo tipo di dato composto da due tipi elementari, in questo caso due stringhe, che potremo poi utilizzare due volte nel nostro schema: <xs:complextype name= COMPLETE_NAME_TYPE > <xs:element name= SURNAME type= xs:string /> <xs:element name= NAME type= xs:string /> Il tipo di dato da definire è un complextype di nome COMPLETE_NAME_TYPE ed è composto dalla sequenza di due dati elementari, SURNAME e NAME, entrambi di tipo stringa. L elemento radice dei documenti che le federazioni devono inviare lo chiamiamo TEAM e lo definiamo come segue: <xs:element name= TEAM > <!-- qui ci vanno gli elementi che compongono TEAM --> <xs:attribute name= country use= required > <xs:restriction base= xs:string > <xs:enumeration value= KOREA /> <xs:enumeration value= JAPAN /> <xs:enumeration value= ITALY /> <!-- tutte le altre nazioni --> Dunque, TEAM è un elemento complesso perché formato da una sequenza di altri elementi, poi vedremo quali. Ha un attributo di nome country che è obbligatorio ed è una stringa. Ma country non è una stringa qualunque, è una restrizione del tipo xs:string. Sì perché country può assumere solo uno di 32 valori alfanumerici prestabiliti, i nomi in inglese delle 32 nazionali qualificate ai mondiali. Questa regola si impone mediante l elemento <xs:restriction> che restringe un tipo definito e mediante l elemento <xs:enumeration> che elenca una serie di costanti che fungono da valori possibili. TEAM è fatto da due elementi: TRAINER e PLAYERS 47

3 F O C U S <xs:element name= TEAM > <xs:element name= TRAINER minoccurs= 1 maxoccurs= 1 > <!-- qui il contenuto di TRAINER --> <xs:element name=»players» minoccurs=»1» maxoccurs=»1»> <!-- qui il contenuto di PLAYERS --> <!-- qui c e l attributo country --> Nel TEAM ci deve essere un solo TRAINER ed un solo elenco di atleti, ciò può essere imposto mediante gli attributi minoccurs e maxoccurs. Veniamo al TRAINER. Le informazioni da gestire sono nome e cognome, nazionalità e numero di tessera FIFA. Il numero di tessera FIFA è un alfanumerico di 10 caratteri. Sugli altri dati non imponiamo restrizioni, vediamo: <xs:element name= TRAINER minoccurs= 1 maxoccurs= 1 > <xs:element name=»tr_compl_name» type=»complete_name_type»/> <xs:element name=»nationality» type=»xs:string»/> <xs:attribute name=»fifa_id» use=»required»> <xs:restriction base=»xs:string»> <xs:length value=»10»/> FIGURA 2 Validazione di Team.xml avvenuta con successo mediante XSV L elemento TR_COMPLETE_NAME è del tipo COMPLETE_NAME_TYPE che abbiamo definito all inizio. Quindi sarà composto da due elementi SURNAME e NAME. La NATIONALITY è una stringa senza restrizioni, mentre l attributo fifa_id è anch esso una stringa ma è sottoposto alla restrizione che la sua lunghezza (elemento <xs:length>) sia esattamente 10. In più l attributo fifa_id è obbligatorio. Tocca all elenco dei calciatori, cioè all elemento PLAYERS. <xs:element name= PLAYERS minoccurs= 1 maxoccurs= 1 > <xs:element name= PLAYER minoccurs= 23 maxoccurs= 23 > <!-- qui il contenuto di PLAYER --> PLAYERS è formato da una sequenza di elementi PLAYER. Per la precisione ci devono essere esattamente 23 occorrenze dell elemento PLAYER, infatti sia minoccurs che maxoccurs di PLAYER valgono 23. Ogni PLAYER è definito come segue : <xs:element name= PLAYER minoccurs= 23 maxoccurs= 23 > <xs:element name=»compl_name» type=»complete_name_type»/> <xs:element name= CLUB type= xs:string /> <xs:attribute name= number use= required > <xs:restriction base= xs:integer > <xs:mininclusive value= 1 /> <xs:maxinclusive value= 23 /> <xs:attribute name= age type= xs:integer use= required /> <xs:attribute name= goalkeeper type= xs:string fixed= YES /> 48 C è una sequenza di COMPL_NAME, nome completo come per il TRAINER, e CLUB, il nome

4 LISTATO 1 Team.xsd, lo schema d esempio <?xml version= 1.0 encoding= UTF-8?> <xs:schema xmlns:xs= > <xs:complextype name= COMPLETE_NAME_TYPE > <xs:element name= SURNAME type= xs:string /> <xs:element name= NAME type= xs:string /> <xs:element name= TEAM > <xs:element name= TRAINER minoccurs= 1 maxoccurs= 1 > <xs:element name= TR_COMPL_NAME type= COMPLETE_NAME_TYPE /> <xs:element name= NATIONALITY type= xs:string /> <xs:attribute name= fifa_id use= required > <xs:restriction base= xs:string > <xs:length value= 10 /> <xs:element name= PLAYERS minoccurs= 1 maxoccurs= 1 > <xs:element name= PLAYER minoccurs= 23 maxoccurs= 23 > <xs:element name= COMPL_NAME type= COMPLETE_NAME_TYPE /> <xs:element name= CLUB type= xs:string /> <xs:attribute name= number use= required > <xs:restriction base= xs:integer > <xs:mininclusive value= 1 /> <xs:maxinclusive value= 23 /> <xs:attribute name= age type= xs:integer use= required /> <xs:attribute name= goalkeeper type= xs:string fixed= YES /> <xs:attribute name= country use= required > <xs:restriction base= xs:string > <xs:enumeration value= KOREA /> <xs:enumeration value= JAPAN /> <xs:enumeration value= CHINA /> <xs:enumeration value= SAUDI ARABIA /> <xs:enumeration value= SOUTH AFRICA /> <xs:enumeration value= CAMEROON /> <xs:enumeration value= SENEGAL /> <xs:enumeration value= TUNISIA /> <xs:enumeration value= NIGERIA /> <xs:enumeration value= COSTA RICA /> <xs:enumeration value= USA /> <xs:enumeration value= MEXICO /> <xs:enumeration value= ARGENTINA /> <xs:enumeration value= PARAGUAY /> <xs:enumeration value= ECUADOR /> <xs:enumeration value= BRAZIL /> <xs:enumeration value= FRANCE /> <xs:enumeration value= POLAND /> <xs:enumeration value= SWEDEN /> <xs:enumeration value= SPAIN /> <xs:enumeration value= RUSSIA /> <xs:enumeration value= PORTUGAL /> <xs:enumeration value= DENMARK /> <xs:enumeration value= CROATIA /> <xs:enumeration value= ITALY /> <xs:enumeration value= ENGLAND /> <xs:enumeration value= SLOVENIA /> <xs:enumeration value= TURKEY /> <xs:enumeration value= BELGIUM /> <xs:enumeration value= GERMANY /> <xs:enumeration value= AUSTRALIA /> <xs:enumeration value= IRELAND REPUBLIC /> <xs:unique name= NUMBERING > <xs:selector xpath=./players/player /> <xs:field /> </xs:unique> </xs:schema> 49

5 F O C U S FIGURA 3 Validazione di Team.xml avvenuta con errore mediante XSV della squadra di club del calciatore. Sul CLUB non ci sono restrizioni. Dopo la sequenza vengono definiti tre attributi di PLAYER. Il numero di maglia number è obbligatorio ed è una restrizione del tipo xs:integer. Precisamente la restrizione consiste nel fatto che i valori che possono essere assunti da number sono compresi tra 1 e 23, estremi inclusi. Ciò è imposto mediante gli elementi mininclusive e maxinclusive. Gli elementi minexclusive e maxexclusive hanno la stessa funzione ma escludono gli estremi dell intervallo dai valori ammessi. Il secondo attributo di PLAYER è age, l età del calciatore. Si tratta di un intero obbligatorio senza restrizioni. Ultimo attributo del PLAYER è goalkeeper che indica se il calciatore deve essere registrato come portiere oppure no. goalkeeper è una stringa, non è obbligatorio e può assumere solo il valore fisso YES, ottenuto con fixed= YES. Quindi se l attributo compare vale YES ed indica che il calciatore è uno dei portieri, altrimenti l attributo deve mancare. Per concludere il nostro schema manca la definizione della quarta regola enunciata all inizio di quest articolo. Bisogna imporre l univocità dell attributo number dell elemento PLAYER. Cioè non ci possono essere due PLAYER con lo stesso number. Si fa come segue: <xs:element name= TEAM > <!-- tutto quello che abbiamo visto prima --> <xs:unique name= NUMBERING > <xs:selector xpath=./players/player /> <xs:field /> </xs:unique> Inseriamo un elemento <xs:unique> a livello di TEAM, cioè nell elemento TEAM ma fuori da tutti gli elementi che lo compongono. Attribuiamo a questa regola il nome NUMBERING. L elemento <xs:selector> indica qual è il nodo rispetto a cui deve essere controllata l unicità. L elemento <xs:field> indica quale campo deve essere univoco. Sia <xs:selector> che <xs:field> devono essere specificati mediante espressioni Xpath. Xpath è uno standard elaborato dal W3C per indicare i percorsi all interno di un documento. Non potendoci dilungare su Xpath diciamo solo che in un percorso scritto con Xpath, il simbolo / serve a scendere di un livello, il simbolo. Serve ad indicare il livello corrente, gli elementi possono essere indicati con il proprio nome mentre il deve essere anteposto al nome per indicare gli attributi. Dunque, nella definizione del selector, partendo dal nodo TEAM, il nodo PLAYER è indicato con l espressione Xpath./PLAYERS/PLAYER poiché è figlio di PLAYERS che è figlio diretto di TEAM, nodo corrente. Nella definizione del field, partendo dal selector, cioè da PLAYER, per raggiungere l attributo number bisogna scendere di un livello. L espressione Xpath Per seguire meglio la logica si può guardare la Figura 1 dove i nodi del nostro schema sono rappresentati graficamente. Bene, lo schema è completo. Lo si può vedere nella sua interezza nel Listato 1. A questo punto la FIFA invia alle federazioni lo schema che ha prodotto. Ogni federazione costruisce un documento con i dati richiesti. Bisogna effettuare il controllo della validità del documento. Purpose Scopo degli schemi è fornire un inventario di costrutti di markup con cui scrivere schemi. Lo scopo di uno schema è definire e descrivere una classe di documenti utilizzando questi costrutti per vincolare e documentare il significato, l utilizzo e le relazioni delle loro parti costituenti: tipi di dati, elementi e corrispondente contenuto, attributi e rispettivi valori, entità e relativi contenuti e notazioni. I costrutti di uno schema possono anche fornire le specifiche per informazioni implicite come nel caso di valori di default. Gli schemi documentano il proprio significato, utilizzo e funzione. In questo modo, il linguaggio degli schemi può essere utilizzato per definire, descrivere e catalogare dei vocabolari per le classi di documenti. Qualsiasi applicazione può utilizzare il formalismo Schema per esprimere la sintassi, i vincoli strutturali e di valore applicabili alle istanze di documento. Il formalismo Schema costituisce un utile livello di controllo dei vincoli che devono essere descritti e validati da un ampio spettro di applicazioni. Per applicazioni che richiedono altri vincoli, arbitrari o complicati, l applicazione deve eseguire direttamente ulteriori validazioni. 50 RIQUADRO 1 Le Purpose del W3C nelle specifiche di Schema

6 LISTATO 2 Team.xml, il documento d esempio <TEAM country= ITALY xmlns:xsi= si:nonamespaceschemalocation= C:\Programmi\XSV\team.xsd > <TRAINER fifa_id= ITA > <TR_COMPL_NAME> <SURNAME>Trapattoni</SURNAME> <NAME>Giovanni</NAME> </TR_COMPL_NAME> <NATIONALITY>Italy</NATIONALITY> </TRAINER> <PLAYERS> <PLAYER number= 1 age= 23 goalkeeper= YES > <SURNAME>Buffon</SURNAME> <NAME>Gianluigi</NAME> <PLAYER number= 2 age= 28 > <SURNAME>Bertotto</SURNAME> <NAME>Valerio</NAME> <CLUB>Udinese</CLUB> <PLAYER number= 3 age= 28 > <SURNAME>Cannavaro</SURNAME> <NAME>Fabio</NAME> <CLUB>Parma</CLUB> <PLAYER number= 4 age= 25 > <SURNAME>Nesta</SURNAME> <NAME>Alessandro</NAME> <CLUB>Lazio</CLUB> <PLAYER number= 5 age= 33 > <SURNAME>Maldini</SURNAME> <NAME>Paolo</NAME> <CLUB>Milan</CLUB> <PLAYER number= 6 age= 28 > <SURNAME>Materazzi</SURNAME> <NAME>Marco</NAME> <CLUB>Inter</CLUB> <PLAYER number= 7 age= 30 > <SURNAME>Albertini</SURNAME> <NAME>Demetrio</NAME> <CLUB>Milan</CLUB> <PLAYER number= 8 age= 24 > <SURNAME>Coco</SURNAME> <NAME>Francesco</NAME> <CLUB>Barcellona</CLUB> <PLAYER number= 9 age= 26 > <SURNAME>Fiore</SURNAME> <NAME>Stefano</NAME> <CLUB>Lazio</CLUB> <PLAYER number= 10 age= 23 > <SURNAME>Gattuso</SURNAME> <NAME>Ivan Gennaro</NAME> <CLUB>Milan</CLUB> <PLAYER number= 11 age= 31 > <SURNAME>Pessotto</SURNAME> <NAME>Gianluca</NAME> <PLAYER number= 12 age= 30 goalkeeper= YES > <SURNAME>Toldo</SURNAME> <NAME>Francesco</NAME> <CLUB>Inter</CLUB> <PLAYER number= 13 age= 26 > <SURNAME>Tacchinardi</SURNAME> <NAME>Alessio</NAME> <PLAYER number= 14 age= 27 > <SURNAME>Tommasi</SURNAME> <NAME>Damiano</NAME> <CLUB>Roma</CLUB> <PLAYER number= 15 age= 24 > <SURNAME>Zambrotta</SURNAME> <NAME>Gianluca</NAME> <PLAYER number= 16 age= 24 > <SURNAME>Zenoni</SURNAME> <NAME>Cristian</NAME> <PLAYER number= 17 age= 27 > <SURNAME>Del Piero</SURNAME> <NAME>Alessandro</NAME> <PLAYER number= 18 age= 28 > <SURNAME>Del Vecchio</SURNAME> <NAME>Marco</NAME> <CLUB>Roma</CLUB> <PLAYER number= 19 age= 28 > <SURNAME>Inzaghi</SURNAME> <NAME>Filippo</NAME> <CLUB>Milan</CLUB> <PLAYER number= 20 age= 27 > <SURNAME>Montella</SURNAME> <NAME>Vincenzo</NAME> <CLUB>Roma</CLUB> <PLAYER number= 21 age= 25 > <SURNAME>Totti</SURNAME> <NAME>Francesco</NAME> <CLUB>Roma</CLUB> <PLAYER number= 22 age= 28 > <SURNAME>Vieri</SURNAME> <NAME>Christian</NAME> <CLUB>Inter</CLUB> <PLAYER number= 23 age= 31 goalkeeper= YES > <SURNAME>Peruzzi</SURNAME> <NAME>Angelo</NAME> <CLUB>Lazio</CLUB> </PLAYERS> </TEAM> 51

7 F O C U S 52 Controllo della validità del documento Nel Listato 2 è possibile vedere il documento inviato dalla FIGC (Federazione Italiana Gioco Calcio) alla FIFA (ovviamente i convocati me li ha indicati Trapattoni in persona!). Per validare automaticamente il documento sulla base dello schema esistono numerosi tool. Per quest esempio è stato utilizzato XSV, un programmino open source che funziona da linea di comando a cui basta passare il nome del documento da validare per ottenere il risultato. XSV si può scaricare dall indirizzo ftp://ftp.cogsci.ed.ac.uk/pub/xsv/xsv12.exe Ovviamente nel documento bisogna in qualche modo indicare il nome dello schema da utilizzare, si fa così: <TEAM country= ITALY xmlns:xsi= xsi:nonamespaceschemalocation= C:\Programmi\XSV\team.xsd > FIGURA 4 L albero di derivazione dei tipi di dato semplici definiti in Schema Dunque affermando che il namespace utilizzato è un istanza di Schema situata all indirizzo C:\Documenti\articoli\Schema\team.xsd. In Figura 2 è possibile vedere la validazione avvenuta con successo di team.xml (Listato 2). In Figura 3 è possibile vedere la validazione avvenuta con errore di team.xml dove era stato attribuito il numero 2 anche a Buffon, violando la regola denominata NUMBERING. Si può notare che entrambe le risposte di XSV sono in formato. Tipi di dato di Schema L esempio è stato molto utile per capire a cosa serve Schema. Abbiamo visto l utilizzo di alcuni tipi di dato, torniamo sull argomento per una panoramica breve ma un po più generale. I tipi di dato in Schema sono organizzati in maniera gerarchica. Ogni tipo si può ottenere dal tipo padre mediante uno dei seguenti quattro metodi: restrizione, estensione, lista ed unione. Abbiamo visto nel nostro esempio alcuni casi di restrizione, per motivi di spazio non ci soffermiamo sugli altri tipi di derivazione. Per maggiori informazioni sulla derivazione dei tipi si possono consultare [4] e [8]. Il tipo di dato che sta alla radice della gerarchia si chiama anytype e da esso è possibile ottenere, per successive derivazioni, tutti i tipi. Al livello subito inferiore di anytype ci sono i due tipi simpletype e complextype di cui abbiamo visto numerose occorrenze nel nostro esempio. I tipi di dato semplici sono quelli che non possono avere elementi figli né attributi, sono deputati a conservare un dato elementare. Esistono 44 tipi di dato semplici, cioè derivati da simpletype, già definiti in Schema. Ad essi è possibile aggiungere qualunque tipo personalizzato, come abbiamo fatto nel nostro esempio. In Figura 4 è rappresentato l albero di derivazione dei tipi di dato semplici definiti in Schema tratto da [4]. La derivazione di un tipo di dato per restrizione può avvenire impo-

8 stando dodici proprietà del tipo, tra cui la lunghezza e l intervallo dei valori ammessi. Queste proprietà sono dette facet. I tipi complessi si dividono a loro volta in due categorie. I tipi complessi con contenuto semplice (simplecontent) possono avere attributi e contenere dati elementari. I tipi complessi con contenuto complesso (complexcontent) possono avare anche degli elementi figlio. Per tutti i tipi complessi la sintassi è: <xs:element name=nome_tipo attributi> <xs:simplecontent> oppure <xs:complexcontent> <!-- contenuto del tipo --> </xs:simplecontent> oppure </xs:complexcontent> </xs:element > Nel nostro esempio all interno dei non abbiamo mai trovato <xs:simplecontent> né <xs:complexcontent>. Questo perché per default il contenuto di è <xs:complexcontent>, dunque nel caso di contenuto complesso la sintassi si può ridurre a: <xs:element name=nome_tipo attributi> <!-- contenuto del tipo --> </xs:element > che è la sintassi utilizzata nel nostro esempio. Schema e SOAP I tipi di dato sono la caratteristica principale di Schema ed il motivo principale per cui si lavora su questo standard. Prima di Schema, chi utilizzava si trovava a dover sopperire alla mancanza dei tipi di dato definendoli da solo. È quello che è successo agli autori di SOAP, Simple Object Access Protocol. SOAP è basato su e, come dice il nome, è un protocollo per l accesso ad oggetti remoti. Essendo nato prima di Schema, SOAP ha dovuto fare i conti con l assenza dei tipi di dato in. Gli autori si sono dovuti sobbarcare un grosso lavoro di definizione dei tipi che li ha impegnati spesso più di tutte le altre attività. Con la stabilizzazione di Schema anche SOAP ha raggiunto una maggiore stabilità, confermata dalla creazione in seno al W3C di un gruppo di lavoro specifico per i protocolli. Il W3C lavora oggi anche su SOAP (versione 1.2). Il gruppo di lavoro di SOAP è impegnato a stretto contatto con il gruppo di Schema per sfruttare al massimo le potenzialità di entrambi gli strumenti. Finalmente SOAP non ha più il compito di definire i tipi di dato per, di questo da oggi si occupa Schema. Per maggiori informazioni sull evoluzione di SOAP in relazione ai tipi di dato e Schema si può consultare [9]. Conclusioni Qualcuno vede Schema come un male necessario, qualcosa di cui non si può proprio fare a meno (per la gestione dei tipi di dato) ma troppo complicato per essere utilizzato nel pieno delle sue potenzialità. Certo non si può affermare che Schema abbia semplificato la vita a chi utilizzava DTD, ma sicuramente si può affermare che si tratta di uno strumento potente ed abbastanza flessibile. Si può utilizzare Schema in maniera minimale come suggerito in [7], oppure cercare di sfruttarlo pienamente, magari con l aiuto di un tool. La scelta resta, come sempre, a chi progetta l applicazione. Molte altre informazioni su Schema e SOAP possono essere reperite sui Riferimenti che seguono quest articolo. BIBLIOGRAFIA [1] M. Ashok, M. Murray Schema Requirements, W3C, 1999 [2] D. C. Fallside Schema Part 0: Primer, W3C, 2001 [3] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn Schema Part 1: Structures, W3C, 2001 [4] P. V. Biron, A. Malhotra Schema Part 2: Datatypes, W3C, 2001 [5] A. Brown, M. Fuchs, J. Robie, P. Wadler Schema: Formal Description, W3C, 2001 [6] E. van der Vlist Using W3C Schema,.com, 2000 [7] K. Kawaguchi W3C Schema Made Simple,.com, 2001 [8] D. Smith Understanding W3C Schema Complex Types,.com, 2001 [9] D. Box A Brief History of SOAP,.com, 2001 RIFERIMENTI [10] - Home page di W3C Schema [11] - Home page di W3C Protocol, cioè SOAP [12] - Articoli su Schema [13] - Articoli su Protocol, tra cui SOAP 53