XML/Schemi di dati

Obiettivi di apprendimento

Panoramica di schemi di dati
Iniziare uno schema nel modo corretto
Entità in generale
Struttura genitore/figlio
Attributi e restrizioni
Terminare lo schema nel modo corretto

Gli schemi di dati sono la base di tutte le pagine XML. Definiscono gli oggetti, le loro relazioni, i relativi attributi e la struttura del modello di dati. Senza di loro, i documenti XML non esisterebbero. In questo capitolo, si arriva a capire lo scopo degli schemi di dati XML, le loro parti e come utilizzarli. Inoltre, esempi saranno inclusi per la copia durante la creazione di un proprio schema dei dati e rendere il vostro lavoro molto più facile. Inoltre, saranno inclusi degli esempi da copiare per creare il proprio schema di dati, così da rendere più facile il lavoro. In fondo a questo modulo è stato incluso uno schema intero, dal quale sono state tratte le parti citate nei vari paragrafi. Si faccia riferimento a questo per capire come lavora uno schema intero a esso se Le piacerebbe vedere come lo Schema intero lavora come uno schema intero.

Panoramica degli schemi di dati

Lo schema di dati, dettagli tecnici a parte, è il modello di dati in cui tutte le informazioni XML vengono convogliate. Ha una struttura gerarchica che parte da un elemento radice (questo concetto verrà spiegato più avanti) e scende fino al dettaglio più minuto del modello, con in mezzo passaggi dettagliati.

Gli schemi di dati hanno due parti principali, le entità e le loro relazioni. Le entità contenute in uno schema dati rappresentano gli oggetti del modello. Hanno identificatori univoci, attributi e nomi in base al tipo di oggetto. Le relazioni nello schema rappresentano, molto semplicemente, le relazioni tra gli oggetti. Le relazioni possono essere uno-a-uno, uno-a-molti, molti-a-molti, ricorsiva e qualsiasi altro tipo che si può trovare in un modello dati.

Ora inizieremo a creare il nostro schema di dati.

Iniziare uno schema nel modo corretto

Tutti gli schemi iniziano allo stesso modo, non importa quale tipo di oggetti rappresentano. La prima riga in ogni schema contiene questa dichiarazione:

<?xml version="1.0" encoding="UTF-8"?>

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.

Poi viene la dichiarazione del namespace:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified">

I namespace sono fondamentalmente dizionari che contengono le definizioni della maggior parte delle codifiche nello schema. Ad esempio, quando 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 è http://www.w3.org/2001/XMLSchema.

Venendo all'esempio più sopra, la prima parte consente a qualsiasi file/programma di sapere che questo file è uno schema. Come la dichiarazione XML, questo è comune a tutti gli schemi XML e si può utilizzarlo anche nel proprio schema. La seconda parte è la dichiarazione del Namespace effettiva; xmlns sta per XML NameSpace. Questo definisce il namespace predefinito dello Schema ed è di solito dato nel codice. Ancora una volta, si consiglia di utilizzare questo codice per avviare gli schemi. L'ultima parte è difficile da capire, ma qui viene data una spiegazione abbastanza dettagliata. Utilizzare "unqualified" è più facile da applicare, fino a queo non si ha un codice davvero complicato.

Entità

Le entità sono fondamentalmente gli oggetti per rappresentare i quali uno schema è stato creato. Come detto prima, hanno attributi e relazioni. Ora vedremo esattamente cosa sono e come scriverne il codice.

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:

<xsd:complexType name="GenreType">
  <xsd:sequence>
    <xsd:element name="name" type="xsd:string"/>
    <xsd:element name="description" type="xsd:string"/>
    <xsd:element name="movie" type="MovieType" minOccurs="1" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

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).

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: <xsd:element name="xxx"> 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:

<xsd:element name="MovieDatabase">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element name="Genre" type="GenreType" minOccurs="1" maxOccurs="unbounded"/>            
       </xsd:sequence>
     </xsd:complexType>
   </xsd:element>

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.

La relazione genitore/figlio

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:

<xsd:complexType name="MovieType">
  <xsd:sequence>
    <xsd:element name="name" type="xsd:string"/>       
    <xsd:element name="actor" type="ActorType" minOccurs="1" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
     
