XML: Eticheta xsd:import

Eticheta <xsd:import> este utilizată pentru a importa un document de schemă și spațiul de nume asociat cu tipurile de date definite în documentul de schemă. Acest lucru permite unui document de schemă XML să facă referire la o bibliotecă de tipuri folosind nume de spații de nume (prefixe). Să aruncăm o privire mai atentă la un document de instanță XML simplu pentru un magazin care utilizează aceste nume multiple de spații de nume:

<?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">
  <!-- Observați declarațiile de spațiu de nume definite în mod explicit, depozitul de prefixe
	reprezintă tipuri de date definite în spațiul de nume
     <code>http://www.opentourism.org/xmltext/Store.xml</code> și 
     prefixul MGR reprezintă tipuri de date definite în spațiul de nume
     <code>http://www.opentourism.org/xmltext/CoreSchema</code>. 
     De asemenea, observați că nu există o declarație implicită de spațiu de nume - fiecare element
	și atributul trebuie să fie asociat cu un spațiu de nume (vom vedea că aceasta este
	necesar dacă examinăm documentul 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>
    <!-- More store information would go here. -->
  </store:Store>
  <!-- More stores would go here. -->
</store:SimpleStore>

Figura 7 Document de instanță XML

Să ne uităm la documentul de schemă și să vedem cum a fost folosită eticheta <xsd:import> pentru a importa tipuri de date dintr-o bibliotecă de tipuri (document de schemă extern).

<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">
  <!-- Prefixul MGR este legat de următorul nume de spațiu de nume:
	<code>http://www.opentourism.org/xmltext/CoreSchema</code>
	Documentul de schemă managerTypeLib.xsd este importat prin asocierea
	schemei cu <code>http://www.opentourism.org/xmltext/CoreSchema</code>
	numele spațiului de nume, care a fost legat de prefixul MGR.
	Atributul elementFormDefault are valoarea „calificat” care indică faptul că
	un document de instanță XML trebuie să utilizeze nume calificate pentru fiecare element (implicit
	spațiul de nume nu poate fi folosit)  
-->
  <!-- Spațiul de nume țintă și spațiul de nume implicit sunt aceleași  -->
  <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>

Figura 8: Schema XML

La fel ca eticheta include și eticheta redefine, eticheta import este un alt mijloc de încorporare a oricăror tipuri de date dintr-un document de schemă extern într-un alt document de schemă și trebuie să apară înainte de orice declarație de element sau atribut. Aceste mecanisme sunt importante atunci când schemele XML sunt modulare și bibliotecile de tipuri sunt menținute și utilizate în mai multe documente de schemă.

Când întregul este mai mare decât suma părților sale: Modularizarea schemei

Acum că am acoperit toate cele trei metode de încorporare a schemelor XML externe, să luăm în considerare importanța acestor mecanisme. Așa cum este tipic pentru majoritatea codului de programare, redundanța este descurajată; acest lucru este valabil și pentru definițiile personalizate ale tipurilor de date. Dacă există deja un tip de date personalizat care poate fi aplicat unui element din documentul dvs. de schemă, nu are sens să utilizați acest tip de date în loc să îl creați din nou în noul document de schemă? Mai mult, dacă știți că un singur tip de date poate fi reutilizat pentru mai multe aplicații, nu ar trebui să aveți o metodă de referință la acel tip de date atunci când aveți nevoie de el?

Ideea din spatele schemelor modulare este să examinați ceea ce face schema dvs., să determinați ce tipuri de date sunt utilizate frecvent într-o formă sau alta și să dezvoltați o bibliotecă de tipuri. Pe măsură ce nevoile dvs. de scheme mai complexe cresc, puteți continua să adăugați la bibliotecă, să reutilizați tipuri de date din biblioteca de tipuri și să redefiniți acele tipuri de date după cum este necesar. Un exemplu de reutilizare ar fi o schemă pentru informații despre clienți – diferite departamente ar folosi scheme diferite, deoarece ar avea nevoie doar de informații parțiale ale clienților. Cu toate acestea, majoritatea, dacă nu toate, departamentele ar avea nevoie de unele informații specifice despre clienți, cum ar fi numele și informațiile de contact, care ar putea fi încorporate în documentele individuale ale schemei departamentale.

Modularizarea schemei este o „cea mai bună practică”. Prin menținerea unei biblioteci de tipuri și reutilizarea și redefinirea tipurilor din biblioteca de tipuri, vă puteți asigura că documentele cu schema XML nu devin copleșitoare și dificil de citit. Lizibilitatea este importantă, deoarece este posibil să nu fiți singurul care folosește aceste scheme și este important ca alții să vă înțeleagă cu ușurință documentele schemei.

„Alege, dar alege cu înțelepciune…”: Alternative de schemă

Până acum am discutat doar schemele XML așa cum sunt definite de World Wide Web Consortium (W3C). Cu toate acestea, există și alte metode de definire a datelor conținute într-un document cu instanță XML, dar vom menționa doar cele două alternative cele mai populare și cunoscute: Document Type Definition (DTD) și Relax NG Schema.

Vom acoperi DTD-urile în capitolul următor. Schema Relax NG este o schemă mai nouă și are multe dintre aceleași caracteristici pe care le are schema W3C XML; Relax NG pretinde, de asemenea, că este mai simplu și mai ușor de învățat, dar acest lucru este foarte subiectiv.

(Include texte din Wikibooks traduse și adaptate de Nicolae Sfetcu)