String-Datentypen

(Auszug aus "XML Schema" von Eric van der Vlist)

Diese Seite erörtert Datentypen, die von dem primitiven Datentyp xs:string abgeleitet sind, sowie andere Datentypen, die ein ähnliches Verhalten zeigen (nämlich xs:hexBinary, xs:base64Binary, Einschränkungen, xs:QName und xs:NOTATION). Von diesen Typen erwartet man nicht, daß sie einen quantifizierbaren Wert haben (W3C XML Schema erwartet nicht einmal, sie sortieren zu können). Ihr Werteraum ist mit ihrem lexikalischen Raum identisch, solange nicht ausdrücklich etwas anderes angegeben ist. Zu beachten ist, daß diese primitiven Datentypen, auch wenn sie hier in diesem Abschnitt wegen ihres ähnlichen Verhaltens als Gruppe dargestellt werden, von der Recommendation als sehr unterschiedlich betrachtet werden.

Die auf dieser Seite behandelten Datentypen werden in der folgenden Abbildung dargestellt.

Die zwei Ausnahmen bei der Whitespace-Verarbeitung (xs:string und xs:normalizedString) sind String-Datentypen. Einer der Hauptunterschiede zwischen diesen Typen ist die angewendete Whitespace-Verarbeitung. Um diese Unterscheidung zu betonen, klassifizieren wir diese Typen anhand ihrer Whitespace-Verarbeitung.

Keine Whitespace-Ersetzung

xs:string

Dieser String-Datentyp ist der einzige vordefinierte Datentyp, für den keine Whitespace-Ersetzung durchgeführt wird. Wie wir im nächsten Kapitel sehen werden, kann die Whitespace-Ersetzung für benutzerdefinierte Datentypen, die von diesem Typ abgeleitet sind, ohne Einschränkungen festgelegt werden. Hingegen kann ein Benutzer-Datentyp nicht so definiert werden, daß keine Whitespace-Ersetzung stattfindet, wenn er von einem anderen vordefinierten Datentyp als xs:string abgeleitet ist.

Abbildung: Strings und ähnliche Datentypen

Wie zu erwarten, ist ein String eine Zeichenfolge, die der in XML 1.0 festgelegten Definition entspricht, nämlich: »Zulässige Zeichen sind Tab, Carriage Return, Linefeed und die zulässigen Zeichen laut Unicode und ISO/IEC 10646.«

Der Wert des folgenden Elements:

ist der volle String:

einschließlich aller Tabulatoren und Carriage Return/Line Feed, sofern das Element title vom Typ xs:string ist.

Normalisierte Strings

xs:normalizedString

Der normalisierte String ist der einzige vordefinierte Datentyp, bei dem Whitespace-Ersetzung ohne Zusammenfassung durchgeführt wird.

Der lexikalische Raum von xs:normalizedString ist derselbe wie der des Typs xs:string, von dem er abgeleitet ist, mit einer Ausnahme: Da jedes Vorkommen von #x9 (Tab), #xA (Linefeed) und #xD (Carriage Return) durch genau ein #x20 (Blank) ersetzt wird, können diese drei Zeichen weder im lexikalischen noch im Werteraum auftreten.

Der Wert desselben Elements:

ist nun der String:

Auf den   Hund gekommen

wobei alle Whitespace-Zeichen durch Blanks ersetzt worden sind, sofern das Element title vom Typ xs:normalizedString ist.

Es gibt keine zusätzlichen Einschränkungen für normalisierte Strings. Jeder Wert, der ein gültiger xs:string ist, ist auch ein gültiger xs:normalizedString. Der Unterschied liegt darin, welche Art von Whitespace-Verarbeitung bei der Bestimmung des lexikalischen Werts angewendet wird.

Zusammengefaßte Strings

Whitespace-Zusammenfassung wird nach der Whitespace-Ersetzung durchgeführt, indem führende und am Ende stehende Blanks entfernt sowie alle zusammenhängenden Folgen von Blanks durch ein einzelnes Blank ersetzt werden. Alle vordefinierten Datentypen (außer xs:string und xs:normalizedString, wie wir gesehen haben) haben zusammengefaßten Whitespace.

