In den vergangenen beiden Tagen haben Sie DTDs und XDR-Schemata erzeugt, um XML-Dokument-Instanzen zu validieren. Sie haben Deklarationen für Elementbeschränkungen und Attributs-Definitionen geschrieben, um Anwendungsregeln durchzusetzen. Sie haben die Unterschiede zwischen DTDs und Schemata kennen gelernt, die in der XML-Syntax gründen. Heute lernen Sie Folgendes kennen:
Gestern haben Sie gesehen, inwiefern XML-Data Reduced (XDR)-Schemata den Document Type Definitions (DTDs) überlegen sind. Sie haben auch eine Reihe anderer Schemasprachen kennen gelernt. Der XDR-Ansatz ist wichtig, weil er von seinem Hersteller Microsoft in zahlreiche E-Commerce-Lösungen implementiert wurde - etwa in BizTalk und die verwandten Initiativen. XDR erfordert jedoch die Verwendung der Tools von Microsofts MSXML, was hinsichtlich der Implementierung bei einigen Plattformen oder der Integration mit verschiedenen älteren Datenmodellen Probleme bereiten kann.
DTDs werden natürlich breit unterstützt und sind vielfach implementiert. Das Problem bei DTDs ist hauptsächlich, dass sie sich nicht in der XML-Syntax ausdrücken, womit Entwickler gezwungen sind, eine neue Sprache zu erlernen und Tools zu verwenden, die nicht auf XML-Grundlage stehen usw. Dazu kommt, dass DTDs kein Mittel für eine umfassende Datentyp-Validierung sind.
Das W3C hat eine Empfehlung für die XML Schema Definition Language (XSD) herausgebracht, die die meisten der beliebten Schemasprachen zu einem einzigen Industriestandard verschmilzt. Die Absicht ist, einen Standard hervorzubringen, der so breit implementiert ist, dass man ihn als wahrhaft plattformunabhängig betrachten kann. Ob das der Fall ist, wird die Zukunft zeigen.
Nachdem die Spezifikationen des W3C zu den Schemasprachen nun vollständig vorliegen, kann man erwarten, dass die Gemeinde der Softwarehersteller die XML Schema Definition (XSD) Language in zunehmendem Maße in ihre Produkte implementiert, die derzeit für die Validierung anderer Dialekte optimiert werden. Microsoft hat zum Beispiel beschlossen, XSD sowohl in seinem Browser als auch bei den Tools für den MSXML zu unterstützen. Zum Zeitpunkt der Drucklegung dieses Buches unterstützen beide, die aktuelle Version des Toolsets für den MSXML-Parser (Version 4) und Microsofts XML 4.0- Parser-SDK XSD. IBM, SUN und Apache gehören zu den wichtigsten Herstellern, die Parser herausgebracht haben, die XSD unterstützen. Andere werden folgen. Dennoch ist abzusehen, dass DTDs und XDR-Schemata eine Zeit lang auf dem Markt bleiben werden, bis die Übergangsphase bei der Unterstützung durch Softwareprodukte abgeschlossen ist.
Die XML Schema Definition Language, auch einfach XML Schema Language genannt, ähnelt der Sprache XDR, die Sie bereits kennen, in vielfacher Hinsicht. Ein XSD-Schema soll die folgenden Dinge leisten:
Die heutige Lektion stellt einen nützlichen Ausschnitt wichtiger Konzepte vor, die dabei helfen, die Sprache XSD zu charakterisieren. Ziel wird sein, Ihnen Informationen für den Vergleich zu liefern, sodass Sie XSD im Verhältnis zu anderen Ansätzen einschätzen können. Viele Beobachter sagen voraus, dass XSD an Popularität gewinnen wird, nachdem es nun in seiner endgültigen Form als Standard oder W3C-Empfehlung vorliegt. Verschiedene Schritte sind für den Weg zum Standard beim W3C typisch. Zu den anderen Schritten in diesem Prozess des W3C finden Sie im nächsten Abschnitt mehr.
Der Gegenstand der heutigen Lektion wird sich wahrscheinlich nach Veröffentlichung dieses Buches weiterhin verändern. Die neuesten Aktualisierungen zur XSD-Spezifikation können Sie unter http://www.w3.org/XML/Schema nachlesen.
Einige der Technologien, die dieses Buch vorstellt, sind zumindest zum Zeitpunkt der Drucklegung noch keine formalen Standards. XSD wurde am 2. Mai 2001 zur W3C- Empfehlung erhoben. Das W3C (http://www.w3.org) ist die Körperschaft, die für die Erstellung, Veröffentlichung und Wartung der Standards von Webtechnologien und verwandten Anstrengungen verantwortlich ist. Eine Normierung durch das W3C erfordert, dass alle Schritte in einem umfassenden Prüfungsprozess erfüllt wurden. Diesen Prozess nennt das W3C den »Recommendation Track« (Weg zur Empfehlung) und er stellt einen systematischen Ansatz dar, einen Konsens bei Initiativen für Webtechnologien zu finden.
Das W3C bezeichnet einen »Standard« als »Empfehlung«. Diese Ebene der Ausgereiftheit erreicht eine Technologie erst, nachdem sie mehrere unterschiedliche Phasen durchlaufen hat. Die nächsten Abschnitte zitieren aus Unterlagen, die auf der Website des W3C unter http://www.w3.org/Consortium/Process-20010208/tr abgerufen werden können.
Ein technischer Bericht beginnt seinen Weg zur Empfehlung als Arbeitsentwurf. Ein Arbeitsentwurf ist ein geprüfter Arbeitsgegenstand in einer Arbeitsgruppe und steht in der Regel für eine Arbeit, die noch im Gange ist, und für ein Gebiet, dem sich das W3C weiterhin widmen will. Die Bezeichnung »Arbeitsentwurf« heißt nicht, dass im W3C ein Konsens über die technische Eingabe besteht.
Arbeitsentwurf im letzten Stadium
Ein Arbeitsentwurf im letzten Stadium ist eine besondere Form des Arbeitsentwurfs, von dem die Arbeitsgruppe denkt, dass er die wichtigsten Erfordernisse ihrer Prüfkriterien und aller begleitenden Dokumente zu den Anforderungen erfüllt. Ein Arbeitsentwurf im letzten Stadium ist eine veröffentlichte technische Eingabe, zu der die Arbeitsgruppe eine Kritik zu den einzelnen Punkten durch andere Gruppen im W3C, durch W3C-Mitglieder und die Öffentlichkeit sucht.
Eine Kandidatur zur Empfehlung erfüllt nach Ansicht der Arbeitsgruppe bereits die relevanten Anforderungen ihrer Prüfkriterien und aller begleitenden Dokumente. Sie wurde veröffentlicht, um Erfahrungen mit der Implementierung zu sammeln und ein Feedback zu erhalten. Erhält eine Eingabe diesen Status, bedeutet das einen expliziten Aufruf an alle, die außerhalb der Arbeitsgruppen oder des W3C selbst arbeiten, Erfahrungen mit der Implementierung zu sammeln.
Eine vorgeschlagene Empfehlung soll den Anforderungen durch die Prüfkriterien beim W3C und begleitender Dokumente schon entsprechen, es gibt bereits ausreichende Erfahrung bei der Implementierung und sie genügt den Bedürfnissen der technischen Gemeinde rund um das W3C und früher Kritiker. Eine vorgeschlagene Empfehlung ist ein technischer Bericht, den der Direktor zur Begutachtung an das Beratungsgremium geschickt hat.
Eine W3C-Empfehlung ist ein technischer Bericht, der das Endresultat einer intensiven Konsens-Suche in- und außerhalb des W3C über eine bestimmte Technologie oder Vorgehensweise darstellt. Das W3C betrachtet die Vorstellungen und die Technik, die in einer Empfehlung spezifiziert werden, als angemessen für eine weite Verbreitung und zur Förderung seiner Mission.
Sie haben am 4. und 5. Tag gelernt, dass Schemata unabhängig von ihrem Vokabular oder der Syntax, in der sie sich ausdrücken, explizit dafür geschrieben werden, Bedienungsregeln durchzusetzen, indem Beschränkungen für XML-Dokumente angefügt werden. Schemasprachen auf der Grundlage der XML-Syntax haben einen Vorteil gegenüber DTDs, weil sie einen Satz an Auszeichnungs-Tags umfassen, der ausgewertet werden kann, um unter Verwendung eines Standard-Parsers sicherzustellen, dass ein Dokument wohlgeformt ist.
XML-Schemata (XSD) unterteilen die Tags, die in Ihrem Dokument verwendet werden, in zwei Gruppen: komplexe Typen und einfache Typen. Komplexe Elementtypen dürfen andere Elemente enthalten und haben Attribute; einfache Typen können dies nicht. Hier ist ein Beispiel für einfache Elemente:
<nachricht>Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen
</nachricht>
<zustellung>email</zustellung>
Der folgende Ausschnitt fasst Elemente zusammen, die als komplex gelten, weil sie über Elementinhalt oder Attribute verfügen:
<nachricht anzahl="10" datum="2001-07-29" von="Kathy Shepherd">
Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen
<empfangsbericht>
<vollständig/>
</empfangsbericht>
</nachricht>
Das nachricht-Element, ein komplexer Elementtyp, wird durch die Attribute anzahl, datum und von modifiziert. Das nachricht-Element enthält Elemente und Daten sowie gemischten Inhalt.
Heute werden Sie lernen, wie man einfache und komplexe Elementtypen programmiert.
Am 4. und 5. Tag (über DTDs und XDR) haben Sie gelernt, dass die Anwendung von Schemaregeln auf Elemente und Attribute zwei unterschiedliche Schritte umfasst. Dies gilt auch für XSD. Die beiden Schritte sind die Definition und die Deklaration der Typen - sowohl bei Elementtypen als auch bei Attributstypen.
Sie werden das Konzept der Namensräume am achten Tag in seiner Tiefe erforschen. Für den Moment müssen Sie einen Standard-Namensraum für all Ihre XSD-Instanzen programmieren, wie Sie es auch im Fall der XDR-Schemata getan haben. Dieser Namensraum wird die Ansammlung der Elemente und Attribute identifizieren, die das XSD-Vokabular ausmachen.
Das Wurzelelement in einem XML-Schema ist das Element Schema, das alle anderen Elemente im Schema-Dokument enthält. Für das Wurzelelement eines XSD-Schemas erzeugen Sie mithilfe des Attributs xmlns einen Namensraum. Das xmlns-Attribut liefert das Präfix, das an die Namen der Elementtypen für das Schema in der XSD-Instanz angefügt wird. Die gegenwärtige Schema-Definition finden Sie unter http://www.w3c.org/1999/ XMLSchema. Der folgende Schema-Tag folgt zum Beispiel der Konvention, xsd als Präfix einzusetzen und es dann zu verwenden, um der benannten Sammlung Elemente hinzuzufügen:
<xsd:schema xmlns:xsd=http://www.w3c.org/1999/XMLSchema>
Per Konvention wird im XSD-Dokument das Präfix xsd (XML Schema Definition) als Proxy zum Namensraum für das XML-Schema verwendet.
Im Dokument der XML-Instanz, die mit Ihrem Schema validiert werden soll, müssen Sie auch eine Namensraum-Deklaration einschließen. Der Namensraum wird immer mit einem xmlns-Attribut in folgendem Format im Wurzelelement der XML-Dokument- Instanz platziert:
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
Dieser Namensraum enthält die Elemente und Attribute des XML-Schemas, die man in eine XML-Dokument-Instanz einfügen kann. Das Präfix xsi wird per Konvention als Proxy zu diesem Namensraum verwendet und auch allen Elementen und Attributen, die zu dem Namensraum gehören, als Affix vorangestellt, das durch einen Doppelpunkt abgetrennt wird.
Per Konvention wird in der XML-Dokument-Instanz das Präfix xsi (XML Schema Instance) als Proxy zum Namensraum des XML-Schemas verwendet.
Die beiden Attribute, die zum Namensraum des XML-Schemas gehören und in der Regel verwendet werden, um die XML-Dokument-Instanz ihrem Schema zuzuordnen, sind xsi:schemaLocation und xsi:noNamespaceSchemaLocation. Diese Attribute erlauben Ihnen, ein Dokument an sein W3C-XML-Schema anzubinden. Dieser Link ist nicht obligatorisch und durch Mechanismen einer jeweiligen Anwendung können andere Anzeigen angegeben werden - wie etwa ein Parameter in der Befehlszeile. Aber es hilft den Tools, die das XML-Schema des W3C unterstützen - Parsern zum Beispiel - ein Schema zu lokalisieren.
Für den Fall, dass das XSD-Dokument ohne Namensraum verknüpft wird - normalerweise bei einer voll qualifizierten Uniform Resource Location (URL) oder einer lokalen Datei - wird das Attribut noNamespaceSchemaLocation verwendet und sieht folgendermaßen aus:
xsi:noNamespaceSchemaLocation="datei_name.xsd">
Ein Namensraum kann jedoch auch zusammen mit einem Dateinamen deklariert werden. In diesem Fall wird die URI für den Namensraum von der URI für das Schema als Teil des gleichen Attributswerts durch ein Leerzeichen getrennt, was dann so aussieht:
xsi:schemaLocation="http://example.org/ns/books/ datei_name.xsd"
Es ist in der vorangehenden Zeile vielleicht schwer zu erkennen, aber ein einzelnes Leerzeichen liegt zwischen dem Namensraum (xsi:schemaLocation="http:// example.org/ns/books/) und dem Namen des Schema-Dokuments (datei_name.xsd).
Bei XSD gibt es das Konzept des benannten Typus, anders als bei den anderen beiden Validiersprachen, die Sie untersucht haben. Wenn Sie zum Beispiel eine Definition für simpleType erstellen, die Elemente beschreibt, die als einfache Elemente gelten, können Sie diese Definition auch benennen, sodass sie an anderer Stelle in der XSD-Instanz wiederverwendet werden kann. Erinnern Sie sich an das Beispiel mit dem XML- Ausschnitt, das zwei einfache Elemente einschloss:
<nachricht>Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen</nachricht>
<zustellung>email</zustellung>
Sie könnten ein simpleType erstellen und es beliebig benennen, nchr zum Beispiel. Das kann man auch als benannte Beschränkung bezeichnen. Die Kodierung für diesen einfachen Typ kann Beschränkungen liefern, die alle anderen einfachen Elemente im Schema mitbenutzen können. Beim letzten Beispiel etwa kann man den Elementen nachricht und zustellung ein simpleType-Element zuordnen, um den Inhalt dieser Elemente als String zu deklarieren. Das könnte dann so aussehen:
1: <xsd:simpleType name="nchr" base="xsd:string"/>
2: <xsd:element name="nachricht" type="nchr"/>
3: <xsd:element name="zustellung" type="nchr"/>
Als Erstes wird Ihnen auffallen, dass allen XSD-Elementen das Präfix xsd: vorangeht, das einen Proxy zu dem XSD-Namensraum liefert, der im Wurzelelement der XSD-Schema- Instanz deklariert wurde. In Zeile 1 wird durch das Element xsd:simpleType das Element als dem einfachen Typ zugehörig definiert und es bekommt durch das name-Attribut den Referenznamen nchr. Beim base-Attribut für das Element handelt es sich um eine Datentypbeschränkung, die den gültigen nchr-Inhalt auf Stringdaten begrenzt. In den Zeilen 2 und 3 werden jeweils die Elemente nachricht und zustellung definiert. simpleType nchr definiert die Beschränkungen, die für diese Elemente erzwungen werden.
Wenn Sie eine benannte Beschränkung erstellen, bestimmen Sie den Namen - in Ihrer XML-Dokument-Instanz existiert er nicht. Der Name bietet eine referenzielle Zuordnung oder einen Link auf die Definition einer XSD-Beschränkung an anderer Stelle.
In der Praxis ziehen es viele Dokumentautoren vor, ihre einfachen Typen vollständig zu qualifizieren, indem sie die passenden Attribute in das xsd:element-Element einfügen, nicht in ein getrenntes simpleType-Element. Das trifft vor allem dann zu, wenn für die Elemente, die definiert werden, nur ein oder zwei Attribute zur vollständigen Qualifikation ihrer Beschränkungen nötig sind. Es ist gleichgültig, ob Sie das xsd:simpleType-Element verwenden oder es lieber ausschließen und dem xsd:element-Element die erforderlichen Attribute anfügen: beide Herangehensweisen sind zulässig. Wenn Sie letzteren Ansatz wählen, sieht das vorherige Beispiel so aus:
1: <xsd:element name="nachricht" type="xsd:string"/>
2: <xsd:element name="zustellung" type="xsd:string"/>
In diesem Beispiel enthalten die type-Attribute nicht mehr den Namen, der einem xsd:simpleType-Element zugeordnet ist, sondern eine voll qualifizierte Datentyp- Deklaration. Beachten Sie, dass der Wert für diese Deklaration das Präfix xsd: einschließt, dessen Interpretation besagt, dass die String-Definition zum xsd-Namensraum gehört. Auf diese Weise kann eine Datentyp-Deklaration für string keinesfalls mit einer Referenz auf ein simpleType-Element mit Namen string verwechselt werden. Namensräume sind wichtig, weil sie dieser Art von Verwirrung, den Namenskonflikten, vorbeugen.
Listing 6.1 zeigt eine Variante des Dokuments nachricht.xml, das Sie bereits erstellt haben und das so modifiziert wurde, dass es die Namensraum-Deklarationen einschließt, die für XSD-Schemata erforderlich sind.
Listing 6.1: Eine XML-Instanz, die den Namensraum für ein XML-Schema und den Standort des Schema-Dokuments angibt - nachricht01_6.xml
1: <?xml version="1.0"?>
2: <notiz
3: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
4: xsi:noNamespaceSchemaLocation="nachricht01_6.xsd">
5: Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen
6: </notiz>
Das Start-Tag für das notiz-Element liegt in den Zeilen 2-4. Zeile 3 schließt den Namensraum für die Referenz auf die XML-Schema-Instanz ein. Zeile 4 liefert eine Zuordnung zu der XSD-Datei, mit der die Instanz validiert wird.
Wie gesagt, fangen alle Elemente in einem XSD-Schema mit dem Präfix xsd: an. Dieses Präfix dient durch die Deklaration xmlns:xsd=http://www.w3.org/2000/10/XML-Schema als Proxy zu dem XSD-Namensraum. Dieser Namensraum sollte im Start-Tag für das Wurzelelement (xsd:schema) des XSD-Schema-Dokuments auftreten. Wie bei allen Namensraum-Proxies ist der Zweck des Präfixes (oder Proxies), die Elemente zu identifizieren, die zum Vokabular der XML Schema Definition-Sprache gehören, nicht das Vokabular des Schema-Autors. Mehr zu den Namensräumen erfahren Sie am 8. Tag. In der Zwischenzeit genügt es festzuhalten, dass der Prozessor den Standort nicht auflöst, auch wenn dieser Namensraum etwas enthält, das wie die Adresse einer Website aussieht.
Nachdem Sie mit einem Texteditor nachricht01_6.xml erstellt haben, erzeugen Sie nun eine XSD-Datei dafür und speichern sie unter nachricht01_6.xsd. Listing 6.2 zeigt ein beispielhaftes Schema.
Listing 6.2: Ein einfaches XSD-Schema für die Nachricht-Instanz - nachricht01_6.xsd
1: <?xml version="1.0"?>
2: <xsd:schema
3: xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
4: <xsd:element name="notiz" type="xsd:string"/>
5: </xsd:schema>
Zeile 3 ist die Namensraum-Deklaration, die sich als xmlns-Attribut für das Wurzelelement xsd:schema zeigt. Zeile 4 deklariert und definiert das Element notiz als Datentyp string, der seinen Ursprung im xsd:-Namensraum hat.
Die Sprache XSD kennt eine Reihe einfacher Datentypen, die in sie eingebaut sind, genau wie dies bei XDR der Fall ist. Zusätzlich zu diesen eingebauten Datentypen wie string und decimal schließt XSD eine Funktionalität zur Entwicklung von Typen ein, die von den eingebauten Typen abgeleitet werden. Ein Attribut zur Bestandskontrolle zum Beispiel kann ein anwenderdefinierter Bestandstyp sein, der sich von einem numerischen String ableitet. Der Schema-Autor kann abgeleitete Typen erzeugen und sie im gesamten XSD-Dokument verwenden. Eine vollständige Liste der einfachen Datentypen, die bei XSD eingebaut sind, finden Sie unter http://www.w3.org/TR/xmlschema-0/. Tabelle 6.1 fasst einige der gebräuchlichen eingebauten Typen zusammen.
http://www.beispiel.com/, http://www.beispiel.com/doc.html#ID5 |
Tabelle 6.1: Einfache Datentypen beim XML-Schema
Die Konstrukte einfacher und komplexer Elementtypen sind Designmerkmale, für die die XSD-Sprache einmalig ist. Wie bereits erwähnt wurde, werden komplexe Elementtypen in XSD als diejenigen definiert, die andere Elemente in ihrem Inhalt zulassen und auch Attribute aufnehmen können.
Im nächsten Beispiel sehen Sie den komplexen Elementtyp in der Nachrichtendokument- Instanz, die Sie in den vergangenen Tagen wieder und wieder manipuliert haben. Listing 6.3 zeigt die modifizierte Nachrichten-Instanz, in der das Element notiz ein Element nachricht enthält. Nachdem ein Element einen Elementinhalt hat, ist für das validierende XSD-Schema der komplexe Elementtyp erforderlich. Sie erinnern sich, dass simpleType für Elemente reserviert ist, die nur Werte enthalten, aber keine Elemente oder Attribute.
Listing 6.3: Ein XML-Dokument mit einem Element, das Elementinhalt hat - nachricht02_6.xml
1: <?xml version="1.0"?>
2: <notiz
3: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
4: xsi:noNamespaceSchemaLocation="nachricht02_6.xsd">
5: <nachricht>Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen</nachricht>
6: </notiz>
In dieser XML-Instanz wird das Wurzelelement notiz (Zeilen 2-6) als komplexer Elementtyp betrachtet, weil es in Zeile 5 ein abgeleitetes nachricht-Element hat. Das Wurzelelement schließt in Zeile 3 das xmlns für die Schema-Instanz (http://www.w3.org/2000/10/XMLSchema-instance) mit dem angefügten Präfix xsi: ein. Das Attribut für das notiz-Element in Zeile 4, xsi:noNamespaceSchemaLocation, hat den Wert "nachricht02.xsd", der der Instanz die XSD-Datei zuordnet.
Auf der Grundlage des XSD-Konzepts für ein komplexes Element muss das Schema, das Sie für diese Dokument-Instanz erzeugen, die Beziehung zwischen notiz und nachricht herstellen, vor allem, dass das nachricht-Element eine Ableitung des Elements notiz ist. Die kürzeste Form für dieses Konstrukt sieht so aus:
Listing 6.4: Ein XSD-Ausschnitt mit einem komplexen Elementtyp
1: <xsd:element name="stamm_element_name">
2: <xsd:complexType>
3: <xsd:element name="ableitung_element_name" type="simple_type_ref"/>
4: </xsd:complexType>
5: </xsd:element>
Zeile 1 beginnt mit der Deklaration für das Stammelement bei einem komplexen Typ. Das complexType-Element zieht sich über die Zeilen 2-4 hin und enthält abgeleitete Elemente. In dem Codeausschnitt, der als Beispiel dient, ist nur ein abgeleitetes Element in Zeile 3 eingeschlossen. Der Name des abgeleiteten Elements in der XML-Dokument-Instanz wird als Wert des name-Attributs im xsd:element-Element angegeben. Das type-Attribut in diesem Beispiel verweist auf die Deklaration des abgeleiteten Elements als einfacher Typ. Wenn es sich bei der Ableitung um einen komplexen Elementtyp handelt, verweist das type-Attribut auf das benannte complexType an anderer Stelle im XSD-Schema.
Listing 6.5 ist ein XSD-Schema für die Nachrichtendokument-Instanz. In diesem Beispiel wurden jedoch im Vergleich zum vorherigen Beispiel für die Kurzform einige zusätzliche Merkmale eingefügt. Es wurde zum Beispiel das Element xsd:sequence eingefügt. Mit diesem Element können Sie die Reihenfolge der abgeleiteten Elemente im Elementsatz festlegen. Das hier gezeigte Beispiel enthält nur ein abgeleitetes Element, xsd:element, das das nachricht-Element im Dokument der XML-Instanz deklariert. Wenn aber notiz mehrere Ableitungen hat, können Sie die Anordnung der abgeleiteten Elemente im Dokument der XML-Instanz steuern, indem Sie diese Ableitungen mit xsd:sequenze einfassen.
Listing 6.5: Ein XSD-Schema mit einem xsd:ComplexType-Element - nachricht02_6.xsd
1: <?xml version="1.0"?>
2: <xsd:schema
3: xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
4: <xsd:element name="nachricht" type="xsd:string"/>
5: <xsd:element name="notiz">
6: <xsd:complexType>
7: <xsd:sequence>
8: <xsd:element ref="nachricht"/>
9: </xsd:sequence>
10: </xsd:complexType>
11: </xsd:element>
12: </xsd:schema>
In den Zeilen 6-10 wird das Element als komplexer Typ definiert. Zeile 7 deklariert eine Sequenz, auch wenn in diesem Beispiel eigentlich nur ein abgeleitetes Element, nachricht, vorkommt. Wird mehr als eine Ableitung in ein Stammelement eingeschlossen, kann man das sequence-Element verwenden, um die zulässigen Anordnungsbedingungen festzulegen, die für die Ableitungen gelten - wenn man überhaupt eine festlegen will. Anders gesagt, ein sequence-Element gibt an, dass die abgeleiteten Elemente im Dokument der Instanz in der Reihenfolge auftreten müssen, in der sie im XSD-Dokument deklariert werden. Zeile 8 verwendet das ref-Attribut, um einen Verweis auf die Definition des nachricht-Elements als einfachen Typ bereitzustellen, die in Zeile 4 vorgenommen wurde. Das ref-Attribut funktioniert analog zum type-Attribut der früheren Beispiele und gestattet dem Autor des Schemas, Elemente ein einziges Mal zu definieren, auch wenn sie in mehreren Deklarationen wiederverwendet werden.
Anders als andere Schemasprachen gestattet Ihnen XSD, die Kardinalität (also die Häufigkeit des möglichen Auftretens) von Elementen mit ziemlicher Genauigkeit zu bestimmen. Sie können einen Minimalwert für die Auftrittsfrequenz eines Elements mit dem Attribut minOccurs im xsd:element-Element festlegen, ebenso einen Maximalwert mit dem Attribut maxOccurs. Die Verwendung dieser Attribute erinnert an den Ansatz mit dem XDR-Schema, den Sie gestern unter die Lupe genommen haben, aber die Gemeinsamkeiten enden hier bereits. Bei XSD gibt es weniger Einschränkungen hinsichtlich der akzeptablen Werte, die für die Verwendung dieser Attribute bereitstehen. Das W3C hat für XSD eine Methode zur Verfügung gestellt, mit der ein festgelegter Bereich für das Auftreten eingegeben werden kann, wenn das wünschenswert erscheint. Dies ist eines der Merkmale, mit denen sich XSD von XDR, DTDs oder anderen Sprachen für die Schema-Definition unterscheidet.
Die Attribute minOccurs und maxOccurs haben den Standardwert »1«, wenn sie nicht anders deklariert werden. Das maxOccurs-Attribut kann auch auf unbegrenzt gesetzt werden, was dem * bei XDR und bei einer DTD entspricht.
Betrachten Sie sich die XML-Instanz in Listing 6.6. Dieses Dokument enthält mehrere eingebettete abgeleitete Elemente. Das Wurzelelement notiz enthält zwei notizen, von denen jede ein leeres anzahl-Element enthält, dem eine Reihe von nachricht-Elementen folgen.
Listing 6.6: Die XML-Nachrichten-Instanz mit komplexer Einbettung - nachricht04_6.xml
1: <?xml version="1.0"?>
2: <notiz
3: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
4: xsi:noNamespaceSchemaLocation="nachricht04_6.xsd">
5: <notizen>
6: <anzahl/>
7: <nachricht>Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen</nachricht>
8: <nachricht>Am besten Rahmmilch</nachricht>
9: </notizen>
10: <notizen>
11: <anzahl/>
12: <nachricht>Hol die Hemden aus der Reinigung ab</nachricht>
13: <nachricht>Geh zur Bank</nachricht>
14: <nachricht>Maeh das Gras</nachricht>
15: </notizen>
16: </notiz>
Angenommen, Sie wollen für diese Instanz Beschränkungen durchsetzen, etwa:
Um ein XSD-Schema zu erstellen, das diese Beschränkungen durchsetzt, müssen Sie sich um die Kardinalität der Elemente kümmern, um ihre Reihenfolge und darum, ob Elemente obligatorisch oder optional sind. Zur Beschränkung der Kardinalität verwenden Sie die Attribute minOccurs und maxOccurs in den passenden xsd:element-Elementen. Wenn Sie die Attribute minOccurs und maxOccurs sorgfältig setzen, können Sie bei XSD Einschränkungen in Bezug auf die Erforderlichkeit hinzufügen. Wenn Sie etwa das Attribut minOccurs für ein bestimmtes Element auf Null setzen, wird dieses Element als optional betrachtet. Setzen Sie minOccurs für ein bestimmtes Element auf Eins oder schließen es ganz aus, weil Eins der Standard ist, dann gilt dieses Element als erforderlich. (Das heißt mindestens ein Auftreten dieses Elements ist obligatorisch.) Sie wissen bereits, dass ein unendlicher Wert größer Eins für maxOccurs mit dem Wert unbegrenzt programmiert wird.
Listing 6.7 zeigt ein mögliches XSD-Schema, das das Dokument nachricht04_6.xml auf Grundlage der oben erwähnten Beschreibung der Beschränkungen validiert.
Listing 6.7: Die Attribute minOccurs und maxOccurs bei XSD - nachricht04_6.xsd
1 <?xml version="1.0"?>
2 <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
3 <xsd:element name="nachricht" type="xsd:string" />
4 <xsd:element name="anzahl" />
5 <xsd:element name="notiz">
6 <xsd:complexType>
7 <xsd:sequence>
8 <xsd:element name="notiz" minOccurs="0" maxOccurs="2" />
9 </xsd:sequence>
10 </xsd:complexType>
11 </xsd:element>
12 <xsd:complexType name="notizTyp">
13 <xsd:sequence>
14 <xsd:element ref="anzahl" />
15 <xsd:element ref="nachricht" maxOccurs="unbegrenzt" />
16 </xsd:sequence>
17 </xsd:complexType>
18 </xsd:schema>
Zeile 8 definiert die Frequenzbeschränkungen (minOccurs="0" maxOccurs="2") für das abgeleitete Element notizen des Wurzelelements notiz. Eine entsprechende XML-Instanz kann zwischen 0 (minOccurs="0") und 2 abgeleitete Elemente notizen haben (maxOccurs="2"). Da Null eingegeben wurde, handelt es sich bei notizen um eine optionale Ableitung.
Zeile 15 gibt an, dass zumindest ein nachricht-Element dem anzahl-Element in der komplexen Ableitung der Reihenfolge, die in jedem Stammelement notizen enthalten ist, folgen muss. Das Containerelement <xsd:sequence> legt dies fest. Der Wert unbegrenzt zeigt an, dass die Gesamtzahl der zulässigen nachricht-Elemente jedoch unbegrenzt ist.
Zeile 12 deklariert den abgeleiteten komplexen Typ, der als notizTyp bezeichnet wird. Dieser neue komplexe Typ ist kein Elementtyp, sondern eine Zuordnung eines Namens und der Beschränkungen, die das Auftreten des benannten Typs in einer Dokument-Instanz steuern. Anders gesagt, notizTyp existiert im zu Grunde liegenden XML-Dokument gar nicht; dennoch müssen notizen-Elemente im XML-Dokument den Beschränkungen entsprechen, die von der abgeleiteten komplexen Gruppe vorgegeben werden. notizen-Elemente dürfen daher nur ein leeres anzahl-Element enthalten, dem eine beliebige Anzahl von nachricht-Elementen folgt. Diese komplexe Sequenz wird nur aus Gründen der Referenzierbarkeit notizTyp genannt; man kann ihr auch einen beliebigen anderen Namen geben.
Die Deklaration von Attributen verläuft bei XSD ganz ähnlich wie die Element- Deklaration, außer dass sie mit attribut-Deklarationen statt mit element-Deklarationen erfolgt. Wie bereits erwähnt, gehören Attributs-Deklarationen zu den Definitionen der komplexen Typen im Schema. Sie haben bei der Element-Deklaration gesehen, dass die Deklaration keine eigentlichen Typen hervorbringt, sondern Verknüpfungen von Namen und Beschränkungen, die das Auftreten des Namens in gültigen Dokument-Instanzen steuern. Das Gleiche gilt für die Attributs-Deklaration.
Listing 6.8 zeigt beispielsweise ein Dokument der XML-Instanz, das sowohl Elemente als auch Attribute enthält. Genauer gesagt umfasst das nachricht-Element in den Zeilen 5-7 Textinhalt und das Attribut anzahl.
Listing 6.8: Elemente und Attribute - nachricht05_6.xml
1: <?xml version="1.0"?>
2: <notiz
3: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
4: xsi:noNamespaceSchemaLocation="nachricht05.xsd">
5: <nachricht anzahl="10">
6: Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen
7: </nachricht>
8: </notiz>
Das muss bei XSD als komplexer Typ programmiert werden. Ein XSD-Schema, das dieses Dokument validiert, wird in Listing 6.9 gezeigt. Dieses Listing bietet mehrere zusätzliche Merkmale, die bis jetzt noch nicht besprochen wurden und bei der Analyse der Instanz erklärt werden.
Die Datentypisierung ist bei XSD meist ein mehrstufiger Prozess. Man beginnt mit der Beschränkung des typisierten Elements durch eine weit gefasste Kategorie und engt diese dann auf einen spezifischeren Typ ein. Das scheint auf den ersten Blick redundant zu sein, erweist sich aber als sehr nützlich, wenn es um große Schemata mit vielen Typvarianten geht. Der erste, allgemeinere Typ wird durch das Element xsd:restriction mit dem Attribut base eingegeben, das die weit gefasste Kategoriebeschränkung deklariert. Normalerweise ist die breite Grundlage der Wert string. Die Ableitungen der xsd:restriction-Elemente bieten eine spezifischere Detail-Definition für Datentypen. Das kann man in Listing 6.9 erkennen.
Listing 6.9: Ein XSD-Schema mit Attributs-Validierung - nachricht05_6.xsd
1: <?xml version="1.0"?>
2: <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
3: <xsd:complexType name="messageType">
4: <xsd:simpleContent>
5: <xsd:restriction base="xsd:string">
6: <xsd:-Attribute name="anzahl"
type="xsd:integer"
use="required"/>
7: </xsd:restriction>
8: </xsd:simpleContent>
9: </xsd:complexType>
10: <xsd:element name="note">
11: <xsd:complexType>
12: <xsd:sequence>
13: <xsd:element name="nachricht"
type="messageType"/>
14: </xsd:sequence>
15: </xsd:complexType>
16: </xsd:element>
17: </xsd:schema>
In den Zeilen 3-9 wird ein komplexer Typ definiert, genannt messageType, womit sichergestellt wird, dass das Element nachricht ein obligatorisches Attribut, anzahl, vom Datentyp Integer enthält.
Beachten Sie, dass das simpleContent-Element (Zeile 4) und das complexType-Element (Zeile 11) keine Namen einschließen. Sie können einen Namen einschließen, wenn Sie vorhaben, die Inhalts-Definitionen an anderer Stelle im Schema wiederzuverwenden. Das vergleichbare complexType-Element in Zeile 3 hat den Namen messageType. Die Deklaration für das nachricht-Element (Zeile 13) enthält eine Referenz (type="messageType") auf die Deklaration des komplexen Typs (Zeilen 3-9), in der die Attributs-Deklaration liegt (Zeile 6).
Das Element sequence in den Zeilen 12-14 wird nur eingeschlossen, um Sie mit der typischen Platzierung und Syntax bekannt zu machen, die für Instanzen verwendet wird, die mehrere abgeleitete Elemente haben, was Beschränkungen zur Reihenfolge notwendig macht.
Die Zeilen 5 und 7 bilden die Grundlage für den Datentyp, in diesem Fall einen String, der als Integerwert näher qualifiziert wird. Das Element restriction wird verwendet, um den vorhandenen (Basis-)Typ anzuzeigen und die Facetten zu identifizieren, mit denen der Wertebereich abgesteckt wird.
Bei XSD wird der Begriff Facette verwendet, um die verschiedenen Beschränkungsmerkmale zu beschreiben, die zur Verfügung stehen, um den jeweils gültigen Datentyp zu modifizieren. Ein String zum Beispiel kann durch die zugelassene Länge, minLength, maxLength, einem vom Anwender definierten Muster, der Verwendung von Leerzeichen oder durch eine Auflistung der zulässigen Werte, beschränkt werden. Im Vergleich dazu ist es nicht sinnvoll, einen Booleschen Wert - der true oder false zurückgibt - etwa durch eine zugelassene Länge, minLength, maxLength oder eine Auflistung zu beschränken. Deshalb unterstützt ein Boolescher Wert keine Facetten für diese Beschränkungen.
Bei der Unterstützung zahlreicher einfacher Datentypen und anwendbarer Facetten ist XSD einzigartig. Eine erschöpfende Auflistung dazu steht unter http://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets bereit.
Die Datentypen, die in Tabelle 6.1 zu den Elementen vorgestellt wurden, gelten auch bei Attributen. Die Liste der Datentypen, die XSD unterstützen, ist weit größer als diejenige bei XDR. Das W3C hat beträchtliches Gewicht auf den Umfang des Datentypsatzes bei XSD gelegt.
Die Unterstützung für Datentypen bei XDR und XSD unterscheidet diese Sprachen von den DTDs, die diese nicht sehr klar unterstützen. Das W3C hat sich bemüht, sicherzustellen, dass XSD einen äußerst umfangreichen und möglichst vollständigen Datentypsatz bekommt. XSD stellt zwei unterschiedliche Arten von Datentypen zur Verfügung: primitive und derived. Der Datentyp primitive umfasst diejenigen, die nicht durch andere Datentypen definiert sind; sie existieren selbstständig und bilden die Grundlage für andere Typen. Der Datentyp derived bezeichnet Datentypen, die durch primitive oder andere abgeleitete Datentypen definiert werden. Betrachten Sie zum Beispiel den primitive-Typ float und den derived-Typ integer. float ist ein klar definiertes mathematisches Konzept, das nicht mit den Begriffen anderer Datentypen definiert werden kann, wogegen integer ein Sonderfall des generelleren Datentyps decimal ist. integer kann also tatsächlich als Ableitung von decimal gelten.
Listing 6.10 zeigt eine etwas komplexere Attributsansammlung, wobei jedes davon zu einem anderen Datentyp gehört.
Listing 6.10: Mehrere Attribute - nachricht06_6.xml
1: <?xml version="1.0"?>
2: <notiz
3: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
4: xsi:noNamespaceSchemaLocation="nachricht06.xsd">
5: <nachricht anzahl="10" datum="2001-07-29" von="Kathy Shepherd">
6: Denke daran, auf dem Nachhauseweg von der Arbeit Milch zu kaufen
7: </nachricht>
8: </notiz>
In Zeile 5 wird ein numerisches (xsd:integer), ein Datums- (xsd:date) und ein String (xsd:string)-Attribut im Dokument der XML-Instanz angezeigt. Die Deklaration dieser Attribute erfordert eine explizite Definition der Datentypen, die ihre Werte beschränken. Die xsd:attribute-Elemente sehen jeweils so aus:
<xsd:attribute name="anzahl" type="xsd:integer" use="required"/>
<xsd:attribute name="datum" type="xsd:date" use="required"/>
<xsd:attribute name="von" type="xsd:string" use="required"/>Jedes Attribut in diesem Beispiel wird durch name (entspricht dem Elementnamen im Dokument der XML-Instanz), type (deklariert den Datentyp in Übereinstimmung mit den oben beschriebenen Beschränkungen) und use (betrifft die Frage, ob die Attribute obligatorisch oder optional sind) deklariert. Wenn Sie deklarieren, dass die Attribute obligatorisch sind und nicht optional, müssen Sie für jedes xsd:-Attribute-Element das Wertepaar use="required" einfügen.
Ein XSD-Schema, das diese Instanz validiert, sehen Sie in Listing 6.11.
Listing 6.11: Ein XSD-Schema, das eine XML-Instanz mit mehreren Attributen validiert - nachricht06_6.xsd
1: <?xml version="1.0"?>
2: <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
3: <xsd:complexType name="messageType">
4: <xsd:simpleContent>
5: <xsd:restriction base="xsd:string">
6: <xsd:attribute name="number"
type="xsd:integer" use="required"/>
7: <xsd:attribute name="date"
type="xsd:date" use="required"/>
8: <xsd:attribute name="from"
type="xsd:string" use="required"/>
9: </xsd:restriction>
10: </xsd:simpleContent>
11: </xsd:complexType>
12: <xsd:element name="note">
13: <xsd:complexType>
14: <xsd:sequence>
15: <xsd:element name="message" type="messageType"/>
16: </xsd:sequence>
17: </xsd:complexType>
18: </xsd:element>
19: </xsd:schema>
In den Zeilen 5-9 wird unter Verwendung des Tags <xsd:restriction base="xsd:string"> die Stringbasis für die Attributsbeschränkungen definiert. Es handelt sich bei jedem Attribut um einen string (Zeile 5), der durch die Deklaration in den Zeilen 6-8 hinsichtlich des Datentyps (integer, date oder string) und hinsichtlich use weiter beschränkt wird. (Im entsprechenden XML-Dokument sind alle Attribute required, also obligatorisch.)
In den vergangenen drei Tagen haben Sie drei verwandte aber unterschiedliche Ansätze kennen gelernt, die programmatisch validierte Beschränkungen bereitstellen, um die Einhaltung der Strukturregeln für Daten und Dokumente sicherzustellen. DTDs gibt es seit geraumer Zeit und sie haben bei einer Reihe von Anwendungen funktioniert. Wenn Ihnen eine knappe Programmierung der Beschränkungen wichtig ist, dann sollten Sie DTDs verwenden - die am wenigsten wortreiche der drei vorgestellten Sprachen. DTDs verwenden jedoch nicht die Syntax von XML-Dokumenten, die für andere Schemavarianten typisch ist. Zwar führt es nicht automatisch zu einer Verbesserung des Prozesses, wenn Schemata sich in der XML-Syntax ausdrücken, sehr wohl aber führt es dazu, dass Optionen der Erweiterbarkeit und der Transformation der Auszeichnungen vorliegen, die es bei DTDs nicht gibt. Schemata, die auf der Grundlage des XML-Vokabulars stehen, können dezidiert hierarchische Auszeichnungen und ausgefeiltere Inhaltsbeschränkungen einsetzen.
Die vielleicht bedeutendste Verbesserung, die Schemata auf XML-Grundlage mit sich bringen, ist ihre Fähigkeit, eine umfassende Datentyp-Validierung zu garantieren. Sie haben gestern und heute gesehen, dass XDR und XSD einen umfangreichen Datentypsatz unterstützen. XSD unterstützt sogar noch mehr als XDR.
XML-basierte Schemata bieten eine weit bessere Unterstützung der Namensräume. Mehr zu den Namensräumen erfahren Sie am 8. Tag, aber es ist wichtig, festzuhalten, dass das Konzept der Namensräume im Zentrum der Anstrengungen beim W3C steht.
XSD - eine kürzlich veröffentlichte Empfehlung des W3C verspricht viel für die Zukunft - verfügt über umfangreichere Datentypen als XDR und die Wahrscheinlichkeit ist hoch, dass es allgemein als von einer Plattform unabhängige Initiative akzeptiert wird. Verfolgen Sie regelmäßig die aufregenden Entwicklungen, die die XML-Technologie in dieser Hinsicht erfährt, auf der Website des W3C unter http://www.w3.org.
Heute haben Sie einige der hauptsächlichen Konstrukte der Implementierung bei XSD kennen gelernt, den Ansatz, der den umfangreichsten Datentypsatz unterstützt. Damit kennen Sie nun die drei populärsten Herangehensweisen zur Validierung von XML- Dokument-Instanzen. Achten Sie bei XSD auf neue Entwicklungen im W3C-Umfeld. Ein regelmäßiger Besuch bei http://www.w3.org hält Sie auf dem Laufenden.
Frage:
Welche der drei Schemasprachen, die in diesem Buch vorgestellt wurden (DTD, XDR
und XSD) wird am häufigsten benutzt?
Antwort:
Ein großer Teil des älteren Codes implementiert zur Zeit DTDs; der XDR-Ansatz
wird jedoch immer rascher akzeptiert, vor allem in der Welt des E-Commerce,
E-Business und beim Management von Zuliefererketten. Microsoft hat die
Entwicklung von Lösungen verbessert, indem es wichtige XML-Technologien mit
der XDR-Validierung herausbrachte. Dennoch wird erwartet, dass die Wirtschaft
in Zukunft einen einzigen Schemastandard allgemein unterstützen wird. Auch
wenn es noch seine Zeit dauern wird, bis sich alle älteren Systeme an XSD
angepasst haben, gibt es bereits eine Absichtserklärung der meisten
Softwarehersteller - auch wenn sie selbst über eine anerkannte Schemasprache
verfügen - in Zukunft XSD voll unterstützen zu wollen.
Frage:
Was ist der Unterschied zwischen DTDs und den XML-basierten Schemasprachen in
Hinsicht auf die Datentypen?
Antwort:
DTDs stellen außer einer Validierung einfacher Texttypen keine leicht
zugängliche Datentyp-Validierung zur Verfügung. Die Schemata auf XML-
Grundlage unterstützen über die standardmäßigen Dokumenttypen hinaus einen
umfassenden Datentypensatz. Die Validierung von Datentypen macht diese
Sprachen geeigneter für eine Verwendung bei Datenanwendungen.
Auch diese Übung soll Ihre Kenntnisse dessen, was Sie heute gelernt haben, überprüfen. Die Lösungen finden Sie wieder in Anhang A.
Gestern haben Sie ein XDR-Schema für Ihre Music Collection Markup Language (MCML) erzeugt. Erstellen Sie nun ein XSD-Schema auf der Grundlage der heutigen Beispiele und Übungen, mit dem Sie Ihre MCML-Dateien validieren.