<xsd:complexType name="ActorType">
  <xsd:sequence>
    <xsd:element name="lname" type="xsd:string"/>
    <xsd:element name="fname" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>

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 <actor></actor> e non <ActorType></ActorType>. 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.

Attributi e restrizioni

Un attributo di un'entità è un oggetto simpleType, in quanto contiene un solo valore. <xsd:element name="lname" type="xsd:string"/> è un buon esempio di attributo. È dichiarato come elemento, ha un nome associato a esso e ha una dichiarazione di tipo. Nell'appendice di questo modulo c'è una lunga lista di simpleTypes incorporati nel namespace predefinito. Gli attributi sono incredibilmente semplici da usare, fino a queo non si cerca di limitarli.

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:

<xsd:simpleType name="emailaddressType">
  <xsd:restriction base="xsd:string">
    <xsd:pattern value="[^@]+@[^\.]+\..+"/>
  </xsd:restriction>
</xsd:simpleType>
   
<xsd:simpleType name="ssnType">
  <xsd:restriction base="xsd:string">
    <xsd:pattern value="\d{3}-\d{2}-\d{4}"/>
  </xsd:restriction>
</xsd:simpleType>

Questo è stato incluso nello schema sotto l'ultimo elemento figlio e prima della chiusura con </xsd:schema>. 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 link nella sezione restrizioni della W3 School.

Introduzione al tag `<xsd:import>`

Il tag <xsd:import> è 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:

<?xml version="1.0" encoding="UTF-8"?>
<store:SimpleStore xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opentourism.org/xmltext/SimpleStore.xsd"
  xmlns:store="http://www.opentourism.org/xmltext/Store"
  xmlns:MGR="http://www.opentourism.org/xmltext/CoreSchema">
  <!-- Si noti che le dichiarazioni del namespace esplicitamente definite: il prefisso store  
     rappresenta i tipi di dati definiti in   
     <code>http://www.opentourism.org/xmltext/Store.xml</code>
     Inoltre, si noti che non c'è nessuna dichiarazione namespace predefinita: ogni elemento
     e attributo deve essere associato ad un namespace (vedremo che questo è 
     necessario perché esaminiamo il documento schema)  
-->
  <store:Store>
    <MGR:Name xmlns:MGR=" http://www.opentourism.org/xmltext/CoreSchema ">
      <MGR:FirstName>Michael</MGR:FirstName>
      <MGR:MiddleNames>Jay</MGR:MiddleNames>
      <MGR:LastName>Fox</MGR:LastName>
    </MGR:Name>
    <store:StoreName>The Gap</store:StoreName>
    <store:StoreAddress>
      <store:Street>86 Nowhere Ave.</store:Street>
      <store:City>Los Angeles</store:City>
      <store:State>CA</store:State>
      <store:ZipCode>75309</store:ZipCode>
    </store:StoreAddress>
    <!-- Ulteriori informazioni sul negozio vanno qui. -->
  </store:Store>
  <!-- Ulteriori negozi vanno qui. -->
</store:SimpleStore>

Guardiamo il documento schema e vediamo come il tag <xsd:import> è stato usato per importare i tipi di dati da una libreria di tipi (documento schema esterno).

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://www.opentourism.org/xmltext/Store.xml"
  xmlns:MGR="http://www.opentourism.org/xmltext/CoreSchema"
  targetNamespace="http://www.opentourism.org/xmltext/Store.xml" elementFormDefault="qualified">
  <!-- Il prefisso MGR è legato al seguente namespace: 
          <code>http://www.opentourism.org/xmltext/CoreSchema</code>
          Il documento dello schema managerTypeLib.xsd viene importato associando lo schema 
          con <code>http://www.opentourism.org/xmltext/CoreSchema</code> 
          che è collegato al prefisso MGR. 
         L'attributo elementFormDefault ha il valore "qualified" e indica che 
          un documento di istanza XML deve usare nomi qualificati per ogni elemento (il
          namespace predefinito non può essere utilizzato)  
