Abstract

Neben den Document Type Definitions ist in jüngerer Zeit ein alternativer Ansatz in den Blickpunkt des Interesses gerückt: die XML-Schemasprachen. XML Schema (im Jahre 2001 als Empfehlung des W3C veröffentlicht) ist dabei die heutzutage am meisten verwendete Schemasprache für XML. Sie wurde ersonnen, um die Einschränkungen der DTDs, die in ihrer Dokumentenorientierung wurzeln, zu umgehen und insbesondere die Möglichkeit zur Datentypisierung zu realisieren.

Der Begriff Schema

• Der Begriff Schema kommt aus dem Umfeld der Datenbanken.
• Man bezeichnet damit Informations- oder Datenmodelle, die als Konstruktionsvorlage oder Dokumentation für einen Datenbankentwurf dienen.
• Ein Schema kann dabei beispielsweise in einer graphischen Datenmodellierungssprache (z.B. ERM oder E3R) vorliegen oder kann die Tabellenstruktur einer relationalen Datenbank bezeichnen.

Warum ein Schema?

• Zum Zeitpunkt, als SGML und damit die DTD erfunden wurde, waren diese hauptsächlich dafür vorgesehen, Dokumente in Papierform zu digitalisieren.
• Es war damals noch nicht vorherzusehen, daß 30 Jahre später eine Weiterentwicklung der Sprache hauptsächlich zur Strukturierung von Daten eingesetzt werden würde.
• Heute werden XML-Sprachen verwendet, um beliebige datenorientierte Inhalte darzustellen. Für diesen Zweck ist der DTD-Mechanismus offenkundig nicht sehr gut geeignet.
• Schemata definieren Bedingungen (sog. constraints ) für XML-Dokumente. Das Definieren solcher Bedingungen mit Schemata ist besser, als diese dann später bei der Programmierung der Applikationen noch prüfen zu müssen. Die Datenvalidierung wird von der Applikationslogik getrennt ( Separation of Concerns , Edsger W. Dijkstra ).

Unzulänglichkeiten und Beschränkungen von DTDs

Für datenintensive Strukturen unterliegt der DTD-Mechanismus folgenden Einschränkungen:

• Unzureichende Datentypunterstützung :
  Für Elemente kennen DTDs nur die 4 im letzten Kapitel vorgestellten Inhaltsmodelle das leere Element ( EMPTY ), ANY , das gemischte Inhaltsmodell sowie namentlich benannte Kindelemente .
  Für Attribute gibt es neben der benutzerdefinierten Aufzählung noch die 8 weiteren Typen CDATA , ID , IDREF , IDREFS , ENTITY , ENTITIES , NMTOKEN , NMTOKENS (vgl. Diskussion im letzten Kapitel ). Strenggenommen handelt es sich aber bei all diesen Datentypen um Zeichenketten, die lediglich keine Markup-Symbole enthalten dürfen ( In XML-Spezifikation nachlesen ).
• Unzureichende Strukturierungsunterstützung : Die Operatoren + , ? und * ermöglichen die Steuerung der Anzahl von Kindelementen. Allerdings ist dies sehr fehlerbehaftet und nur sehr schwer lesbar.
• Keine Unterstützung von Wiederverwendbarkeit : Definierte Elemente können wiederverwendet werden, dies gilt jedoch nicht für Attribute. Sie sind immer an das Element gebunden, für das sie definiert sind.
• Starres Typsystem : Es ist nicht möglich, die vorgegebenen Typen an eigene Bedürfnisse anzupassen (z.B. durch Erweiterung oder Einschränkung).
• Keine Unterstützung von Namensräumen : Namensräume können in der DTD nicht angegeben werden.
• Nur rudimentärer Referenzierungsmechanismus : Die Möglichkeit zur Referenzierung mit dem ID/IDREF -Mechanismus ist Einschränkungen unterworfen. Verknüpfen sind nur innerhalb eines Dokumentes möglich und es gibt keine Unterstützung dafür, Elemente sowohl hinsichtlich der Identifizierung durch IDs als auch in ihrer Eigenschaft als Verweisziel zu differenzieren (vgl. das Beispiel der Projektverwaltung im vorigen Kapitel ).
• DTD-Syntax ist nicht XML : Die Syntax der DTD entspricht nicht der XML-Syntax. Tools müssen dies zusätzlich implementieren.

Schemasprachen

• Als (bessere) Alternative zu DTDs wurden verschiedene (populäre und weniger populäre) Schemasprachen ersonnen, die zueinander in Konkurrenz standen und stehen (vgl. Robin Covers Übersicht über die verschiedenen Schemasprachen ).
• Teilweise haben verschiedene dieser Schemasprachen als Grundlage für die Entwicklung umfassenderer / populärerer Schemasprachten gedient.
• Beispielsweise ist aus den Schemasprachen Document Definition Markup Language (DDML) , XML Data , Datatypes for DTDs (DT4DTD) und Schema for Object-Oriented XML (SOX) die Schemasprache des W3C, XML Schema , entstanden.
• Als weitere Schemasprache, die in direkter Konkurrenz zu XML Schema steht, ist Relax NG , spezifiziert im Gremium OASIS , zu sehen. Für RelaxNG gibt es zwei Notationen: eine XML-basierte Notation sowie eine sog. Kompakte Syntax .
• Die Sprache Schematron verfolgt einen anderen Ansatz. Sie arbeitet nicht grammatikbasiert, sondern ermöglicht basierend auf XPath und XSLT Expressions die Erstellung von Regeln, denen jeweils bestimmte Teile eines Dokuments folgen müssen (=kontextsensitiv). Dabei zielt Schematron darauf ab, daß ein Mensch das Ergebnis der Überprüfung (eine textbasierte Nachricht) liest und auswertet. Schematron ist kein Ersatz für eine Grammatik, kann aber durchaus eine sinnvolle Ergänzung darstellen.

XML Schema

• Der W3C Standard XML Schema (oft durch XSD abgekürzt) ist von allen XML-Schemasprachen der meist genutzte. Damit kommt ihm die größte praktische Bedeutung zu.
• XML-Schema bildet zusammen mit Der XML-Spezifikation selbst und den Namensräumen die Basis aller weiteren W3C-XML-Sprachstandards.
• XML-Schema-Dokumente sind XML-Dokumente.
• DTDs werden aller Wahrscheinlichkeit nach nicht komplett durch Schema ersetzt werden (das würde der selbstauferlegten Forderung der Kompatibilität mit SGML widersprechen).
• Allerdings werden neu entwickelte XML-Sprachen heutzutage nicht mehr in der old style DTD-Grammatik definiert, sondern stattdessen durch ein ausdrucksmächtigeres Schema.

XML Schema definiert...

• ... Strukturen folgender Elemente aus dem XML Information Set:
  • Elemente
  • Attribute
  • Keine Entitäten, keine Notationen

XML Schema - Einführendes

• Die Spezifikation selbst (bestehend aus den beiden Teilen XML Schema Part 1: Structures und XML Schema Part 2: Datatypes ) ist so schwer zu lesen, daß ein eigenständiges, nicht normatives Dokument generiert wurde, nämlich XML Schema Part 0: Primer . In diesem Dokument wird XML Schema an vielen Beispielen anschaulich illustriert.
• XML Schema erlaubt es, Inhaltsmodelle für Elemente, Attributstrukturen und wiederverwendbare Strukturen zu definieren.
• Der Standard bringt eine Reihe vordefinierter Datentypen mit (z.B. string , integer , date ). Zusätzlich dazu können aber auch eigene Datentypen definiert werden.
• XML Schema berücksichtigt Namensräume und definiert einen eigenen Namensraum, in dem sich alle Primitive zur Definition eines eigenen Schemas befinden: http://www.w3.org/2001/XMLSchema (der Namensraum für die Sprache XML Schema ). Dieser Namensraum wird sehr oft an das Präfix xsd gebunden.
• Der zweite durch XML Schema vordefinierte Namensraum ist der Schema-Instance genannte Namensraum http://www.w3.org/2001/XMLSchema-instance . In diesem Namensraum, der oft an das Präfix xsi gebunden wird, befinden sich Elemente und Attribute aus XML-Schema, die in sogenannten Instanzdokumenten (dies ist ein anderer Name für XML-Dokumente, die den Regeln des Schemas genügen) verwendet werden können.
• Zusätzlich dazu kann in einem Schema ein sogenannter Target Namespace angegeben werden. Dieser bezeichnet den Namensraum für die Elemente eines XML-Dokuments, das mit diesem Schema verknüpft ist (der Namensraum für die Sprache des XML-Dokuments ). Dieser Namensraum ist nicht vorgegeben und frei wählbar.

