XML/Schemi di dati: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
tradotto da https://en.wikibooks.org/w/index.php?title=XML_-_Managing_Data_Exchange/Data_schemas&oldid=3441977
 
m Update syntaxhighlight tags - remove use of deprecated <source> tags
Riga 22:
Tutti gli schemi iniziano allo stesso modo, non importa quale tipo di oggetti rappresentano. La prima riga in ogni schema contiene questa dichiarazione:
 
<sourcesyntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
</syntaxhighlight>
</source>
 
Questo testo dice semplicemente al browser o a qualsiasi altro file/programma che acceda a questo schema che si tratta un file XML e che utilizza la codifica della struttura "UTF-8". È possibile copiare questo da utilizzare per avviare il proprio file XML.
Riga 30:
Poi viene la dichiarazione del namespace:
 
<sourcesyntaxhighlight lang="xml">
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified">
</syntaxhighlight>
</source>
 
I namespace sono fondamentalmente dizionari che contengono le definizioni della maggior parte delle codifiche nello schema. Ad esempio, queo si crea uno schema, se si dichiara un oggetto di tipo "String", la definizione del tipo "String" è contenuta nel Namespace insieme a tutti i suoi attributi. Questo è vero per la maggior parte del codice che si scrive. Se avete fatto o visto altri schemi, la maggior parte del codice è preceduto da "xsd:". Un buon esempio è qualcosa come "xsd:sequence" o "xsd:complexType". sequenza e complexType sono entrambi oggetti definiti nel Namespace e sono stati collegati al prefisso "xsd". In realtà, si potrebbe teoricamente non dare un nome al Namespace, se a esso si fa riferimento allo stesso modo in tutto lo Schema. Il più comune Namespace che contiene la maggior parte degli oggetti XML è <nowiki>http://www.w3.org/2001/XMLSchema</nowiki>.
Riga 43:
Esistono due tipi di entità: '''simpleType''' e '''complexType'''. Un oggetto simpleType ha un valore associato a esso. Una stringa è un perfetto esempio di oggetto simpleType, in quanto contiene solo il valore della stringa. La maggior parte dei simpleType usati saranno definiti nel namespace predefinito; tuttavia, è possibile definire il proprio simpleType in fondo allo schema (questo sarà riportato nella sezione restrizioni). Per questo motivo, gli unici oggetti che più spesso è necessario includere nello schema sono i tipi complessi. Un complexType è un oggetto con più di un attributo a esso associato, e può avere o meno elementi figlio a esso collegati. Ecco un esempio di un oggetto complexType:
 
<sourcesyntaxhighlight lang="xml">
<xsd:complexType name="GenreType">
<xsd:sequence>
Riga 51:
</xsd:sequence>
</xsd:complexType>
</syntaxhighlight>
</source>
 