-->
  <!-- Il namespace di destinazione e quello di default sono gli stessi  -->
  <xsd:import namespace="http://www.opentourism.org/xmltext/CoreSchema"
    schemaLocation="ManagerTypeLib.xsd"/>
  <xsd:element name="SimpleStore">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="Store" type="StoreType" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:complexType name="StoreType">
    <xsd:sequence>
      <xsd:element ref="MGR:Name"/>
      <xsd:element name="StoreName" type="xsd:string"/>
      <xsd:element name="StoreAddress" type="StoreAddressType"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="StoreAddressType">
    <xsd:sequence>
      <xsd:element name="Street" type="xsd:string"/>
      <xsd:element name="City" type="xsd:string"/>
      <xsd:element name="State" type="xsd:string"/>
      <xsd:element name="ZipCode" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

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.

Modularizzazione degli schemi

Ora che abbiamo coperto tutti e tre i metodi per incorporare schemi XML esterni, consideriamo l'importanza di questi meccanismi. Come è tipico della maggior parte del codice di programmazione, la ridondanza è disapprovata; questo è vero anche per le definizioni dei tipi di dati personalizzati. Se esiste già un tipo di dati personalizzati che può essere applicato a un elemento del documento schema, non è meglio usare questo tipo di dati piuttosto che crearlo nuovamente all'interno del nuovo documento schema? Inoltre, se si sa che un singolo tipo di dati può essere riutilizzato per diverse applicazioni, non si dovrebbe avere un metodo per fare riferimento a quel tipo di dati queo se ne ha bisogno?

L'idea alla base degli schemi modulari è di esaminare cosa fa il vostro schema, determinare quali tipi di dati sono frequentemente usati in una forma o nell'altra e sviluppare una libreria di tipi. Man mano che aumentano le esigenze di schemi più complessi, è possibile continuare ad aggiungerli alla libreria, riutilizzare i tipi di dati nella libreria dei tipi e ridefinire questi tipi di dati secondo necessità. Un esempio di questo riutilizzo potrebbe essere uno schema per le informazioni sui clienti: reparti diversi utilizzerebbero schemi diversi, in quanto avrebbero bisogno solo di informazioni parziali sui clienti. Tuttavia la maggior parte dei reparti, se non tutti, avrebbe bisogno di alcune informazioni specifiche sui clienti, come il nome e le informazioni di contatto, che potrebbero essere incorporate nei singoli documenti dello schema dipartimentale.

La modularizzazione dello schema è una buona pratica. Mantenendo una libreria di tipi e riutilizzeo e ridefinendo i tipi nella libreria, si può aiutare a garantire che i documenti dello schema XML non diventino schiaccianti e difficili da leggere. La leggibilità è importante, perché potresti non essere l'unico a usare questi schemi, ed è importante che altri possano comprendere facilmente i tuoi documenti schema.

Alternative di schema

Finora in questo libro abbiamo discusso solo gli schemi XML come definiti dal World Wide Web Consortium (W3C). Tuttavia ci sono altri metodi per definire i dati contenuti in un documento XML, ma menzioneremo solo le due alternative più popolari e conosciute: Document Type Definition (DTD) e Relax NG Schema.

Tratteremo le DTD nel prossimo modulo. Lo Relax NG Schema^[1] è più recente e ha molte delle stesse caratteristiche dello schema W3C XML; Relax NG sostiene anche di essere più semplice, e più facile da imparare, ma questo è molto soggettivo.

Appendice

Anzitutto, lo schema completo usato negli esempi di questo modulo:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified">
    
   <xsd:element name="MovieDatabase">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element name="Genre" type="GenreType" minOccurs="1" maxOccurs="unbounded"/>            
       </xsd:sequence>
     </xsd:complexType>
   </xsd:element>
         
     <xsd:complexType name="GenreType">
       <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
         <xsd:element name="description" type="xsd:string"/>
         <xsd:element name="movie" type="MovieType" minOccurs="1" maxOccurs="unbounded"/>
       </xsd:sequence>
     </xsd:complexType>
     
     <xsd:complexType name="MovieType">
       <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
         <xsd:element name="rating" type="xsd:string"/>
         <xsd:element name="director" type="xsd:string"/>
         <xsd:element name="writer" type="xsd:string"/>
         <xsd:element name="year" type="xsd:int"/>
         <xsd:element name="tagline" type="xsd:string"/>       
         <xsd:element name="actor" type="ActorType" minOccurs="1" maxOccurs="unbounded"/>
       </xsd:sequence>
     </xsd:complexType>
     
     <xsd:complexType name="ActorType">
       <xsd:sequence>
         <xsd:element name="lname" type="xsd:string"/>
         <xsd:element name="fname" type="xsd:string"/>
         <xsd:element name="gender" type="xsd:string"/>
         <xsd:element name="bday" type="xsd:string"/>
         <xsd:element name="birthplace" type="xsd:string"/>
         <xsd:element name="ssn" type="ssnType"/>
       </xsd:sequence>
     </xsd:complexType>
     
     <xsd:simpleType name="ssnType">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="\d{3}-\d{2}-\d{4}"/>
       </xsd:restriction>
   </xsd:simpleType>
   