Wir werden Tokens, Binärformate, URIs, qualifizierte Namen, Notationen und alle davon abgeleiteten Typen in diese Kategorie einordnen. Obwohl diese Datentypen eine Reihe von Eigenschaften gemeinsam haben, müssen wir noch einmal betonen, daß diese Einordnung nur aus Gründen der Erläuterung stattfindet und nicht unmittelbar in der Recommendation zu finden ist.

Token

xs:token

xs:token ist xs:normalizedString, bei dem die Whitespace-Zeichen zusammengefaßt worden sind. Da Whitespace-Zeichen im lexikalischen Raum von xs:token durchaus auftreten können, wird dieser Typ besser » tokenisiert« statt einfach nur »Token« genannt.

Dasselbe Element:

ist immer noch ein gültiges xs:token, dessen Wert nun der folgende String ist:

Auf den Hund gekommen

bei dem alle Whitespace-Zeichen zunächst durch Blanks ersetzt, dann alle am Ende stehenden Blanks entfernt und zusammenhängende Folgen von Blanks durch einzelne Blanks ersetzt wurden.

Genau wie bei xs:normalizedString gibt es keine Einschränkung für xs:token , und jeder Wert, der ein gültiger xs:string ist, ist auch ein gültiges xs:token . Der Unterschied liegt in der Art der Whitespace-Verarbeitung bei der Bestimmung des lexikalischen Werts. Dies gilt nicht für diejenigen abgeleiteten Datentypen, die zusätzliche Einschränkungen bezüglich ihrer lexikalischen und Werteräume haben. Die Einschränkung für die lexikalischen Räume von xs:normalizedString ist daher eine Einschränkung durch die Projektion ihres geparsten Raums (verschiedene Werte ihres geparsten Raums werden in denselben Wert ihres lexikalischen Raums transformiert), nicht aber eine Einschränkung, die Werte ihres lexikalischen Raums ungültig machen würde, wie es bei allen anderen vordefinierten Datentypen der Fall ist.

Die von xs:token abgeleiteten vordefinierten Datentypen sind xs:language, xs:NM -TOKEN und xs:Name.

xs:language

Dieser Typ wurde so angelegt, daß er alle von RFC 1766 standardisierten Sprachcodes akzeptiert. Einige gültige Werte dieses Datentyps sind en, en-US, de oder de-DE .

xs:NMTOKEN

Dies entspricht der Produktion »Nmtoken« (Namenstoken) von XML 1.0, also eines einzelnen Tokens (eine Zeichenfolge ohne Blanks), das aus Zeichen besteht, die in XML-Namen erlaubt sind. Einige gültige Werte für diesen Datentyp sind "Snoopy" , "CMS" , "1950-10-04" oder "3810518883" . Nicht zulässige Werte sind unter anderem "brachte die klassische Musik in die Peanuts-Comics ein" (Blanks sind verboten) oder "kühn,dreist" (Kommata sind verboten).

xs:Name

Dies ist dem xs:NMTOKEN sehr ähnlich, hat jedoch die zusätzliche Einschränkung, daß die Werte mit einem Buchstaben oder den Zeichen »:« oder »-« beginnen müssen. Dieser Datentyp entspricht der XML 1.0-Definition »Name«. Einige gültige Werte für diesen Datentyp sind "Snoopy", "CMS" oder "-1950-10-04-10:00". Ungültige Werte sind unter anderem »3810518883« (xs:Name kann nicht mit einer Ziffer beginnen) oder »kühn,dreist« (Kommata sind verboten). Dieser Datentyp sollte nicht für Namen verwendet werden, die durch ein Namensraum-Präfix »qualifiziert« werden können, denn wir werden noch einen weiteren Datentyp (xs:QName) kennenlernen, der für solche Werte eine besondere Semantik bietet. Der Datentyp xs:NCName ist von xs:Name abgeleitet.

xs:NCName

Dies ist der »noncolonized name« (»doppelpunktloser Name«), der von der Empfehlung Namespaces in XML 1.0 definiert wird, d.h. ein xs:Name ohne jeglichen Doppelpunkt (»:«). Daher ist dieser Datentyp wahrscheinlich derjenige vordefinierte Datentyp, der dem Begriff eines »Namens« in den meisten Programmiersprachen am besten entspricht, auch wenn einige Zeichen wie »-« oder ».« häufig immer noch problematisch sein werden. Einige gültige Werte für diesen Datentyp sind "Snoopy", "CMS" oder "-1950-10-04-10-00". Ungültige Werte sind unter anderem »-1950-10-04:10-00 « oder »kühn:dreist« (Doppelpunkte sind verboten). xs:ID, xs:IDREF und xs:ENTITY sind von xs:NCName abgeleitet.