Gültigkeit hinsichtlich eines Schemas, Gültigkeit und Wohlgeformtheit

Definition der Gültigkeit hinsichtlich eines Schemas

Ein XML-Dokument heißt gültig hinsichtlich eines Schemas (schema valid) , wenn es über ein Schema verfügt, und konform zu diesem aufgebaut ist.

Verknüpfen eines Dokuments mit einem Schema

• Im Gegensatz zu einer DTD kann ein XML-Schema-Dokument üblicherweise nicht als internal Subset in ein XML-Dokument eingebettet werden.
• Stattdessen wird die Verbindung zu einem Schema in einem XML-Dokument durch eines der beiden Attribute schemaLocation bzw. noNamespaceSchemaLocation (für den Fall, daß ein Schema ohne Target Namespace vorliegt) angegeben. Eines dieser Attribute muß im Wurzelelement des Dokuments angegeben werden.

Verknüpfen eines Dokuments mit einem Schema - Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<ProjektVerwaltung 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://www.barbara-zengler.de/vorlesung/projektverwaltung.xsd"/>

• Die Verknüpfung von Dokument und Schema findet im Wurzelelement statt.
• Der XML-Schema-Instanzen-Namensraum wird an das Präfix xsi gebunden. Damit können Elemente und Attribute aus Schema in das Dokument eingebunden werden.
• In der nächsten Zeile wird schon das erste Element aus Schema verwendet: schemaLocation verknüpft durch Angabe der URI des Schemas das Dokument mit dem Schema.
• Weil entweder schemaLocation oder noNamespaceSchemaLocation im Wurzelelement eines Dokuments angegeben werden müssen, ist die Angabe des Schema-Instanzen-Namensraums für jedes Dokument zwingend!

Schema für Schema - Metaschema!

• Jedes XML-Schema-Dokument ist ein XML-Dokument.
• Jedes XML-Dokument kann durch ein Schema beschrieben werden.
• Folge: Jedes XML-Schema-Dokument kann selbst wieder durch ein Schema (Schema für Schema) beschrieben werden.
• Damit kann jedes Schema auf Gültigkeit hinsichtlich dieses Metaschemas überprüft werden. Das war eine wichtige Forderung beim Sprachentwurf von XML Schema. Für DTDs besteht diese Möglichkeit nicht.
• Dieselben Tools, die die Gültigkeit eines Dokuments hinsichtlich eines Schemas prüfen, können auch die Gültigkeit eines Schemas hinsichtlich des Metaschemas prüfen.
• Solch ein Metaschema ist wieder ein XML-Dokument - auch hierfür könnte man nun wieder ein Schema angeben...
• Um zu vermeiden, daß hier eine unendliche Kette von Schemavalidierungen entsteht, hat man sich dazu entschlossen, das Schema für Schema durch sich selbst zu beschreiben.

Schema für Schema - Metaschema!

XML Schema - Typsystem

• XML-Schema definiert insgesamt 44 sogenannte Primitivtypen . Darunter finden sich die aus der DTD bekannten Element- und Attributtypen, sowie eine Fülle Neuer.
• Den Datentypen lassen sich folgende Eigenschaften zuordnen:
  • Atomare versus aggregierte Typen:
    • Unter einem atomaren Datentyp versteht man einen Datentyp, der die kleinste Informationseinheit darstellt. Die Information ist nicht mehr weiter unterteilbar, d.h. nicht mehr erkennbar weiter unterstrukturiert (Beispiel string ) oder der Zugriff auf die Teilkomponenten ist nicht möglich (Beispiel: date - kein Zugriff auf Jahr, Monat, Tag).
    • Aggregierte Datentypen sind Datentypen, die sich entweder
      • aus Werten eines oder mehrerer verschiedenen Datentypen zusammensetzen (Vereinigungstypen)
      • oder aus mehreren Werten eines atomaren Datentyps zusammensetzen (Listen), z.B. drei Dezimalzahlen 8 10.5 12 .
  • Primitive versus abgeleitete Typen :
    • Primitive Datentypen existieren unabhängig von anderen Datentypen (z.B. float ).
    • Abgeleitete Datentypen benötigen andere Datentypen, von deren Definition sie abhängig sind (z.B. )
  • Vorgegebene versus anwenderdefinierte Typen :
    • Vorgegebenen Datentypen sind all diejenigen die in XML Schema Part 2 definiert sind. Es wurden all diejenigen Datentypen definiert, die mit einer hohen Wahrscheinlichkeit von einer großen Anzahl Benutzern "neu erfunden" worden wären.
    • Anwenderdefinierte Typen können vom Benutzer selbst festgelegt werden.

XML Schema - Typsystem

XML Schema - Datentypen - Datum und Zeit

XML Schema - Datentypen - String und davon Abgeleitete

XML Schema - Datentypen - decimal und davon Abgeleitete

XML Schema - Datentypen - weitere vordefinierte Primitivtypen

XML Schema am Beispiel - Wurzelelement schema

• Den Wurzelknoten bildet das Element schema .
• Direkt unterhalb dieses Elements werden in einer flachen Struktur alle Definitionen dieses Schemas angegeben.
• Attribute des schema -Elements:
  • (Optionale) Angabe des Namensraums für das Zielvokabular: targetNamespace als URI.
  • elementFormDefault : kann den Namensraumzwang für Elemente des Instanzdokuments lockern. qualified gibt an, daß sich die Elemente des Dokuments immer im Zielnamensraum befinden müssen, unqualified hingegen erlaubt das Vorkommen von Elementen auch außerhalb dieses Namensraums. Vorgabewert: unqualified .
  • attributeFormDefault : analog für Attribute.

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

XML Schema - Elementdefinitionen

• Direkt unterhalb des Wurzelelements
• Durch das XSD-Element element
• XML Schema bringt zahlreiche vordefinierte Elementtypen mit, darüber hinaus erlaubt es auch die Definition eigener Typen.
• Es unterstützt auch die Inhaltsmodelle der DTD: unstrukturierter Inhalt (Text), leeres Inhaltsmodell, explizit benannte Kindelemente, beliebige Kindelemente, gemischtes Inhaltsmodell.

<xsd:element
                    name="elementName"
                    type="typeName"/>

• Entspricht -- abgesehen von der Typdefinition -- bis hierher den Möglichkeiten, die auch DTDs bieten.

XML Schema - Elementeigenschaften

Des weiteren können folgende Eigenschaften für Elemente mit Hilfe von Attributen angegeben werden:

• abstract : falls auf true gesetzt, darf ein solches Element nicht in einem XML-Dokument auftreten. Es kann ausschließlich zur Strukturierung des Schemaentwurfs eingesetzt werden und als Basis von Spezialisierungen dienen. Vorgabewert ist false
• block : erlaubt es, die Verwendung abgeleiteter Typen zu kontrollieren. Zugelassene Belegungen sind beliebige Kombinationen aus extension , restriction und substitution oder der Einzelwert #all .
  Die hier angegebenen Typen dürfen im Instanzdokument nicht als Ersatz des Originaltyps auftreten.
  Der Wert #all verbietet generell die Ersetzung eines Elements durch andere.
• default : Vorgabebelegung des Inhalts durch eine beliebige Zeichenkette, die konform zum gewählten Typ ist. Dieser Wert wird durch den XML-Prozessor an die Applikation gemeldet, wenn kein Wert im Dokument angegeben wird.
• fixed : erlaubt es, Elemente mit einem konstanten Wert zu belegen.
  default und fixed schließen sich gegenseitig aus.