</xsd:schema>

È 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.

Tipi primitivi

Questa è una tabella con tutti i tipi primitivi che gli attributi del tuo schema possono essere.

Tipo	Sintassi	Esempi di valore	Caratteristiche del contenuto
xsd:anyURI	<xsd:element name = “url” type = “xsd:anyURI” />	http://www.w3.com	length, minLength, maxLength, pattern, enumeration, whitespace
xsd:boolean	<xsd:element name = “hasChildren” type = “xsd:boolean” />	true o false o 1 o 0	pattern e whitespace
xsd:byte	<xsd:element name = “stdDev” type = “xsd:byte” />	da -128 a 127	length, minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:date	<xsd:element name = “dateEst” type = “xsd:date” />	2004-03-15	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:dateTime	<xsd:element name = “xMas” type = “xsd:dateTime” />	2003-12-25T08:30:00	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:decimal	<xsd:element name = “pi” type = “xsd:decimal” />	3.1415292	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, fractionDigits, e totalDigits
xsd:double	<xsd:element name = “pi” type = “xsd:double” />	3.1415292 o INF o NaN	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:duration	<xsd:element name = “MITDuration” type = “xsd:duration” />	P8M3DT7H33M2S
xsd:float	<xsd:element name = “pi” type = “xsd:float” />	3.1415292 o INF o NaN	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:gDay	<xsd:element name = “dayOfMonth” type = “xsd:gDay” />	---11	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:gMonth	<xsd:element name = “monthOfYear” type = “xsd:gMonth” />	--02--	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:gMonthDay	<xsd:element name = “valentine” type = “xsd:gMonthDay” />	--02-14	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:gYear	<xsd:element name = “year” type = “xsd:gYear” />	1999	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:gYearMonth	<xsd:element name = “birthday” type = “xsd:gYearMonth” />	1972-08	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:ID	<xsd:attribute name="id" type="xsd:ID"/>	id-102	length, minLength, maxLength, pattern, enumeration, e whitespace
xsd:IDREF	<xsd:attribute name="version" type="xsd:IDREF"/>	id-102	length, minLength, maxLength, pattern, enumeration, e whitespace
xsd:IDREFS	<xsd:attribute name="versionList" type="xsd:IDREFS"/>	id-102 id-103 id-100	length, minLength, maxLength, pattern, enumeration, e whitespace
xsd:int	<xsd:element name = “age” type = “xsd:int” />	77	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:integer	<xsd:element name = “age” type = “xsd:integer” />	77	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:long	<xsd:element name = “cannelNumber” type = “xsd:int” />	214	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace
xsd:negativeInteger	<xsd:element name = “belowZero” type = “xsd:negativeInteger” />	-123	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:nonNegativeInteger	<xsd:element name = “numOfchildren” type = “xsd:nonNegativeInteger” />	2	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:nonPositiveInteger	<xsd:element name = “debit” type = “xsd:nonPositiveInteger” />	0	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:positiveInteger	<xsd:element name = “credit” type = “xsd:positiveInteger” />	500	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:short	<xsd:element name = “numOfpages” type = “xsd:short” />	476	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, whitespace, e totalDigits
xsd:string	<xsd:element name = “name” type = “xsd:string” />	Joeseph	length, minLength, maxLength, pattern, enumeration, whitespace, e totalDigits
xsd:time	<xsd:element name = “credit” type = “xsd:time” />	13:02:00	minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, e whitespace,