Questo codice inizia con la dichiarazione di un complexType e il suo nome. Queo altre entità vi si riferiscono, come ad esempio un elemento padre, farà riferimento a questo nome. La seconda riga inizia con la sequenza di attributi ed elementi figli, che sono tutti dichiarati con "element". Gli elementi sono dichiarati come elementi nella prima parte della riga di codice, e il loro nome, a cui faranno riferimento altri documenti, è incluso come "name" come seconda parte. Dopo le prime due dichiarazioni viene la dichiarazione di "type". Si noti che per gli elementi ''name'' e ''description'' il loro tipo è "xsd:string", cioè il tipo di stringa è definito nel namespace "xsd". Per l'elemento ''movie'' il tipo è "MovieType", e poiché non c'è namespace prima di "MovieType", si presume che questo tipo sia incluso in questo schema (potrebbe riferirsi a un tipo definito in un altro schema se l'altro schema fosse incluso nella parte superiore del nostro schema; ma di questo ci si occuperà in seguito). "minOccurs" e "maxOccurs" rappresentano la relazione tra GenreType e MovieTypes. "minOccurs" può essere sia 0 sia un numero arbitrario, a seconda del modello di dati. "maxOccurs" può essere 1 (relazione uno-a-uno), un numero arbitrario (relazione uno-a-molti), o "unbounded" (relazione uno-a-molti).
Riga 57:
Per ogni schema, ci deve essere un '''elemento radice'''. Questa entità contiene ogni altra entità al di sotto di essa nella gerarchia. Per esempio, queo si crea uno schema per includere una lista di film, l'elemento principale sarebbe qualcosa come MovieDatabase, o forse MovieCollection, solo qualcosa che contiene logicamente tutti gli altri oggetti (come genere, film, attore, regista, regista, plotline, etc.) Si inizia sempre con questa linea di codice: <code><xsd:element name="xxx"></code> mostreo che è l'elemento principale e poi prosegue come un normale complexType. Tutti gli altri oggetti inizieranno con simpleType o complexType. Ecco un esempio di codice per un elemento radice chiamato MovieDatabase:
 
<sourcesyntaxhighlight lang="xml">
<xsd:element name="MovieDatabase">
<xsd:complexType>
Riga 65:
</xsd:complexType>
</xsd:element>
</syntaxhighlight>
</source>
 
Questo rappresenta un database di film dove l'elemento figlio di MovieDatabase è un genere. Da lì va su film e via dicendo. Nei prossimi paragrafi continueremo a usare questo esempio per capire meglio.
Riga 72:
Il rapporto genitore/figlio è un argomento chiave negli schemi di dati. Rappresenta la struttura di base della gerarchia del modello di dati, delineeo chiaramente la configurazione dall'alto verso il basso. Guardate questo pezzo di codice che mostra come i film hanno degli attori a essi associati:
 
<sourcesyntaxhighlight lang="xml">
<xsd:complexType name="MovieType">
<xsd:sequence>
Riga 86:
</xsd:sequence>
</xsd:complexType>
</syntaxhighlight>
</source>
 
All'interno di ogni MovieType, c'è un elemento chiamato "actor" che è di tipo "ActorType". Queo il documento XML è popolato di informazioni, i tag circostanti per l'attore saranno <code><actor></actor></code> e non <code><ActorType></ActorType></code>. Per mantenere il tuo Schema scorrevole e senza errori, il campo ''type'' nell'elemento padre sarà sempre uguale al campo ''name'' nella dichiarazione dell'elemento figlio complexType.
Riga 95:
In alcuni casi, alcuni dati devono rispettare uno steard per mantenere l'integrità dei dati. Un esempio potrebbe essere un numero di previdenza sociale o un indirizzo e-mail. Se si dispone di un database di indirizzi e-mail a cui inviare e-mail di massa, è necessario che siano tutti indirizzi validi, altrimenti si otterrebbero svariati messaggi di errore ogni volta che si inviano e-mail di massa. Per evitare questo problema, si può prendere un noto simpleType e aggiungere una restrizione per meglio soddisfare le vostre esigenze. Si può fare questo in due modi, ma uno è più semplice e migliore da usare in schemi di dati. Si potrebbe modificare il simpleType all'interno della sua dichiarazione nell'elemento genitore, ma diventa disordinato, e se un altro schema vuole usarlo, il codice deve essere scritto di nuovo. Il modo migliore per farlo è elencare un nuovo tipo in fondo allo schema che modifica un simpleType precedentemente conosciuto. Ecco un esempio di questo con un numero di sicurezza sociale:
 
<sourcesyntaxhighlight lang="xml">
<xsd:simpleType name="emailaddressType">
<xsd:restriction base="xsd:string">
Riga 107:
</xsd:restriction>
</xsd:simpleType>
</syntaxhighlight>
</source>
 
Questo è stato incluso nello schema sotto l'ultimo elemento figlio e prima della chiusura con <code></xsd:schema></code>. La prima riga dichiara il simpleType e gli dà un nome, "ssnType". Puoi dargli qualsiasi nome tu voglia, a patto che vi si faccia riferimento correttamente in tutto lo Schema. In questo modo è possibile utilizzare questo tipo in qualsiasi punto dello schema, o in qualsiasi altro schema, a condizione che i riferimenti siano corretti. La seconda riga fa sapere allo schema che si tratta di un tipo ristretto e la sua base è una stringa definita nel namespace predefinito. Fondamentalmente, questo tipo è una stringa con una restrizione su di essa, e la terza riga è la restrizione effettiva. Può essere uno dei molti tipi di restrizioni, che sono elencati nell'appendice di questo modulo. Questo accade con il tipo "pattern", e significa che solo una certa sequenza di caratteri sarà consentita nel documento XML ed è definita nel campo ''value''. Questa particolare sequenza di caratteri significa tre cifre, un trattino, due cifre, un trattino e quattro cifre. Per saperne di più su come usare le restrizioni, segui questo [http://www.w3schools.com/schema/schema_elements_ref.asp link] nella sezione restrizioni della W3 School.
Riga 114:
Il tag <code><xsd:import></code> è usato per importare un documento schema e il namespace associato con tipi di dati definiti nel documento schema. Questo permette a un documento di schema XML di fare riferimento a una libreria di tipi useo i nomi dei namespace (prefissi). Diamo un'occhiata più da vicino a un semplice documento di istanza XML per un negozio che usa questi nomi multipli di namespace:
 
<sourcesyntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<store:SimpleStore xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Riga 144:
<!-- Ulteriori negozi vanno qui. -->
</store:SimpleStore>
</syntaxhighlight>
</source>
 
Guardiamo il documento schema e vediamo come il tag <code><xsd:import></code> è stato usato per importare i tipi di dati da una libreria di tipi (documento schema esterno).
 
<sourcesyntaxhighlight lang="xml">
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.opentourism.org/xmltext/Store.xml"
Riga 188:
</xsd:complexType>
</xsd:schema>
</syntaxhighlight>
</source>
 
Come il tag ''include'' e il tag ''redefine'', il tag di importazione è un altro mezzo per incorporare qualsiasi tipo di dati di un documento schema esterno in un altro documento schema e deve avvenire prima di qualsiasi elemento o dichiarazione di attributo. Questi meccanismi sono importanti queo gli schemi XML sono modularizzati e le librerie di tipi sono mantenute e utilizzate in documenti con schemi multipli.
Riga 207:
Anzitutto, lo schema completo usato negli esempi di questo modulo:
 
<sourcesyntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
 
Riga 259:
</xsd:schema>
</syntaxhighlight>
</source>
 
È tempo di tornare all'inizio... e rivedere tutti i tipi di dati, gli elementi e gli attributi dello schema che abbiamo coperto fino a ora (e forse alcuni che non abbiamo ancora visto). Le seguenti tabelle descrivono in dettaglio i tipi di dati XML, gli elementi e gli attributi che possono essere utilizzati in uno schema XML.