• final : verhindert die Ableitung von Typen. Die zulässigen Belegungen sind mit denen für block identisch, nur daß durch dieses Attribut die Vererbungsmechanismen bereits auf Schemaebene verboten werden, während block ihre Nutzung im Instanzdokument einschränkt.
• form: legt fest, ob das Element im Instanzdokument mit Namensraumpräfix erscheint. Zulässige Belegungen: qualified (Namensraumpräfix muß angegeben werden) und unqualified .
• id : erlaubt die eineindeutige Kennzeichnung eines Elements durch eine schemaweit eindeutige Zeichenkette.
• minOccurs : Minimalkardinalität, d.h. Mindestzahl zulässiger Vorkommen dieses Elements. Der Attributinhalt ist ein Element aus nonNegativeInteger . Das Attribut ist optional, und wird bei fehlender Angabe mit dem Vorgabewert 1 belegt.
• maxOccurs : Maximalkardinalität, d.h. Höchstzahl zulässiger Vorkommen dieses Elements. Der Attributinhalt ist entweder ein Element aus nonNegativeInteger oder die Zeichenkette unbounded zur Kennzeichnung beliebig vieler Auftreten. Das Attribut ist optional, und wird bei fehlender Angabe mit dem Vorgabewert 1 belegt.
• name : Unqualifizierter Name des Elements, konform zur NCName-Produktion der Namensraum-Spezifikation.
• nillable : Erlaubt Null-Werte im Instanzdokument, die Semantik ist dabei an die in relationalen Datenbanksystemen verwirklichte angelehnt. Die Belegung ist entweder true oder false , was auch als Vorgabe bei Fehlen dieses Attributs angenommen wird.
• ref : Referenz auf eine andere Elementdeklaration zur Übernahme der dort spezifizierten Definitionen.
• substitutionGroup : Name einer Gruppe von Elementen, die anstatt des aktuellen Elements im Instanzdokument auftreten dürfen.
• type : Ein durch Schema Part 2 vordefinierter Typ, oder jeder beliebige anwenderdefinierte.

XML Schema am Beispiel - Elementdefinitionen

Nachfolgend finden Sie einige beispielhafte Elementdeklarationen für nicht strukturierten (= keine Kindelemente), aber typisierten, Elementinhalt:

<element name="geburtsdatum" type="xsd:date"/>
<element name="pi" 
  type="xsd:double" 
  fixed="3.141592653" 
  block="#all"/>
<element name="vorname" 
 type="xsd:token" 
 minOccurs="1" 
 maxOccurs="unbounded"/> 
<element name="artikelNummer" 
 type="xsd:NCName" 
 form="qualified"/>
 <element

• geburtsdatum definiert ein XML-Element des Typs date zur Darstellung eines Datums. Weitere Festlegungen sind nicht getroffen, daher wird das Element mit minOccurs und maxOccurs 1 belegt. Damit ist es im Instanzdokument zwingend anzugeben.
• pi entspricht mit seiner konstanten Belegung ( fixed -Attribut) der gleichnamigen mathematischen Konstante. Als Datentyp wurde double , eine Gleitkommazahl mit doppelter Genauigkeit gewählt. Durch die Belegung von block mit #all wird verhindert, daß eine weitere Spezialisierung des Elements durch Vererbung oder Aggregation erfolgt.
• Die Definition für vorname nutzt token als Datentyp. Hier werden automatisch mehrfache, führende und abschließende Leerzeichen sowie sonstige Formatierungssymbole entfernt. Der Vorname kann darüber hinaus beliebig häufig auftreten -- maxOccurs ist mit dem Wert unbounded belegt. Die minimale Auftrittshäufigkeit wird mit 1 ( minOccurs ) festgelegt, dies entspricht der Vorgabebelegung.
• Für das Element artikelNummer ist als Typ NCName ausgewählt. Dies entspricht beliebigen Zeichenketten, die keinen Doppelpunkt enthalten. Darüberhinaus ist das Attribut form mit dem Wert qualified versehen. Dies führt dazu, daß das Namensraumkürzel für dieses Element zwingend im Instanzdokument anzugeben ist.

Elementdefinition - freies Inhaltsmodell

Zur Umsetzung des freien Inhaltsmodells, das beliebige Inhalte aus den definierten Elementen und freien Texten zuläßt, wird ebenfalls auf das Typsystem zurückgegriffen.
Wird das type Attribut nicht belegt, so wird gemäß Vorgabe der Typ anyType angenommen. Elemente dieses Typs können beliebige wohlgeformte Inhalte beherbergen.
Die beiden nachfolgenden Angaben sind daher äquivalent:

 <element
   name="elementName"
   type="xsd:anyType"/>
<element name="elementName"/>

Verwendung von Typen - complexType - leeres Inhaltsmodell

XSD hat verglichen mit der DTD einen strengeren Typbegriff. Dies zeigt sich deutlich in der Existenz des XSD-Elements complexType . Dieses Element erlaubt die Bildung von Typen losgelöst von ihrere Verwendung. Syntaktisch kann die complexType -Definition sowohl innerhalb einer Elementdefinition, als auch separat erfolgen.
Den einfachsten Anwendungsfall bildet die eingebettete leere complexType -Definition zur Darstellung des leeren Inhaltsmodells.
Die Syntax hierfür lautet (der XSD-Namensraum sei an das Präfix xsd gebunden):

<xsd:element
   name="elementName">
   <xsd:complexType/>
</xsd:element>

In einem Instanzdokument werden für die obige Festlegung ausschließlich die beiden Darstellungsformen zum leeren Element ( <elementName/> bzw. <elementName></elementName> ) akzeptiert.

Verwendung von Typen - complexType - strukturierter Inhalt - Reihenfolgetypen

• In XML Schema wird explizit angegeben, in welcher Reihenfolge Kindelemente auftreten sollen. Hierfür gibt es folgende drei Möglichkeiten, die miteinander kombiniert werden können:
  • sequence : Sequentielles Auftreten der Elemente in der angegebenen Reihenfolge.
  • choice : Auswahl - entspricht einer ODER -Verknüpfung von einzelnen Elementen.
  • all : Erlaubt die Angabe der Kindelemente in beliebiger Reihenfolge.

Elementdefinition und Reihefolgetypen am Beispiel Projektverwaltung

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="ProjektVerwaltung">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="Person" maxOccurs="unbounded"/>
    <xsd:element ref="Projekt" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="Person">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element name="Vorname" type="xsd:token" maxOccurs="unbounded"/>
    <xsd:element name="Nachname" type="xsd:token"/>
    <xsd:element ref="Qualifikationsprofil" minOccurs="0"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="Projekt">
  <xsd:complexType/>
 </xsd:element>
 <xsd:element name="Qualifikationsprofil">
  <xsd:complexType mixed="true">
   <xsd:sequence>
    <xsd:element name="Qualifikation" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="Leistungsstufe" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
</xsd:schema>

• In diesem Schema sind alle Elementdefinitionen für die Projektverwaltung enthalten. In diesem Beispiel werden 4 Dinge demonstriert:
  • Innerhalb jedes element -Elements sind die entsprechenden Kindelemente in sequence -Strukturen eingebettet. Sie müssen genau in der Reihenfolge ihres Auftretens im Schema auch im Instanzdokument wiedergegeben werden.
  • Verwendung des leeren Inhaltsmodells für Projekt
  • Verwendung des gemischten Inhaltsmodells (siehe nächste Seite) für Qualifikationsprofil
  • Referenzierung auf Elementdefinitionen mit Hilfe des ref -Attributs.

Gemischtes Inhaltsmodell im Vergleich zur DTD

 <xsd:element name="Qualifikationsprofil">
  <xsd:complexType mixed="true">
   <xsd:sequence>
    <xsd:element name="Qualifikation" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="Leistungsstufe" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>