xs:ID

Dieser Typ ist von xs:NCName abgeleitet. Dem Werteraum wird eine zusätzliche Einschränkung hinzugefügt, nämlich, daß es keine doppelten Werte in einem Dokument geben darf. Mit anderen Worten, die Werte von Attributen oder Elementen einfachen Typs, die diesen Datentyp haben, können als eindeutige Bezeichner verwendet werden. Daher emuliert dieser Datentyp den Attributtyp ID von XML 1.0. Wir werden diese Verwendung unter Definition von Eindeutigkeit, Schlüsseln und Schlüsselverweisen im einzelnen betrachten.

xs:IDREF

Dieser Typ ist von xs:NCName abgeleitet. Die Einschränkung, die dem Werteraum hier hinzugefügt wird, besteht darin, daß der Wert einer ID, die im selben Dokument definiert ist, entsprechen muß.

xs:ENTITY

Auch dies gibt es aus Gründen der Kompatibilität mit den DTDs von XML 1.0. Dieser Typ ist von xs:NCName abgeleitet und muß einem ungeparsten Entity, das in einer DTD definiert ist, entsprechen.

XML 1.0 gibt die folgende Definition ungeparster Entities: »Ein ungeparstes Entity ist eine Ressource, deren Inhalt Text sein kann, aber nicht muß. Falls es sich um Text handelt, muß es sich nicht um XML handeln. Jedes ungeparste Entity hat eine ihm zugeordnete Notation, die über seinen Namen identifiziert wird. Außer der Anforderung, daß ein XML-Prozessor die Bezeichner für das Entity und die Notation der Anwendung zur Verfügung stellt, legt XML keine Einschränkungen für den Inhalt ungeparster Entities fest.« In der Praxis wird dieser Mechanismus selten benutzt, denn es ist allgemein üblich, Links zu den Ressourcen zu definieren, die als ungeparste Entities definiert werden könnten.

Qualifizierte Namen

xs:QName

In Übereinstimmung mit der Empfehlung Namespaces in XML 1.0 unterstützt xs:QName die Verwendung von Namen mit Namensraum-Präfix. Ein xs:QName mit Namensraum-Präfix verwendet eine abkürzende Schreibweise, um einen URI zu identifizieren. Jeder xs:QName enthält im Ergebnis eine Menge von Tupeln der Art {Namensraum-Name, lokaler Teil}, wobei der Namensraum-Name der URI ist, der durch eine Namensraum-Deklaration mit dem Präfix verknüpft ist. Auch wenn der lexikalische Raum von xs:QName demjenigen von xs:Name sehr ähnlich ist (die einzige zusätzliche Einschränkung besteht darin, daß es höchstens einen Doppelpunkt in einem xs:QName geben kann, der außerdem nicht das erste Zeichen sein darf), sind die Werteräume dieser Datentypen vollständig unterschiedlich (ein Skalar für xs:Name, hingegen ein Tupel für xs:QName). Außerdem ist xs:QName als primitiver Datentyp definiert. Die Einschränkung, die dieser Datentyp gegenüber xs:Name zusätzlich hat, besteht darin, daß das Präfix als Namensraum-Präfix innerhalb des Geltungsbereichs des Elements, in dem dieser Datentyp verwendet wird, definiert sein muß.

W3C XML Schema hat uns bereits selbst einige Beispiele von QNames geliefert. Wenn wir <xs:attribute name="lang" type="xs:language"/> schreiben, ist das Attribut type ein xs:QName, dessen Wert das folgende Tupel ist:

{"http://www.w3.org/2001/XMLSchema", "language"}

Mit dem Präfix xs: ist nämlich der URI "http://www.w3.org/2001/XMLSchema" verknüpft. Wenn es keine Namensraum-Deklaration für dieses Präfix gibt, wird das Attribut type als ungültig betrachtet.

Das Präfix eines xs:QName ist optional. Wir können auch schreiben:

<xs:element ref="book" maxOccurs="unbounded"/>

Hier ist das Attribut ref wiederum ein xs:QName und sein Wert ist das folgende Tupel:

{NULL, "book"}

Wir haben schließlich keinen Default-Namensraum definiert. xs:QName unterstützt Default-Namensräume jedoch; wenn im Gültigkeitsbereich dieses Elements ein Default-Namensraum definiert ist, wird der Wert von dessen URI für dieses Tupel verwendet.

URIs

Einschränkungen

Dies ist ein weiterer String-Datentyp, bei dem lexikalischer und Werteraum unterschiedlich sind. Dieser Datentyp versucht, die Formatunterschiede zwischen XML und URIs im Sinne der RFCs 2396 und 2732 zu kompensieren. Diese RFCs stehen Nicht-ASCII-Zeichen nicht gerade freundlich gegenüber und verlangen zahlreiche Escape-Sequenzen, die in XML nicht notwendig sind. Die W3C XML Schema Recommendation beschreibt nicht, welche Transformation durchzuführen ist, sondern merkt nur an, daß sie dem ähnelt, was für die Link-Locator von XLink beschrieben wurde.

Als Beispiel für diese Transformation würde das Attribut href eines wie folgt geschriebenen XHTML-Links:

in den folgenden Wert des Werteraums umgewandelt:

"http://dmoz.org/World/Fran%c3%a7ais/"

Der Datentyp Einschränkungen berücksichtigt keinerlei xml:base-Attribute, die möglicherweise in dem Dokument definiert worden sind.

Notationen

xs:NOTATION

Dies ist wahrscheinlich der obskurste der String-Datentypen. Dieser Datentyp wurde geschaffen, um die Notationen von XML 1.0 zu implementieren. Er kann nicht unmittelbar, sondern nur mit Hilfe benutzerdefinierter abgeleiteter Datentypen in einem Schema benutzt werden. Wir werden im nächsten Kapitel mehr dazu sehen.

Binäre stringcodierte Datentypen

XML 1.0 kann keine binären Inhalte aufnehmen. Diese müssen daher als Strings codiert werden, ehe sie in ein XML-Dokument geschrieben werden können. W3C XML Schema hat zwei primitive Datentypen definiert, um zwei gebräuchliche Codierungen (hexBinary und base64) zu unterstützen. Diese Codierungen können verwendet werden, um beliebige binäre Inhalte aufzunehmen, unter anderem auch Textformate, deren Inhalt sich möglicherweise nicht mit den XML-Auszeichnungen verträgt. Andere binäre Textcodierungen können auch verwendet werden (wie etwa uuXXcode, Quoted Printable, BinHex, aencode oder base85, um nur einige zu nennen), ihr Wert würde jedoch nicht von W3C XML Schema erkannt werden.

xs:hexBinary

Dies definiert eine einfache Methode dafür, binäre Inhalte als Zeichenfolgen zu codieren, indem der Wert eines jeden binären Oktetts in zwei Hexadezimalziffern umgewandelt wird. Diese Codierung unterscheidet sich von der BinHex-Methode (die von Apple eingeführt wurde, in RFC 1741 beschrieben ist und einen Mechanismus zur Komprimierung sich wiederholender Zeichen unterstützt).

Ein XML-Header in UTF-8 wie der folgende:

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

würde in der Codierung als xs:hexBinary so aussehen:

3c3f786d6c2076657273696f6e3d22312e302220656e636f64696e673d225554462d38223f3e

xs:base64Binary

Dies entspricht der als »base64« bekannt gewordenen Codierung, die in RFC 2045 beschrieben ist. Dabei werden Gruppen von je sechs Bits auf ein Array von 64 druckbaren Zeichen abgebildet.

Derselbe Header würde in der Codierung als xs:base64Binary so aussehen:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4=

Die W3C XML Schema Recommendation hat die Tatsache übersehen, daß RFC 2045 einen Zeilenumbruch nach jeweils 76 Zeichen verlangt. Dies sollte in einer Berichtigungsliste klargestellt werden. Die Tatsache, daß W3C XML Schema diese Zeilenumbrüche als optional ansieht, hat zur Folge, daß der lexikalische und der Werteraum von xs:base64Binary nicht als identisch anzusehen sind.