Elementi schema

Ecco una lista di tutti gli elementi che possono essere inclusi nei vostri schemi.^[2]

Elemento	Descrizione
all	Specifica che gli elementi figlio possono apparire in qualsiasi ordine. Ogni elemento bambino può comparire 0 o 1 volta.
annotation	Specifica l'elemento di primo livello per i commenti allo schema
any	Consente all'autore di estendere il documento XML con elementi non specificati dallo schema
anyAttribute	Consente all'autore di estendere il documento XML con attributi non specificati dallo schema
appInfo	Specifica le informazioni che devono essere utilizzate dall'applicazione (deve andare all'interno dell'annotazione)
attribute	Definisce un attributo
attributeGroup	Definisce un gruppo di attributi da utilizzare nelle definizioni di tipi complessi
choice	Consente solo uno degli elementi contenuti nella dichiarazione <choice> per essere presente all'interno dell'elemento contenitore
complexContent	Definisce estensioni o restrizioni su un tipo complesso che contiene solo contenuto o elementi misti
complexType	Definisce un elemento di tipo complesso
documentation	Definisce i commenti di testo in uno schema (deve andare all'interno dell'annotazione)
element	Definisce un elemento
extension	Estende un elemento simpleType o complexType esistente
field	Specifica un'espressione XPath che specifica il valore utilizzato per definire un vincolo di identità
group	Definisce un gruppo di elementi da utilizzare nelle definizioni di tipi complessi
import	Aggiunge più schemi con un diverso namespace di destinazione a un documento
include	Aggiunge più schemi con lo stesso spazio dei nomi di destinazione a un documento
key	Specifica un attributo o un valore di elemento come una chiave (univoca, mai vuota e sempre presente) all'interno dell'elemento contenitore in un documento di istanza
keyref	Specifica che un attributo o un valore di un elemento corrispondono a quelli della chiave specificata o dell'elemento univoco
list	Definisce un elemento di tipo semplice come un elenco di valori
notation	Descrive il formato di dati non XML all'interno di un documento XML
redefine	Ridefinisce tipi semplici e complessi, gruppi e gruppi di attributi da uno schema esterno
restriction	Definisce le restrizioni su simpleType, simpleContent o complexContent
schema	Definisce l'elemento radice di uno schema
selector	Specifica un'espressione XPath che seleziona un insieme di elementi per un vincolo di identità
sequence	Specifica che gli elementi figli devono apparire in una sequenza. Ogni elemento figlio può ricorrere da 0 a qualsiasi numero di volte
simpleContent	Contiene estensioni o restrizioni su un tipo complesso di solo testo o su un tipo semplice come contenuto e non contiene elementi
simpleType	Definisce un tipo semplice e specifica i vincoli e le informazioni sui valori degli attributi o degli elementi di solo testo
union	Definisce un tipo semplice come una raccolta (unione) di valori da tipi di dati semplici specificati
unique	Definisce che un elemento o un valore di attributo deve essere univoco

Restrizioni e aspetti del tipi di dati

Ecco un elenco di tutti i tipi di restrizioni che possono essere incluse nello schema. ^[3]

Restrizione	Descrizione
enumeration	Definisce un elenco di valori accettabili
fractionDigits	Specifica il numero massimo di posizioni decimali consentite. Deve essere uguale o maggiore di zero
length	Specifica il numero esatto di caratteri o voci di elenco consentite. Deve essere uguale o maggiore di zero
maxExclusive	Specifica i limiti superiori per i valori numerici (il valore deve essere inferiore a questo valore)
maxInclusive	Specifica i limiti superiori per i valori numerici (il valore deve essere minore o uguale a questo valore)
maxLength	Specifica il numero massimo di caratteri o voci di elenco consentite. Deve essere uguale o maggiore di zero
minExclusive	Specifica i limiti inferiori per i valori numerici (il valore deve essere maggiore di questo valore)
minInclusive	Specifica i limiti inferiori per i valori numerici (il valore deve essere maggiore o uguale a questo valore)
minLength	Specifica il numero minimo di caratteri o voci di elenco consentite. Deve essere uguale o maggiore di zero
pattern	Definisce l'esatta sequenza di caratteri che sono accettabili
totalDigits	Specifica il numero esatto di cifre consentite. Deve essere maggiore di zero
whiteSpace	Specifica in che modo lo spazio bianco (avanzamento riga, tabulazioni, spazi, ritorni a capo) è elicoidale

