Datentypen und Kompabilität von XSD

Sie wissen bereits, daß XML SCHEMA seit Mai 2001 Standard ist. Aber welche Datentypen werden hier unterstützt? IM Gegensatz zur DTD in der mehr oder weniger nur string als Datentyp möglich war, haben wir im XML Schema nicht Datentypen, wie decimal, positveInteger oder etwa boolesn zu nutzen. Sondern wir könen auch eigene Wertebereiche schaffen. Wie etwa den "GefrierSiedepunktinteger".

Wie wird das gemacht?

<xsd:simpleType name="GefrierSiedepunktinteger">
<xsd:restriction base="xsd:nonNegativeInteger">
<xsd:maxInclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>

Zunächst definieren wi9r den Namen für den Datentyp bzw. Wertebereich. Mit der Angabe

xsd:restriction base = xsd:nonNegativeInteger

legen wir fest, daß zur einen Seite keine negativen Zahlen vorkommen dürfen. Zur anderen Seite setzen wir den maximal Wert auf 100 fest.

xsd:maxInclusive value ="100"

Als nächstes stellt sich die Frage, ab wann "funktioniert" XML Schema.

Sehen wir also nach, welcher Parser welche Validierung unterstützt.

Microsoft gibt hier Auskunft:

Version Support
MSXML No support for schemas.
MSXML 2.0 Support for XML-Data Reduced (XDR) schemas.
MSXML 2.6 Support for XDR schemas.
MSXML 3.0 Support for XDR schemas.
MSXML 4.0 Support for XML Schema Definition (XSD) and XDR schemas.

Das bedeutet, daß wir nur mit der aktuellen beta Version MSXML 4.0 des Parsers Unterstützung für den neuen Standard finden. Gut, das kann nicht mehr allzulange dauern, bis auch die Beta zur Endverion wird. Bis dahin haben wir noch Zeit uns mit diesem neuen Standard zu befasssen.

Nehmen wir also mal die Datentypen unter die Lupe.

Zunächst der simpletype.

Dieser stellt lediglich eine Erweiterung eines vorhandenen Basistypes dar.

Wie beschreibt das W3C den simpleType?

Schema Component: Simple Type Definition

{name}

Optional. An NCName as defined by [Namespaces in XML].

{target namespace}

Either absent or a namespace name, as defined in [Namespaces in XML].

{variety}

One of {atomic, list, union}. Depending on the value of {variety}, further properties are defined as follows:

atomic

{primitive type definition}: A ·built-in· ·primitive· datatype definition (or the simple ur-type definition).

list

{item type definition}: An ·atomic· or ·union· simple type definition.

union

{member type definitions}: A non-empty sequence of simple type definitions.

{facets}

A possibly empty set of Facets (§2.4).

{fundamental facets}

A set of Fundamental facets (§2.4.1)

{base type definition}

If the datatype has been ·derived· by ·restriction· then the Simple Type Definition component from which it is ·derived·, otherwise the Simple Type Definition for anySimpleType (§4.1.6).

{final}

A subset of {restriction, list, union}.

{annotation}

Optional. An annotation.

Hierbei enthält Name den Namen des Typs. Der neue Typ entsteht durch Listenbildung mit List, Einschränkung eines Typs mit Restriction oder durch Vereinigung anderer
Typen mit Union. Das sieht dann beispielsweise wie folgt aus:

<simpleType name="Grundfarben">
<restriction base="string">
<enumeration value="rot"/>
<enumeration value="blau"/>
<enumeration value="grün"/>
</restriction>
</simpleType>

Neben dem simpleType gibt es auch den complexType. Die Beschreibung dafür lautet:

Im Fall des ComplexType entsteht der neue Typ durch Kombination verschiedener
vorhandener Elemente.

XML Representation Summary: complexType Element Information Item
<complexType
abstract = boolean : false
block = (#all | List of (extension | restriction))
final = (#all | List of (extension | restriction))
id = ID
mixed = boolean : false
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleContent | complexContent | ((group | all | choice | sequence)? , ((attribute |
attributeGroup)* , anyAttribute?))))
</complexType>

Es werden also die Model Group Elemente group, all, choice und sequenz auf SimpleContent (einfache Typen oder Modifikationen davon) oder ComplexContent (bereits erstellte komplexe Typen) angewandt. Am deutlichsten wird dies wohl an ein Paar Beispielen:

Eine Publikation muss also die Elemente Titel, Author und Datum enthalten.

Eine Auswahl zwischen Zug, Flugzeug oder Auto. (entspricht in der DTD <!ELEMENT
transportation (train | plane | automobile)>)

Zum Schluß sehen wir uns noch Model Group-Definition und Komponenten an.

Eine Model Group ist einfach eine Gruppe die durch verschiedene Kombinations-möglichkeiten entsteht. Dies entspricht in etwa den logischen und/oder Verknüpfungen. Eine Group entsteht dabei entweder, indem alle Elemente genau einmal enthalten sein müssen (all), die Elemente mindestens einmal, aber auch öfter auftreten können (sequence) oder einer Auswahl aus mehreren Möglichkeiten (choice).

Angabe des W3C:

<group
id = ID
maxOccurs = (nonNegativeInteger | unbounded) : 1
minOccurs = nonNegativeInteger : 1
name = NCName
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (all | choice | sequence)?)
</group>

Beispiele für sequence und choice haben wir bereits oben behandelt, daher noch ein
kleines für all (jedes der Elemente muss genau einmal auftreten):

<all>
<element name="Title" type="string" minOccurs="1" maxOccurs="1"/>
<element name="Author" type="string" minOccurs="1" maxOccurs="1"/>
<element name="Date" type="string" minOccurs="1" maxOccurs="1"/>
<element name="ISBN" type="string" minOccurs="1" maxOccurs="1"/>
<element name="Publisher" type="string" minOccurs="1" maxOccurs="1"/>
</all>

Somit stellt XSD eine Reihe von Möglichkeiten zur Verfügung die Definition von Elemente, Angabe der Strukturen des XML Dokuments und deren Datentypen. Auffällig geworden ist auf jeden Fall eines: Die Möglichkeiten gegenüber der DTD sind umfangreicher geworden zu Lasten der Länge Ausdrucksweise. Übrigens eine Übersicht der Datentypen ist als gif hinterlegt und zum download als Artikelverweis verfügbar.