<!ELEMENT Qualifikationsprofil (#PCDATA | Qualifikation | Leistungsstufe)*>
<!ELEMENT Qualifikation (#PCDATA)>
<!ELEMENT Leistungsstufe (#PCDATA)>

• Von besonderem Interesse ist die Definition des Qualifikationsprofils mit gemischtem Inhaltsmodell. Dies wird durch das Boole'sche Attribut mixed ausgedrückt.
• Wichtiger Unterschied zur DTD: DTD-validierende Parser können gemischte Inhalte nur rudimentär prüfen. Mit XSD eröffnet sich die Möglichkeit zur vollständigen inhaltlichen Validierung gemischter Inhalte. Die DTD erlaubt es zwar, (möglicherweise) auftretende Elemente innerhalb unstrukturierter Textpassagen zu spezifizieren, es ist aber nicht möglich, die Häufigkeit oder Reihenfolge der Elemente anzugeben (vgl. Beispiel-DTD zur Projektverwaltung - dort wäre auch die Hintereinanderreihung von Qualifikationen ohne zugehörige Leistungsstufe zulässig). Insgesamt kann durch DTD-basierte Validierung das Auftreten von Elementen in gemischten Inhaltsmodellen nicht geprüft werden. Durch den Einsatz von XML-Schema ergibt sich auch für gemischte Inhaltsmodelle die Möglichkeit zur strikten Validierung. Dies bedeutet konkret, daß Anzahl und Auftretensreihenfolge der angegebenen Kindelemente überprüft werden können.

Globale und lokale Elementdefinitionen

• Globale Elementdefinitionen werden zunächst deklariert und in einem zweiten Schritt durch Referenzierung als Kindelemente verwendet (wie Person und Projekt innerhalb Projektverwaltung, oder Qualifikationsprofil innerhalb des Elements Person).
• Ihre Gegenstücke, die lokalen Elementdeklarationen befinden die sich hingegen vollständig im Elternelement finden (wie Vorname, Nachname und Qualifikation).
• Durch Globale Elementdefinitionen können vollständige Elemente an verschiedenen Stellen im Schema referenziert und so verwendet werden. Die Definition ist der lokalen ebenbürtig und wird im Instanzdokument identisch behandelt.
• Mit dem Referenzierungsmechanismus für Elemente kann eine einfache Form der Wiederverwendung umgesetzt werden. Jedoch werden Elemente hierbei zwingend in ihrer vollständigen Definition, d.h. Name, Typ und Inhaltsmodell, eingebunden. (Im Grunde genommen ist diese Art der Wiederverwendung für Elemente bereits mit den Mitteln der DTD möglich. Allerdings, wie im eben betrachteten Beispiel, auch dergestalt, daß nur die vollständige Definition übernommen werden kann.)

Benannte komplexe Typen

• XML-Schema bietet zusätzlich die Möglichkeit, strukturierte Typen, die ausschließlich durch ihr Inhaltsmodell definiert werden, festzulegen.
• Die Benennung des Typs wird hierdurch unabhängig von der Namensgebung der typisierten Instanz.
• Syntaktisch erfolgt die Typbildung durch die Benennung des complexType-Elements durch ein Attribut name.
• Um die mehrfache Verwendung eines solchen Typen zu ermöglichen, muß seine Definition zwingend auf einer Baumstufe erfolgen, die für alle nutzenden Elemente erreichbar ist. Üblicherweise werden daher diese Definitionen auf der ersten Stufe, direkt unterhalb des Wurzelknotens, plaziert.
• Zur Unterscheidung dieser benannten komplexen Typen werden die bisher genutzten -- namenlosen Typen -- als anonyme komplexe Typen bezeichnet.
• Das nachfolgende Beispiel zeigt die Definition des benannten komplexen Typen PersonType . Dieser Typ wird zur Festlegung des Inhaltsmodells des Elements Person verwendet.

<xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
   <xsd:complexType name="PersonType">
    <xsd:sequence>
    <xsd:element name="Vorname" type="xsd:string" maxOccurs="unbounded"/>
    <xsd:element name="Nachname" type="xsd:string"/>
    <xsd:element ref="Qualifikationsprofil" minOccurs="0"/>
   </xsd:sequence>
   </xsd:complexType>
   
   <xsd:element name="ProjektVerwaltung">
      <xsd:complexType>
         <xsd:sequence>
            <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/>
            <xsd:element ref="Projekt" maxOccurs="unbounded"/>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>

   <xsd:element name="Projekt">
      <xsd:complexType/>
   </xsd:element>

   <xsd:element name="Qualifikationsprofil">
      <xsd:complexType mixed="true">
         <xsd:sequence>
            <xsd:element name="Qualifikation" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="Leistungsstufe" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
</xsd:schema>

Erweiterung, Einschränkung und Substitution

• In XML-Schema gibt es die Möglichkeit, eigene Datentypen durch Erweiterung (Extension), Einschränkung (Restriction) und Substitution anderer Datentypen zu definieren. In allen Fällen dient ein bereits definierter Datentyp als Basis.
• Erweiterung (Extension) : Die im bestehenden Datentyp enthaltene Information ist jedoch nicht ausreichend, es werden zusätzliche Informationen benötigt. Der bestehende Datentyp wird daher um diese Information ergänzt (erweitert).
  Beispiel: Es gibt einen bereits definierten Datentyp eine Adresse , der aus Name, Straße und Ort besteht. Adressen in D zeichnen sich zusätzlich noch durch eine Postleitzahl aus. Der ursprungliche Datentyp Adresse kann demnach um die Postleitzahl erweitert werden.
• Einschränkung (Restriction) : Analog zur Definition von Datentypen durch Erweiterung können auch durch Einschränkung eigene Datentypen abgeleitet werden. Der abgeleitete Datentyp ist dem Originaltyp sehr ähnlich, seine Deklarationen sind jedoch eingeschränkt, die Werte des abgeleiteten Typs entsprechen einer Untermenge der Werte des ursprünglichen Typs. Mit anderen Worten: Wenn eine Anwendung Werte des Originaltyps verarbeiten kann, kann sie auch Werte des abgeleiteten Typs verarbeiten.
  Beispiel: Setzen eines Vorgabewerts oder Beschränkung in der Anzahl von erlaubten Kindelementen (etwa von 0 - unendlich auf 1-5)
• Substitution : Mit Hilfe der Substitution kann ein Element durch ein anderes Element ersetzt werden. Elemente werden hierzu sogenannten Substitutionsgruppen zugeordnet. Die Elemente dieser Gruppe können dann anstatt eines speziellen benannten Elements, des Head Elements verwendet werden.

Ableitung durch Einschränkung -- Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="parentType">
 <xsd:sequence>
  <xsd:element name="elementA" type="xsd:int"/>
 </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="childType">
<xsd:complexContent>
 <xsd:restriction base="parentType">
  <xsd:sequence>
   <xsd:element name="elementA" type="xsd:short"/>
  </xsd:sequence>
 </xsd:restriction>
</xsd:complexContent>
</xsd:complexType>

<xsd:element name="usage1" type="parentType"/>
<xsd:element name="usage2" type="childType"/>

</xsd:schema>

• Im Beispiel sehen Sie zwei benannte komplexe Typen childType und parentType .
• childType basiert auf parentType und erbt von diesem. Die Vererbung ist ausgedrückt durch das base -Attribut im Element restriction , das auf den benannten Elterntypen verweist.
• Inhalte von restriction -Elementen werden genauso angegeben wie Inhalte von komplexen Typen: Es werden Elemente definiert, sowie die Art und Weise ihres Auftretens (Reihenfolge, Häufigkeit).
• elementA in childType schränkt elementA in parentType ein: der Datentyp short ( -2 15 <= short <= 2 15 -1 ) ist enger gefaßt als der Datentyp int ( -2 31 <= short <= 2 31 -1 ).
• Die beiden Elementdefinitionen usage1 und usage2 zeigen die Verwendung der anwenderdefinierten Typen.

Ableitung durch Einschränkung -- weitere Arten der Einschränkung

Es gibt - über die soeben gezeigte Möglichkeit der EInschränkung auf Typisierung hinaus -- weiter Möglichkeiten der Einschränkung, die Sie in der folgenden Tabelle zusammengestellt sehen.

Ableitung durch Erweiterung -- Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:complexType name="parentElement">
  <xsd:sequence>
   <xsd:element name="elementA"/>
  </xsd:sequence>
 </xsd:complexType>
 
 <xsd:complexType name="childElement">
  <xsd:complexContent>
   <xsd:extension base="parentElement">
    <xsd:sequence>
     <xsd:element name="elementB"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="Test">
  <xsd:complexType>
 <xsd:element name="Elternelement" type="parentElement">
 </xsd:element>
 <xsd:element name="Kindelement" type="childElement">
 </xsd:element>
  </xsd:complexType>
</xsd:element>
</xsd:schema>

• Die Erweiterung definiert zusätzliche Elemente zum Basistyp.
• Im Beispiel sehen Sie erneut zwei benannte komplexe Typen: parentElement und childElement genannt.
• Während parentElement genau ein Element elementA beinhaltet, wird childElement dahingehend erweitert, daß es zusätzlich dazu auch noch genau ein Element elementB beinhalten kann.

Ableitung komplexer Typen von einfachen Typen

• komplexe (Daten-)Typen : XML-artiger, strukturierter Inhalt
• einfache (Daten-)Typen : die 44 von XML Schema vordefinierten Datentypen. Sie entsprechen nicht XML-artigem (strukturiertem) Inhalt
• XML Schema erlaubt es, komplexe Typen von einfachen Typen abzuleiten.
• Elemente, die einfache Datentypen (simpleTypes) als Werte haben, können zunächst keine Attribute haben.
• Soll dies ermöglicht werden, muß eine derartige Ableitung erfolgen.

Ableitung von komplexen Typen durch einfache Typen -- Beispiel

Dieses Schema definiert das Element Vorname als einfachen Typ (string).

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="Vorname" type="xs:string">
 </xs:element>
</xs:schema>

<?xml version="1.0" encoding="UTF-8"?>
<Vorname xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="./verySimpleContent.xsd">Johanna Eleonore Laura Ottilie
</Vorname>

Hier hingegen wird der Datentyp string erweitert. Das Element enthält immer noch einen einfachen Datentyp ( simpleContent ), darf aber nun ein Attribut ( rufname ) enthalten.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="Vorname">
  <xs:complexType>
   <xs:simpleContent>
    <xs:extension base="xs:string">
     <xs:attribute 
      name="rufname" 
      type="xs:string"/>
    </xs:extension>
   </xs:simpleContent>
  </xs:complexType>
 </xs:element>
</xs:schema>

<?xml version="1.0" encoding="UTF-8"?>
<Vorname xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="./simpleContent.xsd" rufname="Hannelore">Johanna Eleonore Laura Ottilie
</Vorname>

Festlegen eigener primitiver Datentypen -- simpleType

• XML Schema ermöglicht es, eigene (primitive) Datentypen festzulegen oder eigene Typen von bestehenden abzuleiten.
• Dies erfolgt mit Hilfe des Elements simpleType .
  • Ableitung durch Einschränkung
  • Listen
  • Vereinigungstypen
• Für Ableitung durch Einschränkung gilt: An jeder Stelle, an der eine Ausprägung eines Supertyps erwartet wird, darf auch eine Ausprägung eines davon abgeleiteten Subtypen auftreten.
  (Beispiel: wird an einer Stelle des Instanzdokumentes durch das Schema das Auftreten einer Ausprägung von integer verlangt, so kann der Anwender auch Ausprägungen der Subtypen int , short oder byte angeben, ohne die Gültigkeit des XML-Dokuments zu beeinträchtigen.)

Festlegen eigener primitiver Datentypen -- Listen

• Listen bestehen aus einer Aneinanderreihung atomarer Datentypen.
• Zusätzlich zu den drei in XML Schema vordefinierten Listentypen NMTOKENS , IDREFS und ENTITIES besteht die Möglichkeit, eigene Listentypen zu definieren, die sich aus atomaren Datentypen zusammensetzen.
• Das folgende Beispiel zeigt die Definition eines Listentyps ListeDerWochentage :

  <xsd:simpleType name="dieWochentage">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="Montag"/>
      <xsd:enumeration value="Dienstag"/>
      <xsd:enumeration value="Mittwoch"/>
      <xsd:enumeration value="Donnerstag"/>
      <xsd:enumeration value="Freitag"/>
      <xsd:enumeration value="Samstag"/>
      <xsd:enumeration value="Sonntag"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="ListeDerWochentage">
    <xsd:list itemType="dieWochentage"/>
  </xsd:simpleType>

• Zunächst werden durch die aufzählende Einschränkung bei dieWochentage die Werte des Typs auf eine Menge ganz spezieller Werte begrenzt.
• Der so definierte Datentyp wird dann als Basis für den Listentyp verwendet.

Festlegen eigener primitiver Datentypen -- Vereinigungstypen

• Vereinigungstypen setzen sich aus einer Menge von Ausgangstypen zusammen.
• Im Beispiel sehen Sie die Definition eines Typen termin , der eine Vereinigung aus dem vorgegebenen Primitivtypen date und einer Liste ListeDerWochentage darstellt.

  <xsd:element name="Termin" type="termin"/>
  <xsd:element name="Wochentage" type="ListeDerWochentage"></xsd:element>
  <xsd:simpleType name="termin">
    <xsd:union memberTypes="xsd:date ListeDerWochentage"/>
  </xsd:simpleType>

Festlegen eigener primitiver Datentypen -- Ableitung durch Einschränkung

• Im Beispiel ist ein weiteres Beispiel für einen einschränkenden Datentyp dargestellt.
• Der vorgegebene Typ integer wird derart limitiert, daß lediglich die Werte zwischen 10000 und 99999 als gültige Wertbelegungen zulässig sind.

  <xsd:simpleType name="myInteger">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="10000"/>
    <xsd:maxInclusive value="99999"/>
  </xsd:restriction>
</xsd:simpleType>

Ableitung durch Einschränkung - Arten der Einschränkung

XML Schema definiert 12 voneinander unabhängige sogenannte Fassetten , die zur Begrenzung der erlaubten Werte vom Primitivtypen eingesetzt werden können. Nicht alle Fassetten können auf alle Typen angewendet werden. Eine Übersicht zur Anwendbarkeit findet sich in Anhang B von XML Schema Part 0: Primer .

• length : Gibt die Anzahl der zulässigen Einheiten des Datentyps an (bei zeichenkettenartigen Datentypen entspricht dies der Anzahl der Zeichen) an. Bei Listen kann hiermit die Anzahl der Elemente festgelegt werden.
  

  <xs:simpleType name="Postleitzahl">    
   <xs:restriction base="xs:string">       
    <xs:length value="5"/>
   </xs:restriction> 
  </xs:simpleType>

• minLength : Definiert die minimale Länge von atomaren Datentypen bzw. die minimale Anzahl von Elementen einer Liste.
  

  <simpleType name='nichtleereZeichenkette'>
    <restriction base='string'>
      <minLength value='1'/>
    </restriction>
  </simpleType>

  <xs:simpleType name="VornamenList">
   <xs:list itemType="xs:token"/> 
  </xs:simpleType> 
  <xs:simpleType name="VornamenRestrictedList">
   <xs:restriction base="VornamenList">
    <xs:minLength value="1"/>
   </xs:restriction> 
  </xs:simpleType> 

• maxLength : Definiert die maximale Länge von atomaren Datentypen bzw. die maximale Anzahl von Elementen einer Liste.
  

  <simpleType name='form-input'>
    <restriction base='string'>
      <maxLength value='50'/>
    </restriction>
  </simpleType>

  <xs:simpleType name="VornamenList">    
   <xs:list itemType="xs:token"/> 
  </xs:simpleType> 
  <xs:simpleType name="VornamenRestrictedList">    
   <xs:restriction base="VornamenList">       
    <xs:minLength value="1"/>       
    <xs:maxLength value="3"/>
   </xs:restriction> 
  </xs:simpleType>

• pattern : Ein pattern legt dem Wertebereich eines atomaren Datenyps definierte Bedingungen auf. Die Werte werden auf Zeichen begrenzt, die einem bestimmten Muster entsprechen. Der Wert des Musters muß ein regulärer Ausdruck sein (siehe nächste Seite).
• enumeration : Mit einer Aufzählung wird der Wertebereich eines Datentyps auf eine genau spezifizierte Menge eingeengt.
  

  <simpleType name='feiertage'>
      <annotation>
          <documentation>Feiertage</documentation>
      </annotation>
      <restriction base='gMonthDay'>
        <enumeration value='--01-01'>
          <annotation>
              <documentation>Neujahr</documentation>
          </annotation>
        </enumeration>
        <enumeration value='--08-20'>
          <annotation>
              <documentation>Friedensfest</documentation>
          </annotation>
        </enumeration>
        <enumeration value='--12-24'>
          <annotation>
              <documentation>Heiligabend</documentation>
          </annotation>
        </enumeration>
      </restriction>
  </simpleType>

• whiteSpace : Der Wertebereich des betreffenden Datentypen kann nach den drei Regeln, wie sie auch für die Normalisierung von (zeichenkettenartigen) Attributwerten gelten, eingegrenzt werden:
  • preserve : keine Normalisierung, der Wert bleibt unverändert.
  • replace :Tabulatoren ( #x9 ), Zeilenvorschub ( #xA ) und Wagenrücklauf ( #xD ) werden durch Leerzeichen ( #x20 ) ersetzt.
  • collapse : Es werden die Regeln von replace angewandt. Zusätzlich dazu werden mehrfach direkt hintereinander vorkommende Leerzeichen zu einem einzelnen Leerzeichen zusammengefaßt sowie führende und abschließende Leerzeichen entfernt.
• maxInclusive : Mit maxInclusive kann die obere (inklusive) Grenze für den Wertebereich eines Datentyps angegeben werden.

  <xs:simpleType name="ZahlenBisNeunundneunzig">
   <xs:restriction base="xs:decimal">
    <xs:maxInclusive value="99"/>
   </xs:restriction>
  </xs:simpleType> 

• maxExclusive : Analog maxInclusive , mit dem Unterschied, daß der angegebene Wert nicht mehr zum Wertebereich zählt.
  

  <xs:simpleType name="ZahlenUnterHundert">
   <xs:restriction base="xs:decimal">
    <xs:maxExclusive value="100"/>
   </xs:restriction>
  </xs:simpleType> 

• minInclusive : Gibt die untere (inklusive) Grenze eines Wertebereichs an.

  <simpleType name='HundertUndMehr'>
    <restriction base='integer'>
      <minInclusive value='100'/>
    </restriction>
  </simpleType>

• minExclusive : Analog minInclusive , mit dem Unterschied, daß der angegebene Wert nicht mehr zum Wertebereich zählt.
  

  <simpleType name='MehrAlsNeunundneunzig'>
    <restriction base='integer'>
      <minExclusive value='99'/>
    </restriction>
  </simpleType>

• totalDigits : Gibt die Gesamtstellen einer Zahl an, gebildet aus der Summe der Vorkomma- und der Nachkommastellen.
  

  <xs:simpleType name="myNumber">
   <xs:restriction base="xs:decimal">
    <xs:totalDigits value="7"/>
   </xs:restriction>
  </xs:simpleType>

• fractionDigits : Steuert die Anzahl der Nachkommastellen eines Dezimalbruches.
  

  <simpleType name='celsiusBodyTemp'>
    <restriction base='decimal'>
      <totalDigits value='4'/>
      <fractionDigits value='1'/>
      <minInclusive value='36.4'/>
      <maxInclusive value='40.5'/>
    </restriction>
  </simpleType>

Reguläre Ausdrücke

Ein Regulärer Ausdruck ist eine Syntax, die eine Menge von Zeichenketten beschreibt.

• Reguläre Ausdrücke haben ihre Wurzeln im Betriebssystem UNIX, wo sie seit den 1960ern in Editoren Einzug fanden.
• Heute werden sie in vielen Programmiersprachen verwendet (z.B. Java seit JDK1.4, Perl, C++, C#, Python, PHP, Ruby, ... )
• Verwendung: Erkennen von Zeichenketten, die bestimmten Mustern entsprechen.
• In XML Schema: Vorgeben von Mustern für Zeichenketten.
• Syntax: Quantoren, Fluchtsymbole, Zeichenklassen

Reguläre Ausdrücke - Quantoren

Quantoren steuern die Auftrittshäufigkeit von sog. atomaren Einheiten (Zeichen, Zeichenklasse, Regulärer Ausdruck).

Reguläre Ausdrücke - Beispiele für Quantoren

Reguläre Ausdrücke - Fluchtsymbole

Ein Fluchtsymbol (engl.: character escape ) in regulären Ausdrücken dient der Darstellung von Zeichen, die anderweitig nur schwer oder unmöglich in einen regulären Ausdruck schreiben kann (weil sie mit Bedeutung belegt sind oder praktisch schwer zu schreiben sind wie etwa Zeilenumbrüche, Zeilenvorschub oder Tabulatoren). Diese sind in Teilen aus den Programmiersprachen bekannt.

Reguläre Ausdrücke - Zeichenklassen

Verschiedene Zeichen mit ähnlichen Eigenschaften werden im XML Schema zu Zeichenklassen gruppiert. Diese Zeichen können so in ihrer Gesamtheit durch die Verwendung der sie bezeichnenden Symbole in den regulären Ausdrücken verwendet werden.
So bezeichnet die Angabe der Zeichenklasse \p{X} alle Zeichen aus X. Diese Angaben können durch \P{X} invertiert werden. ( [\P{X}] = [^\p{X}] ).

• Buchstaben

  Symbol	Bedeutung
  L	Alle Buchstaben
  Lu	Großbuchstaben (uppercase)
  Ll	Kleinbuchstaben (lowercase)
  Lt	Titlecase: Großschreibung des ersten Zeichens eines Wortes. Diese Art der Schreibung ist üblicherweise abhängig von der verwendeten Sprache. Im Englischen jedoch kommt der Name aus dem Zeitschriftenwesen, da dort oft in Überschriften einzelne Wörter großgeschrieben werden.
  Lm	Modifier: Verschiedene Ton- und Betonungszeichen
  Lo	Other: Alle Zeichen, die in keine der sonstigen L-Zeichenfamilien fallen

• Markierungssymbole

  Symbol	Bedeutung
  M	Alle Markierungssymbole
  Mn	Markierungssymbole ohne Leerzeichen (z.B. diakritische Zeichen: kleine Zeichen wie Punkte, Häkchen, Kringel, sie markieren eine besondere Betonung oder Aussprache.)
  Mc	Markierungssymbole spacing combining : Hauptsächlich im asiatischen Sprachraum anzutreffende (Myanmar, Khmer, Tibetisch, Bengalisch, ...) Markierungssymbole, die mit Leerzeichen kombiniert sind.
  Me	Andere Markierungssymbole, die andere Zeichen beinhalten (z.B. das kyrillische Zeichen für Hunderttausend und Million).

• Zahlen

  Symbol	Bedeutung
  N	Alle Nummern
  Nd	Dezimalzahlen, darunter auch auch arabisch-indische, gurmukhi und gujarati (zwei indische Schriften), thailändisch, und Weitere,
  Nl	Durch Buchstaben dargestellte Nummern, z.B. die lateinischen Zahlen I , II , III , ....
  No	Andere Darstellungen von Nummern (z.B. Brüche 1/4, 1/2, 3/4, weitere Khmer-Symbole für 10 bis 100, hochgestellt und tiefgestellte Ziffern, in Kreisen dargestellte Zahlen, etc.)

• Interpunktionssymbole

  Symbol	Bedeutung
  P	Alle Interpunktionssymbole (Punctuation)
  Pc	Verbindende Interpunktionssymbole wie Unterstrich, Bogen über Zeichen, etc.
  Pd	Verbindungsstriche
  Ps	Bereiche öffnende Interpunktionssymbole (z.B. öffnende Klammern)
  Pe	Bereiche schließende Interpunktionssymbole (z.B. schließende Klammern)
  Pi	Zitatbeginn (z.B. öffnende Anführungszeichen)
  Pf	Zitatende (z.B. schließende Anführungszeichen)
  Po	Alle anderen Interpunktionssymbole (z.B. Semikolen, Ausrufezeichen, Fragezeichen, etc.)

• Seperatoren

  Symbol	Bedeutung
  Z	Alle Separatoren
  Zs	Alle Leerzeichen (einfache, diverse Längen (3-fach, 4-fach), aber auch mongolische vokaltrennende Leerzeichen)
  Zl	Zeilentrenner ( #x2028 )
  Zp	Absatztrenner ( #x2029 )

• Symbole

  Symbol	Bedeutung
  S	Alle Symbole
  Sm	mathematische Symbole
  Sc	Währungssymbole ( €, $ )
  Sk	Modifier (wenige Akzente, Betonungshinweise, etc.)
  So	weitere Symbole (Copyright-Symbol, Grad Celsius, Pfeile, etc.)

• Sonstige

  Symbol	Bedeutung
  C	Alle Sonstigen
  Cc	Kontrollzeichen (z.B. End of Transmission , >Backspace , Delete , etc.)
  Cf	Formatierungszeichen (z.B. syrisches Abkürzungszeichen)
  Co	Zeichen aus dem Unicode-Bereich zur freien anwenderdefinierten Belegung (mit ungefähr 137500 Zeichen)
  Cn	Zeichen, denen innerhalb Unicode explizit keine Belegung zugewiesen wurde

Reguläre Ausdrücke - Negation und Zeichensequenzen

• Durch das Zeichen ^ wird eine Negation eines Ausdrucks definiert.
• Desweiteren existieren noch folgende vor definierte Zeichensequenzen mit häufig anzutreffenden Zeichen:

  Symbol	Bedeutung
  .	Alle Zeichen außer Zeilenumbruch und Zeilenvorschub (entspricht [^\n\r] )
  \s	Versammelt Leerzeichen, Tabulator, Zeilenumbruch und Zeilenvorschub ( [#x20\t\n\r] )
  \S	Alles außer Leerzeichen, Tabulator, Zeilenumbruch und Zeilenvorschub ( [^\s] )
  \i	Die initialen Zeichen eines gültigen XML-Namens: ein Buchstabe, der Unterstrich _ oder der Doppelpunkt :
  \I	Die Negation der vorhergehenden Definition ( [^\i] )
  \c	Alle für XML-Namen zugelassenen Zeichen
  \C	Alle Zeichen, die nicht in XML-Namen zugelassen sind
  \d	Entspricht \p{Nd} : Dezimalzahlen, darunter auch auch arabisch-indische, gurmukhi und ....
  \D	Alle Zeichen, die nicht Dezimalzahlen entsprechen ( [^\d] )
  \w	Alle Zeichen außerhalb der Zeichenklassen Interpunktion , Separatoren " und Sonstige ( [#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}] )
  \W	Alle Zeichen innerhalb der Zeichenklassen Interpunktion , Separatoren " und Sonstige ( [^\w] )

Reguläre Ausdrücke - Beispiele

• KFZ-Kennzeichen

  <xsd:simpleType name="gerAutoNummer">
   <xsd:restriction base="xs:string">
    <xsd:pattern value="\p{Lu}{1,3}-\p{Lu}{1,2} \p{Nd}{1,4}"/>
   </xsd:restriction> 
  </xsd:simpleType>

• Social Security Number (vgl. Professional XML Schemas . By Kurt Cagle, Jon Duckett, Oliver Griffin, Stephen Mohr, Francis Norton, Nikola Ozu, Ian Stokes-Rees, Jeni Tennison, and Kevin Williams. Wrox Programmer to Programmer Series. Birmingham, UK: Wrox Press Ltd., [July] 2001. ISBN: 1-861005-47-4)

  <xsd:simpleType name="SSN">
    <xsd:restriction base="xs:string">
      <xsd:pattern value="[0-9]{3}-[0-9]{2}-[0-9]{4}"></xsd:pattern>
    </xsd:restriction>
  </xsd:simpleType>

• Initialen (vgl. Beispiel auf W3 Schools )

  <xsd:element name="Initialien">
  <xsd:simpleType>
    <xsd:restriction base="xs:string">
      <xsd:pattern value="[A-Z]{2,3}"/>
    </xsd:restriction>
  </xsd:simpleType>
  </xsd:element> 

• Vorwahl (vgl. Tutorium für angewandte Informatik an der Universität Karlsruhe (von Götz Bürkle)

  <xsd:simpleType name="Vorwahltyp">
    <xsd:restriction base="xs:string">
      <xsd:minLength value="3"></xsd:minLength>
      <xsd:maxLength valie="5"></xsd:maxLength>
      <xsd:pattern value="0[1-9]{2,4}"></xsd:pattern>
    </xsd:restriction>
  </xsd:simpleType>

XML Schema - Attributdefinitionen

• Die Definition von Attributen erfolgt mit dem Element attribute .
• Es können analog zu DTDs optionale Attribute, zwingend anzugebende Attribute und Attribute mit festen Werten angegeben werden.
• Darüber hinaus könne auch Aufzählungsattribute und Mengen realisiert werden.
• Folgende Eigenschaften können für Attributdefinitionen angegeben werden:
  • name : Ein Name ohne Doppelpunkt ( NCName )
  • id : kann mit einer Schema-weit eindeutigen Zeichenkette zum Zweck der Identifikation gekennzeichnet werden.
  • default : Erlaubt die Angabe eines Vorgabewert. Dieser Vorgabewert wird vom XML-Prozessor an die verarbeitende Applikation geliefert, wenn im Instanzdokument kein Wert für das Attribut angegeben ist.
  • fixed : Erlaubt die Festlegung eines konstanten Werts für das Attribut. fixed und default schließen sich gegenseitig aus.
  • type : Mit type wird der Typ des Attributes (ein simpleType ) bestimmt.
  • form : Legt fest, ob der Attributname im XML-Instanzdokument durch ein Namensraumpräfix eingeleitet wird (Belegung: qualified , andernfalls unqualified ).
  • ref : Verweis auf eine globale Attributdefinition.
  • use : Legt mit den Werten optional , required oder prohibited die Verwendung des Attributes fest. Vorgabewert ist optional , das Attribut wird nicht zwingend im XML-Dokument erwartet. Den Gegensatz hierzu bildet required , wodurch das Attribut als zwingend anzugeben definiert wird. prohibited verbietet die Nutzung des Attributes im XML-Dokument.

XMl Schema am Beispiel - Attributdefinitionen

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
 <xsd:attribute name="myAtt1"/>
 <xsd:attribute name="myAtt2" type="xsd:decimal"/>
 <xsd:attribute name="myAtt3">
  <xsd:simpleType>
   <xsd:restriction base="xsd:int">
    <xsd:minInclusive value="10"/>
    <xsd:maxInclusive value="20"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:attribute>
 <xsd:simpleType name="myType1">
  <xsd:restriction base="xsd:string">
   <xsd:maxLength value="5"/>
  </xsd:restriction>
 </xsd:simpleType>
 <xsd:attribute name="myAtt4" type="myType1"/>
 <xsd:element name="foo">
  <xsd:complexType>
   <xsd:attribute ref="myAtt1" use="optional"/>
   <xsd:attribute ref="myAtt2" use="required"/>
   <xsd:attribute ref="myAtt3" use="prohibited"/>
   <xsd:attribute ref="myAtt4"/>
   <xsd:attribute name="myAtt5" type="xsd:date" id="myDate"/>
   <xsd:attribute name="myAtt6">
    <xsd:simpleType>
     <xsd:restriction base="xsd:float">
      <xsd:totalDigits value="5"/>
     </xsd:restriction>
    </xsd:simpleType>
   </xsd:attribute>
  </xsd:complexType>
 </xsd:element> 
 <xsd:element name="bar">
   <xsd:complexType>
     <xsd:attribute ref="myAtt1" use="required"/>
   </xsd:complexType>
 </xsd:element>
</xsd:schema>

• Für das Attribut myAtt1 ist kein Typ vorgegeben. Es ist damit per Definition vom Typ anySimpleType
• Dem Attribute myAtt2 wird hingegen der vordefinierte Typ decimal zugewiesen.
• Der Datentyp für Für myAtt3 wird innerhalb der Attributdefinition selbst definiert ( simpleType ). Mit einer Einschränkung werden die zulässigen Werte limitiert. Diese dürfen zwar vom Typ int sein, davon sind aber nur die Werte 10 und 20 für das Attribut gültig.
• myAtt4 zeigt die Verwendung eines benannten komplexen Typs für die Typdefinition eines Attributs. Zunächst wird der komplexe Typ namens myType1 definiert. Er erlaubt Zeichenketten mit einer maximalen Länge von 5 Zeichen. Dieser Typ wird danach in der Typdefinition
• In der Elementdefinition für foo wird die Verwendung der global definierten Attribute myAtt1 bis myAtt4 demonstriert. Diese werden mit Hilfe des ref -Attributs referenziert. myAtt1 ist als optional anzugebend deklariert, wohingegen myAtt2 zwingend anzugeben ist. Für myAtt3 ist die Verwendung im Instanzdokument verboten ( prohibited ).
• myAtt5 stellt eine lokale Attributdefinition dar, sie ist nur innerhalb der Elementdefinition von foo gültig. Die Attributwerte müssen vom Typ date sein. Darüber hinaus erhält das Attribut noch eine Zeichenkette zur Identifikation: id .
• myAtt6 entspricht wiederum der Bildung eines anonymen (inneren) Datentyps. Die lokale Attributdefinition beschränkt Werte vom Typ float auf 5 Stellen.
• In der Elementdefinition von bar wird die globale Attributdefinition für myAtt1 wiederverwendet, für dieses Element ist das Attribut zwingend anzugeben.

XML Schema am Beispiel - komplettes Schema der Projektverwaltung

Das vollständige Schema für das Beispiel Projektverwaltung ist hier aufgeführt.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="Nachname" type="xsd:string"/>
 <xsd:complexType name="PersonType">
  <xsd:sequence>
   <xsd:element ref="Vorname" maxOccurs="unbounded"/>
   <xsd:element ref="Nachname" maxOccurs="unbounded"/>
   <xsd:element name="Qualifikationsprofil" type="QualifikationsprofilType" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="PersID" type="xsd:ID" use="required"/>
  <xsd:attribute name="Gehaltsgruppe" default="1a">
   <xsd:simpleType>
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:enumeration value="1"/>
     <xsd:enumeration value="1a"/>
     <xsd:enumeration value="2"/>
    </xsd:restriction>
   </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="mitarbeitInProjekt" type="xsd:IDREFS" use="required"/>
 </xsd:complexType>
 <xsd:complexType name="ProjektType">
  <xsd:attribute name="ID" type="xsd:ID" use="required"/>
  <xsd:attribute name="date" type="xsd:date"/>
  <xsd:attribute name="budget" default="10000.00">
   <xsd:simpleType>
    <xsd:restriction base="xsd:double">
     <xsd:fractionDigits value="2"/>
    </xsd:restriction>
   </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="Projektleiter" type="xsd:IDREF" use="required"/>
  <xsd:attribute name="Mitarbeiter" type="xsd:IDREFS" use="required"/>
 </xsd:complexType>
 <xsd:element name="ProjektVerwaltung">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/>
    <xsd:element name="Projekt" type="ProjektType" maxOccurs="unbounded"/>
   </xsd:sequence>
   <xsd:attribute name="version" type="xsd:string" fixed="1.0"/>
  </xsd:complexType>
 </xsd:element>
 <xsd:complexType name="QualifikationsprofilType" mixed="true">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
   <xsd:element ref="Qualifikation"/>
   <xsd:element ref="Leistungsstufe"/>
   <xsd:any namespace="http://www.w3.org/1999/xhtml"/>
  </xsd:choice>
 </xsd:complexType>
 <xsd:element name="Qualifikation" type="xsd:string"/>
 <xsd:element name="Leistungsstufe" type="xsd:string"/>
 <xsd:element name="Vorname" type="xsd:string"/>
</xsd:schema>

XML Schema am Beispiel - schemakonformes Instanzdokument der Projektverwaltung

Abschließend eine gültige (sowohl valid als auch schema valid) Dokumentinstanz der Projektverwaltungsstruktur.

<?xml version="1.0" encoding="ISO-8859-1"?>
<ProjektVerwaltung xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.barbara-zengler.de/vorlesung/projektverwaltung.xsd">
 <Person PersID="Pers01" mitarbeitInProjekt="Prj01">
  <Vorname>Hans</Vorname>
  <Nachname>Hinterhuber</Nachname>
 </Person>
 <Person PersID="Pers02" mitarbeitInProjekt="Prj02">
  <Vorname>Franz</Vorname>
  <Vorname>Xaver</Vorname>
  <Nachname>Obermüller</Nachname>
  <Qualifikationsprofil>
     IT-Kompetenz verschiedene Betriebssysteme und <Leistungsstufe>professionelle</Leistungsstufe>
   <Qualifikation>Programmierung</Qualifikation> verschiedener Programmiersprachen
     <Qualifikation>Entwickler</Qualifikation> von 1988-1990
     <Qualifikation>Projektleiterfunktion</Qualifikation> von 1990-93 im X42-Projekt in Abteilung AB&amp;C
   </Qualifikationsprofil>
 </Person>
 <Person PersID="Pers03" mitarbeitInProjekt="Prj02">
  <Vorname>Fritz</Vorname>
  <Nachname>Meier</Nachname>
 </Person>
 <Projekt ID="Prj01" Projektleiter="Pers01" Mitarbeiter="Pers01"/>
 <Projekt ID="Prj02" Projektleiter="Pers02" Mitarbeiter="Pers03"/>
</ProjektVerwaltung>

XML Schema - Tools

Mittlerweile existieren eine Reihe von Werkzeugen, mit deren Hilfe XML-Schemata (grafisch) erstellt und gepflegt werden können. Eine kleine Auswahl finden Sie hier versammelt.

• Der <oXygen/> XML Editor beinhaltet einen Visual Schema Editor . Erlaubt das Generieren von Instanzdokumenten zu einem Schema. Kostenpflichtig.
• Der Schema Editor aus der XML Spy Suite von Altova unterstützt unter anderem die grafische Erstellung von Schemata. Generieren von Instanzdokumenten möglich. Kostenpflichtig.
• Stylus Studio XML Schema Editor: Auch die Stylus Studio Suite bringt einen grafischen Schema-Editor mit sich. Kostenpflichtig.
• Eine umfassende Übersicht über XML Schema-Tools findet sich auf der XML Schema Webseite des W3C

XML Schema - Übungsaufgabe

Erstellen Sie ein Schema, das die folgenden Bedingungen abbildet.

• Das Element Information Item Autor verfügt über die Kindknoten Vorname (mindestens einmaliges, aber höchstens zweimaliges Auftreten) sowie Nachname . Beide Elemente sind Namen und verfügen über keine interne Formatierung durch Leerzeichen oder Zeilenumbrüche
• Der Wurzelknoten Zeitschrift enthält genau ein als Verlag bezeichnetes Kindelement des Typs string .
• Jeder Beitrag besitzt mindestens einen aber beliebig viele Autor en.
• Jedes Element Information Item des Typs Beiträge enthält eine positive Anzahl von Element Information Items des Namens Beitrag .
• Jedes Element Information Item des Typs Beitrag enthält das Attribut Seitenanzahl (positive Ganzzahl) und Annahmedatum (Datum)
• Jedes Element Information Item des Typs Zeitschrift enthält genau ein Element Information Item des Namens Beiträge .
• Zu jedem Beitrag existiert eine Menge von Schlagworten . Diese werden in einem Element Information Item Schlagworte abgelegt. Dieses Element kann zwischen drei und fünf Zeichenketten als Eintrag beinhalten.