Regex

Speciali espressioni regolari (regex) possono essere usate per costruire un modello. Il linguaggio regex in XML Schema si basa sul linguaggio per le espressioni regolari di Perl. Di seguito sono riportate alcune notazioni comuni:

. (the period	per qualsiasi carattere
\d	per qualsiasi cifra
\D	per qualsiasi carattere che non sia una cifra
\w	per qualsiasi carattere di parola (alfanumerico)
\W	per qualsiasi carattere non di parola (cioè -, +, =)
\s	per qualsiasi spazio bianco (incluso space, tab, newline e return)
\S	per ogni carattere che non è uno spazio bianco
x*	deve avere zero o più x
(xy)*	deve avere zero o più xy
x+	ripetizione della x, almeno una volta
x?	deve avere una o nessuna x
(xy)?	deve avere una o nessuna xy
[abc]	deve includere uno da un gruppo di valori
[0-9]	deve includere l'intervallo di valori da 0 a 9
x{5}	avere esattamente 5 x (di fila)
x{5,}	avere almeno 5 x (di fila)
x{5,8}	almeno 5 ma al massimo 8 x (di fila)
(xyz){2}	avere esattamente 2 xyz (di fila)

Ad esempio, lo schema per la convalida di un numero di previdenza sociale è \d{3}-\d{2}-\d{4} Il codice dello schema per emailAddressType è \w+\W\w@{1}\w+\W\w+.\w+.\w*
[w+]	almeno un carattere word (alfanumerico),	per esempio answer
[W*]	seguito da nessuno, uno o più caratteri non di parola,	per esempio -
[w*@{1}]	seguito da qualsiasi (o nessuna) parola carattere e uno at-sign,	per esempio my@
[w+]	seguito da almeno un carattere di parola,	per esempio mail
[W*]	seguito da nessuno, uno o più caratteri non di parola,	per esempio _
[w+.]	seguito da almeno un carattere di parola e periodo,	per esempio please.
[w+.*]	da zero a infinite volte seguito dalla stringa precedente,	per esempio opentourism.
[w*]	alla fine seguito da nessuno, uno o più caratteri di parola	per esempio org
email-address: answer-my@mail_please.opentourism.org

Attributi del documento di istanza

Questi attributi non richiedono di essere dichiarati nello schema.

Attributo	Descrizione	Esempio
xsi:nil	Indica che un determinato elemento non ha un valore o che il valore è sconosciuto. L'elemento deve essere impostato su nillable all'interno del documento dello schema: <xsd:element name=”last_name” type=”xsd:string” nillable=true”/>	<full_name xmlns:xsi= ”http://www.w3.org/2001/XMLSchema-instance”> <first_name>Madonna</first_name> <last_name xsi:nil=”true”/> </full_name>
xsi:noNamespaceSchemaLocation	Individua lo schema per gli elementi che non si trovano in alcun namespace	<radio xsi:noNamespaceSchemaLocation= ”http://www.opentourism.org/xmtext/radio.xsd”> <!—radio stuff goes here -- > </radio>
xsi:schemaLocation	Individua gli schemi per gli elementi e gli attributi che si trovano in un namespace specificato	<radio xmlns= ”http://www.opentourism.org/xmtext/NS/radio xmlns:xsi= ”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation= ”http://www.arches.uga.eduNS/radio” ”http://www.opentourism.org/xmtext/radio.xsd”> <!—radio stuff goes here -- > </radio>
xsi:type	Può essere utilizzato nei documenti di istanza per indicare il tipo di un elemento.	<height xsi:type=”xsd:decimal”>78.9</height>

Per ulteriori informazioni sulle strutture, i tipi di dati e gli strumenti di XML Schema si può visitare il sito http://www.w3.org/XML/Schema

Note

[1] ttp://www.relaxng.org/

[2] ttp://www.w3schools.com/schema/schema_elements_ref.asp

[3] ttp://www.w3schools.com/schema/schema_elements_ref.asp

[1]

[2]

[3]