edition W3C.de

XML Schema Teil 2: Datentypen

Deutsche Übersetzung

Diese Version:
http://www.edition-w3c.de/TR/2001/REC-xmlschema-2-20010502/
Übersetzer:
Toby Baier
Michael Ebert
Andreas Geissel
Mario Jeckle
Nik Klever
Elke Meier
Sebastian Werner
Buchcover

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern sowie beim Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.


W3C

XML Schema Teil 2: Datentypen

W3C Empfehlung 02. Mai 2001

Diese Version:
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
(in XML und HTML, mit einem Schema und einer DTD einschließlich der Datentypdefinitionen, sowie ein Schema für die vordefinierten Datentypen in einem getrennten Namensraum)
Neueste Ausgabe:
http://www.w3.org/TR/xmlschema-2/
Vorhergehende Ausgabe:
http://www.w3.org/TR/2001/PR-xmlschema-2-20010330/
Herausgeber:
Paul V. Biron (Kaiser Permanente, Health Level Seven) <Paul.V.Biron@kp.org>
Ashok Malhotra (Microsoft, ehemals IBM) < ashokma@microsoft.com >

Zusammenfassung

"XML Schema: Datentypen" ist der zweite Teil der XML Schema Sprache. Hier werden Möglichkeiten beschrieben, um Datentypen zu definieren, die sowohl in XML Schemata als auch in anderen XML-Spezifikationen eingesetzt werden können. Die Datentypsprache, die selbst in XML 1.0 repräsentiert ist, stellt eine Obermenge der Möglichkeiten dar, die durch XML 1.0 Dokumenttyp-Definitionen (DTDs) gegeben sind, um Datentypen für Elemente und Attribute zu spezifizieren.

Status dieses Dokuments

Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seines Erscheinens. Andere Dokumente können dieses ersetzen. Der letzte Stand der Dokumentreihe wird vom W3C gepflegt.

Dieses Dokument wurde von Mitgliedern des W3Cs und anderen interessierten Parteien überprüft und vom Direktor als W3C Empfehlung bestätigt. Es handelt sich um ein stabiles Dokument, welches als Referenz eingesetzt und in anderen Dokumenten (als solches) zitiert werden kann. Die Rolle des W3Cs bei der Erstellung der Empfehlungen liegt darin, die Aufmerksamkeit auf die Spezifikation zu ziehen und ihren weit verbreiteten Einsatz anzuregen. Dies erweitert die Funktionalität und die Interoperabilität des Web.

Dieses Dokument wurde von der XML Schema Working Group im Rahmen der W3C XML Activity erstellt. Die Ziele der XML-Schema-Sprache werden in dem Dokument XML Schema Requirements erörtert. Die Autoren dieses Dokuments sind Mitglieder der XML Schema Working Group. Dabei können verschiedene Teile von unterschiedlichen Autoren verfasst worden sein.

Die Version dieses Dokuments enthält einige redaktionelle Änderungen früherer Versionen.

Bitte melden sie Fehler in diesem Dokument an www-xml-schema-comments@w3.org (archive). Die Liste der bekannten Fehler in dieser Spezifikation ist unter http://www.w3.org/2001/05/xmlschema-errata verfügbar.

Nur die englische Version dieses Dokuments ist normativ. Informationen zu Übersetzungen dieses Dokuments sind unter http://www.w3.org/2001/05/xmlschema-translations verfügbar.

Unter http://www.w3.org/TR/ sind eine Liste der momentan verfügbaren Spezifikation und andere technische Dokumente zu finden.

Inhaltsverzeichnis

1 Ziel dieser Spezifikation
2 Typsystem
3 Vordefinierte Datentypen
4 Datentyp-Komponenten
5 Konformität

Anhänge

A Schema für Datentypdefinitionen (normativ)
B DTD für Datentypdefinitionen (nicht normativ)
C Datentypen und Fassetten
D ISO 8601 Datums- und Zeit-Formate
E Addition von Zeitspannen zu Zeitpunkten
F Reguläre Ausdrücke
G Glossar (nicht normativ)
H Referenzen
I Danksagungen (nicht normativ)

1 Ziel dieser Spezifikation

next sub-section1.1 Zweckbestimmung

In der [XML 1.0 (Second Edition)] Spezifikation werden eingeschränkte Möglichkeiten definiert, Datentypen für den Inhalt eines Dokuments anzugeben. In diesen Dokumenten werden Datentypen für Elemente oder Attribute entweder im Dokument enthalten oder referenziert angegeben. Autoren von XML-Dokumenten sowohl von traditionellen Dokumenten als auch von XML-Instanzen für den Transport von Daten benötigen oft einen höheren Grad der Typprüfung, um eine gewisse Robustheit bei der Auswertung von Dokumenten und beim Übertragen von Daten sicherzustellen.

Die folgenden zwei XML-Instanzen zeigen typische Beispiele mit impliziten Datentypen: Die erste stellt eine Rechnung dar und die zweite ein Memo oder eine E-Mail.

Daten-orientiert Dokumenten-orientiert
  <Rechnung>
    <RechnungsDatum>1999-01-21</RechnungsDatum>
    <LieferDatum>1999-01-25</LieferDatum>
    <RechnungsAdresse>
      <Name>Alfred Mustermann</Name>
      <Straße>Musterstraße 42</Straße>
      <Stadt>Musterstadt</Stadt>
      <PLZ>77777</PLZ>
    </RechnungsAdresse>
    <Telefon>0424242/424242</Telefon>
    <Fax>0424242/424224</Fax>
  </Rechnung>
  <Memo priorität="hoch" datum="1999-03-23">
    <Von>Hans Mustermann</Von>
    <An>Alfred Mustermann</An>
    <Betreff>letzte Vorversion</Betreff>
    <Rumpf>
       Wir müssen die letzte Vorversion <betont>baldmöglichst</betont>
       durchdiskutieren. Bitte schicke mir eine Email an <Email>mailto:hans.mustermann@beispiel.com</Email>
       oder ruf' mich unter folgender Nummer an:
       <Telefon>0424242/424242</Telefon>
    </Rumpf>
  </Memo>

Die Rechnung enthält verschiedene Datumsangaben, Telefonnummern und Adressangaben. Das Memo enthält auch Datums- und Telefonnummernangaben und darüber hinaus E-Mail-Adressen und Prioritätsangaben (mit einer kurzen Liste von zulässigen Werten: "niedrig", "normal", "hoch"). Anwendungen, die Rechnungen und Memos verarbeiten, müssen in der Lage sein, Fehler in den Daten zu erkennen.

In beiden Fällen gibt es Regeln zur Festlegung der Gültigkeit, die nicht mit einer DTD beschreibbar sind. Durch die eingeschränkten Möglichkeiten ist es validierenden XML-Prozessoren nicht möglich, eine strengere Typenprüfung vorzunehmen, wie sie in diesen Fällen notwendig wäre. Das Ergebnis ist, dass das Prüfen der Typen vom Entwickler gemacht werden muss. Diese Spezifikation soll sowohl Autoren von XML-Dokumenten als auch Entwicklern ein robustes und ausbaufähiges Typsystem liefern, das auch in XML-Prozessoren integriert werden kann. Wie in den folgenden Abschnitten erläutert, können diese Datentypen auch in anderen XML-bezogenen Standards eingesetzt werden.

previous sub-sectionnext sub-section1.2 Anforderungen

Das Dokument [XML Schema Requirements] zeigt auf, welche konkreten Anforderungen durch diese Spezifikation abgedeckt sein müssen. Die Spezifikation muss

  1. primitive Datentypen wie byte, date (Datum), integer, sequence (Folge) sowie die Datentypen von SQL, Java usw. abdecken.
  2. ein Typsystem definieren, das geeignet ist, Daten aus Datenbanksystemen zu exportieren bzw. in Datenbanksysteme zu importieren.
  3. zwischen Anforderungen an die lexikalische Darstellung und an darunter liegende Informationsmengen unterscheiden.
  4. das Anlegen von benutzerdefinierten Datentypen zulassen, die von bestehenden Typen abgeleitet sein können, und deren Attribute enger reglementieren (z. B. Wertebereich, Genauigkeit, Länge, Format).

previous sub-sectionnext sub-section1.3 Themengebiet

Dieser Teil der XML-Schema-Sprache befasst sich mit den Datentypen, die in einem XML Schema eingesetzt werden können. Diese Datentypen können den Inhalt von Elementen beschreiben, die bei Verwendung einer DTD mit #PCDATA und Attributwerten verschiedener Typen spezifiziert sind. Die Idee ist, dass diese Spezifikation auch für andere Aktivitäten im XML-Umfeld verwendet werden kann (wie z. B. [XSL] und [RDF Schema]).

previous sub-sectionnext sub-section1.4 Terminologie

Die Terminologie, die im Rahmen dieser Spezifikation verwendet wird, um XML-Schema-Datentypen zu beschreiben, wird im Hauptteil dieser Spezifikation definiert. Die im Folgenden definierten Termini werden verwendet, um jene Definitionen zu bilden und Aktionen zu beschreiben, die ein Datentypprozessor bereitstellen muss.

[Definition:] Aus Kompatibilitätsgründen (for compatibility)
Ein Merkmal dieser Spezifikation, das lediglich aufgenommen wurde, um sicherzustellen, dass Schemata, die dieses Merkmal einsetzen, kompatibel zu [XML 1.0 (Second Edition)] bleiben.
[Definition:] kann (may)
Standard-konforme Dokumente und Prozessoren dürfen, müssen sich aber nicht zwingend wie beschrieben verhalten.
[Definition:] entsprechen (match)
(Von Zeichenketten oder Namen:) Zwei miteinander verglichene Zeichenketten oder Namen müssen identisch sein. Zeichen mit mehreren möglichen Darstellungen nach ISO/IEC 10646 (z. B. Zeichen) entsprechen sich nur dann, wenn sie dieselbe Darstellung besitzen. Groß-/Kleinschreibung ist zu beachten. (Von Zeichenketten und Grammatikregeln:) Eine Zeichenkette entspricht einer grammatischen Produktion, wenn die Zeichenkette zu der Sprache gehört, die durch die Produktion erzeugt wurde.
[Definition:] muss (must)
Standard-konforme Dokumente und Prozessoren müssen sich wie beschrieben verhalten, anderenfalls handelt es sich um einen Fehler.
[Definition:] Fehler (error)
Eine Verletzung der Regeln dieser Spezifikation; Ergebnisse sind undefiniert. Entsprechende Software darf Fehler finden und melden, und sie darf diese beheben.

previous sub-section1.5 Regeln und Beiträge

Diese Spezifikation beinhaltet drei Arten normativer Aussagen über Schema-Komponenten, ihre Darstellung in XML und deren Beiträge zur Schema-Validierung:

[Definition:] Regeln für Schemata (constraint on schemas)
Regeln für die Schemakomponenten selbst, wie beispielsweise Komponenten, die Bedingungen enthalten, müssen ihrerseits Komponenten sein. Sie sind zum größten Teil in Datentyp-Komponenten (§4) zu finden.
[Definition:] Schema-Darstellungsregeln (schema representation constraint)
Regeln für die Darstellung von Schema-Komponenten in XML. Einige davon, aber nicht alle, sind definiert in Schema für Datentypdefinitionen (normativ) (§A) und in DTD für Datentypdefinitionen (nicht normativ) (§B).
[Definition:] Validierungsregeln (Validation Rule)
Regeln, die mittels Schema-Komponenten formuliert sind und validierbar sein müssen. Sie sind in Datentyp-Komponenten (§4) zu finden.

2 Typsystem

Dieser Abschnitt beschreibt das konzeptionelle Framework, das sich hinter dem Typsystem verbirgt, das in dieser Spezifikation definiert wird. Das Framework ist sowohl unter dem Einfluss des sprachunabhängigen Standards für Datentypen [ISO 11404] als auch der Datentypen von [SQL] und anderen Programmiersprachen wie Java entstanden.

Die in dieser Spezifikation erläuterten Datentypen entsprechen den maschinenlesbaren Repräsentationen bekannter abstrakter Konzepte wie integer und date. Die Definition dieser abstrakten Konzepte findet man in anderen Publikationen.

next sub-section2.1 Datentypen

[Definition:] Ein Datentyp in dieser Spezifikation entspricht einem Tripel, bestehend aus a) einer Menge von verschiedenen Werten -- dem sog. Wertebereich, b) einer Menge von lexikalischen Darstellungen -- dem sog. lexikalischen Bereich und c) einer Menge von Fassetten, die die Charakteristika des Wertebereichs beschreiben, und einigen speziellen Werten oder lexikalischen Einträgen .

previous sub-sectionnext sub-section2.2 Wertebereich

[Definition:] Ein Wertebereich ist eine Menge von Werten zu einem gegebenen Datentyp. Jeder Wert im Wertebereich eines Datentyps ist durch ein oder mehrere Literale im lexikalischen Bereich bezeichnet. Der Wertebereich eines Datentyps kann auch auf eine der folgenden Arten definiert werden:

Wertebereiche haben bestimmte Eigenschaften, wie z. B. die Kardinalität, eine geeignete Definition von Gleichheit und können eventuell geordnet sein, so dass es möglich wird, Werte innerhalb des Wertebereichs zu vergleichen. Eigenschaften von Wertebereichen in dieser Spezifikation sind in Grundlegende Fassetten (§2.4.1) definiert.

previous sub-sectionnext sub-section2.3 Lexikalischer Bereich

Zusätzlich zum Wertebereich hat jeder Datentyp einen lexikalischen Bereich.

[Definition:] Ein lexikalischer Bereich ist eine Menge von zulässigen Literalen für einen Datentyp.

Zum Beispiel sind "100" und "1.0E2" zwei verschiedene Literale aus dem lexikalischen Bereich von float, die beide denselben Wert beschreiben. Das Typsystem in dieser Spezifikation stellt einen Mechanismus für Schema-Designer bereit, um die Menge der Werte und die korrespondierende Menge von zulässigen Literalen zu diesen Werten des Datentyps zu kontrollieren.

Anmerkung:

Die Literale in den lexikalischen Bereichen in dieser Spezifikation besitzen folgende Charakteristika:
Interoperabilität:
Die Anzahl der Literale zu jedem Wert wurde klein gehalten: Es gibt eine Eins-zu-eins-Abbildung zwischen Literalen und Werten für jeden Datentyp. Damit ist es einfach, Werte zwischen verschiedenen Systemen auszutauschen. In vielen Fällen sind Konvertierungen zwischen unterschiedlichen Repräsentationen sowohl auf dem Ursprungssystem der Daten als auch auf dem Empfängersystem notwendig, sei es zur Verarbeitung oder zur Benutzerinteraktion.
Grundsätzliche Lesbarkeit:
Statt einer binären Darstellung werden textuelle Literale eingesetzt. Damit kann man diese von Hand editieren, debuggen usw.
Einfaches Parsen und Serialisieren:
Wenn möglich sind Literale ähnlich gestaltet wie in Programmiersprachen und Bibliotheken.

2.3.1 Kanonische lexikalische Repräsentation

Während die meisten in dieser Spezifikation definierten Datentypen nur eine einzige lexikalische Repräsentation besitzen, d.h. jeder Wert im Wertebereich eines Datentyps ist nur durch ein einziges Literal in seinem lexikalischen Bereich bezeichnet, muss das jedoch nicht immer der Fall sein. Das Beispiel aus dem vorigen Abschnitt zeigt zwei Literale für den Datentyp float, die beide denselben Wert darstellen. Ähnlich sieht es beim Datum aus, es kann einige Literale geben, die dieselbe Zeit in unterschiedlichen Zeitzonen bezeichnen.

[Definition:] Eine kanonische lexikalische Repräsentation ist eine Menge von Literalen aus der Menge von gültigen Werten zu einem Datentyp, die so gewählt ist, dass es eine 1:1-Abbildung zwischen den Literalen der kanonischen lexikalischen Repräsentation und Werten aus dem Wertebereich gibt.

previous sub-sectionnext sub-section2.4 Fassetten

[Definition:] Eine Fassette ist ein Aspekt der Definition des Wertebereichs. Allgemein gesagt, jede Fassette charakterisiert einen Wertebereich entlang unabhängiger Achsen oder Dimensionen.

Die Fassetten eines Datentyps dienen dazu, diejenigen Aspekte eines Datentyps voneinander zu trennen, die sich von denen anderer Datentypen unterscheiden. Statt einen Datentyp in einer textuellen Beschreibung zu definieren, sind die Datentypen in dieser Spezifikation durch die Synthese der Fassetten definiert, die zusammen den Wertebereich und die Eigenschaften des jeweiligen Datentyps bestimmen.

Es gibt zwei Arten von Fassetten: grundlegende Fassetten, die den Datentyp definieren, und nicht grundlegende oder einschränkende Fassetten, die die zulässigen Werte eines Datentyps reglementieren.

2.4.1 Grundlegende Fassetten

[Definition:] Eine grundlegende Fassette ist eine abstrakte Eigenschaft, die dazu dient, den Wert eines Wertebereichs semantisch zu charakterisieren.

Alle grundlegenden Fassetten werden vollständig in Grundlegende Fassetten (§4.2) beschrieben.

2.4.2 Einschränkende oder nicht grundlegende Fassetten

[Definition:] Eine einschränkende Fassette ist eine optionale Eigenschaft, die bei einem Datentyp gesetzt werden kann, um seinen Wertebereich einzuschränken.

Die Einschränkung des Wertebereichs wirkt sich konsequenterweise auch auf den lexikalischen Bereich einschränkend aus. Das Hinzufügen von einschränkenden Fassetten zu einem Basistyp ist in Ableitung durch Einschränkung (§4.1.2.1) beschrieben.

Alle einschränkenden Fassetten werden vollständig in Einschränkende Fassetten (§4.3) beschrieben .

previous sub-section2.5 Gegenüberstellung von Datentypen

Es ist sinnvoll, die in dieser Spezifikation definierten Datentypen entlang verschiedener Dimensionen zu kategorisieren und somit eine Menge von Charakterisierungs-Dichotomien zu bilden.

2.5.1 Atomare Datentypen, Listen- und Vereinigungs-Datentypen

Als Erstes muss zwischen atomaren, Listen- und Vereinigungs-Datentypen unterschieden werden.

Zum Beispiel könnte ein einzelnes Token, das dem aus [XML 1.0 (Second Edition)] stammenden Nmtokenentspricht, einen Wert aus dem Wertebereich eines atomaren Datentyps (NMTOKEN) annehmen, während eine Sequenz solcher Tokens den Wert eines Listen-Datentyps (NMTOKENS) annehmen könnte.

2.5.1.1 Atomare Datentypen

Atomare Datentypen können entweder primitive oder abgeleitete Datentypen sein. Der Wertebereich eines atomaren Datentyps ist eine Menge von "atomaren" Werten, die für diese Spezifikation nicht weiter teilbar sind. Der lexikalische Bereich eines atomaren Datentyps ist eine Menge von Literalen, deren interne Struktur vom jeweiligen Datentyp abhängt.

2.5.1.2 Listen-Datentypen

Einige Typsysteme (wie diejenigen, die in [ISO 11404] beschrieben sind), behandeln Listen-Datentypen als Spezialfälle der allgemeineren Begriffe Aggregat oder Kollektion.

Listen sind stets abgeleitete Datentypen. Der Wertebereich einer Liste ist eine Menge von endlichen Sequenzen atomarer Werte. Der lexikalische Bereich einer Liste ist die Menge von Literalen, deren interne Struktur aus der durch Leerräume getrennten Sequenz von Literalen der atomaren Datentypen der Einträge der Liste aufgebaut ist (wobei die Leerräume S in [XML 1.0 (Second Edition)]entsprechen).

[Definition:] Der atomare Datentyp, der an der Definition einer Liste beteiligt ist, wird als itemType dieser Liste bezeichnet.

Beispiel
  <simpleType name="Größe">
    <list itemType="decimal" />
  </simpleType>

  <PackungsGrößen xsi:type="Größe">100 250 1000</PackungsGrößen>

Eine Liste kann von einem atomaren Datentyp abgeleitet werden, dessen lexikalischer Bereich Leerräume zulässt (wie z. B. string oder anyURI). In solch einem Fall werden die Einträge der Liste trotzdem unabhängig von der Eingabe durch Leerräume getrennt.

Beispiel
  <simpleType name="ListeVonZeichenketten">
    <list itemType="string" />
  </simpleType>
  <meineListe xsi:type="ListeVonZeichenketten">
    Das ist nicht der Listeneintrag 1
    Das ist nicht der Listeneintrag 2
    Das ist nicht der Listeneintrag 3
  </meineListe>
Die Liste meineListe im Beispiel oben besteht nicht aus drei, sondern aus 18 Einträgen, d.h. der Wert des Elements meineListe ist nicht eine Liste der Länge 3 sondern der Länge 18.

Ist ein Datentyp von einem Listen-Datentyp abgeleitet, dann sind die folgenden einschränkenden Fassetten anwendbar:

Für length, maxLength und minLength wird die Einheit der Länge als Anzahl von Listeneinträgen gemessen. Der Wert von whiteSpace wird unveränderbar (fixed) auf den Wert collapse festgesetzt.

Die kanonische lexikalische Repräsentation eines Listen-Datentyps ist als die lexikalische Form definiert, nach der jedes Element der Liste die kanonische lexikalische Repräsentation des itemType hat.

2.5.1.3 Vereinigungs-Datentypen

Der Wertebereich und der lexikalische Bereich einer Vereinigung entsprechen der Vereinigung der Wertebereiche und der lexikalischen Bereiche der an der Vereinigung beteiligten memberTypes. Nach dem aktuellen Stand gibt es keine vordefiniertenVereinigungs-Datentypen.

Beispiel
Ein prototypisches Beispiel für einen Vereinigungs-Datentyp ist das maxOccurs Attribut des Elements element in XML Schema selbst: Es stellt die Vereinigung aus nonNegativeInteger und einer Aufzählung mit einem einzigen Eintrag, der Zeichenkette "unbounded", dar, wie das folgende Beispiel zeigt:
  <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger"
        default="1"/>
    <attribute name="maxOccurs">
      <simpleType>
        <union>
          <simpleType>
            <restriction base="nonNegativeInteger"/>
          </simpleType>
          <simpleType>
            <restriction base="string">
              <enumeration value="unbounded"/>
            </restriction>
          </simpleType>
        </union>
      </simpleType>
    </attribute>
  </attributeGroup>

Ein Vereinigungs-Datentyp kann aus beliebig vielen (mindestens 2) atomaren oder Listen-Datentypen bestehen.

[Definition:] Datentypen, die Teil der Definition eines Vereinigungs-Datentyps sind, nennt man memberTypes des Vereinigungs-Datentyps.

Die Reihenfolge, in der die jeweiligen memberTypes bei der Definition angegeben werden, ist signifikant. D.h. die Reihenfolge, der <simpleType>-Kindelemente im <union>-Element bzw. die Reihenfolge der QNames im Attribut memberTypes ist keinesfalls gleichgültig. Bei der Validierung wird ein zu validierendes Element oder der Wert eines Attributs entlang dieser Reihenfolge gegen die memberTypes geprüft, bis es zu einer Übereinstimmung kommt. Die Reihenfolge, nach der ausgewertet werden soll, kann mit dem Attribut xsi:type geändert werden.

Beispiel
Als Beispiel sei die folgende Definition gegeben: Die erste Instanz des Elements <size> wird richtig als integer (§3.3.13) validiert, die zweite und dritte als string (§3.2.1).
  <xsd:element name='size'>
    <xsd:simpleType>
      <xsd:union>
        <xsd:simpleType>
          <xsd:restriction base="integer"/>
        </xsd:simpleType>
        <xsd:simpleType>
          <xsd:restriction base="string"/>
        </xsd:simpleType>
      </xsd:union>
    </xsd:simpleType>
  </xsd:element>
  <size>1</size>
  <size>large</size>
  <size xsi:type="xsd:string">1</size>

Die kanonische lexikalische Repräsentation eines Vereinigungs-Datentyps ist definiert als die lexikalische Form, in der die Werte die kanonische lexikalische Repräsentation des verwendeten memberTypes haben.

Anmerkung:

Ein in dieser Spezifikation als atomar bezeichneter Datentyp muss nicht gleichzeitig ein "atomarer" Datentyp in der Programmiersprache sein, die diese Spezifikation umsetzt. Ebenso muss ein Listen-Datentyp nicht einem "Listen"-Datentyp in der Programmiersprache entsprechen, in der diese Spezifikation implementiert wird. Des Weiteren muss auch ein Vereinigungs-Datentyp nicht durch einen "Vereinigungs"-Datentyp der Programmiersprache realisiert sein, die zur Implementierung dieser Spezifikation verwendet wird.

2.5.2 Primitive und abgeleitete Datentypen

Im Folgenden werden die Unterschiede zwischen primitiven und abgeleiteten Datentypen erläutert.

  • [Definition:] Primitive Datentypen sind nicht durch andere Datentypen definiert; sie existieren von Anfang an.
  • [Definition:] Abgeleitete Datentypen sind durch andere Datentypen definiert.

So beruht z. B. float in dieser Spezifikation auf dem wohl bekannten und definierten mathematischen Konzept, das nicht durch andere Datentypen ausgedrückt werden kann, während integer den Spezialfall des allgemeineren Datentyps decimal darstellt.

[Definition:] Es gibt einen konzeptionellen Datentyp mit dem Namen anySimpleType. Dabei handelt es sich um die einfache Version der Urtyp-Definition aus [XML Schema Part 1: Structures]. anySimpleType kann als Basistyp für alle primitiven Datentypen verstanden werden. Der Wertebereich von anySimpleType entspricht der Vereinigung der Wertebereiche aller primitiven Datentypen.

Diese Spezifikation definiert sowohl primitive als auch abgeleitete Datentypen. Es wird davon ausgegangen, dass eine sorgfältig ausgesuchte Menge von primitiven Datentypen den meisten Benutzern in der angebotenen Form ausreicht und genauso benutzt werden kann, auf der anderen Seite aber auch als eine breite Basis dient, von der die enorme Vielfalt von Datentypen abgeleitet werden kann, die von Schema-Entwicklern benötigt wird.

In obigem Beispiel ist integer von decimalabgeleitet.

Anmerkung:

Ein in dieser Spezifikation als primitiver Datentyp bezeichneter Datentyp muss in einer Programmiersprache, die zur Implementierung dieser Spezifikation verwendet wird, kein "primitiver" Datentyp sein. Ebenso muss ein abgeleiteter Datentyp in einer Programmiersprache, die zur Realisierung dieser Spezifikation benutzt wird, nicht unbedingt ein "abgeleiteter" Datentyp sein.

Wie in XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen (§4.1.2) genauer beschrieben, muss jeder benutzerdefinierte Datentyp auf eine der drei folgenden Arten durch andere Datentypen ausgedrückt werden: 1) durch Zuweisen von einschränkenden Fassetten, die dazu dienen, den Wertebereich des benutzerdefinierten Datentyps auf eine Untermenge des Wertebereichs des Basistypseinzuschränken; 2) durch die Erzeugung eines Listen -Datentyps, dessen Wertebereich aus einer endlichen Sequenz von Werten des itemType besteht; oder 3) durch die Erzeugung eines Vereinigungs-Datentyps, dessen Wertebereich aus Vereinigung der Wertebereiche der memberTypes besteht.

2.5.2.1 Ableitung durch Einschränkung

[Definition:] Man sagt, ein Datentyp ist durch Einschränkung aus einem anderen Datentyp abgeleitet, wenn Werte für null oder mehr einschränkende Fassetten spezifiziert sind, die dazu dienen, den Wertebereich und/oder den lexikalischen Bereich auf eine Untermenge von denen seines Basistyps einzuschränken.

[Definition:] Jeder Datentyp, der durch Einschränkung abgeleitet wurde, ist durch einen anderen Datentyp definiert, der als Basistyp bezeichnet wird. Basistypen können sowohl primitiv als auch abgeleitet sein.

2.5.2.2 Ableitung durch Auflistung

Ein Listen-Datentyp kann von einem anderen Datentyp (seinem itemType) abgeleitet werden, in dem ein Wertebereich erzeugt wird, der aus der endlichen Sequenz der Werte seines itemType besteht.

2.5.2.3 Ableitung durch Vereinigung

Ein Datentyp kann von einem oder mehreren Datentypen abgeleitet werden, in dem man deren Wertebereiche und konsequenterweise auch deren lexikalische Bereichevereinigt.

2.5.3 Vordefinierte (built-in) und benutzerdefinierte Datentypen

Konzeptionell gibt es keinen Unterschied zwischen den vordefiniertenabgeleiteten Datentypen dieser Spezifikation und den von Schema-Designern erzeugten benutzerdefinierten Datentypen. Die vordefiniertenabgeleiteten Datentypen sind von so allgemeiner Natur, dass Schema-Designer diese "nachbauen" würden, wenn es sie nicht gäbe. Außerdem lässt sich anhand dieser abgeleiteten Datentypen dieser Spezifikation demonstrieren, wie der Ablauf der Erzeugung von Datentypen und Eigenschaften der Datentypen dieser Spezifikation funktioniert.

Anmerkung:

Ein in dieser Spezifikation als vordefiniert bezeichneter Datentyp muss in einer zur Implementierung dieser Spezifikation verwendeten Programmiersprachen nicht "vordefiniert" sein. Ebenso muss ein in dieser Spezifikation benutzerdefinierter Datentyp in einer Programmiersprache, die dazu benutzt wird, diese Spezifikation umzusetzen, nicht "benutzerdefiniert" sein.

3 Vordefinierte Datentypen

Diagram of built-in type hierarchy Notation Declaration Schema ComponentSchema ComponentElement Declaration Schema ComponentIdentity Constraint Definition Schema ComponentModel Group Definition Schema ComponentSimple Type Definition Schema ComponentComplex Type Definition Schema ComponentParticle Schema ComponentModel Group Schema ComponentAttribute Use Schema ComponentWildcard Schema ComponentAttribute Declaration Schema ComponentAttribute Group Definition Schema ComponentSchema Components

Alle vordefinierten Datentypen aus dieser Spezifikation (sowohl die primitiven als auch die abgeleiteten) können durch eine eindeutige URI-Referenz adressiert werden, die wie folgt aufgebaut ist:

  1. Der Basis-URI entspricht der URI des XML-Schema-Namensraums
  2. Der Fragment-Bezeichner ist der Name des Datentyps

Um zum Beispiel den Datentyp int zu adressieren, lautet der URI

Zusätzlich lässt sich jedes Element, das eine Fassette eines Datentyps definiert, ebenfalls durch einen eindeutigen URI adressieren, der wie folgt aufgebaut ist:

  1. Der Basis-URI entspricht dem URI des XML-Schema-Namensraums.
  2. Der Fragment-Bezeichner ist der Name der Fassette.

Die Adressierung der maxInclusive-Fassette sieht z. B. folgendermaßen aus:

Analog läßt sich jede Verwendung einer Fassette in einer vordefinierten Datentypdefinition durch einen eindeutigen URI adressieren, der folgendermaßen aussieht:

  1. Der Basis-URI entspricht der URI des XML-Schema-Namensraums
  2. Der Fragment-Bezeichner ist der Name des Datentyps gefolgt von einem Punkt (".") und dem Namen der Fassette

Die Adressierung der Verwendung der maxInclusive-Fassette in der Definition von int sieht z. B. folgendermaßen aus:

next sub-section3.1 Hinweise zu Namensräumen

Die in dieser Spezifikation definierten vordefinierten Datentypen wurden dafür entworfen, sowohl zusammen mit der XML Schema Definitions-Sprache als auch in anderen XML-Spezifikationen eingesetzt werden zu können. Um den Umgang mit der XML Schema Definitions-Sprache zu erleichtern, haben die vordefinierten Datentypen in dieser Spezifikation den Namensraum:

Zur Erleichterung des Einsatzes der vordefinierten Datentypen in anderen Spezifikationen außerhalb der XML Schema Definitions-Sprache ist jeder vordefinierte Datentyp auch in dem Namensraum mit dem folgendem URI definiert:

Dieser Namensraum gilt sowohl für vordefinierteprimitive als auch für vordefinierteabgeleitete Datentypen.

Jeder benutzerdefinierte Datentyp ist auch einem eindeutigen Namensraum zugeordnet. Allerdings kommen benutzerdefinierte Datentypen nicht aus dem in dieser Spezifikation definierten Namensraum; im Gegenteil, sie stammen aus dem Namensraum des Schemas, in welchem sie definiert wurden (siehe XML Darstellung von Schematas in [XML Schema Part 1: Structures]).

previous sub-sectionnext sub-section3.2 Primitive Datentypen

3.2.1 string
3.2.2 boolean
3.2.3 decimal
3.2.4 float
3.2.5 double
3.2.6 duration
3.2.7 dateTime
3.2.8 time
3.2.9 date
3.2.10 gYearMonth
3.2.11 gYear
3.2.12 gMonthDay
3.2.13 gDay
3.2.14 gMonth
3.2.15 hexBinary
3.2.17 anyURI
3.2.18 QName
3.2.19 NOTATION

Die in dieser Spezifikation definierten primitiven Datentypen werden im Folgenden näher erläutert. Zu jedem Datentyp wird dessen Wertebereich und lexikalischer Bereich definiert, einschränkende Fassetten aufgeführt und jeder davon abgeleitete Datentyp wird spezifiziert.

Das Hinzufügen weiterer primitiver Datentypen ist nur durch neue Versionen dieser Spezifikation möglich.

3.2.1 string

[Definition:] Der Datentyp string repräsentiert Zeichenketten in XML. Der Wertebereich des Datentyps string ist die Menge von Sequenzen endlicher Länge von Zeichen (wie in [XML 1.0 (Second Edition)] definiert), die der Char-Produktion aus [XML 1.0 (Second Edition)] entsprechen. Ein Zeichen ist eine atomare Kommunikationseinheit und ist nicht genauer spezifiziert, außer anzumerken, dass jedes Zeichen zu einer Kodierung des Universal Character Sets korrespondiert, die jeweils durch eine ganze Zahl vom Typ Integer dargestellt wird.

Anmerkung:

Viele Sprachen besitzen Schriftsysteme, in denen Kindelemente benötigt werden, um zum Beispiel Aspekte wie das bidirektionale Formatieren oder Ruby-Annotationen (siehe [Ruby] und Abschnitt 8.2.4 Überschreiben des bidirektionalen Algorithmus: das BDO Element) zu steuern. Als einfacher Datentyp, der nur Zeichen und keine Kindelemente enthalten kann, ist string daher oft zur Darstellung von Texten nicht geeignet. In solchen Fällen sollte stattdessen ein komplexer Datentyp benutzt werden, der ein gemischtes Inhaltsmodell zulässt. Weitere Informationen findet man in Abschnitt 5.5 Any Element, Any Attribut der [XML Schema Language: Part 2 Primer].

Anmerkung:

Wie in geordnet angemerkt, bedeutet die Tatsache, dass diese Spezifikation keine Ordnungsbeziehung auf den Datentyp string definiert, nicht, dass Anwendungen Zeichenketten als nicht geordnet behandeln müssen.
3.2.1.1 Einschränkende Fassetten

string hat die folgenden beschränkenden Fassetten :

3.2.1.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von string:

3.2.2 boolean

[Definition:] Der Wertebereich von boolean dient dazu, das mathematische Konzept einer zweiwertigen Logik abzubilden: {true, false}.

3.2.2.1 Lexikalische Repräsentation

Eine Instanz des Datentyps boolean kann durch die gültigen Literale {true, false, 1, 0} beschrieben werden.

3.2.2.2 Kanonische Repräsentation

Die kanonische Repräsentation für boolean ist die Menge der Literale {true, false}.

3.2.2.3 Einschränkende Fassetten

boolean hat die folgenden beschränkenden Fassetten :

3.2.3 decimal

[Definition:] Der Datentyp decimal stellt Dezimalzahlen beliebiger Genauigkeit dar. Der Wertebereich von decimal ist die Menge aller Werte i × 10^-n, wobei i und n ganze Zahlen sind mit n >= 0. Die Ordnungsbeziehung auf den Datentyp decimal lautet: x < y wenn y - x positiv ist.

[Definition:] Der Wertebereich eines von decimal abgeleiteten Datentyps mit einem Wert für totalDigits von p ist die Menge der Werte i × 10^-n, wobei n und i ganze Zahlen sind mit p >= n >= 0 und die Anzahl der signifikanten Dezimalstellen in i ist kleiner oder gleich p.

[Definition:] Der Wertebereich eines von decimal abgeleiteten Datentyps mit einem Wert für fractionDigits von s ist die Menge der Werte i × 10^-n, wobei i und n ganze Zahlen sind mit 0 <= n <= s.

Anmerkung:

Sämtliche Prozessoren mit minimaler Unterstützung müssen Zahlen vom Datentyp decimal mit mindestens 18 Dezimalstellen unterstützen (d.h. mit totalDigits von 18). Allerdings dürfen Prozessoren mit minimaler Unterstützung eine anwendungsorientierte Limitierung der maximalen Anzahl an Dezimalstellen, die sie unterstützen, setzen. Für diesen Fall muss diese anwendungsorientierte maximale Anzahl klar dokumentiert sein.
3.2.3.1 Lexikalische Repräsentation

Die lexikalische Repräsentation des Datentyps decimal besteht aus einer endlichen Sequenz von Ziffern (#x30-#x39) getrennt durch einen Punkt, der sie als Dezimalzahl kenntlich macht. Falls die Fassette totalDigits spezifiziert ist, darf die Anzahl der Ziffern nur kleiner oder gleich wie in totalDigits sein. Ist die Fassette fractionDigits spezifiziert, muss die Anzahl der rechts vom Punkt stehenden Ziffern kleiner oder gleich der Anzahl der fractionDigits sein. Ein Vorzeichen ist erlaubt, aber nicht erforderlich. Ist kein Vorzeichen vorhanden, wird "+" angenommen. Führende und nachfolgende Nullen sind ebenfalls optional. Ist der Bruchteil Null, können sowohl der Punkt als auch die nachfolgenden Nullen rechts vom Punkt weggelassen werden. Beispiele: -1.23, 12678967.543233, +100000.00, 210

3.2.3.2 Kanonische Repräsentation

Die kanonische Repräsentation von decimal ist definiert, indem einige der in der Lexikalische Repräsentation (§3.2.3.1) vorhandenen Optionen verboten werden. Insbesondere ist ein führendes "+"-Zeichen nicht gestattet. Ein Dezimalpunkt ist zwingend. Führende oder nachfolgende Nullen sind nicht zulässig bis auf folgende Ausnahme: Sowohl rechts als links vom Punkt muss mindestens eine Ziffer stehen, die jedoch Null sein darf.

3.2.3.4 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von decimal:

3.2.4 float

[Definition:] float entspricht dem einfach-genauen IEEE 32-Bit Datentyp einer Gleitkommazahl [IEEE 754-1985]. Der grundlegende Wertebereich von float setzt sich aus den Werten m × 2^e zusammen, wobei m vom Datentyp integer ist, mit dem Absolutwert kleiner als 2^24, und e eine ganze Zahl zwischen -149 und 104, die Grenzen eingeschlossen. Zusätzlich zum gerade beschriebenen Wertebereich enthält der Wertebereich von float noch die folgenden speziellen Werte: die positive und negative Null, plus und minus unendlich sowie den Wert not-a-number (keine-Zahl). Die Ordnungsbeziehung auf den Datentyp float ist: x < y wenn y - x positiv ist. Die positive Null ist größer als die negative Null. Not-a-number ist nur mit sich selbst gleich und größer als alle anderen float-Werte einschließlich plus unendlich.

Ein Literal im lexikalischen Bereich, das eine Dezimalzahl d darstellen soll, wird auf den normalisierten Wert im Wertebereich von float abgebildet, der d im Sinne von [Clinger, WD (1990)] am nächsten liegt; liegt d exakt zwischen zwei solchen Werten, dann wird der gerade Wert gewählt.

3.2.4.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von float-Werten besteht aus der Mantisse gefolgt von einem optionalen Buchstaben "e" oder "E" und einem Exponenten. Der Exponent muss vom Typ integer sein und die Mantisse vom Typ decimal. Die Darstellung von Exponent und Mantisse muss den lexikalischen Regeln für integer und decimal genügen. Wenn das "E" bzw. "e" und der nachfolgende Exponent fehlen, wird der Wert des Exponenten mit 0 angenommen.

Die lexikalischen Repräsentationen für die speziellen Werte positive und negative Null, plus und minus unendlich und not-a-number lauten 0, -0, INF, -INF und NaN.

Die folgenden Literale sind gültige Beispiele für float: -1E4, 1267.43233E12, 12.78e-2, 12 und INF

3.2.4.2 Kanonische Repräsentation

Die kanonische Repräsentation von float wird definiert, indem einige der in der Lexikalische Repräsentation (§3.2.4.1) vorhandenen Optionen verboten werden. Insbesondere muss der Exponent durch ein großes "E" eingeleitet werden. Führende Nullen und das vorangestellte optionale "+"-Zeichen sind im Exponenten nicht erlaubt. Das vorangestellte optionale "+"-Zeichen ist in der Mantisse nicht erlaubt und der Dezimalpunkt ist zwingend vorgeschrieben. Führende und folgende Nullen sind nicht gestattet, mit folgenden Ausnahmen: Zahlendarstellungen müssen nomalisiert sein, so dass links vom Dezimalpunkt genau eine Ziffer steht und mindestens eine Ziffer rechts vom Dezimalpunkt.

3.2.5 double

[Definition:] double entspricht dem doppelt-genauen IEEE 64-Bit-Datentyp einer Gleitkommazahl [IEEE 754-1985]. Der grundlegende Wertebereich von double setzt sich aus Werten der Form m × 2^e zusammen, dabei ist m vom Datentyp Integer mit einem Absolutwert, der kleiner ist als 2^53, und e ist ein Integer-Wert zwischen -1075 und 970, die Grenzen eingeschlossen. Zusätzlich enthält der Wertebereich des Datentyps double noch die folgenden speziellen Werte: eine positive und negative Null, minus und plus unendlich und not-a-number. Die Ordnungsbeziehung auf double lautet: x < y wenn y - x positiv ist. Die positive Null ist größer als die negative Null. Not-a-number ist nur mit sich selbst gleich und größer als alle anderen double-Werte einschließlich plus unendlich.

Ein Literal im lexikalischen Bereich repräsentiert eine Dezimalzahl d, die auf einen normalisierten Wert im Wertebereich des Datentyps double abgebildet wird, der am nächsten bei d liegt; liegt d genau zwischen zwei solchen Werten, wird der gerade Wert gewählt. Dies ist die beste Näherung von d ([Clinger, WD (1990)], [Gay, DM (1990)]), die genauer ist als die in [IEEE 754-1985] geforderte Abbildung.

3.2.5.1 Lexikalische Repräsentation

Ein Wert des Datentyps double besteht aus einer Mantisse, gefolgt von einem optionalen durch ein "E" oder "e" eingeleiteten Exponenten. Der Exponent muss vom Datentyp integer sein. Die Mantisse muss eine Dezimalzahl sein. Die Darstellungen für Mantisse und Exponent müssen den lexikalischen Regeln für integer und decimal gehorchen. Fehlen das "E" bzw. "e" und der folgende Exponent, wird 0 als Exponent angenommen.

Die speziellen Werte positive und negative Null, plus und minus unendlich sowie not-a-number haben die folgende lexikalische Repräsentation: 0, -0, INF, -INF und NaN.

Die folgenden Beispiele sind legale Literale für double: -1E4, 1267.43233E12, 12.78e-2, 12 und INF

3.2.5.2 Kanonische Repräsentation

Die kanonische Repräsentation von double ist definiert, indem einige der in der Lexikalische Repräsentation (§3.2.5.1) vorhandenen Optionen verboten werden. Insbesondere muss der Exponent durch ein großes "E" eingeleitet werden. Führende Nullen und vorangestellte optionale "+"-Zeichen sind im Exponenten nicht erlaubt. Das vorangestellte optionale "+"-Zeichen ist in der Mantisse nicht erlaubt und der Dezimalpunkt ist zwingend vorgeschrieben. Vorangestellte und nachfolgende Nullen sind nicht erlaubt, mit folgenden Ausnahmen: Zahlendarstellungen müssen in der Form normalisiert werden, so dass links vom Dezimalpunkt genau eine Ziffer und mindestens eine Ziffer rechts vom Dezimalpunkt steht.

3.2.6 duration

[Definition:] : Der Datentyp duration stellt eine Zeitdauer dar. Der Wertebereich von duration ist ein sechsdimensionaler Raum. Die einzelnen Koordinatenteile bezeichnen das gregorianische Jahr, Monat, Tag, Stunde, Minute und Sekunde, die in §5.5.3.2 in [ISO 8601] definiert sind. Diese Komponenten sind nach ihrer Signifikanz geordnet, z. B. Jahr, Monat, Tag, Stunde, Minute, Sekunde.

3.2.6.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von duration ist das in [ISO 8601] beschriebene erweiterte Format PnYn MnDTnH nMnS. Dabei stellt nY die Anzahl an Jahren, nM die Anzahl an Monaten und nD die Anzahl an Tagen dar. "T" trennt die Datums- und Zeitangabe. Die Anzahl an Stunden wird durch nH, die der Minuten durch das zweite nM und die der Sekunden durch nS dargestellt. Die Angabe zu Sekunden kann ggf. auch Dezimalstellen enthalten und so beliebige Genauigkeiten erreichen.

Die Werte zu Jahr, Monat und Tag, Stunde und Minute sind nicht eingeschränkt, sondern erlauben einen beliebigen Integer-Wert. Der Wert für Sekunden kann ein beliebiger Dezimalwert sein. D.h. die lexikalische Repräsentation von duration entspricht nicht dem in §5.5.3.2.1 von [ISO 8601] vorgestellten Format.

Um negative Zeitspannen darzustellen, kann einem duration-Wert ein Minuszeichen vorangestellt werden. Fehlt das Minuszeichen, handelt es sich um eine positive Zeitdauer. Vgl. auch ISO 8601 Datums- und Zeit-Formate (§D).

Um beispielsweise die Zeitspanne von 1 Jahr, 2 Monaten, 3 Tagen, 10 Stunden und 30 Minuten darzustellen, würde die entsprechende Angabe wie folgt aussehen: P1Y2M3DT10H30M. Eine Zeitspanne von -120 Tagen hätte folgende Form: -P120D.

Es ist möglich, die Genauigkeit herabzusetzen oder die Darstellung zu verkürzen, solange folgende Bedingungen erfüllt sind:

  • Sind die Angaben zu Jahren, Monaten, Tagen, Stunden, Minuten oder Sekunden Null, können sie und ihr Bezeichner (z. B. Y nach der Jahresangabe) weggelassen werden. Es muss mindestens eine Angabe mit Bezeichner vorhanden sein.
  • Der Sekundenanteil kann durch einen Dezimalbruch angegeben werden.
  • Der T-Bezeichner sollte nicht erscheinen, wenn es keine Zeitangaben (Stunde, Minute, Sekunde) gibt. Der P-Bezeichner ist zwingend erforderlich.
Beispiele
P1347Y, P1347M, P1Y2MT2H erlaubt
P0Y1347M, P0Y1347M0D erlaubt
P-1347M, P1Y2MT nicht erlaubt
-P1347M erlaubt
3.2.6.2 Ordnungsbeziehung auf duration

Generell gibt die Ordnungsbeziehung auf duration nur eine partielle Ordnung an, denn zwischen bestimmten Zeitspannen, wie zum Beispiel einem Monat, gibt es keine festgelegte Beziehung, z. B. ein Monat (P1M) und 30 Tage (P30D). Die Ordnungsbeziehung zwischen zwei Zeitspannen x und y ist: x < y, wenn s+x < s+y für jeden qualifizierten Zeitstempel (dateTime) s aus der Liste unten gilt. Die Werte für s verursachen die größten Abweichungen beim Addieren von Zeitstempeln (dateTime) und Zeitspannen (duration). Die Addition von Zeitspannen und Zeitpunkten ist in "Addtion von Zeitspannen und Zeitpunkten" definiert (Addition von Zeitspannen zu Zeitpunkten (§E)).

  • 1696-09-01T00:00:00Z
  • 1697-02-01T00:00:00Z
  • 1903-03-01T00:00:00Z
  • 1903-07-01T00:00:00Z

Die folgende Tabelle zeigt die stärkste festlegbare Beziehung zwischen verschiedenen Beispielzeitspannen. Das Symbol < > bedeutet, dass die Ordnungsbeziehung nicht festgelegt ist. {Beachten sie, dass das Sekunden-Feld wegen der Schaltsekunden zwischen 59 und 60 variieren kann.} Durch die in §E definierte Addition von Zeitspannen und Zeitpunkten sind diese immer noch geordnet.

Relation
P1Y > P364D <> P365D <> P366D < P367D
P1M > P27D <> P28D <> P29D <> P30D <> P31D < P32D
P5M > P149D <> P150D <> P151D <> P152D <> P153D < P154D

Implementierungen ist es freigestellt, Optimierungen bei der Berechnung der Ordnungsbeziehung vorzunehmen. So könnte beispielsweise die folgende Tabelle dazu verwendet werden, Zeitintervalle über eine kleine Anzahl von Monaten mit deren Länge in Tagen zu vergleichen.

Months 1 2 3 4 5 6 7 8 9 10 11 12 13 ...
Days Minimum 28 59 89 120 150 181 212 242 273 303 334 365 393 ...
Maximum 31 62 92 123 153 184 215 245 276 306 337 366 397 ...
3.2.6.3 Fassetten von Zeitspannen vergleichen

Beim Vergleich von duration-Werten, die minInclusive-, minExclusive-, maxInclusive- und maxExclusive-Fassetten besitzen, sollten nicht definierte Vergleiche als "false" angesehen werden.

3.2.6.4 Total geordnete Zeitspannen

Für einige der von duration abgeleiteten Datentypen kann die Existenz einer totalen Ordnung garantiert werden. Damit dies gilt, dürfen sie lediglich aus den Feldern bestehen, die in nur einer Zeile der folgenden Liste aufgeführt sind, und das Angeben der Zeitzone muss entweder zwingend erforderlich oder verboten sein.

  • Jahr, Monat
  • Tag, Stunde, Minute, Sekunde

Beispielsweise könnte ein Datentyp als Entsprechung für das in [SQL] definierte Jahr-Monat-Intervall definiert werden. Dieses besteht lediglich aus einer vierstelligen Jahreszahl und einer zweistelligen Monatszahl, alle anderen Felder sind nicht spezifiziert. Dieser Datentyp könnte wie unten definiert sein und würde eine totale Ordnung haben.

<simpleType name="SQL-Year-Month-Interval">
    <restriction base="duration">
      <pattern value="P\p{Nd}{4}Y\p{Nd}{2}M"/>
    </restriction>
</simpleType>
3.2.6.5 Einschränkende Fassetten

duration hat die folgenden beschränkenden Fassetten :

3.2.7 dateTime

[Definition:] dateTime stellt einen spezifischen Zeitpunkt dar. Der Wertebereich von dateTime entspricht dem Raum von möglichen Kombinationen aus Datum und Tageszeit wie in §5.4 von [ISO 8601] definiert.

3.2.7.1 Lexikalische Repräsentation

Eine der in [ISO 8601] erlaubten lexikalischen Repräsentationen wird als lexikalische Repräsentation für dateTime verwendet. Dabei handelt es sich um das erweiterte Format aus [ISO 8601] CCYY-MM-DDThh:mm:ss. "CC" steht für das Jahrhundert (engl. Century), "YY" für das Jahr, "MM" für den Monat und "DD" für den Tag. Der Buchstabe "T" dient als Trennzeichen zwischen Datum und Zeit. Stunden, Minuten und Sekunden werden durch "hh", "mm" und "ss" repräsentiert. Zusätzliche Ziffern sind möglich, um bei Bedarf die Genauigkeit der Sekunden durch weitere Dezimalstellen nach dem Punkt zu erhöhen. Z.B. ss.ss... Es sind beliebig viele Dezimalstellen zulässig. Der Teil der Sekunden nach dem Punkt ist optional, während der Teil vor dem Punkt nicht optional ist. Für Jahreszahlen größer als 9999 können links weitere Stellen aufgenommen werden. Hat eine Jahresangabe weniger als vier Stellen, muss diese links mit Nullen aufgefüllt werden. Anderenfalls ist sie unzulässig.

Das Feld CCYY muss mindestens vier und die Felder MM, DD, SS, hh, mm und ss exakt zwei Ziffern lang sein. Bei weniger als zwei Stellen müssen die Felder mit Nullen aufgefüllt werden.

Dieser Darstellung kann direkt ein "Z" nachgestellt werden, um anzuzeigen, dass es sich um die Coordinated Universal Time (UTC) handelt. Folgt der Zeitangabe statt einem "Z" ein Plus- oder Minuszeichen, bedeutet das, dass darauf folgende hh:mm die Differenz zur UTC angeben (der Minutenanteil ist zwingend). In ISO 8601 Datums- und Zeit-Formate (§D) findet man weitere Details zu gültigen Werten und verschiedenen Feldern. Ist die Zeitzone mit angegeben, müssen Stunden und Minuten auch angegeben werden.

Um z.B. den 31. Mai 1999 um 13:20h in der Zeitzone Eastern Standard Time, die der UTC um 5 Stunden nachläuft, darzustellen, würde das folgendermaßen geschrieben werden: 1999-05-31T13:20:00-05:00.

3.2.7.2 Kanonische Repräsentation

Die kanonische Repräsentation für dateTime ist definiert, indem einige der wahlfreien Punkte der Lexikalische Repräsentation (§3.2.7.1) eingeschränkt wurden. Das heißt explizit: Entweder wird die Zeitzone nicht angegeben, oder wenn doch, muss die Zeitzone UTC sein. Dies muss durch ein "Z" angegeben werden.

3.2.7.3 Ordnungsbeziehung auf dateTime

Allgemein gibt die Ordnungsbeziehung auf dateTime eine partielle Ordnung an, da es bestimmte dateTime-Instanzen gibt, für die es keine festgelegte Beziehung gibt. So gibt es beispielsweise keine Ordnung zwischen (a) 2000-01-20T12:00:00 und 2000-01-20T12:00:00Z. Basierend auf den aktuell verwendeten Zeitzonen könnte (a) von 2000-01-20T12:00:00+12:00 bis 2000-01-20T12:00:00-13:00 variieren. Es ist jedoch möglich, dass dieser Bereich in Zukunft auf Basis lokaler Gesetze vergrößert oder verkleinert wird. Deshalb verwendet die folgende Definition einen etwas breiteren Bereich von nicht festgelegten Werten: +14:00...-14:00.

In der folgenden Definition wird die Notation S[Jahr] verwendet, um das Jahresfeld einer dateTime darzustellen, S[Monat] steht für das Monatsfeld usw. Die Notation (Q & "-14:00") bedeutet, dass Q der Zeitzone -14:00 zugerechnet wird, wobei Q noch keine Zeitzone hat. Dies ist eine logische Erklärung des Ablaufs. Aktuellen Implementierungen ist es freigestellt, zu optimieren, solange das Resultat dasselbe bleibt.

Die Ordnung zwischen zwei dateTimes P und Q ist durch folgenden Algorithmus definiert:

A. Normalisiere P und Q: Das bedeutet, dass Zeitzonen ungleich Z nach Z konvertiert werden, indem die Additionsoperation verwendet wird, die in "Addieren von duration und dateTimes" (§E) definiert ist.

  • 2000-03-04T23:00:00+03:00 ist normalisiert 2000-03-04T20:00:00Z

B. Falls P und Q entweder beide eine Zeitzone haben oder beide keine haben, vergleiche P und Q Feld für Feld, angefangen beim Jahresfeld, und liefere ein Ergebnis, sobald eines festgelegt werden kann, wie folgt:

  1. Für jedes i aus {Jahr, Monat, Tag, Stunde, Minute, Sekunde}
    1. Falls P[i] und Q[i] beide nicht spezifiziert sind, fahre fort mit nächstem i.
    2. Falls P[i] nicht spezifiziert ist und Q[i] ist spezifiziert oder umgekehrt, stoppen und (P <> Q) als Ergebnis zurückgeben.
    3. Falls P[i] < Q[i], stoppen und (P < Q) als Ergebnis zurückgeben.
    4. Falls P[i] > Q[i], stoppen und (P > Q) als Ergebnis zurückgeben.
  2. Stoppen und (P = Q) zurückgeben.

C. Anderenfalls, falls P eine Zeitzone enthält und Q nicht führe folgende Vergleiche durch:

  1. P < Q, falls P < (Q mit Zeitzone +14:00)
  2. P > Q, falls P > (Q mit Zeitzone -14:00)
  3. P <> Q anderenfalls, das heißt, falls (Q mit Zeitzone +14:00) < P < (Q mit Zeitzone -14:00)

D. Anderenfalls, falls P keine Zeitzone enthält und Q enthält eine Zeitzone, führe folgende Vergleiche:

  1. P < Q, falls (P mit Zeitzone +14:00)
  2. P > Q, falls (P mit Zeitzone -14:00)
  3. P <> Q anderenfalls, das heißt, falls (P mit Zeitzone +14:00) < Q < (P mit Zeitzone -14:00)

Beispiele:

Determinate Indeterminate
2000-01-15T00:00:00 < 2000-02-15T00:00:00 2000-01-01T12:00:00 <> 1999-12-31T23:00:00Z
2000-01-15T12:00:00 < 2000-01-16T12:00:00Z 2000-01-16T12:00:00 <> 2000-01-16T12:00:00Z
2000-01-16T00:00:00 <> 2000-01-16T12:00:00Z
3.2.7.4 Total geordnete dateTimes

Für bestimmte von dateTime abgeleitete Typen kann eine totale Ordnung garantiert werden. Um das sicherstellen zu können, muss gefordert werden, dass bestimmte Felder stets gesetzt und die anderen, wenn noch übrig, stets nicht gesetzt sind. Z.B. enthält der Datentyp date (Datum) ohne Zeitzone lediglich die Felder Jahr, Monat und Tag. Darum haben dates ohne Zeitzone eine totale Ordnung auf sich selbst.

3.2.7.5 Einschränkende Fassetten

dateTime hat die folgenden beschränkenden Fassetten :

3.2.8 time

[Definition:] time repräsentiert eine Instanz der Zeit, die jeden Tag wiederkehrt. Der Wertebereich von time entspricht dem Bereich der Tageszeitwerte, die in §5.3 von [ISO 8601] definiert sind. Das ist eine Menge von Tageszeitinstanzen mit der Dauer null.

Da die lexikalische Repräsentation die Angabe einer Zeitzone freistellt, können time-Werte nur teilweise geordnet werden, weil die Ordnung zwischen einem Wert mit und einem Wert ohne Zeitzone nicht festgelegt werden kann. Die Ordnungsbeziehung auf time entspricht der Ordnungsbeziehung auf dateTime (§3.2.7.3) unter Verwendung eines beliebigen Datums. Siehe auch Additionsoperation von duration und dateTime (§E). Paare von time-Werten mit oder ohne Zeitzone sind total geordnet.

3.2.8.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von time entspricht der von dateTime ohne deren linken Teil: hh:mm:ss.sss mit einer optionalen Zeitzonenangabe. Z.B. würde man 1:20 nachmittags zur Eastern Standard Time, die 5 Stunden hinter der Coordinated Universal Time (UTC) herläuft, schreiben: 13:20:00-05:00. Siehe auch ISO 8601 Datums- und Zeit-Formate (§D).

3.2.8.2 Kanonische Repräsentation

Die kanonische Repräsentation von time ist definiert, indem einige der Optionen der lexikalischen Repräsentation (§3.2.8.1) verboten wurden. Die Zeitzone muss entweder weggelassen werden oder der Coordinated Universal Time (UTC) entsprechen, die durch ein "Z" ausgedrückt wird. Zusätzlich lautet die kanonische Repräsentation für Mitternacht 00:00:00.

3.2.9 date

[Definition:] date stellt ein Kalenderdatum dar. Der Wertebereich von date ist eine Menge Kalenderdaten des gregorianischen Kalenders, gemäß Definition in § 5.4 von [ISO 8601]. Insbesondere ist es eine Menge von einen Tag langen, nicht periodischen Instanzen. Beispielsweise repräsentiert lexikalisch 1999-10-26 das Kalenderdatum 26. Oktober 1999, unabhängig davon, wie viele Stunden ein Tag hat.

Da die lexikalische Repräsentation die Angabe einer Zeitzone freistellt, können date-Werte nur teilweise geordnet werden, weil es nicht möglich ist, die Ordnung zwischen einem Datum mit und ohne Zeitzone ohne Mehrdeutigkeiten festzulegen. Falls date-Werte als Zeitperioden zu verstehen sind, legt die Ordnungsbeziehung auf date die Ordnung der Startwerte fest. Das wird in Ordnungsbeziehung auf dateTime (§3.2.7.3) erläutert. Siehe auch Addition von Zeitspannen und dateTime (§E). Paare von date-Werten mit oder ohne Zeitzone sind total geordnet.

3.2.9.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von date ist die reduzierte (rechts abgeschnittene) lexikalische Repräsentation von dateTime: CCYY-MM-DD. Links darf kein Feld abgeschnitten werden. Die Angabe einer Zeitzone ist freistellt. Um Jahreszahlen mit mehr als vier Stellen darstellen zu können, dürfen weitere Ziffern links angefügt werden und ein vorangestelltes Minuszeichen ist erlaubt.

Um zum Beispiel den 31. Mai 1999 zu bezeichnen, würde man schreiben: 1999-05-31. Siehe auch ISO 8601 Datums- und Zeit-Formate (§D).

3.2.10 gYearMonth

[Definition:] gYearMonth repräsentiert einen bestimmten gregorianischen Monat in einem bestimmten gregorianischen Jahr. Der Wertebereich von gYearMonth ist die Menge aller Monate im gregorianischen Kalender, wie in [ISO 8601] §5.2.1 definiert. Dabei handelt es sich um bestimmte, einen Monat lange, nicht periodische Instanzen. Zum Beispiel würde 1999-10 den kompletten Monat Oktober im Jahr 1999 repräsentieren, gleichgültig wie viele Tage dieser Monat hat.

Da die lexikalische Repräsentation die Angabe einer Zeitzone erlaubt, gibt es keine vollständige Ordnungsbeziehung auf gYearMonth, denn es ist nicht möglich, die Ordnung zwischen zwei Werten anzugeben, von denen einer eine Zeitzonenangabe hat und der andere nicht. Falls gYearMonth-Werte zur Angabe von Zeitperioden verwendet werden, richtet sich die Ordnungsbeziehung nach den Startwerten. Im Abschnitt §3.2.7.3 Ordnungsbeziehung auf dateTime wird das näher erläutert. Siehe auch Addition von duration und dateTime (§E). Paare von gYearMonth-Werten mit oder ohne Zeitzone sind total geordnet.

Anmerkung:

Da Monat/Jahr-Kombinationen in einem Kalender nur selten mit Monat/Jahr-Kombinationen in anderen Kalendern übereinstimmen, sind sie normalerweise nicht in einfache Werte konvertierbar, die mit Monat/Jahr-Kombinationen in anderen Kalendern übereinstimmen. Dieser Typ sollte deshalb mit Vorsicht in Kontexten eingesetzt werden, wo die Konvertierung in andere Kalender gefordert ist.
3.2.10.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von gYearMonth ist eine reduzierte (rechts abgeschnittene) lexikalische Repräsentation von dateTime: CCYY-MM. Es ist nicht erlaubt, links Teile abzuschneiden. Die Angabe einer Zeitzone ist erlaubt. Um Jahreszahlen über 9999 darstellen zu können, dürfen links weitere Stellen angefügt werden. Ein vorangestelltes Minuszeichen ist erlaubt.

Um z.B. den Monat Mai im Jahr 1999 darzustellen, würde man schreiben: 1999-05. Siehe auch ISO 8610 Date and Time Formats (§D).

3.2.10.2 Einschränkende Fassetten

gYearMonth hat die folgenden beschränkenden Fassetten :

3.2.11 gYear

[Definition:] gYear stellt ein Jahr im gregorianischen Kalender dar. Der Wertebereich von gYear ist die Menge der Jahre im gregorianischen Kalender, wie sie in [ISO 8601] §5.2 definiert sind. Dabei handelt es sich um eine bestimmte, ein Jahr lange, nicht periodische Instanz. Z.B. 1999 repräsentiert das Jahr 1999, unabhängig davon, wie viele Monate das Jahr hat.

Da die lexikalische Repräsentation von gYear die Angabe einer Zeitzone erlaubt, gibt es keine vollständige Ordnungsbeziehung auf gYear, denn es ist nicht möglich, die Ordnung zwischen zwei Werten anzugeben, von denen einer eine Zeitzonenangabe hat und der andere nicht. Falls gYear zur Angabe von Zeitperioden verwendet wird, richtet sich die Ordnung nach den Startwerten. Im Abschnitt §3.2.7.3 Ordnungsbeziehung auf dateTime wird das näher erläutert. Siehe auch Addition von duration und dateTime (§E). Paare von gYear-Werten mit oder ohne Zeitzone sind total geordnet.

Anmerkung:

Da Jahre in einem Kalender nur selten mit Jahren in anderen Kalendern übereinstimmen, sind sie normalerweise nicht in einfache Werte konvertierbar, die mit Jahren in anderen Kalendern übereinstimmen. Dieser Typ sollte deshalb mit Vorsicht in Kontexten eingesetzt werden, wo die Konvertierung in andere Kalender gefordert ist.

3.2.11.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von gYear ist eine reduzierte (rechts abgeschnittene) lexikalische Repräsentation von dateTime: CCYY. Es ist nicht erlaubt, links Teile abzuschneiden. Die Angabe einer Zeitzone ist erlaubt. Um Jahreszahlen über 9999 darstellen zu können, dürfen links weitere Stellen angefügt werden. Ein vorangestelltes Minuszeichen ist erlaubt.

Um z.B. das Jahr 1999 darzustellen, würde man 1999 schreiben. Siehe auch ISO 8610 Date and Time Formats (§D).

3.2.12 gMonthDay

[Definition:] gMonthDay ist ein wiederkehrendes gregorianisches Datum, genauer ein Tag eines Jahres, wie der 3. Mai. Sich willkürlich wiederholende Daten werden von diesem Datentyp nicht unterstützt. Der Wertebereich von gMonthDay ist die Menge von Kalenderdaten, wie in §3 von [ISO 8601] definiert. Dabei handelt es sich um eine Menge von jährlich wiederkehrenden, einen Tag dauernden Instanzen.

Da die lexikalische Repräsentation von gMonthDay die Angabe einer Zeitzone erlaubt, gibt es keine vollständige Ordnungsbeziehung auf gMonthDay, denn es ist nicht möglich, die Ordnung zwischen zwei Werten anzugeben, von denen einer eine Zeitzonenangabe hat und der andere nicht. Falls gMonthDay zur Angabe von Zeitperioden verwendet wird, richtet sich die Ordnung nach den Startwerten. Im Abschnitt §3.2.7.3 Ordnungsbeziehung auf dateTime wird das näher erläutert. Siehe auch Addition von duration und dateTime (§E). Paare von gMonthDay-Werten mit oder ohne Zeitzone sind total geordnet.

Anmerkung:

Da Kombinationen von Tag und Monat in einem Kalender nur selten mit entsprechenden Kombinationen in anderen Kalendern übereinstimmen, sind sie normalerweise nicht in einfache Werte konvertierbar, die mit der Kombinationen von Tag und Monat in anderen Kalendern übereinstimmen. Dieser Typ sollte deshalb mit Vorsicht in Kontexten eingesetzt werden, wo die Konvertierung in andere Kalender gefordert ist.
3.2.12.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von gMonthDay ist die links abgeschnittene lexikalische Repräsentation von date: --MM-DD. Die Angabe einer Zeitzone ist erlaubt. Ein Vorzeichen ist nicht gestattet. Es sind keine anderen Formate zulässig. Siehe auch ISO 8610 Date und Time Formats (§D).

Dieser Datentyp kann dazu verwendet werden, einen bestimmten Tag eines Monats darzustellen, um zum Beispiel auszudrücken, dass mein Geburtstag am 14. September ist.

3.2.12.2 Einschränkende Fassetten

gMonthDay hat die folgenden beschränkenden Fassetten :

3.2.13 gDay

[Definition:] gDay ist ein wiederkehrender gregorianischer Tag, ein Tag in einem Monat, wie der 5. eines Monats. Willkürlich wiederkehrende Tage werden von diesem Datentyp nicht unterstützt. Der Wertebereich von gDay ist eine Menge der Kalenderdaten, wie in §3 von [ISO 8601] definiert. Dabei handelt es sich um eine einen Tag lange periodische Instanz.

Mit diesem Datentyp werden bestimmte Tage eines Monats dargestellt. So lässt sich z.B. ausdrücken, dass man am 15. jedes Monats seinen Gehaltsscheck bekommt.

Da die lexikalische Repräsentation von gDay die Angabe einer Zeitzone zulässt, gibt es keine vollständige Ordnung auf gDay, denn es ist nicht möglich, die Ordnung zwischen zwei Werten festzulegen, von denen einer eine Zeitzone hat und der andere nicht. Falls gDay zur Angabe von Zeitperioden verwendet wird, richtet sich die Ordnung nach dem Startwert. Im Abschnitt §3.2.7.3 Ordnungsbeziehung auf dateTime wird das näher erläutert. Siehe auch Addition von duration und Datentyp (§E). Paare von gDay-Werten mit oder ohne Zeitzone sind total geordnet.

Anmerkung:

Da Tage in einem Kalender nur selten mit Tagen in anderen Kalendern übereinstimmen, sind Werte dieses Types nicht einfach oder intuitiv auf andere Kalender übertragbar. Darum sollte dieser Typ mit Vorsicht eingesetzt werden, wenn die Übertragbarkeit auf andere Kalender gefordert ist.
3.2.13.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von gDay ist die links abgeschnittene lexikalische Repräsentation von date: ---DD. Die Angabe einer Zeitzone ist erlaubt. Ein Vorzeichen ist nicht zulässig. Andere Darstellungsarten sind nicht erlaubt. Siehe auch ISO 8610 Date und Time Formats (§D).

3.2.14 gMonth

[Definition:] gMonth ist ein gregorianischer Monat, der jedes Jahr wiederkehrt. Der Wertebereich von gMonth ist die Menge der Kalendermonate, wie sie in §3 von [ISO 8601] definiert sind. Es handelt sich um eine Menge von einen Monat langen, sich jährlich wiederholenden Instanzen.

Dieser Datentyp kann verwendet werden, um einen bestimmten Monat darzustellen, um z.B. auszudrücken, dass Weihnachten im Dezember ist.

Da die lexikalische Repräsentation von gMonth die Angabe einer Zeitzone erlaubt, gibt es keine vollständige Ordnungsbeziehung auf gMonth, denn es ist nicht möglich, die Ordnung zwischen zwei Werten anzugeben, von denen einer eine Zeitzonenangabe hat und der andere nicht. Falls gMonth zur Angabe von Zeitperioden verwendet wird, richtet sich die Ordnung nach den Startwerten. Im Abschnitt §3.2.7.3 Ordnungsbeziehung auf dateTime wird das näher erläutert. Siehe auch Addition von duration und dateTime (§E). Paare von gMonth-Werten mit oder ohne Zeitzone sind total geordnet.

Anmerkung:

Da Monate in einem Kalender nur selten mit Monaten in anderen Kalendern übereinstimmen, sind Werte dieses Types nicht einfach oder intuitiv auf andere Kalender übertragbar. Darum sollte dieser Typ mit Vorsicht eingesetzt werden, wenn die Übertragbarkeit auf andere Kalender gefordert ist.
3.2.14.1 Lexikalische Repräsentation

Die lexikalische Repräsentation von gMonth entspricht der sowohl links als auch rechts abgeschnittenen lexikalischen Repräsentation von date: --MM--. Die Angabe einer Zeitzone ist erlaubt. Ein Vorzeichen ist nicht zulässig. Andere Darstellungsarten sind nicht erlaubt. Siehe auch ISO 8610 Date und Time Formats (§D). Andere Darstellungsarten sind nicht erlaubt. Siehe auch ISO 8610 Date und Time Formats (§D).

3.2.14.2 Einschränkende Fassetten

gMonth hat die folgenden beschränkenden Fassetten :

3.2.15 hexBinary

[Definition:] hexBinary repräsentiert hexadezimal kodierte Daten. Der Wertebereich von hexBinary ist die Menge von Oktettsequenzen endlicher Länge.

3.2.15.1 Lexikalische Repräsentation

In der lexikalischen Repräsentation von hexBinary wird jedes Oktett mit zwei Zeichen aus [0-9a-fA-F] dargestellt. Z.B. ist "0FB7" die hexadezimale Kodierung der 16-Bit-Integer-Zahl 4023 (binär 111110110111).

3.2.15.2 Kanonische Repräsentation

Zur Definition der kanonischen Repräsentation wurde die lexikalische Repräsentation in bestimmten Punkten eingeschränkt. Das bedeutet, dass die Kleinbuchstaben [a-f] nicht erlaubt sind.

3.2.15.3 Einschränkende Fassetten

hexBinary hat die folgenden beschränkenden Fassetten :

3.2.16 base64Binary

[Definition:] base64Binary stellt binäre Daten Base64-kodiert dar. Der Wertebereich von base64Binary ist die Menge von Oktettsequenzen endlicher Länge. Für base64Binary wird der gesamte binäre Datenstrom unter Verwendung der Base64 Content Transfer Encoding nach Definition in Sektion 6.8 von [RFC 2045] kodiert.

3.2.16.1 Einschränkende Fassetten

base64Binary hat die folgenden beschränkenden Fassetten :

3.2.17 anyURI

[Definition:] anyURI stellt einen Uniform Resource Identifier (URI) dar. Ein anyURI-Wert kann absolut oder relativ sein und darf Fragment-Bezeichner enthalten (z.B. könnte es eine URI-Refenz sein). Dieser Datentyp sollte verwendet werden, um kenntlich zu machen, dass der Wert die Regeln erfüllt, die in [RFC 2396] definiert und in [RFC 2732] berichtigt sind.

Die Abbildung von anyURI-Werten auf URIs ist in Abschnitt 5.4 Locator-Attribute der [XML 1.0 (Second Edition)] (siehe auch Abschnitt 8: Zeichen-Kodierung in URI-Referenzen von [Character Model]). Das bedeutet, dass mit einem anyURI eine große Bandbreite an internationalisierten Ressourcen-Bezeichnern abgedeckt werden kann und immer noch als URI im Sinne von [RFC 2396] (berichtigt von [RFC 2732]) verstanden wird.

Anmerkung:

Für jedes URI-Schema gibt es spezielle Syntaxregeln, nach denen ein URI dieses Schemas gebildet werden muss. Das schließt die Syntax von zulässigen Fragment-Bezeichnern ein. Weil es für einen Prozessor nicht praktikabel wäre, nachzuprüfen, ob eine URI-Refenrenz ihrem Kontext gemäß verwendet wird, folgt diese Spezifikation den Vorgaben von [RFC 2396] (berichtigt von [RFC 2732]) auf folgende Weise: Solche Regeln und Restriktionen sind nicht Teil der Gültigkeit und werden von Prozessoren mit minimaler Unterstützung nicht geprüft. Somit wird Prozessoren mit minimaler Unterstützung nur ein sehr bescheidenes Pflichtprogramm abverlangt.
3.2.17.1 Lexikalische Repräsentation

Der lexikalische Bereich von anyURI ist eine endlich lange Zeichenkette, die einem legalen URI entspricht, wenn ein Prüfalgorithmus vorliegt, der in Abschnitt 5 von [RFC 2396] (berichtigt von [RFC 2732]) definiert ist.

Anmerkung:

Leerzeichen sind prinzipiell zulässig im lexikalischen Bereich von anyURI, sie sollten allerdings vermieden werden (stattdessen sollte %20 verwendet werden).
3.2.17.2 Einschränkende Fassetten

anyURI hat die folgenden beschränkenden Fassetten :

3.2.18 QName

[Definition:] QName stellt XML-qualifizierte Namen dar. Der Wertebereich ist eine Menge von Tupeln der Form {Namespace-Name, Lokal-Teil}. Dabei ist der Namespace-Name ein URI und der Lokal-Teil ein NCName. Der lexikalische Bereich von QName ist die Menge von Zeichenketten, die der QName-Produktion von [XML 1.0 (Second Edition)] entsprechen.

Anmerkung:

Die Abbildung von Literalen im lexikalischen Bereich auf Werte im Wertebereich von QName verlangt eine Deklaration des Namespaces im Sichtbarkeitsbereich, indem QName verwendet wird.
3.2.18.1 Einschränkende Fassetten

QName hat die folgenden beschränkenden Fassetten :

3.2.19 NOTATION

[Definition:] NOTATION stellt den Attributtyp NOTATION aus [XML 1.0 (Second Edition)] dar. Der Wertebereich von NOTATION ist die Menge QNames. Der lexikalische Bereich von NOTATION ist die Mengen aller Notationsnamen, die im aktuellen Schema deklariert sind.

Schema Komponenten Beschränkung: Vorausgesetzter Wert für die enumeration-Fassette von NOTATION
Es ist ein Fehler, wenn NOTATION direkt in einem Schema verwendet wird. Nur Datentypen, die von NOTATION abgeleitet sind, indem sie einen Wert für enumeration spezifizieren, dürfen verwendet werden.

Aus Kompatibilitätsgründen sollte NOTATION nur in Attributen benutzt werden (siehe Terminologie §1.4).

3.2.19.1 Einschränkende Fassetten

NOTATION hat die folgenden beschränkenden Fassetten :

previous sub-section3.3 Abgeleitete Datentypen

3.3.2 token
3.3.3 language
3.3.4 NMTOKEN
3.3.5 NMTOKENS
3.3.6 Name
3.3.7 NCName
3.3.8 ID
3.3.9 IDREF
3.3.10 IDREFS
3.3.11 ENTITY
3.3.12 ENTITIES
3.3.13 integer
3.3.16 long
3.3.17 int
3.3.18 short
3.3.19 byte

Dieser Abschnitt liefert eine konzeptionelle Definition aller abgeleiteten vordefinierten Datentypen in dieser Spezifikation. Die XML-Repräsentation zur Definition von abgeleiteten Datentypen (entweder vordefiniert oder benutzerdefiniert) wird im Abschnitt §4.1.2 XML-Repräsentation einfacher Schema-Komponenten zur Typ-Definition beschrieben. Die vollständigen Definitionen der abgeleitetenvordefinierten Datentypen wird in Anhang A geprüft (normativ) (§A).

3.3.1 normalizedString

[Definition:] normalizedString stellt eine von Leerraum bereinigte Zeichenkette dar. Der Wertebereich von normalizedString ist die Menge der Zeichenketten, die weder carriage return (Wagenrücklauf) (#xD), line feed (Zeilenvorschub) (#xA) noch Tabulatorzeichen (#x9) enthalten. Der lexikalischer Bereich von normalizedString ist die Menge der Zeichenketten, die weder carriage return, line feed noch Tabulatorzeichen enthalten. Der Basistyp von normalizedString ist string.

3.3.1.1 Einschränkende Fassetten

normalizedString hat die folgenden beschränkenden Fassetten :

3.3.1.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von normalizedString:

3.3.2 token

[Definition:] token stellt in Tokens übersetzte Zeichenketten dar. Der Wertebereich von token ist die Menge von Zeichenketten, die kein carriage return (#xD), kein line feed (#xA) und kein Tabulatorzeichen (#x9) sowie am Anfang und Ende keine Leerzeichen (#x20) enthalten, und auch im Inneren der Zeichenkette folgen Leerzeichen nicht nacheinander. Der lexikalische Bereich von token ist die Menge der Zeichenketten, die kein carriage return, kein line feed und keine Tabulatorzeichen enthalten, weder mit Leerzeichen beginnen noch enden und auch im Inneren der Zeichenketten keine Leerzeichenfolgen enthalten, die länger sind als zwei oder mehr Leerzeichen.

3.3.2.1 Einschränkende Fassetten

token hat die folgenden beschränkenden Fassetten :

3.3.2.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von token:

3.3.3 language

[Definition:] language repräsentiert Bezeichner für natürliche Sprachen, wie sie in [RFC 1766] definiert werden. Der Wertebereich von language ist die Menge aller Zeichenketten, die einen gültigen Bezeichner einer natürlichen Sprache darstellen, wie sie im Abschnitt language identification von [XML 1.0 (Second Edition)] definiert werden. Der lexikalische Bereich von language ist die Menge aller Zeichenketten, die einen gültigen Bezeichner einer natürlichen Sprache darstellen, wie sie im Abschnitt language identification von [XML 1.0 (Second Edition)] definiert werden.

3.3.3.1 Einschränkende Fassetten

language hat die folgenden beschränkenden Fassetten :

3.3.4 NMTOKEN

[Definition:] NMTOKEN ist die Repräsentation des NMTOKEN-Attributs aus [XML 1.0 (Second Edition)]. Der Wertebereich von NMTOKEN ist die Menge der Tokens, die der Nmtoken-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der lexikalische Bereich ist die Menge der Zeichenketten, die der Nmtoken-Produktion in [XML 1.0 (Second Edition)] entsprechen.

3.3.4.1 Einschränkende Fassetten

NMTOKEN hat die folgenden beschränkenden Fassetten :

3.3.4.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von NMTOKEN:

3.3.5 NMTOKENS

[Definition:] NMTOKENS ist die Repräsentation des NMTOKENS-Attributs aus [XML 1.0 (Second Edition)]. Der Wertebereich von NMTOKENS ist die Menge der endlich langen, mindestens einen Eintrag enthaltenden Sequenzen von NMTOKENs. Der lexikalischer Bereich von NMTOKENS ist die Menge von Token-Listen, deren Einträge durch Leerräume separiert sind und in den lexikalischen Bereich von NMTOKEN gehören. Der itemType von NMTOKENS ist NMTOKEN.

3.3.5.1 Einschränkende Fassetten

NMTOKENS hat die folgenden beschränkenden Fassetten :

3.3.6 Name

[Definition:] Name stellt XML-Namen dar. Der Wertebereich ist die Menge aller Zeichenketten, die der Name-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der lexikalische Bereich ist die Menge aller Zeichenketten, die der Name-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der Basistyp von Name ist token.

3.3.6.1 Einschränkende Fassetten

Name hat die folgenden beschränkenden Fassetten :

3.3.6.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von Name:

3.3.7 NCName

[Definition:] NCName repräsentiert einen "non-colonized" XML-Namen, d.h. einen XML-Namen, der keinen Doppelpunkt enthält. Der Wertebereich von NCName ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der lexikalische Bereich ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der Basistyp von NCName ist Name.

3.3.7.1 Einschränkende Fassetten

NCName hat die folgenden beschränkenden Fassetten :

3.3.7.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von NCName:

3.3.8 ID

[Definition:] ID repräsentiert den ID-Attribut-Typ von [XML 1.0 (Second Edition)]. Der Wertebereich von ID ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der lexikalische Bereich ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der Basistyp von ID ist NCName.

Aus Kompatibilitätsgründen (siehe Terminologie (§1.4)) sollte ID nur für Attribute verwendet werden.

3.3.8.1 Einschränkende Fassetten

ID hat die folgenden beschränkenden Fassetten :

3.3.9 IDREF

[Definition:] IDREF repräsentiert den IDREF-Attribut-Typ von [XML 1.0 (Second Edition)]. Der Wertebereich von ID ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der lexikalischer Bereich ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen. Der Basistyp von IDREF ist NCName.

Aus Kompatibilitätsgründen (siehe Terminologie (§1.4)) sollte IDREF nur auf Attributen verwendet werden.

3.3.9.1 Einschränkende Fassetten

IDREF hat die folgenden beschränkenden Fassetten :

3.3.9.2 Abgeleitete Datentypen

Die folgenden vordefinierten Datentypen sind abgeleitet von IDREF:

3.3.10 IDREFS

[Definition:] IDREFS ist die Repräsentation des IDREFS-Attributs aus [XML 1.0 (Second Edition)]. Der Wertebereich von IDREFS ist die Menge der endlich langen, mindestens einen Eintrag enthaltenden Sequenzen von IDREFs. Der lexikalische Bereich von IDREFS ist die Menge von Token-Listen, deren Einträge durch Leerräume separiert sind und in den lexikalischer Bereich von IDREF gehören. Der itemType von NMTOKENS ist IDREF.

Aus Kompatibilitätsgründen (siehe Terminologie (§1.4)) sollte IDREFS nur auf Attributen verwendet werden.

3.3.10.1 Einschränkende Fassetten

IDREFS hat die folgenden beschränkenden Fassetten :

3.3.10.2 Derived datatypes

Die folgenden vordefinierten Datentypen sind abgeleitet von IDREFS:

    3.3.11 ENTITY

    [Definition:] ENTITY repräsentiert den ENTITY-Attribut-Typ aus [XML 1.0 (Second Edition)]. Der lexikalische Bereich von ENTITY ist die Menge aller Zeichenketten, die der NCName-Produktion in [XML 1.0 (Second Edition)] entsprechen und als ungeparste Entity in der Document Type Definition deklariert sind. Der lexikalische Bereich von ENTITY ist die Menge aller Zeichenketten, die der NCName-Produktion in [Namespaces in XML] entsprechen. Der Basistyp von ENTITY ist NCName.

    Anmerkung:

    Die Sichtbarkeit des Wertebereichs von ENTITY ist auf ein spezifisches Dokument begrenzt.

    Aus Kompatibilitätsgründen (siehe Terminologie (§1.4)) sollte ENTITY nur auf Attributen verwendet werden.

    3.3.11.1 Einschränkende Fassetten

    ENTITY hat die folgenden beschränkenden Fassetten :

    3.3.11.2 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von ENTITY:

    3.3.12 ENTITIES

    [Definition:] ENTITIES repräsentiert den ENTITIES-Attribut-Typ von [XML 1.0 (Second Edition)]. Der Wertebereich von ENTITIES ist die Menge von endlich langen , mindestens einen Eintrag enthaltenden Sequenzen von ENTITYs, die als ungeparste Entität in der Document Type Definition deklariert sind. Der lexikalische Bereich von ENTITIES ist die Menge von Token-Listen, deren Einträge durch Leerraum sind und in den lexikalischen Bereich von ENTITY gehören. Der itemType von ENTITIES ist ENTITY.

    Anmerkung:

    Die Sichtbarkeit des Wertebereichs von ENTITIES ist auf ein spezifisches Dokument begrenzt.

    Aus Kompatibilitätsgründen (siehe Terminologie (§1.4)) sollte ENTITIES nur auf Attributen verwendet werden.

    3.3.12.1 Einschränkende Fassetten

    ENTITIES hat die folgenden beschränkenden Fassetten :

    3.3.13 integer

    [Definition:] integer ist von decimal abgeleitet, in dem der Wert von fractionDigits fest auf 0 gesetzt wurde. Das Ergebnis ist das mathematische Standardkonzept der ganzen Zahlen (integer numbers). Der Wertebereich von integer ist die unendliche Menge { ..., -2, -1, 0, 1, 2, ... }. Der Basistyp von integer ist decimal.

    3.3.13.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von integer besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: -1, 0, 12678967543233, +100000.

    3.3.13.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von integer zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.13.1) eingeschränkt. Sowohl ein führendes "+" als auch führende Nullen sind nicht erlaubt.

    3.3.13.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von integer:

    3.3.14 nonPositiveInteger

    [Definition:] nonPositiveInteger ist von integer abgeleitet, indem der Wert von maxInclusive fest auf 0 gesetzt wurde. Das Ergebnis ist das mathematische Standardkonzept der nicht positiven ganzen Zahlen (non-positive integers). Der Wertebereich von nonPositiveInteger ist die unendliche Menge { ..., -2, -1, 0 }. Der Basistyp von nonPositiveInteger ist integer.

    3.3.14.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von nonPositiveInteger besteht aus einem negativen Vorzeichen ("-") gefolgt von einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Besteht die Ziffernsequenz ausschließlich aus Nullen, ist das Vorzeichen optional. Beispiele sind: -1, 0, -12678967543233, -100000.

    3.3.14.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von nonPositiveInteger zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.14.1) eingeschränkt. Das negativen Vorzeichen ("-") ist auch beim Token "0" anzugeben und führende Nullen sind nicht erlaubt.

    3.3.14.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von nonPositiveInteger:

    3.3.15 negativeInteger

    [Definition:] negativeInteger ist von nonPositiveInteger abgeleitet, indem der Wert für maxInclusive fest auf -1 gesetzt wurde. Das Ergebnis ist das mathematische Standardkonzept für negative ganze Zahlen. Der Wertebereich von negativeInteger ist die unendliche Menge { ..., -2, -1 }. Der Basistyp ist nonPositiveInteger.

    3.3.15.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von negativeInteger besteht aus einem negativen Vorzeichen ("-") gefolgt von einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: -1, -12678967543233, -100000.

    3.3.15.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von nonPositiveInteger zu definieren,werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.15.1) eingeschränkt. Das bedeutet, dass führende Nullen nicht erlaubt sind.

    3.3.16 long

    long ist von integerabgeleitet, indem der Wert von maxInclusive fest auf 9223372036854775807 und der von minInclusive fest auf -9223372036854775808 gesetzt wurde. Der Basistyp von long ist integer.

    3.3.16.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von long besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: -1, 0, 12678967543233, +100000.

    3.3.16.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von long zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.16.1) eingeschränkt. Ein führendes "+" als auch führende Nullen sind nicht erlaubt.

    3.3.16.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von long:

    3.3.17 int

    [Definition:] int ist von long abgeleitet, indem der Wert von maxInclusive fest auf 2147483647 und der von minInclusive fest auf -2147483648 gestetzt wurde. Der Basistyp von int ist long.

    3.3.17.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von int besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: -1, 0, 12678967543233, +100000.

    3.3.17.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von int zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.17.1) eingeschränkt. Ein führendes "+", sowie führende Nullen sind nicht erlaubt.

    3.3.17.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von int:

    3.3.18 short

    [Definition:] short ist von int abgeleitet, indem der Wert von maxInclusive fest auf 32767 und der von minInclusive fest auf -32768 gesetzt wurde. Der Basistyp von short ist int.

    3.3.18.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von short besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: -1, 0, 12678, +10000.

    3.3.18.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von short zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.17.1) eingeschränkt. Ein führendes "+" und führende Nullen sind nicht erlaubt.

    3.3.18.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von short:

    3.3.19 byte

    [Definition:] byte ist von int abgeleitet, indem der Wert von maxInclusive fest auf 127 und der von minInclusive fest auf -128 gesetzt wurde. Der Basis-Typ von byte ist short.

    3.3.19.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von byte besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: -1, 0, 126, +100.

    3.3.19.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von byte zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.18.1) eingeschränkt. Ein führendes "+", ebenso wie führende Nullen sind nicht erlaubt.

    3.3.20 nonNegativeInteger

    [Definition:] nonNegativeInteger ist von von integer abgeleitet, indem der Wert von minInclusive fest auf 0 gesetzt wurde. Der Wertebereich von nonNegativeInteger ist die unendliche Menge { 0, 1, 2. ... }. Der Basistyp von nonNegativeInteger ist integer.

    3.3.20.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von nonNegativeInteger besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39) und optional einem vorangestellten Vorzeichen. Falls kein Vorzeichen vorhanden ist, wird "+" angenommen. Beispiele sind: 1, 0, 12678967543233, +100000.

    3.3.20.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von nonNegativeInteger zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.20.1) eingeschränkt. Ein führendes "+" und führende Nullen sind nicht erlaubt.

    3.3.20.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von nonNegativeInteger:

    3.3.21 unsignedLong

    [Definition:] unsignedLong ist von nonNegativeInteger abgeleitet, indem der Wert von maxInclusive fest auf 18446744073709551615 gesetzt wurde. Der Basistyp von unsignedLong ist nonNegativeInteger.

    3.3.21.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von unsignedLong besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 12678967543233, +100000.

    3.3.21.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von unsignedLong zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.21.1) eingeschränkt. Führende Nullen sind nicht erlaubt.

    3.3.21.4 Abgeleitete Datentypen

    3.3.22 unsignedInt

    [Definition:] unsignedInt ist von unsignedLong abgeleitet, indem der Wert von maxInclusive fest auf 4294967295 gesetzt wurde. Der Basistyp von unsignedInt ist unsignedLong.

    3.3.22.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von unsignedInt besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 1267896754, +100000.

    3.3.22.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von unsignedInt zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.22.1) eingeschränkt. Führende Nullen sind nicht erlaubt.

    3.3.22.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von unsignedInt:

    3.3.23 unsignedShort

    [Definition:] unsignedShort ist von unsignedInt abgeleitet, indem der Wert von maxInclusive fest auf 65536 gesetzt wurde. Der Basistyp von unsignedShort ist unsignedInt.

    3.3.23.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von unsignedInt besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 12678, 10000.

    3.3.23.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von unsignedInt zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.23.1) eingeschränkt. Führende Nullen sind nicht erlaubt.

    3.3.23.4 Abgeleitete Datentypen

    Die folgenden vordefinierten Datentypen sind abgeleitet von unsignedShort:

    3.3.24 unsignedByte

    [Definition:] unsignedByte ist von unsignedShort abgeleitet, indem der Wert von maxInclusive fest auf 255 gesetzt wurde. Der Basistyp von unsignedByte ist unsignedShort.

    3.3.24.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von unsignedByte besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 126, +100.

    3.3.24.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von unsignedByte zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.24.1) eingeschränkt. Führende Nullen sind nicht erlaubt.

    3.3.25 positiveInteger

    [Definition:] positiveInteger ist von nonNegativeInteger abgeleitet, indem der Wert von minInclusive fest auf 1 gesetzt wurde. Das Ergebnis ist das mathematische Standardkonzept der positiven ganzen Zahlen (positive integers). Der Wertebereich von positiveInteger ist die unendliche Menge { 1, 2, ... }. Der Basistyp von positiveInteger ist nonNegativeInteger.

    3.3.25.1 Lexikalische Repräsentation

    Die lexikalische Repräsentation von positiveInteger besteht aus einem optionalen positiven Vorzeichen ("+") gefolgt von einer endlich langen Sequenz von Dezimalziffern ((#x30-#x39). Beispiele sind: 1, 12678967543233, +100000.

    3.3.25.2 Kanonische Repräsentation

    Um die kanonische Repräsentation von positiveInteger zu definieren, werden einige der wahlfreien Punkte der lexikalischen Repräsentation (§3.3.25.1) eingeschränkt. Ein führendes "+", sowie führende Nullen sind nicht erlaubt.

    4 Datentyp-Komponenten

    Die folgenden Abschnitte behandeln detailliert die Eigenschaften und die Bedeutung jeder Art von Schema-Komponenten, die bei der Definition von Datentypen eine Rolle spielen. Für jede Eigenschaft werden die Arten von Werten spezifiziert, die diese Eigenschaft annehmen kann. Jede Eigenschaft muss angegeben werden, wenn sie nicht ausdrücklich als optional gekennzeichnet ist. Optionale Eigenschaften, die nicht angegeben werden, haben nicht verwendet als Wert. Der Wert einer Eigenschaft, die mit einem Mengen-, Untermengen- oder Liste-Wert belegt wird, darf leer sein, es sei denn, es wird explizit verboten: Das ist nicht das Gleiche wie nicht verwendet . Jeder Wert einer Eigenschaft, der eine Über- oder Untermenge einer Menge darstellt, kann gleich dieser Menge sein, es sei denn, es wird explizit eine Über- oder Untermenge gefordert.

    Weitere Informationen zum Begriff der (Schema-)Komponenten zur Definition von Datentypen findet man im Abschnitt Details zu Schema-Komponenten von [XML 1.0 (Second Edition)].

    next sub-section4.1 Einfache Typdefinition

    Definitionen einfacher Typen legen fest:

    4.1.1 Schema-Komponente zur Definition einfacher Datentypen

    Die Komponenten zur Definition einfacher Datentypen besitzen folgende Eigenschaften:

    Schema Komponente: Simple Type Definition
    {Name}
    ein NCName, wie in [XML 1.0 (Second Edition)] definiert. (Optional)
    {Ziel-Namensraum}
    entweder nicht angegeben oder ein Name eines Namensraumes, wie in [XML 1.0 (Second Edition)] definiert.
    {Sorte}
    kann sein: {atomic, list, union}. Abhängig von {Sorte} können folgende Eigenschaften zusätzlich angegeben werden:
    atomic
    {primitive Typ-Definition}
    Definition eines primitiven vordefinierten-Datentyps (oder eines einfachen Urtyps)
    list
    {Definition eines Eintragstyps}
    Definition eines atomaren oder eines Vereinigungstyps
    union
    {Definition eines Member-Typs}
    Definition einer nicht leeren Sequenz einfacher Typen
    {Fassetten}
    Eine möglicherweise leere Menge von Definitionen einfacher Typen
    {grundlegende Fassetten}
    Eine Menge von grundlegenden Fassetten
    {Basistyp-Definition}
    Komponente zur Definition einfacher Datentypen, von der sie abgeleitet ist, wenn der Datentyp durch Einschränkung abgeleitet wurde, anderenfalls Definition einfacher Typen für anySimpleType (§4.1.6).
    {abgeschlossen}
    Eine Untermenge von {restriction, list, union}
    {Anmerkung}
    Eine Anmerkung (optional)

    Datentypen werden durch ihren {Name} und {Ziel-Namensraum} identifiziert. Von anonymen Datentypen (Datentypen ohne {Name}) abgesehen, müssen Datentypen innerhalb eines Schemas eindeutig identifizierbar sein.

    Ist {Sorte}atomar, ist der Wertebereich des definierten Datentyps eine Untermenge des Wertebereichs von {Basistyp-Definition} (eine Untermenge der Definition des primitiven Typs). Ist {Sorte} eine Liste, ist der Wertebereich des definierten Datentyps eine Menge endlich langer Sequenzen von Werten aus dem Wertebereich der Definition des itemType. Ist {Sorte} eine Vereinigung, ist der Wertebereich des definierten Datentyps die Vereinigung der Wertebereiche jedes Member-Typs.

    Ist {Sorte}atomar, muss auch {Sorte} von {Basistyp-Definition} atomar sein. Ist {Sorte} eine Liste, muss {Sorte} der Definition des itemTypes atomar entsprechen oder eine Vereinigung sein. Ist {Sorte} eine Vereinigung, muss die Definition der memberTypes eine Liste von Datentypdefinitionen sein.

    Der Wert von {Fassetten} besteht aus einer Menge von Fassetten, die direkt in der Datentypdefinition spezifiziert sind, zusammen mit der möglicherweise leeren Menge der Fassetten der {Basistyp-Definition}.

    Der Wert von {grundlegende Fassetten} besteht aus der Menge der {Fassetten} und ihren Werten.

    Wenn {abgeschlossen} die leere Menge ist, dann kann der Typ benutzt werden, um andere Typen abzuleiten; die expliziten Werte restriction, list und union verhindern weitere Ableitungen durch jeweils restriction, list und union. Der Wert von {grundlegende Fassetten} besteht aus der Menge der {Fassetten} und ihren Werten.

    4.1.2 XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen

    Die XML-Repräsentation einer Schema-Komponente für eineEinfache Typdefinition ist eine <simpleType> Element-Informationseinheit. Die Komponente und ihre Repräsentation korrespondieren wie folgt:

    XML Darstellung: simpleType Element Informationseinheit

    <simpleType
    final = (#all | (list | union | restriction))
    id = ID
    name = NCName
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?, (restriction | list | union))
    </simpleType>

    Datatype Definition Schemakomponente
    Eigenschaft Darstellung
    {Name} der tatsächliche Wert des name-Attributs, anderenfalls null
    {abgeschlossen} eine Menge von Werten, die vom aktuellen Wert des final-Attributs abhängt, falls das final-Attribut gesetzt ist, oder vom finalDefault-Attribut, wenn gesetzt, anderenfalls der leere String, wie folgt:
    der leere String
    die leere Menge;
    #all
    {restriction, list, union};
    anderenfalls
    eine Menge, deren Mitglieder aus der obigen Menge stammen und alle gesetzt oder nicht gesetzt sind, abhängig davon, ob der String einen gleichnamigen, durch Leerzeichen geteilten Unter-String enthält.

    Anmerkung:

    Obwohl das finalDefault-Attribut von schema andere Werte als restriction, list or union aufführen darf, werden diese ignoriert, wenn {abgeschlossen} angegeben ist.
    {Ziel-Namensraum} der tatsächliche Wert des targetNamespace-Attributs des Elternelements.
    {Anmerkung} die Anmerkung, die dem Inhalt des <annotation>-Elements entspricht, wenn gesetzt, anderenfalls null.

    Ein abgeleiteter Datentyp kann auf die drei folgenden Arten von einem primitiven oder abgeleiteten Datentyp abgeleitet sein: durch Einschränkung, durch Auflistung oder durch Vereinigung.

    4.1.2.1 Ableitung durch Einschränkung
    XML Darstellung: restriction Element Informationseinheit

    <restriction
    base = QName
    id = ID
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
    </restriction>

    Simple Type Definition Schemakomponente
    Eigenschaft Darstellung
    {Sorte} Der "tatsächliche Wert von {Sorte} in der {Basistyp-Definition}
    {Fassetten} Die Vereinigung der Menge von Fassetten (§2.4) Komponenten, nach denen durch die [Kinder] der Fassetten, die mit {Fassetten} der {Basistyp-Definition} verschmolzen sind, aufgelöst wird. Diese unterliegen den Fassetten-Gültigkeitsbeschränkungen in Fassetten (§2.4).
    {Basistyp-Definition} Die Komponente der Einfache Typdefinition, die durch die Angabe des base-Attributes oder des <simpleType>-Kindknotens entsteht.
    Beispiel
    Ein e-commerce-Schema könnte einen Datentyp namens tatsächlichen Wert (der Strichcode, der auf dem Produkt erscheint) definieren, indem es der pattern-Fassette des vordefiniert-Datentyps einen Wert zuweist.
    <simpleType name="Sku">
      <restriction base="string">
        <pattern value="\d{3}-[A-Z]{2}"/>
      </restriction>
    </simpleType>
    In diesem Fall ist Sku der Name des neuen benutzerdefinierten Datentyps, string ist dessen Basis-Typ und pattern ist die Fassette.
    4.1.2.2 Ableitung durch Auflistung
    XML Darstellung: list Element Informationseinheit

    <list
    id = ID
    itemType = QName
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?, (simpleType?))
    </list>

    Simple Type Definition Schemakomponente
    Eigenschaft Darstellung
    {Sorte} list
    {Definition eines Eintragstyps} Die Komponente der Einfache Typdefinition, die durch die Angabe des itemType [Attribut] entsteht.

    Ein Listen-Datentyp muss von einem atomaren oder einem Vereinigungs-Datatyp abgeleitet sein, dem sog. itemType des Listen-Datentyps. Daraus entsteht ein Datentyp, dessen Wertebereich aus Sequenzen endlicher Länge von Werten aus dem Wertebereich des itemType besteht und dessen lexikalischer Bereich sich aus durch Leerraum getrennte Listen von Literalen zusammensetzt.

    Beispiel
    Ein System, das Listen von Gleitkommazahlen aufnehmen soll:
    <simpleType name="listOfFloat">
      <list itemType="float"/>
    </simpleType>
    
    In diesem Fall ist listOfFloat der Name des neuen, abgeleiteten Datentyps, float steht für den itemType und Liste ist die Ableitungsmethode.

    Wie in Listen-Datentypen (§2.5.1.2) erwähnt, gibt es zu einem Datentyp, der von einem Listen-Datentyp abgeleitet ist, folgende einschränkende Fassetten:

    und zwar ungeachtet der einschränkenden Fassetten, die auf den atomaren Datentyp anwendbar sind, der als itemType dient.

    Die Einheit der Längenangabenlength, maxLength und minLength wird in der Anzahl von Listeneinträgen (list items) gemessen. Der Wert von whiteSpace ist unveränderbar der Collapse-Wert.

    4.1.2.3 Ableitung durch Vereinigung
    XML Darstellung: union Element Informationseinheit

    <union
    id = ID
    memberTypes = List of QName
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?, (simpleType*))
    </union>

    Simple Type Definition Schemakomponente
    Eigenschaft Darstellung
    {Sorte} Vereinigung
    {Definition eines Member-Typs} Die Sequenzen von Einfache Typdefinition-Komponenten, die durch den Eintrag im tatsächlichen Wert des memberTypes [Attributs] entsteht, falls ein solcher Eintrag existiert, gefolgt von den Einfache Typdefinition-Komponenten, die durch die Angabe der <simpleType> [Kindelemente] entstehen, sofern vorhanden. Falls {Sorte} union für Einfache Typdefinition-Komponenten ist, nach denen oben aufgelöst wurde, dann wird diese Einfache Typdefinition durch ihre {Definition eines Member-Typs} ersetzt.

    Ein Vereinigungs-Datentyp kann von einem oder mehreren atomaren, Listen- oder Vereinigungs-Datentypen abgeleitet sein. Das sind die sog. memberTypes dieses Vereinigungs-Datentyps.

    Beispiel
    In einem Beispiel aus einer typischen darstellungsorientierten Text Markup Language möchte man die Schriftgröße als integer zwischen 8 und 72 oder als eines der Tokens "small", "medium" oder "large" angeben. Mit dem im Folgenden definierten Vereinigungs-Datentyp kann das erreicht werden:
    <xsd:attribute name="size">
      <xsd:simpleType>
        <xsd:union>
          <xsd:simpleType>
            <xsd:restriction base="xsd:positiveInteger">
              <xsd:minInclusive value="8"/>
              <xsd:maxInclusive value="72"/>
            </xsd:restriction>
          </xsd:simpleType>
          <xsd:simpleType>
            <xsd:restriction base="xsd:NMTOKEN">
              <xsd:enumeration value="small"/>
              <xsd:enumeration value="medium"/>
              <xsd:enumeration value="large"/>
            </xsd:restriction>
          </xsd:simpleType>
        </xsd:union>
      </xsd:simpleType>
    </xsd:attribute>
    
    <p>
    <font size="large">A header</font>
    </p>
    <p>
    <font size="12">this is a test</font>
    </p>
    

    Wie in Vereinigungs-Datentypen (§2.5.1.3) erwähnt, können für einen von einem Vereinigungs-Datentyp abgeleiteten Datentyp nur folgende einschränkende Fassetten verwendet werden:

    unabhängig von den einschränkenden Fassetten, die auf die an der Vereinigung beteiligten Datentypen anwendbar sind.

    4.1.3 Reglementierungen auf der XML-Repräsentation einfacher Schema-Komponenten zur Typ-Definition

    Schema Darstellungs-Beschränkung: Einzelner Fassetten-Wert
    Solange es diese Spezifikation nicht ausdrücklich gestattet, Mehrere pattern (§4.3.4.3) und Mehrere Aufzählungen (§4.3.5.3)) anzugeben, darf jede einschränkende Fassette nur einmal pro Ableitungsstufe angegeben werden.
    Schema Darstellungs-Beschränkung: itemType-Attribute oder simpleType-Kindknoten
    Es muss entweder das base- [Attribut] der <restriction> oder aber das simpleType- [Kindelement] angegeben sein, beide zusammen sind nicht gestattet.
    Schema Darstellungs-Beschränkung: memberTypes-Attribute oder simpleType-Kindknoten
    Es muss entweder das memberTypes- [Attribut] der <union> angegeben sein, oder es gibt mindestens ein simpleType- [Kindelement].

    4.1.4 Regeln zur Validierung Einfacher Typdefinitionen

    Validierungsregel: Fassetten-gültig
    Ein Wert in einem Wertebereich ist Fassetten-gültig in Hinblick auf eine einschränkende Fassette, falls:
    1 der Wert Fassetten-gültig ist im Hinblick auf die einzelne einschränkende Fassette,die unten angegeben ist.
    Validierungsregel: Datentyp-gültig
    Eine Zeichenkette ist Datentyp-gültig im Hinblick auf eine Datentypdefinition, falls:
    1 sie einem Literal aus dem lexikalischen Bereich des Datentyps entspricht, wie im Folgenden angegeben:
    1.1 Falls die Menge {Fassetten} pattern enthält, muss die Zeichenkette pattern gültig (§4.3.4.4) sein;
    1.2 Ist pattern kein Mitglied von {Fassetten}, dann gilt:
    1.2.1 Ist {Sorte} atomar, muss die Zeichenkette einem Literal aus dem lexikalichen Bereich des {Basistyp-Definition} entsprechen.
    1.2.2 Ist {Sorte} eine Liste, muss die Zeichenkette eine Sequenz von durch Whitespaces getrennten Tokens sein, von denen jedes einem Literal aus dem lexikalischen Bereich der {Definition eines Eintragstyps} entsprechen muss.
    1.2.3 Ist {Sorte} eine Vereinigung, muss die Zeichenkette einem Literal aus dem lexikalischen Bereich mindesten eines Mitglieds von {Definition eines Member-Typs} entsprechen.
    2 Der durch das entsprechende Literal bezeichnete Wert im vorigen Schritt ist ein Mitglied des Wertebereichs des Datenyps. Wie durch seine Fassetten-Gültigkeit in §4.1.4 bestimmt, ist er Fassetten-gültig (§4.1.4) im Hinblick auf alle Mitglieder von {Fassetten} (außer von pattern).

    4.1.5 Reglementierungen auf einfache Komponenten zur Typdefinition

    Schema Komponenten Beschränkung: einsetzbare Fassetten
    Die einschränkenden Fassetten, die Mitglieder der {Fassetten} sein können, beruhen auf der {Basistyp-Definition}, wie in den folgenden Tabelle spezifiziert wird:
    {Basistypdefinition} anwendbare {Fassetten}
    Wenn {variety} list ist, dann
    [alle Datentypen] length, minLength, maxLength, pattern, enumeration, whiteSpace
    Wenn {variety} union ist, dann
    [Alle Datentypen] pattern, enumeration
    andernfalls, wenn {variety} atomic ist, dann
    string length, minLength, maxLength, pattern, enumeration, whiteSpace
    boolean pattern, whiteSpace
    float pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    double pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    decimal totalDigits, fractionDigits, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
    duration pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    dateTime pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    time pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    date pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    gYearMonth pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    gYear pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    gMonthDay pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    gDay pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    gMonth pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
    hexBinary length, minLength, maxLength, pattern, enumeration, whiteSpace
    base64Binary length, minLength, maxLength, pattern, enumeration, whiteSpace
    anyURI length, minLength, maxLength, pattern, enumeration, whiteSpace
    QName length, minLength, maxLength, pattern, enumeration, whiteSpace
    NOTATION length, minLength, maxLength, pattern, enumeration, whiteSpace
    Schema Komponenten Beschränkung: Liste der atomaren Datentypen
    Schema Komponenten Beschränkung: keine cirkulären Vereinigungen
    Falls {Sorte} vom Typ Vereinigung ist, dann handelt es sich um einen Fehler, wenn {Name} und {Ziel-Namensraum} {Name} und {Ziel-Namensraum} jedes Mitglieds der {Definition eines Member-Typs} entsprechen würden.

    4.1.6 Einfache Typdefinitionen für anySimpleType

    Es gibt eine Definition eines einfachen Datentyps, die annähernd der Urtypdefinition entspricht, die es in jedem Schema per Definition gibt. Sie hat die folgenden Eigenschaften:

    Schema Komponente: anySimpleType
    {Name}
    anySimpleType
    {Ziel-Namensraum}
    http://www.w3.org/2001/XMLSchema
    {Ziel-Namensraum}
    die Definition des Urtyps
    {Basistyp-Definition}
    die leere Menge
    {Sorte}
    fehlt

    previous sub-sectionnext sub-section4.2 Grundlegende Fassetten

    4.2.1 gleich
    4.2.2 geordnet
    4.2.5 numerisch

    4.2.1 gleich

    In jedem Wertebereich gibt es den Begriff der Gleichheit mit den folgenden Regeln:

    • Für ein beliebiges a und b im Wertebereich gilt, a ist entweder gleich b, geschrieben a = b, oder a ist ungleich b, geschrieben a != b.
    • Es gibt kein Wertepaar a und b im Wertebereich, für das gilt sowohl a = b als auch a != b zutrifft.
    • Für jedes a im Wertebereich gilt a = a.
    • Für ein beliebiges a und b im Wertebereich gilt, a = b, nur wenn role="eq">b = a ist.
    • Für beliebige a, b und c im Wertebereich gilt, wenn a = b und b = c, dann a = c.
    • Für ein beliebiges a und b im Wertebereich gilt, ist a = b, so sind a und b nicht unterscheidbar (z. B. Gleichheit ist Identität).

    Zu beachten ist, dass als eine Konsequenz aus den oben beschriebenen Regeln Folgendes gilt: Gegeben seien ein WertebereichA und ein WertebereichB, die weder durch Einschränkung noch eine Vereinigung miteinander in Verbindung stehen, für jedes Wertepaar (a, b) mit a aus A und b aus B ist a != b.

    Auf jedem Datentyp ist die Operation Equal über die equality- Eigenschaft eines Wertebereichs definiert: für beliebige Werte a und b aus einem Wertebereich gilt, Equal(a, b) ist wahr, wenn a = b ist.

    Anmerkung:

    Es gibt keine Schema-Komponente, die der grundlegenden Fassette equal enspricht.

    4.2.2 geordnet

    [Definition:] Eine Ordnungsbeziehung auf einem Wertebereich ist eine mathematische Beziehung, die den Mitgliedern des Wertebereichs eine totale Ordnung oder partielle Ordnung auferlegt.

    [Definition:] Ein Wertebereich und damit ein Datentyp wird als geordnet bezeichnet, wenn dafür eine Ordnungsbeziehung definiert ist.

    [Definition:] Eine partielle Ordnung ist eine Ordnungsbeziehung, die irreflexiv, asymmetrisch und transitiv ist.

    Eine partielle Ordnung hat die folgenden Eigenschaften:

    • Es gibt kein a im Wertebereich, für das gilt a < a (Irreflexivität).
    • Für alle a und b aus dem Wertebereich gilt, ist a < b, dann ist nicht (b < a) (Asymmetrie).
    • Für alle a, b und c aus dem Wertebereich gilt, ist a < b und b < c, dann ist auch a < c (Transitivität).

    Die Notation a <> b bedeutet, dass a != b und weder a < b noch b < a ist.

    [Definition:] Eine totale Ordnung ist eine partielle Ordnung, für die gilt, dass kein a und b angegeben werden kann, für das gilt, a <> b.

    Eine totale Ordnung besitzt alle Attribute, die oben für die partielle Ordnung angegeben sind, und zusätzlich die folgenden:

    • Für jedes a und b aus dem Wertebereich gilt entweder a < b, b < a oder a = b.

    Anmerkung:

    Die Tatsache, dass in dieser Spezifikation keine Ordnungsbeziehung für einige Datentypen definiert wird, bedeutet nicht, dass andere Applikationen jene Datentypen nicht als geordnet behandeln dürfen, indem sie ihnen eine eigene Ordnungsbeziehung aufprägen.

    Geordnet gibt an,

    4.2.2.1 Die ordered Schema-Komponente
    Schema Komponente: ordered
    {geordneter Wert}
    einer aus {false, partial, total}.

    {geordneter Wert} stützt sich auf {Sorte}, {Fassetten} und {Definition eines Member-Typs} aus den Komponenten der Einfache Typdefinition, in denen es auch eine geordnet-Komponente als Mitglied der {grundlegende Fassetten} gibt.

    Wenn {Sorte}atomar ist, dann wird {geordneter Wert} von {geordneter Wert} der {Basistyp-Definition} abgeleitet, wie für jeden primitiven Typ, wie in der Tabelle in (§) spezifiziert.

    Wenn {Sorte} eine Liste ist, dann ist {geordneter Wert}false.

    Wenn {Sorte} eine Vereinigung ist, und wenn {geordneter Wert} eines jeden Mitglieds der {Definition eines Member-Typs}true ist, und alle Mitglieder der {Definition eines Member-Typs} einen gemeinsamem Vorfahren haben, dann ist {geordneter Wert}true; anderenfalls false.

    4.2.3 beschränkt

    [Definition:] Ein Wert u aus dem geordneten Wertebereich U wird als obere inklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von U), wenn für alle v aus V gilt u >= v.

    [Definition:] Ein Wert u aus dem geordneten Wertebereich U wird als obere exklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von U), wenn für alle v aus V gilt u > v.

    [Definition:] Ein Wert l aus dem geordneten Wertebereich L wird als untere inklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von L), wenn für alle v aus V gilt u <= v.

    [Definition:] Ein Wert l aus dem geordneten Wertebereich L wird als untere exklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von L), wenn für alle v aus V gilt u < v.

    [Definition:] Ein Datentyp ist beschränkt, wenn sein Wertebereich entweder eine obere inklusive Schranke oder obere exklusive Schranke bzw. entweder eine untere inklusive Schranke oder eine untere exklusive Schranke hat.

    bounded gibt an,

    4.2.3.1 Die bounded Schema-Komponente
    Schema Komponente: bounded

    {Wert} hängt von {Sorte}, {Fassetten} und der {Definition eines Member-Typs} in den Komponenten der Einfache Typdefinition ab, in denen es eine beschränkt-Komponente als Teil der {grundlegende Fassetten} gibt.

    Ist {Sorte}atomar und es ist minInclusive oder minExclusive sowie maxInclusive or maxExclusive aus den {Fassetten} gesetzt, dann ist {Wert}true; anderenfalls ist {Wert}false

    Ist {Sorte} eine Liste und es gehört {Wert}, minLength oder maxLength zu den {Fassetten}, dann ist {Wert}true; anderenfalls ist {Wert}false.

    Ist {Sorte} eine Vereinigung und {Wert} ist true für jedes Mitglied der {Definition eines Member-Typs} und alle Mitglieder der {Definition eines Member-Typs} sind von einer gemeinsamen Basis abgeleitet, dann ist {Wert}true; anderenfalls ist {Wert}false.

    4.2.4 Kardinalität

    [Definition:] Jeder Wertebereich trägt das Konzept der Kardinalität mit sich. Einige Wertebereiche sind endlich, einige sind abzählbar unendlich, während andere überabzählbar unendlich sein könnten (obwohl in dieser Spezifikation kein überabzählbar unendlicher Wertebereich definiert wird). Man sagt, ein Datentyp hat die Kardinalität seines Wertebereichs.

    In manchen Fällen ist es nützlich, Wertebereiche (und damit Datentypen) nach ihrer Kardinalität zu kategorisieren. Es gibt zwei signifikante Fälle:

    Kardinalität gibt an

    4.2.4.1 Die Schema-Komponenten zur Kardinalität
    Schema Komponente: Kardinalität
    {Kardinalitätswert}
    Einer der Werte {finite, countably infinite}.

    {Kardinalitätswert} hängt von {Sorte}, {Fassetten} und {Definition eines Member-Typs} in den Komponenten der Einfache Typdefinition ab, in denen es auch eine Komponente Kardinalität als Mitglied der {grundlegende Fassetten} gibt.

    Ist {Sorte}atomar und {Kardinalitätswert} ist finite (endlich), dann ist {Kardinalitätswert}finite.

    Ist {Sorte}atomar und {Kardinalitätswert} ist countably infinite (abzählbar unendlich), und eine der folgenden Bedingen ist erfüllt, dann ist {Kardinalitätswert}finite; anderenfalls countably infinite:

    1. Einer der Werte aus den {Fassetten} ist gesetzt: length, maxLength, totalDigits.
    2. Alle der folgenden Aussagen sind wahr:
      1. Entweder minInclusive oder minExclusive aus den {Fassetten} ist gesetzt.
      2. Entweder maxInclusive oder maxExclusiveaus den {Fassetten} ist gesetzt.
      3. Eine der folgenden Aussagen ist wahr:
        1. fractionDigits aus den {Fassetten} ist gesetzt.
        2. {Basistyp-Definition} entspricht date, gYearMonth, gYear, gMonthDay, gDay oder gMonth oder einem von diesen abgeleiteten Typ.

    Ist {Sorte} eine Liste und length oder minLength und maxLength gehören zu den {Fassetten}, so ist {Kardinalitätswert} is finite (endlich), anderenfalls countably infinite (abzählbar unendlich).

    Ist {Sorte} eine Vereinigung und {Kardinalitätswert} ist finite für jedes einzelne Mitglied der {Definition eines Member-Typs}, so ist {Kardinalitätswert}finite, anderenfalls countably infinite.

    4.2.5 numerisch

    [Definition:] Man bezeichnet einen Datentyp als numerisch, wenn seine Werte Begriffe für Quantitäten (in einem beliebigen mathematischen Zahlensystem) darstellen.

    [Definition:] Ein Datentyp, dessen Werte nicht numerisch sind, wird als nicht numerisch (non-numeric) bezeichnet.

    numerisch zeigt an

    4.2.5.1 Die numerisch-Schema-Komponente
    Schema Komponente: numerisch

    {Wert} hängt von {Sorte}, {Fassetten}, {Basistyp-Definition} und {Definition eines Member-Typs} in den Komponenten der Einfache Typdefinition ab, in denen es auch eine Kardinalität-Komponente als Mitglied der {grundlegende Fassetten} gibt.

    Ist {Sorte}atomar, so ist {Wert} von {Wert} der {Basistyp-Definition}abgeleitet. Für alle primitiven Datentypen ist {Wert} in der Tabelle in (§) spezifiziert.

    Ist {Sorte} eine Liste, so ist {Wert}false.

    Ist {Sorte} eine Vereinigung und {Wert} ist true für jedes Mitglied der {Definition eines Member-Typs}, so ist {Wert}true, anderenfalls false.

    previous sub-section4.3 Einschränkende Fassetten

    4.3.1 length
    4.3.2 minLength
    4.3.3 maxLength
    4.3.4 pattern

    4.3.1 length

    [Definition:] length gibt die Anzahl der Längeneinheiten an, wobei die Längeneinheiten je nach Typ, von dem abgeleitet wird, variieren. Der Wert von length muss vom Typ nonNegativeInteger sein.

    Bei string und Datentypen, die von stringabgeleitet sind, wird length in Zeichen ( character: siehe Definition in [XML 1.0 (Second Edition)]) gemessen. Bei anyURI, wird die Länge length wie bei string in Einheiten vom Typ Zeichen gemessen. Length von Daten vom Typ hexBinary, base64Binary und Datentypen, die von ihnen abgeleitet sind, wird in Oktetten (8 bits) binärer Daten gemessen. Bei Datentypen, die von Listeabgeleitet sind, gibt length die Anzahl der Einträge der Liste an.

    Anmerkung:

    Bei string und Datentypen, die von string abgeleitet sind, wird length nicht immer der "Zeichenkettenlänge" entsprechen, die vom Benutzer wahrgenommen wird. Ebenso muss sie nicht mit der Anzahl von Speichereinheiten in einer digitalen Darstellung übereinstimmen. Deshalb sollte man vorsichtig sein, wenn man einen Wert für length angibt oder versucht, auf Speicherplatzanforderungen von einem gegebenen Wert length zu schließen.

    length hat folgende Funktion:

    Beispiel
    im Folgenden ist die Definition eines benutzerdefinierten Datentyps für tatsächliche Werte, die genau 8 Zeichen lang sein müssen, dargestellt. Durch das Setzen der Eigenschaft "fixed='true'" für length stellen wir sicher, dass in Datentypen, die von tatsächlichen Wert abgeleitet sind, die Werte anderer Eigenschaften, wie zum Beispiel pattern, gesetzt oder verändert werden können; jedoch kann die Länge length nicht geändert werden.
    <simpleType name="tatsächlichen Wert">
       <restriction base="string">
         <length value="8" fixed="true"/>
       </restriction>
    </simpleType>
    4.3.1.1 Die length-Schemakomponente
    Schema Komponente: length
    {Wert}
    Ein Wert vom Typ nonNegativeInteger.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für length angeben, der ungleich {Wert} ist.

    4.3.1.2 XML-Darstellung von length-Schemakomponenten

    Die XML-Darstellung einer length Schemakomponente ist eine <length> Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: length Element Informationseinheit

    <length
    fixed = boolean : false
    id = ID
    value = nonNegativeInteger
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </length>

    length Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'
    {Anmerkung} Die Anmerkungen, die mit allen <annotation> Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.1.3 Regeln zur Validation von length
    Validierungsregel: length gültig
    Ob ein Wert in einem Wertebereich Wertebereich Fassetten-gültig ist hinsichtlich length, ist folgendermaßen bestimmt:
    1 Wenn die {Sorte} atomar ist, dann:
    1.1 Wenn {primitive Typ-Definition} vom Typ string ist, dann muss die in Zeichen gemessene Länge des Wertes gleich {Wert}sein;
    1.2 Wenn {primitive Typ-Definition} vom Typ hexBinary oder base64Binary ist, dann muss die in Oktetten binärer Daten gemessene Länge des Wertes gleich {Wert}sein;
    2 Wenn die {Sorte} vom Typ Listeist, dann muss die Anzahl der Listeneinträge des Wertes gleich {Wert}sein
    4.3.1.4 Regeln für length-Schemakomponenten
    Schema Komponenten Beschränkung: length und minLength oder maxLength
    Wenn length und entweder minLength oder maxLength Mitglieder einer Menge von {Fassetten} sind, so ist dies ein Fehler.
    Schema Komponenten Beschränkung: length Gültigkeitsbeschränkung
    Wenn length zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} gehört und der Wert {Wert} nicht gleich dem Wert {Wert} der Länge length im Elternelement ist, so ist dies ein Fehler.

    4.3.2 minLength

    [Definition:] minLength gibt die minimale Anzahl von Längeneinheiten an, wobei die Längeneinheiten je nach Typ, von dem abgeleitet wird, variieren. Der Wert von minLength muss vom Typ nonNegativeInteger sein.

    Bei string und Datentypen, die von stringabgeleitet sind, wird minLength in Zeichen ( character: siehe Definition in [XML 1.0 (Second Edition)]) gemessen. Bei hexBinary, base64Binary und Datentypen, die von ihnen abgeleitet sind, wird minLength in Oktetten (8 Bit) binärer Daten gemessen. Bei Datentypen, die von Liste abgeleitet sind, gibt minLength die Anzahl der Einträge der Liste an.

    Anmerkung:

    Bei string und Datentypen, die von string abgeleitet sind, wird minLength nicht immer der "Zeichenkettenlänge" entsprechen, die vom Benutzer wahrgenommen wird. Ebenso muss sie nicht mit der Anzahl von Speichereinheiten in einer digitalen Darstellung übereinstimmen. Deshalb sollte man vorsichtig sein, wenn man einen Wert für minLength angibt oder versucht, auf Speicherplatzanforderungen von einem gegebenen Wert minLength zu schließen.

    minLength hat folgende Funktion:

    • Einen Wertebereich auf Werte mit mindestens einer bestimmten Anzahl von Längeneinheiten zu beschränken, wobei die Längeneinheiten je nach {Basistyp-Definition} variieren.
    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser Datentyp fordert von Zeichenketten, dass sie mindestens ein Zeichen haben (d.h. eine leere Zeichenkette liegt nicht im Wertebereich dieses Datentyps).
    <simpleType name="nicht-leere-Zeichenkette">
      <restriction base="string">
        <minLength value="1"/>
      </restriction>
    </simpleType>
    4.3.2.1 Die minLength-Schemakomponente
    Schema Komponente: minLength
    {Wert}
    Ein Wert vom Typ nonNegativeInteger.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für minLength angeben, der ungleich {Wert} ist.

    4.3.2.2 XML-Darstellung der minLength-Schemakomponente

    Die XML-Darstellung einer minLength-Schemakomponente ist eine <minLength>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: minLength Element Informationseinheit

    <minLength
    fixed = boolean : false
    id = ID
    value = nonNegativeInteger
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </minLength>

    minLength Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelemente] übereinstimmen, wenn welche vorhanden sind.
    4.3.2.3 minLength-Validationsregeln
    Validierungsregel: minLength gültig
    Ob ein Wert in einem Wertebereich hinsichtlich minLength fassetten-gültig ist, ist folgendermaßen bestimmt:
    1 Wenn die {Sorte} atomar ist, dann
    1.1 Wenn die {primitive Typ-Definition} vom Typ string ist, dann muss die in Zeichen gemessene Länge des Wertes größer oder gleich {Wert} sein;
    1.2 Wenn die {primitive Typ-Definition} hexBinary oder base64Binary ist, dann muss die in Oktetten von binären Daten gemessene Länge des Wertes größer oder gleich {Wert} sein;
    2 Wenn die {Sorte} Liste ist, dann muss die Anzahl der Listeneinträge des Wertes größer oder gleich {Wert} sein.
    4.3.2.4 Regeln für minLength-Schemakomponenten
    Schema Komponenten Beschränkung: minLength <= maxLength
    Wenn sowohl minLength als auch maxLength Mitglieder einer Menge von {Fassetten} sind, dann muss {Wert} von minLength kleiner oder gleich dem Wert {Wert} von maxLength sein.
    Schema Komponenten Beschränkung: minLength-Gültigkeitsbeschränkung
    Wenn minLength zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} gehört und {Wert} kleiner als {Wert} von minLength im Elternelement ist, so ist dies ein Fehler.

    4.3.3 maxLength

    [Definition:] maxLength gibt die maximale Anzahl von Längeneinheiten an, wobei die Längeneinheiten je nach Typ, von dem abgeleitet wird, variieren. Der Wert von maxLength muss vom Typ nonNegativeInteger sein.

    Bei string und Datentypen, die von stringabgeleitet sind, wird maxLength in Zeichen (character: siehe Definition in [XML 1.0 (Second Edition)] gemessen. Bei hexBinary, base64Binary und Datentypen, die von ihnen abgeleitet sind, wird maxLength in Oktetten (8 Bit) binärer Daten gemessen. Bei Datentypen, die von Listeabgeleitet sind, gibt maxLength die Anzahl der Einträge der Liste an.

    Anmerkung:

    Bei string und Datentypen, die von string abgeleitet sind, wird maxLength nicht immer der "Zeichenkettenlänge" entsprechen, die vom Benutzer wahrgenommen wird. Ebenso muss sie nicht mit der Anzahl von Speichereinheiten in einer digitalen Darstellung übereinstimmen. Deshalb sollte man vorsichtig sein, wenn man einen Wert für maxLength angibt oder versucht, auf Speicherplatzanforderungen von einem gegebenen Wert maxLength zu schließen.

    maxLength hat folgende Funktion:

    • Ein Wertebereich auf Werte mit höchstens einer bestimmten Anzahl von Längeneinheiten zu beschränken, wobei die Längeneinheiten je nach {Basistyp-Definition} variieren.
    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser könnte verwendet werden, um nur Eingaben in ein Formular mit einer Anzahl von Zeichen, die unter einer oberen Schranke liegen, zu akzeptieren.
    <simpleType name='Formular-Eingabe'>
      <restriction base="string">
        <maxLength value="50"/>
      </restriction>
    </simpleType>
    4.3.3.1 Die maxLength-Schemakomponente
    Schema Komponente: maxLength
    {Wert}
    Ein Wert vom Typ nonNegativeInteger.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für maxLength angeben, der ungleich {Wert} ist.

    4.3.3.2 XML-Darstellung der maxLength-Schemakomponenten

    Die XML-Darstellung einer maxLength-Schemakomponente ist eine <maxLength> Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: maxLength Element Informationseinheit

    <maxLength
    fixed = boolean : false
    id = ID
    value = nonNegativeInteger
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </maxLength>

    maxLength Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'.
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.3.3 maxLength-Validationsregeln
    Validierungsregel: maxLength gültig
    Ob ein Wert in einem Wertebereich hinsichtlich maxLength Fassetten-gültig ist, ist folgendermaßen bestimmt:
    1 Wenn die {Sorte} atomar ist, dann gilt:
    1.1 Wenn die {primitive Typ-Definition} vom Typ string ist, dann muss die in Zeichen gemessene Länge des Wertes kleiner oder gleich {Wert} sein;
    1.2 Wenn die {primitive Typ-Definition} vom Typ hexBinary oder base64Binary ist, dann muss die in Oktetten binärer Daten gemessene Länge des Wertes kleiner oder gleich {Wert} sein;
    2 Wenn die {Sorte} vom Typ Liste ist, dann muss die Anzahl der Listeneinträge des Wertes kleiner oder gleich {Wert} sein.
    4.3.3.4 Regeln für maxLength-Schemakomponenten
    Schema Komponenten Beschränkung: maxLength-Gültigkeitsbeschränkung
    Wenn maxLength zu den Mitgliedern einer Menge von {Fassetten} einer {Basistyp-Definition} gehört und der Wert {Wert} größer als {Wert} von maxLength im Elternelement ist, so ist dies ein Fehler.

    4.3.4 pattern

    [Definition:] pattern ist eine Beschränkung des Wertebereich eines Datentyps; dies wird erreicht, indem der lexikalische Bereich auf Literale beschränkt wird, die in ein bestimmtes Muster passen. Der Wert von pattern muss ein regulärer Ausdruck sein.

    pattern hat folgende Funktion:

    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps abgebildet; dieser stellt Postleitzahlen in den USA besser dar, indem er nur Zeichenketten zuläßt, die auf einen bestimmten regulärer Ausdruck passen.
    <simpleType name="US-Postleitzahl">
      <restriction base="string">
        <pattern value="[0-9]{5}(-[0-9]{4})?"/>
      </restriction>
    </simpleType>
    4.3.4.1 Die pattern-Schemakomponente
    Schema Komponente: pattern
    4.3.4.2 XML-Darstellung von pattern-Schemakomponenten

    Die XML-Darstellung für eine pattern-Schemakomponente ist eine <pattern>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: pattern Element Informationseinheit

    <pattern
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </pattern>

    {Wert} muss muss ein gültiger regulärer Ausdruck sein.
    pattern Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Anmerkung} Die Anmerkungen, die mit allen <annotation> Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.4.3 Beschränkungen für die XML-Darstellung von pattern
    Schema Darstellungs-Beschränkung: Mehrere pattern
    Wenn mehrere <pattern> Element-Informationseinheiten als [Kindelemente] eines <simpleType> vorhanden sind, sollten die [Werte] so kombiniert werden, als ob sie in einem einzigen regulären Ausdruck als getrennte Äste auftreten würden.

    Anmerkung:

    Aus den Regeln für die Schema-Darstellung für Mehrere pattern (§4.3.4.3) und den Regeln für Einschränkung folgt, dass pattern-Fassetten, die im gleichen Schritt einer Typableitung definiert sind, mit Oder verbunden werden; jedoch werden pattern-Fassetten, die in verschiedenen Schritten einer Typableitung spezifiziert sind, mit Und verbunden.

    Deswegen können Autoren, wenn sie zwei Einschränkungen gleichzeitig erlassen wollen, dies entweder mit einem einzigen pattern tun, welches die Schnittmenge der beiden pattern, die sie zur Einschränkung verwenden wollen, bildet; oder sie definieren jedes pattern in einem separaten Schritt der Typableitung.
    4.3.4.4 pattern-Validationsregeln
    Validierungsregel: pattern gültig
    Ein Literal in einem lexikalischen Bereich ist hinsichtlich eines pattern Fassetten-gültig, wenn:
    1 Das Literal zu den Zeichenketten gehört, die der regulärer Ausdruck, der in {Wert} spezifiziert ist, bezeichnet.

    4.3.5 enumeration

    [Definition:] Die Aufzählung enumeration beschränkt den Wertebereich auf bestimmte benannte Werte.

    enumeration legt keine Reihenfolge in seinem geschaffenen Wertebereich fest; der Wert der geordnet-Eigenschaft des Datentyps, von dem abgeleitet wird, bleibt für den abgeleiteten Datentyp bestehen.

    enumeration hat folgende Funktion:

    • Eine Wertebereich auf bestimmte benannte Werte zu beschränken.
    Beispiel
    Im Folgenden ist eine Datentypdefinition eines benutzerdefinierten Datentyps dargestellt, der die Werte von Daten auf 3 aufgezählte US-Feiertage beschränkt. Diese Datentypdefinition würde in einem Schema auftauchen, das von einem "Endnutzer" geschrieben wurde und zeigt, wie man einen Datentyp definiert, indem man die Werte in seinem Wertebereich auflistet. Die aufgezählten Werte müssen Literale sein, die type-valid für den Basistyp sind.
    <simpleType name="US-Feiertage">
        <annotation>
            <documentation>einige US-Feiertage</documentation>
        </annotation>
        <restriction base="gMonthDay">
          <enumeration value="--01-01">
            <annotation>
                <documentation>Neujahr</documentation>
            </annotation>
          </enumeration>
          <enumeration value="--07-04">
            <annotation>
                <documentation>4. Juli</documentation>
            </annotation>
          </enumeration>
          <enumeration value="--12-25">
            <annotation>
                <documentation>Weihnachten</documentation>
            </annotation>
          </enumeration>
        </restriction>
    </simpleType>
    4.3.5.1 Die enumeration-Schemakomponente
    Schema Komponente: enumeration
    {Wert}
    Eine Liste von Werten aus dem Wertebereich der {Basistyp-Definition}.
    {Anmerkung}
    Optional. Eine Anmerkung.
    4.3.5.2 XML-Darstellung von enumeration-Schemakomponenten

    Die XML-Darstellung einer enumeration-Schemakomponente ist eine <enumeration>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: enumeration Element Informationseinheit

    <enumeration
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </enumeration>

    enumeration Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Anmerkung} Die Anmerkungen, die mit allen <annotation> Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.5.3 Beschränkungen für die XML-Darstellung von enumeration
    Schema Darstellungs-Beschränkung: Mehrere Aufzählungen
    Wenn mehrere <enumeration>-Element-Informationseinheiten als [Kindelemente] eines <simpleType> existieren, sollte der Wert {Wert} der enumeration-Komponente die Menge aller solchen [Wert]e sein.
    4.3.5.4 enumeration-Validationsregeln
    Validierungsregel: enumeration gültig
    Ein Wert in einem Wertebereich ist Fassetten-gültig hinsichtlich enumeration, wenn der Wert einer der Werte ist, die in {Wert} angegeben sind.
    4.3.5.5 Beschränkungen für enumeration-Schemakomponenten
    Schema Komponenten Beschränkung: enumeration-Gültigkeitsbeschränkung
    Wenn ein Mitglied von {Wert} nicht im Wertebereich der {Basistyp-Definition} liegt, so ist dies ein Fehler.

    4.3.6 whiteSpace

    [Definition:] whiteSpace beschränkt den Wertebereich von Typen, die von string abgeleitet sind so, dass verschiedene Verhaltensweisen, die in Attribute Value Normalization in [XML 1.0 (Second Edition)] spezifiziert sind, in Kraft treten. Der Wert von whiteSpace muss einer der folgenden sein: {preserve, replace, collapse}.

    preserve
    Keine Normalisierung wird ausgeführt, der Wert wird nicht verändert. (Dies ist das Verhalten, das in [XML 1.0 (Second Edition)] für Elementinhalte verlangt wird.)
    replace
    Jedes #x9 (Tabulator)-, #xA (Zeilenvorschub)- und #xD (Wagenrücklauf)-Zeichen wird durch #x20 (space) ersetzt.
    collapse
    Nach der Verarbeitung, wie sie replace vorsieht, werden aufeinander folgende Vorkommen von #x20's auf ein einziges #x20 gekürzt, und #x20, die entweder als Präfix oder Suffix vorhanden sind, werden entfernt.

    Anmerkung:

    Die Notation #xA, die hier (und in anderen Abschnitten der Spezifikation) verwendet wird, ist eine Darstellung des Universal Character Set (UCS) Codes für ein hexadezimales A (Zeilenvorschub); dieser wird als U+000A abgebildet. Die Notation muss von &#xA; unterschieden werden, da dies die XML character reference für denselben UCS Code ist.

    whiteSpace ist auf alle atomaren- und Listen- Datentypen anwendbar. Für alle anderen atomaren Datentypen außer string (und Typen, die durch Einschränkung davon abgeleitet sind) ist der Wert von whiteSpacecollapse und kann vom Schema-Autor nicht geändert werden; für string ist der Wert von whiteSpacepreserve; für jeden Typ, der durch Einschränkung von stringabgeleitet ist, kann der Wert von whiteSpace einer der drei zulässigen Werte sein. Für alle Datentypen, die von Listeabgeleitet sind, ist der Wert von whiteSpacecollapse und kann nicht von einem Schema-Autor geändert werden. Für alle Datentypen, die durch Vereinigungabgeleitet sind, findet whiteSpace keine direkte Anwendung; jedoch wird das Verhalten von Vereinigungs-Typen - was Normalisierung anbelangt - durch den Wert von whiteSpace bestimmt, der indem memberTypes angegeben ist, gegen den die Vereinigung erfolgreich validiert wird.

    Anmerkung:

    Mehr Informationen über whiteSpace finden Sie in der Diskussion über die Normalisierung von Leerraum in: Details über Schemakomponenten in [XML Schema Part 1: Structures].

    whiteSpace hat folgende Funktion:

    • Ein Wertebereich nach seinen Leerraum-Normalisierungsregeln zu beschränken.
    Beispiel
    Im Folgenden ist die Datentypdefinition für den vordefinierten, abgeleiteten token-Datentyp dargestellt.
    <simpleType name="token">
        <restriction base="normalizedString">
          <whiteSpace value="collapse"/>
        </restriction>
    </simpleType>
    4.3.6.1 Die whiteSpace-Schemakomponente
    Schema Komponente: whiteSpace
    {Wert}
    Eines von {preserve, replace, collapse}.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für whiteSpace angeben, der ungleich {Wert} ist.

    4.3.6.2 XML-Darstellung von whiteSpace-Schemakomponenten

    Die XML-Darstellung einer whiteSpace-Schemakomponente ist eine <whiteSpace>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: whiteSpace Element Informationseinheit

    <whiteSpace
    fixed = boolean : false
    id = ID
    value = (collapse | preserve | replace)
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </whiteSpace>

    whiteSpace Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'.
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelemente] übereinstimmen, wenn welche vorhanden sind.
    4.3.6.3 whiteSpace-Validationsregeln

    Anmerkung:

    Es gibt keine Validierungsregeln für whiteSpace. Mehr Informationen finden Sie in der Diskussion über die Normalisierung von Leerraum in: Details über Schemakomponenten in [XML Schema Part 1: Structures].
    4.3.6.4 Regeln für whiteSpace-Schemakomponenten
    Schema Komponenten Beschränkung: whiteSpace-Gültigkeitsbeschränkung
    Wenn whiteSpace zu den Mitgliedern einer Menge von {Fassetten} zählt und eine der folgenden Bedingungen zutrifft, so ist dies ein Fehler:
    1 Der Wert {Wert} ist replace oder preserve und {Wert} von whiteSpace im Elternelement ist collapse.
    2 Der Wert {Wert} ist preserve und {Wert} von whiteSpace im Elternelement ist replace.

    4.3.7 maxInclusive

    [Definition:] maxInclusive gibt die obere inklusive Schranke des Wertebereichs für einen Datentyp mit der geordnet-Eigenschaft an. Der Wert von maxInclusive muss im Wertebereich des Basistyp liegen.

    maxInclusive hat folgende Funktion:

    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Er begrenzt Werte auf Integer-Werte, die kleiner oder gleich 100 sind, indem er maxInclusive verwendet.
    <simpleType name="hundert-oder-weniger">
      <restriction base="integer">
        <maxInclusive value="100"/>
      </restriction>
    </simpleType>
    4.3.7.1 Die maxInclusive-Schemakomponente
    Schema Komponente: maxInclusive
    {Wert}
    Ein Wert aus dem Wertebereich der {Basistyp-Definition}.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für maxInclusive angeben, der ungleich {Wert} ist.

    4.3.7.2 XML-Darstellung einer maxInclusive-Schemakomponente

    Die XML-Darstellung einer maxInclusive-Schemakomponente ist eine <maxInclusive>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: maxInclusive Element Informationseinheit

    <maxInclusive
    fixed = boolean : false
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </maxInclusive>

    maxInclusive Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'.
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.7.3 maxInclusive-Validationsregeln
    Validierungsregel: maxInclusive gültig
    Ob ein Wert in einem geordneten Wertebereich Fassetten-gültig ist hinsichtlich maxInclusive, ist folgendermaßen festgelegt:
    1 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} true ist, dann muss der Wert als Zahl kleiner oder gleich {Wert} sein;
    2 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} false ist (beispielsweise, gehört die {Basistyp-Definition} zu den Datentypen, die mit Datum und Zeit verwandt sind), muss der Wert chronologisch kleiner oder gleich {Wert} sein;
    4.3.7.4 Regeln für maxInclusive-Schemakomponenten
    Schema Komponenten Beschränkung: minInclusive <= maxInclusive
    Wenn der in minInclusive angegebene Wert größer als der im selben Datentyp für maxInclusive angegebene Wert ist, so stellt dies einen Fehler dar.
    Schema Komponenten Beschränkung: maxInclusive-Gültigkeitsbeschränkung
    Es ist ein Fehler, wenn eine der nachstehenden Bedingungen zutrifft:
    1 maxInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer als {Wert} von maxInclusive im Elternelement.
    2 maxExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer oder gleich {Wert} von maxExclusive im Elternelement.
    3 minInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner als {Wert} von minInclusive im Elternelement.
    4 minExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner oder gleich {Wert} von minExclusive im Elternelement.

    4.3.8 maxExclusive

    [Definition:] maxExclusive gibt die obere exklusive Schranke des Wertebereichs eines Datentyps mit der geordnet Eigenschaft an. Der Wert von maxExclusive muss im Wertebereich des Basistyps liegen.

    maxExclusive hat folgende Funktion:

    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser begrenzt Werte auf Integer-Werte, die kleiner oder gleich 100 sind, indem maxExclusive verwendet wird.
    <simpleType name="kleiner-als-hundert-und-eins">
      <restriction base="integer">
        <maxExclusive value="101"/>
      </restriction>
    </simpleType>
    Bitte beachten Sie, dass der Wertebereich dieses Datentyps identisch mit dem vorhergehenden ist ('hundert-oder-weniger').
    4.3.8.1 Die maxExclusive-Schemakomponente
    Schema Komponente: maxExclusive
    {Wert}
    Ein Wert aus dem Wertebereich der {Basistyp-Definition}.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für maxExclusive angeben, der ungleich {Wert} ist.

    4.3.8.2 XML-Darstellung von maxExclusive-Schemakomponenten

    Die XML-Darstellung einer maxExclusive-Schemakomponente ist eine <maxExclusive>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: maxExclusive Element Informationseinheit

    <maxExclusive
    fixed = boolean : false
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </maxExclusive>

    maxExclusive Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.8.3 maxExclusive-Validationsregeln
    Validierungsregel: maxExclusive gültig
    Ob ein Wert in einem geordneten Wertebereich Fassetten-gültig ist hinsichtlich maxExclusive, ist folgendermaßen bestimmt:
    1 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} true ist, dann muss der Wert als Zahl kleiner als {Wert} sein;
    2 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} false ist (beispielsweise, gehört die {Basistyp-Definition} zu den Datentypen, die mit Datum und Zeit verwandt sind), muss der Wert chronologisch kleiner als {Wert} sein;
    4.3.8.4 Regeln für maxExclusive-Schemakomponenten
    Schema Komponenten Beschränkung: maxInclusive und maxExclusive
    Wenn sowohl maxInclusive als auch maxExclusive im selben Ableitungsschritt einer Datentypdefinition angegeben sind, so stellt dies einen Fehler dar.
    Schema Komponenten Beschränkung: minExclusive <= maxExclusive
    Wenn der für minExclusive angegebene Wert größer ist als der für maxExclusive für denselben Datentyp angegebene, so stellt dies einen Fehler dar.
    Schema Komponenten Beschränkung: maxExclusive-Gültigkeitsbeschränkung
    Es ist ein Fehler, wenn eine der nachfolgenden Bedingungen zutrifft.
    1 maxExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer als {Wert} von maxExclusive im Elternelement.
    2 maxInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer als {Wert} von maxInclusive im Elternelement.
    3 minInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner oder gleich {Wert} von minInclusive im Elternelement.
    4 minExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner oder gleich {Wert} von minExclusive im Elternelement.

    4.3.9 minExclusive

    [Definition:] minExclusive gibt die exklusive untere Schranke der Wertebereich eines Datentyps mit der geordnet Eigenschaft an. Der Wert von minExclusive muss im Wertebereich des Basistyps liegen.

    minExclusive hat folgende Funktion:

    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps abgebildet. Dieser begrenzt durch die Verwendung von minExclusive Werte auf Integer-Werte, die größer oder gleich 100 sind.
    <simpleType name="mehr-als-neun-und-neunzig">
      <restriction base="integer">
        <minExclusive value="99"/>
      </restriction>
    </simpleType>
    Bitte beachten Sie, dass der Wertebereich dieses Datentyps identisch mit dem vorhergehenden ist ('hundert-oder-mehr').
    4.3.9.1 Die minExclusive-Schemakomponente
    Schema Komponente: minExclusive
    {Wert}
    Ein Wert aus dem Wertebereich der {Basistyp-Definition}.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für minExclusive angeben, der ungleich {Wert} ist.

    4.3.9.2 XML-Darstellung von minExclusive-Schemakomponenten

    Die XML-Darstellung einer minExclusive Schemakomponente ist eine <minExclusive>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: minExclusive Element Informationseinheit

    <minExclusive
    fixed = boolean : false
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </minExclusive>

    minExclusive Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.9.3 minExclusive-Validationsregeln
    Validierungsregel: minExclusive gültig
    Ob ein Wert in einem geordneten Wertebereich hinsichtlich minExclusive Fassetten-gültig ist, ist folgendermaßen bestimmt:
    1 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} true ist, dann muss der Wert als Zahl größer sein als {Wert};
    2 Wenn die numerisch-Eigenschaft der {grundlegende Fassetten} false ist (beispielsweise, die {Basistyp-Definition} gehört zu den Datentypen, die mit Date und Time verwandt sind), dann muss der Wert chronologisch größer sein als {Wert};
    4.3.9.4 Regeln für minExclusive-Schemakomponenten
    Schema Komponenten Beschränkung: minInclusive und minExclusive
    Wenn sowohl minInclusive als auch minExclusive im selben Datentyp spezifiziert sind, so ist dies ein Fehler.
    Schema Komponenten Beschränkung: minExclusive < maxInclusive
    Wenn der für minExclusive angegebene Wert größer oder gleich dem im selben Datentyp angegebenen Wert maxInclusive ist, so ist dies ein Fehler.
    Schema Komponenten Beschränkung: minExclusive-Gültigkeitsbeschränkung
    Es ist ein Fehler, wenn eine der nachstehenden Bedingungen zutrifft:
    1 minExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner als {Wert} von minExclusive im Elternelement.
    2 maxInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer als {Wert} von maxInclusive im Elternelement.
    3 minInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner als {Wert} von minInclusive im Elternelement.
    4 maxExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer oder gleich {Wert} von maxExclusive im Elternelement.

    4.3.10 minInclusive

    [Definition:] minInclusive gibt die inklusive untere Schranke des Wertebereichs eines Datentyps mit der geordnet-Eigenschaft an. Der Wert von minInclusive muss im Wertebereich des Basistyps liegen.

    minInclusive hat folgende Funktion:

    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser begrenzt Werte durch die Verwendung von minInclusive auf Integer-Werte, die größer oder gleich 100 sind.
    <simpleType name="hundert-oder-mehr">
      <restriction base="integer">
        <minInclusive value="100"/>
      </restriction>
    </simpleType>
    4.3.10.1 Die minInclusive-Schemakomponente
    Schema Komponente: minInclusive
    {Wert}
    Ein Wert aus dem Wertebereich der {Basistyp-Definition}.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für minInclusive angeben, der ungleich {Wert} ist.

    4.3.10.2 XML-Darstellung von minInclusive-Schemakomponenten

    Die XML-Darstellung einer minInclusive-Schemakomponente ist eine <minInclusive>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: minInclusive Element Informationseinheit

    <minInclusive
    fixed = boolean : false
    id = ID
    value = anySimpleType
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </minInclusive>

    minInclusive Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'.
    {Anmerkung} Die Anmerkungen, die mit allen <annotation> Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.10.3 minInclusive-Validationsregeln
    Validierungsregel: minInclusive gültig
    Ein Wert in einem geordneten Wertebereich ist hinsichtlich minInclusive Fassetten-gültig , wenn:
    1 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} true true ist, dann muss der Wert als Zahl größer oder gleich {Wert} sein;
    2 Wenn die numerisch-Eigenschaft in den {grundlegende Fassetten} false ist (beispielsweise, wenn die {Basistyp-Definition} zu den Datentypen gehört, die mit Date und Time verwandt sind), dann muss der Wert chronologisch größer oder gleich {Wert} sein;
    4.3.10.4 Regeln für minInclusive-Schemakomponenten
    Schema Komponenten Beschränkung: minInclusive < maxExclusive
    Wenn der für minInclusive angegebene Wert größer oder gleich dem für denselben Datentyp angegebenen Wert maxExclusive ist, so ist dies ein Fehler.
    Schema Komponenten Beschränkung: minInclusive-Gültigkeitsbeschränkung
    Es ist ein Fehler, wenn eine der folgenden Bedingungen zutrifft:
    1 minInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist kleiner als {Wert} von minInclusive im Elternelement.
    2 maxInclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer als {Wert} von maxInclusive im Elternelement.
    3 minExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} de {Basistyp-Definition} und {Wert} ist kleiner oder gleich {Wert} von minExclusive im Elternelement.
    4 maxExclusive gehört zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} und {Wert} ist größer oder gleich {Wert} von maxExclusive im Elternelement.

    4.3.11 totalDigits

    [Definition:] totalDigits gibt die maximale Anzahl von Dezimalstellen in Werten an, die von decimal abgeleitet sind. Der Wert von totalDigits muss von Typ positiveInteger sein.

    totalDigits hat folgende Funktion:

    • Einen Wertebereich auf Werte mit einer bestimmten maximalen Anzahl von Dezimalstellen (#x30-#x39) zu beschränken.
    Beispiel
    Im Folgenden ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser könnte verwendet werden, um Geldsummen in einer Finanz-Anwendung abzubilden, die keine Zahlen haben soll, die größer als eine Million Euro sind und nur ganze Cents erlaubt. Diese Definition würde in einem Schema vorkommen, das von einem "Endnutzer" geschrieben wurde und zeigt, wie man einen Datentyp definiert, indem man Werte für Fassetten angibt, die den Bereich eines Basistyp auf eine Weise einschränken, die für den Basistyp spezifisch ist (anders als durch die Angabe von max-/ min-Werten, wie in vorhergehenden Abschnitten).
    <simpleType name="Summe">
      <restriction base="decimal">
        <totalDigits value="8"/>
        <fractionDigits value="2" fixed="true"/>
      </restriction>
    </simpleType>
    4.3.11.1 Die totalDigits-Schemakomponente
    Schema Komponente: totalDigits
    {Wert}
    Ein Wert vom Typ positiveInteger.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für totalDigits angeben, der ungleich {Wert} ist.

    4.3.11.2 XML-Darstellung von totalDigits-Schemakomponenten

    Die XML-Darstellung einer totalDigits-Schemakomponente ist eine <totalDigits>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: totalDigits Element Informationseinheit

    <totalDigits
    fixed = boolean : false
    id = ID
    value = positiveInteger
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </totalDigits>

    totalDigits Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'.
    {Anmerkung} Die Anmerkungen, die mit allen <annotation> Element-Informationseinheiten in den [Kindelemente] übereinstimmen, wenn welche vorhanden sind.
    4.3.11.3 totalDigits Gültigkeitsregeln
    Validierungsregel: totalDigits gültig
    Ein Wert in einem Wertebereich ist hinsichtlich totalDigits Fassetten-gültig , wenn:
    1 Die Anzahl der Dezimalstellen im Wert kleiner oder gleich {Wert} ist;
    4.3.11.4 Beschränkungen für totalDigits-Schemakomponenten
    Schema Komponenten Beschränkung: totalDigits-Gültigkeitsbeschränkung
    Wenn totalDigits zu den Mitgliedern einer Menge von {Fassetten} der {Basistyp-Definition} gehört und {Wert} größer ist als {Wert} von totalDigits im Elternelement ist, so ist dies ein Fehler.

    4.3.12 fractionDigits

    [Definition:] fractionDigits gibt die maximale Anzahl von Nachkommastellen bei Werten, die von decimal abgeleitet sind, an. Der Wert von fractionDigits muss vom Typ nonNegativeInteger sein.

    fractionDigits hat folgende Funktion:

    • Einen Wertebereich auf Werte mit einer bestimmten maximalen Anzahl von Nachkommastellen zu begrenzen.
    Beispiel
    Nachstehend ist die Definition eines benutzerdefinierten Datentyps dargestellt. Dieser könnte verwendet werden, um die Höhe der Körpertemperatur einer Person auf der Celsius-Skala abzubilden. Diese Definition würde in einem Schema vorkommen, das von einem "Endnutzer" geschrieben wurde und zeigt, wie man einen Datentyp definiert, indem man Werte für Fassetten festlegt, die den Bereich des Basistyps einschränken.
    <simpleType name="celsiusKoerperTemp">
      <restriction base="decimal">
        <totalDigits value="4"/>
        <fractionDigits value="1"/>
        <minInclusive value="36.4"/>
        <maxInclusive value="40.5"/>
      </restriction>
    </simpleType>
    
    4.3.12.1 Die fractionDigits-Schemakomponente
    Schema Komponente: fractionDigits
    {Wert}
    Ein Wert vom Typ nonNegativeInteger.
    {Unveränderbar}
    Ein Wert vom Typ boolean.
    {Anmerkung}
    Optional. Eine Anmerkung.

    Wenn {Unveränderbar}true ist, dann können Typen, deren momentaner Typ die {Basistyp-Definition} ist, keinen Wert für fractionDigits angeben, der ungleich {Wert} ist.

    4.3.12.2 XML-Darstellung von fractionDigits-Schemakomponenten

    Die XML-Darstellung einer fractionDigits-Schemakomponente ist eine <fractionDigits>-Element-Informationseinheit. Die Übereinstimmungen zwischen den Eigenschaften der Element-Informationseinheit und den Eigenschaften der Komponente sind die folgenden:

    XML Darstellung: fractionDigits Element Informationseinheit

    <fractionDigits
    fixed = boolean : false
    id = ID
    value = nonNegativeInteger
    {jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
    Content: (annotation?)
    </fractionDigits>

    fractionDigits Schemakomponente
    Eigenschaft Darstellung
    {Wert} Der tatsächliche Wert des value- [Attributs]
    {Unveränderbar} Der tatsächliche Wert des fixed- [Attributs], wenn vorhanden, ansonsten ist der Wert 'false'
    {Anmerkung} Die Anmerkungen, die mit allen <annotation>-Element-Informationseinheiten in den [Kindelementen] übereinstimmen, wenn welche vorhanden sind.
    4.3.12.3 fractionDigits Gültigkeitsregeln
    Validierungsregel: fractionDigits gültig
    Ein Wert in einem Wertebereich ist Fassetten-gültig hinsichtlich fractionDigits, wenn:
    1 Die Anzahl der Nachkommastellen des Wertes kleiner oder gleich {Wert} ist;
    4.3.12.4 Beschränkungen für fractionDigits-Schemakomponenten
    Schema Komponenten Beschränkung: fractionDigits kleiner oder gleich totalDigits
    Wenn fractionDigits größer als totalDigits ist, so ist dies ein Fehler.

    5 Konformität

    Diese Spezifikation beschreibt zwei Stufen der Konformität für Datentyp-Prozessoren. Die erste muss von allen Prozessoren zwingend erfüllt werden. Ob die zweite Stufe unterstützt wird, wird von den Anwendungsumgebungen abhängen, für die der Prozessor bestimmt ist.

    [Definition:] Prozessoren mit minimaler Unterstützung müssen die Regeln für Schemata und Validierungsregeln vollständig und richtig implementieren.

    [Definition:] Prozessoren, die Schemata in der Form von XML Dokumenten wie in XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen (§4.1.2) (und anderen wesentlichen Teilen von Datentyp-Komponenten (§4)) beschrieben akzeptieren, sollen zusätzlich konform zur XML-Darstellung von Schemata sein; und sie müssen, wenn sie Schema-Dokumente verarbeiten, vollständig und richtig alle in dieser Spezifikation implementieren. Desweiteren müssen sie genau die Spezifikationen von XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen (§4.1.2) (und anderen relevanten Teilen von Datentyp-Komponenten (§4)) für die Zuordnung des Inhalts solcher Dokumente zu Schemakomponenten, die in der Validierung verwendet werden, einhalten.

    Anmerkung:

    Indem die Konformitäts-Anforderungen, die sich auf die konkrete Syntax von XML Schema-Dokumenten beziehen, abgetrennt werden, lässt diese Spezifikation Prozessoren zu, die validieren, indem sie Schemata verwenden, die in einer optimierten binären Darstellung gespeichert sind, des weiteren dynamisch generierte Schemata, die als Datenstrukturen einer Programmiersprache dargestellt sind, oder Implementationen, in die bestimmte Schemata in ausführbaren Code wie Java oder C kompiliert sind. Solche Prozessoren können als Prozessoren mit minimaler Unterstützung, aber nicht notwendigerweise als konform zur XML-Darstellung von Schemata bezeichnet werden.

    A Schema für Datentypdefinitionen (normativ)

    B DTD für Datentypdefinitionen (nicht normativ)

    C Datentypen und Fassetten

    C.1 Grundlegende Fassetten

    Die folgende Tabelle zeigt die Werte der grundlegenden Fassetten für alle vordefinierten Datentypen.

    Datentyp Ordnung beschränkt Kardinalität numerisch
    primitiv string ungeordnet nein abzählbar unendlich nein
    boolean ungeordnet nein endlich nein
    float total ja endlich ja
    double total ja endlich ja
    decimal total nein abzählbar unendlich ja
    duration partiell nein abzählbar unendlich nein
    dateTime partiell nein abzählbar unendlich nein
    time partiell nein abzählbar unendlich nein
    date partiell nein abzählbar unendlich nein
    gYearMonth partiell nein abzählbar unendlich nein
    gYear partiell nein abzählbar unendlich nein
    gMonthDay partiell nein abzählbar unendlich nein
    gDay partiell nein abzählbar unendlich nein
    gMonth partiell nein abzählbar unendlich nein
    hexBinary ungeordnet nein abzählbar unendlich nein
    base64Binary ungeordnet nein abzählbar unendlich nein
    anyURI ungeordnet nein abzählbar unendlich nein
    QName ungeordnet nein abzählbar unendlich nein
    NOTATION ungeordnet nein abzählbar unendlich nein
    abgeleitet normalizedString ungeordnet nein abzählbar unendlich nein
    token ungeordnet nein abzählbar unendlich nein
    language ungeordnet nein abzählbar unendlich nein
    IDREFS ungeordnet nein abzählbar unendlich nein
    ENTITIES ungeordnet nein abzählbar unendlich nein
    NMTOKEN ungeordnet nein abzählbar unendlich nein
    NMTOKENS ungeordnet nein abzählbar unendlich nein
    Name ungeordnet nein abzählbar unendlich nein
    NCName ungeordnet nein abzählbar unendlich nein
    ID ungeordnet nein abzählbar unendlich nein
    IDREF ungeordnet nein abzählbar unendlich nein
    ENTITY ungeordnet nein abzählbar unendlich nein
    integer total nein abzählbar unendlich ja
    nonPositiveInteger total nein abzählbar unendlich ja
    negativeInteger total nein abzählbar unendlich ja
    long total ja endlich ja
    int total ja endlich ja
    short total ja endlich ja
    byte total ja endlich ja
    nonNegativeInteger total nein abzählbar unendlich ja
    unsignedLong total ja endlich ja
    unsignedInt total ja endlich ja
    unsignedShort total ja endlich ja
    unsignedByte total ja endlich ja
    positiveInteger total nein abzählbar unendlich ja

    D ISO 8601 Datums- und Zeit-Formate

    next sub-sectionD.1 Konventionen nach ISO 8601

    Die primitiven Datentyps duration, dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth und gYear verwenden an [ISO 8601] angelehnte lexikalische Formate. Dieser Anhang enthält detailliertere Informationen über die ISO-Formate und diskutiert einige Abweichungen der in dieser Spezifikation definierten Datentypen.

    [ISO 8601] spezifiziert die Repräsentation des Datums im proleptischen gregorianischen Kalender sowie Zeiten und die Repräsentation von Zeitspannen. Der proleptische gregorianische Kalender enthält auch Datumsangaben vor 1582 (dem Jahr seiner Einführung als kirchlicher Kalender). Es soll darauf hingewiesen werden, dass die in dieser Spezifikation beschriebenen Datentypen weder alle durch [ISO 8601] abgedeckten Datentypen abdecken, noch alle lexikalischen Repräsentationen für diese Datentypen unterstützen.

    Die lexikalischen Formate von [ISO 8601] werden durch "Bilder" beschrieben, in denen Buchstaben anstelle von Ziffern verwendet werden. Für die primitiven Datentypen dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth und gYear haben diese Buchstaben folgende Bedeutung:

    • C -- repräsentiert eine Ziffer in den Tausender- und Hunderter-Stelle des Zeitelements "Jahr" (year), also das Jahrhundert (century). Erlaubt sind Werte zwischen 0 und 9.
    • Y -- repräsentiert eine Ziffer in den Zehner- und Einser-Stelle des Zeitelements "Jahr" (year). Erlaubt sind Werte zwischen 0 und 9.
    • M -- repräsentiert eine Ziffer im Zeitelement "Monat" (month). Die zwei Ziffern in einem MM Format können Werte zwischen 1 und 12 annehmen.
    • D -- repräsentiert eine Ziffer im Zeitelement "Tag" (day). Die zwei Ziffern in einem DD Format können Werte zwischen 1 und 28 haben, wenn der Monatswert 2 ist, zwischen 1 und 29, wenn der Monatswert 2 und das Jahr ein Schaltjahr ist, zwischen 1 und 30, wenn der Monatswert 4, 6, 9 oder 11 ist, und zwischen 1 und 31, wenn der Monatswert 1, 3, 5, 7, 8, 10 oder 12 ist.
    • h -- repräsentiert eine Ziffer im Zeitelement "Stunde" (hour). Die zwei Ziffern in einem hh Format können Werte zwischen 0 und 23 annehmen.
    • m -- repräsentiert eine Ziffer im Zeitelement "minute". Die zwei Ziffern in einem mm Format können Werte zwischen 0 und 59 annehmen.
    • s -- repräsentiert eine Ziffer im Zeitelement "second". Die zwei Ziffern in einem hh Format können Werte zwischen 0 und 60 annehmen. In den in dieser Spezifikation beschriebenen Formaten kann auf die Anzahl der ganzen Sekunden die Angabe von Bruchteilen von Sekunden mit beliebiger Präzision folgen. Im Bild wird dies durch die Darstellung "ss.sss" repräsentiert. Ein Wert von 60 oder mehr ist nur im Fall von Schaltsekunden gestattet.

      Genau genommen ist ein Wert von 60 oder mehr nicht sinnvoll, es sei denn Monat und Tag könnten den 31. März, den 30. Juni, den 30. September oder den 31. Dezember in UTC repräsentieren. Weil die Schaltsekunde als letzte Sekunde des Tages in UTC-Zeit addiert oder subtrahiert wird, könnte die zu lange (oder kurze) Minute in der lokalen Zeitzone zu anderen Zeiten vorkommen. Für den Fall, dass die Schaltsekunde zusammen mit einen ungeeigneten Monat oder Tag verwendet wird, sollte sie (und eventuell vorhandene Bruchteile von Sekunden) auf die darauf folgende Minute addiert oder subtrahiert werden.

    Für alle Informationseinheiten, die durch die obigen Buchstaben gekennzeichnet sind, sind führende Nullen vorgeschrieben, soweit dies angegeben ist.

    Zusätzlich zu den obigen Buchstaben werden einige Buchstaben als Bezeichner verwendet und erscheinen in lexikalischen Formaten als sie selbst:

    • T -- wird als Zeit-Bezeichner verwendet, um in dateTime den Beginn der Repräsentation der Tageszeit anzuzeigen.
    • Z -- wird als Zeitzonen-Bezeichner verwendet und folgt in den Typen dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth und gYear direkt (ohne Leerzeichen) auf das Daten-Element, welches in koordinierter Universalzeit (UTC) die Tageszeit angibt.

    Im lexikalischen Format für duration werden außerdem folgende Buchstaben als Bezeichner verwendet und erscheinen in lexikalischen Formaten als sie selbst:

    • P -- wird als Zeitspannen-Bezeichner verwendet und wird Daten-Elementen, die eine Zeitspanne repräsentieren, vorangestellt.
    • Y -- folgt in Zeitspannen auf die Jahreszahl.
    • M -- folgt in Zeitspannen auf die Jahreszahl.
    • D -- folgt in Zeitspannen auf Anzahl der Monate oder Minuten.
    • H -- folgt in Zeitspannen auf die Anzahl der Tage.
    • S -- folgt in Zeitspannen auf die Anzahl der Sekunden.

    Die Werte für die Komponenten Jahr, Monat, Tag, Stunde und Minuten sind nicht eingeschränkt, sondern erlauben beliebige ganze Zahlen. Der Wert für die Sekunden-Komponente erlaubt entsprechend eine beliebige Dezimalzahl. Das alternative Format aus § 5.5.3.2.1 von [ISO 8601] ist folglich im lexikalischen Format für duration und für davon abgeleitete Datentypen nicht gestattet.

    previous sub-sectionnext sub-sectionD.2 Abgeschnittene und gekürzte Formate

    [ISO 8601] unterstützt eine Reihe von "abgeschnittenen" (truncated) Formaten, in denen einige der Zeichen links von einem bestimmten Format (beispielsweise dem Jahrhundert) weggelassen werden dürfen. Solche abgeschnittenen Formate sind im Allgemeinen für die in dieser Spezifikation definierten Datentypen nicht gestattet, mit drei Ausnahmen: Der Datentyp time verwendet ein abgeschnittenes Format für dateTime, das einen Zeitpunkt, der sich jeden Tag wiederholt, repräsentiert. Entsprechend verwenden die Datentypen gMonthDay und gDay links abgeschnittene Formate für date. Der Datentyp gMonth verwendet ein links und rechts abgeschnittenes Format für date.

    [ISO 8601] unterstützt auch eine Reihe von "gekürzten" (reduced) oder rechts abgeschnittenen Formaten, in denen einige der Zeichen rechts von einem bestimmten Format, wie etwa der Zeit, weggelassen werden dürfen. Auch rechts abgeschnittene Formate sind im Allgemeinen für die in dieser Spezifikation definierten Datentypen nicht gestattet, mit den folgenden Ausnahmen: Rechts abgeschnittene Repräsentationen von dateTime werden in den lexikalischen Repräsentationen von date, gMonth und gYear verwendet.

    previous sub-sectionD.3 Abweichungen von den ISO 8601-Formaten

    D.3.1 Minuszeichen erlaubt

    Ein optionales Minuszeichen ist ohne Leerzeichen direkt vor der lexikalischen Repräsentation von duration, dateTime, date, gMonth und gYear gestattet.

    D.3.2 Kein Jahr Null

    Das Jahr "0000" ist ein illegaler Wert für Jahre.

    D.3.3 Mehr als 9999 Jahre

    Um Jahreszahlen nach 9999 Rechnung zu tragen, sind für die Jahr-Repräsentation von dateTime, date, gYearMonth und gYear mehr als vier Ziffern gestattet, wie von [ISO 8601 Draft Revision] vorgesehen.

    E Addition von Zeitspannen zu Zeitpunkten

    Dieser Anhang spezifiziert, wie bei gegebenem Zeitpunkt (dateTime) S und Zeitspanne (duration) D ein Zeitpunkt (dateTime) E berechnet werden kann, so dass E das Ende der Zeitspanne ist, die bei S beginnt und die Länge D hat, d.h. E = S + D. Solche Berechnungen werden beispielsweise verwendet, um festzustellen, ob ein Zeitpunkt (dateTime) in eine bestimmte Zeitspanne fällt. Dieser Anhang spricht auch die Addition des Datentyps duration zu den Datentypen date, gYearMonth, gYear, gDay und gMonth an, die alle als Menge von dateTimes betrachtet werden können. In diesen Fällen bezieht sich die Addition auf den ersten bzw. Start-Zeitpunkt (dateTime) der Menge.

    Dies ist eine logische Erklärung des Ablaufs. Implementierungen haben die Freiheit, Optimierungen vorzunehmen, solange die gleichen Ergebnisse erzielt werden. Die Berechnung verwendet die Notation S[Jahr] um die Jahreszahl von S zu repräsentieren, S[Monat] für den Monat usw. Sie verwendet außerdem die folgenden Funktionen:

    31 M = Januar, März, Mai, Juli, August, Oktober, Dezember
    30 M = April, Juni, September, November
    29 M = Februar AND (modulo(J, 400) = 0 OR (modulo(J, 100) != 0) AND modulo(J, 4) = 0)
    28 sonst

    next sub-sectionE.1 Algorithmus

    Diese Berechnung besteht im Wesentlichen daraus, D in die Felder <Jahr,Monat> und <Tag, Stunde, Minute, Sekunde> aufzuteilen. <Jahr,Monat> wird dann zu S addiert. Falls der resultierende Tag außerhalb des Monats liegt, wird er so festgesetzt, dass er in den Monat fällt. Aus dem 31. April würde also der 30. April. Anschließend wird <Tag, Stunde, Minute, Sekunde> dazuaddiert. Diese Addition kann dazu führen, dass sich Jahr und Monat ändern.

    Schaltsekunden werden von der Berechnung als Überlauf behandelt. Im Wesentlichen wird ein Wert von 60 Sekunden in S so behandelt, als sei er eine Zeitspanne von 60 Sekunden, die zu S addiert wird (mit einer 0 im Sekunden-Feld). Alle nachfolgenden Berechnungen verwenden 60 Sekunden pro Minute.

    Auf diese Weise hat die Addition von PT1M zu einer dateTime-Instanz immer dasselbe Ergebnis wie die Addition von PT60S. Diese spezielle Definition der Addition wurde so gestaltet, dass sie dem üblichen Verfahren entspricht, und was noch noch wichtiger ist, über die Zeit stabil ist.

    Eine Definition, die versucht Schaltsekunden zu berücksichtigen, müsste ständig auf den neuesten Stand gebracht werden und könnte keine Vorhersage über die Ergebnisse der Additionen zukünftiger Implementierungen treffen. Die Entscheidung, Schaltsekunden in UTC einzufügen, obliegt der [International Earth Rotation Service (IERS)]-Organisation. Sie kündigt regelmäßig an, wann Schaltsekunden eingefügt werden sollen, jedoch nicht mehr als ein Jahr im Voraus. Für mehr Information zu Schaltsekunden siehe [U.S. Naval Observatory Time Service Department] (Zeitdienst der US Seewarte).

    Das Folgende ist die exakte Spezifikation der Berechnung. Die Schritte müssen in der spezifizierten Reihenfolge ausgeführt werden. Wenn ein Feld in D nicht angegeben ist, muss dafür der Wert 0 angenommen werden. Wenn ein Feld in S nicht angegeben ist, muss dafür der kleinste erlaubte Wert angenommen werden. Nachdem die Berechnung beendet ist, wird das entsprechende Feld in E entfernt (auf "nicht angegeben" gesetzt).

    • Monat (kann weiter unten noch verändert werden)
      • temp := S[Monat] + D[Monat]
      • E[Monat] := modulo(temp, 1, 13)
      • Übertrag:= fQuotient(temp, 1, 13)
    • Jahr (kann weiter unten noch verändert werden)
      • E[Jahr] := S[Jahr] + D[Jahr] + Übertrag
    • Zeitzone
      • E[Zeitzone] := S[Zeitzone]
    • Sekunden
      • temp := S[Sekunde] + D[Sekunde]
      • E[Sekunde] := modulo(temp, 60)
      • Übertrag:= fQuotient(temp, 60)
    • Minuten
      • temp := S[Minute] + D[Minute] + Übertrag
      • E[Minute] := modulo(temp, 60)
      • Übertrag:= fQuotient(temp, 60)
    • Stunden
      • temp := S[Stunde] + D[Stunde] + Übertrag
      • E[Stunde] := modulo(temp, 24)
      • Übertrag:= fQuotient(temp, 24)
    • Tag
      • if S[Tag] > maxTagInMonat(E[Jahr], E[Monat])
        • tempTag := maxTagInMonat(E[Jahr], E[Monat])
      • else if S[Tag] < 1
        • tempTag := 1
      • else
        • tempTag := S[Tag]
      • E[Tag] := tempTag + D[Tag] + Übertrag
      • START LOOP
        • IF E[Tag] < 1
          • E[Tag] := E[Tag] + maxTagInMonat(E[Jahr], E[Monat] - 1)
          • Übertrag := -1
        • ELSE IF E[Tag] > maxTagInMonat(E[Jahr], E[Monat])
          • E[Tag] := E[Tag] - maxTagInMonat(E[Jahr], E[Monat])
          • Übertrag := 1
        • ELSE EXIT LOOP
        • temp := E[Monat] + Übertrag
        • E[Monat] := modulo(temp, 1, 13)
        • E[Jahr] := E[Jahr] + fQuotient(temp, 1, 13)
        • GOTO START LOOP

    Beispiele:

    dateTime duration Ergebnis
    2000-01-12T12:13:14Z P1Y3M5DT7H10M3.3S 2001-04-17T19:23:17.3Z
    2000-01 -P3M 1999-10
    2000-01-12 PT33H 2000-01-13

    previous sub-sectionE.2 Kommutativität und Assoziativität

    Zeitspannen werden addiert, indem sie einfach feldweise zusammengezählt werden, ohne Berücksichtigung von Überlauf.

    Die Reihenfolge der Addition von Zeitspannen zu Zeitpunkten ist nicht beliebig. Es gibt Fälle, in denen gilt:

    ((dateTime + duration1) + duration2) != ((dateTime + duration2) + duration1)

    Beispiel:

    (2000-03-30 + P1D) + P1M = 2000-03-31 + P1M = 2001-04-30

    (2000-03-30 + P1M) + P1D = 2000-04-30 + P1D = 2000-05-01

    F Reguläre Ausdrücke

    Ein regulärer AusdruckR ist eine Zeichenfolge, die eine Menge von ZeichenkettenL(R) bezeichnet. Wenn ein regulärer AusdruckR verwendet wird, um einen lexikalischen Bereich zu beschränken, so wird damit festgelegt, dass nur die Zeichenketten in L(R) gültige Literale für die Werte dieses Typs sind.

    [Definition:] Ein regulärer Ausdruck besteht aus einem oder mehreren Zweigen (branches), getrennt durch das | Zeichen.

    Regulärer Ausdruck (regular expression)
    [1] regExp ::= branch ( '|' branch )*

    Für alle Zweige S und für alle regulären Ausdrücke T sind folgende gültige reguläre Ausdrücke R: Die beschriebene Menge von Zeichenketten L(R) enthält:
    (die leere Zeichenkette) Die Menge, die nur die leere Zeichenkette enthält.
    S Alle Zeichenketten in der Menge L(S)
    S|T Alle Zeichenketten in der Menge L(S) und alle Zeichenketten in der Menge L(T)

    [Definition:] Ein Zweig (branch) besteht aus null oder mehr miteinander verketteten Teilen (pieces).

    Zweig (branch)
    [2] branch ::= piece*

    Für alle Teile S und für alle Zweige T sind folgendes gültige Zweige R: Die beschriebene Menge von Zeichenketten L(R) enthält:
    S Alle Zeichenketten in der MengeL(S)
    S T Alle Zeichenketten st, für die gilt: s ist in L(S) enthalten und t in L(T).

    [Definition:] Ein Teil (piece) ist ein Atom, möglicherweise gefolgt von einem Quantifikator.

    Teil (piece)
    [3] piece ::= atom quantifier?

    Für alle Atome S und nicht-negativen ganzen Zahlen n, m mit n <= m, sind folgende gültige Teile R: Die beschriebene Menge von Zeichenketten L(R) enthält:
    S Alle Zeigenketten in der Menge L(S)
    S? Die leere Zeichenkette und alle Zeichenketten in der Menge L(S).
    S* Alle Zeichenketten in der Menge L(S?) und alle Zeichenketten st, für die gilt: s ist in L(S*) und t ist in L(S). ( Alle Verkettungen von null oder mehr Zeichenketten aus L(S) )
    S+ Alle Zeichenketten st, für die gilt: s ist in L(S) und t ist in L(S*). ( Alle Verkettungen von einer oder mehr Zeichenketten aus L(S) )
    S{n,m} Alle Zeichenketten st, für die gilt: s ist in L(S) und t ist in L(S{n-1,m-1}). ( Alle Folgen von mindestens n und höchstens m Zeichenketten aus L(S) )
    S{n} Alle Zeichenketten in der Menge L(S{n,n}). ( Alle Folgen von genau n Zeichenketten aus L(S) )
    S{n,} Alle Zeichenketten in L(S{n}S*) ( Alle Folgen von mindestens n Zeichenketten aus L(S) )
    S{0,m} Alle Zeichenketten st, für die gilt: s ist in L(S?) undt ist in L(S{0,m-1}). ( Alle Folgen von höchstens m Zeichenketten aus L(S) )
    S{0,0} Die Menge, die nur die leere Zeichenkette enthält.

    Anmerkung:

    Die Sprache für reguläre Ausdrücke in der Programmiersprache Perl [Perl] enthält keinen Quantifikator der Form S{,m), da er logisch äquivalent zu S{0,m} ist. Wir haben diese logische Möglichkeit deshalb in der Sprache für reguläre Ausdrücke, die durch diese Spezifikation definiert wird, nicht berücksichtigt. Wir würden uns über weitere Meinungen von Implementierern und Schema-Autoren zu dieser Fragestellung freuen.

    [Definition:] Ein Quantifikator ist eines der Zeichen ?, *, +, {n,m} oder {n}, mit der in der obigen Tabelle definierten Bedeutung.

    Quantifikator (quantifier)
    [4] quantifier ::= [?*+] | ( '{' quantity '}' )
    [5] quantity ::= quantRange | quantMin | QuantExact
    [6] quantRange ::= QuantExact ',' QuantExact
    [7] quantMin ::= QuantExact ','
    [8] QuantExact ::= [0-9]+

    [Definition:] Ein Atom ist entweder ein normales Zeichen, eine Zeichenklasse oder ein in Klammern eingefasster regulärer Ausdruck.

    Atom
    [9] atom ::= Char | charClass | ( '(' regExp ')' )

    Für alle normalen Zeichen c, Zeichenklassen C, und regulären Ausdrücke S sind folgendes gültige Atome R: Die beschriebene Menge von Zeichenketten L(R) enthält:
    c die einzelne Zeichenkette, die nur c enthält
    C alle Zeichenketten in der Menge L(C)
    (S) alle Zeichenketten in der Menge L(S)

    [Definition:] Ein Meta-Zeichen ist entweder ., \, ?, *, +, {, } (, ), [ oder ]. Diese Zeichen haben in regulären Ausdrücken eine spezielle Bedeutung, können aber als Fluchtsymbol angegeben werden, um Atome zu bilden, die die Menge der Zeichenketten beschreiben, die nur das Zeichen selbst enthalten. D.h. ein als Fluchtsymbol geschriebenes Meta-Zeichen verhält sich wie ein normales Zeichen.

    [Definition:] Ein normales Zeichen ist ein XML-Zeichen, das kein Meta-Zeichen ist. In einem regulären Ausdruck ist ein normales Zeichen ein Atom, das eine einelementige Menge von Zeichenketten bezeichnet, die nur das Zeichen selbst enthält.

    Normales Zeichen (normal character)
    [10] Char ::= [^.\?*+()|#x5B#x5D]

    Beachten Sie, dass ein normales Zeichen entweder durch sich selbst oder durch eine Zeichen-Referenz (character reference) repräsentiert werden kann.

    F.1 Zeichenklassen

    [Definition:] Eine Zeichenklasse ist ein Atom R, das eine Menge von Zeichen C(R) benennt. Die durch eine Zeichenklasse R festgelegte Menge von Zeichen L(R) enthält für jedes Zeichen c in C(R) eine einelementige Zeichenkette "c".

    Zeichenklasse (character class)
    [11] charClass ::= charClassEsc | charClassExpr

    Eine Zeichenklasse ist entweder ein Zeichenklassen-Fluchtsymbol oder ein Zeichenklassen-Ausdruck.

    [Definition:] Ein Zeichenklassen-Ausdruck ist eine Zeichengruppe, eingeschlossen von den Zeichen [ und]. Für alle Zeichengruppen G ist [G] ein gültiger Zeichenklassen-Ausdruck, der die Menge von Zeichen C bezeichnet, wobei gilt: [G]) = C(G.

    Zeichenklassen-Ausdruck (character class expression)
    [12] charClassExpr ::= '[' charGroup ']'

    [Definition:] Eine Zeichengruppe ist entweder eine positive Zeichengruppe, eine negative Zeichengruppe, oder eine Zeichenklassen-Subtraktion.

    Zeichengruppe (character group)
    [13] charGroup ::= posCharGroup | negCharGroup | charClassSub

    [Definition:] Eine positive Zeichengruppe besteht aus einem oder mehreren miteinander konkatenierten Zeichen-Bereichen oder Zeichenklassen-Fluchtsymbole. Eine positive Zeichengruppe bezeichnet die Zeichen-Menge, die alle Zeichen enthält, die durch ihre einzelnen Bereiche oder Fluchtsymbolen angegeben werden.

    Positive Zeichengruppe (positive character group)
    [14] posCharGroup ::= ( charRange | charClassEsc )+

    Für alle Zeichen-Bereiche R, alle Zeichenklassen-Fluchtsymbole E und alle positiven Zeichengruppen P sind Folgende gültige positive Zeichengruppen G: Die bezeichnete Zeichen-Menge C(G) enthält:
    R Alle Zeichen in C(R)
    E Alle Zeichen in C(E)
    RP Alle Zeichen in C(R)und alle Zeichen in C(P)
    EP Alle Zeichen in C(E) und alle Zeichen in C(P)

    [Definition:] Eine negative Zeichengruppe ist eine positive Zeichengruppe, der ein ^ Zeichen vorangestellt ist. Für alle positiven Zeichengruppen P ist ^P eine gültige negative Zeichengruppe, und C(^P) enthält alle XML-Zeichen, die nicht in C(P) enthalten sind.

    Negative Zeichengruppe (negative character group)
    [15] negCharGroup ::= '^' posCharGroup

    [Definition:] Eine Zeichenklassen-Subtraktion ist ein Zeichenklassen-Ausdruck, der von einer positive Zeichengruppe oder negative Zeichengruppe abgezogen wird, gekennzeichnet durch das - Zeichen

    Zeichenklassen-Subtraktion (character class subtraction)
    [16] charClassSub ::= ( posCharGroup | negCharGroup ) '-' charClassExpr

    Für jede positive Zeichengruppe oder negative ZeichengruppeG und jeden Zeichenklassen-AusdruckC ist G-C eine gültige Zeichenklassen-Subtraktion, die die Menge der Zeichen in C(G) bezeichnet, die nicht auch in C(C) sind.

    [Definition:] Ein Zeichen-Bereich R bezeichnet eine Menge von Zeichen C(R), die alle XML-Zeichen enthält, deren UCS-Zeichenwerte in den angegebenen Bereich fallen.

    Zeichen-Bereich (character range)
    [17] charRange ::= seRange | XmlCharRef | XmlCharIncDash
    [18] seRange ::= charOrEsc '-' charOrEsc
    [19] XmlCharRef ::= ( '&#' [0-9]+ ';' ) | (' &#x' [0-9a-fA-F]+ ';' )
    [20] charOrEsc ::= XmlChar | SingleCharEsc
    [21] XmlChar ::= [^\#x2D#x5B#x5D]
    [22] XmlCharIncDash ::= [^\#x5B#x5D]

    Ein einzelnes XML-Zeichen ist ein Zeichen-Bereich, der eine Menge von Zeichen benennt, die nur das Zeichen selbst enthält. Alle XML-Zeichen sind gültige Zeichen-Bereiche, mit Ausnahme der folgenden:

    Ein Zeichen-Bereichkann auch in der Form s-e geschrieben werden, um die Menge aller XML-Zeichen zu beschreiben, deren UCS-Zeichenwert größer oder gleich dem Zeichenwert von s, aber nicht größer als der Zeichenwert von e ist.

    s-e ist ein gültiger Zeichen-Bereich genau dann, wenn gilt:

    Anmerkung:

    Der Zeichenwert eines Einzelzeichen-Fluchtsymbols ist der Zeichenwert des einzelnen Zeichens in der Zeichenmenge, für die das Fluchtsymbol steht.

    F.1.1 Zeichenklassen-Fluchtsymbole

    [Definition:] Ein Zeichenklassen-Fluchtsymbol ist eine kurze Zeichenfolge, die eine vordefinierte Zeichenklasse identifiziert. Gültige Zeichenklassen-Fluchtsymbole sind die Einzelzeichen-Fluchtsymbole, die Mehrzeichen-Fluchtsymbole, und die Kategorie-Fluchtsymbole (einschließlich der Block-Fluchtsymbole).

    Zeichenklassen-Fluchtsymbol
    [23] charClassEsc ::= ( SingleCharEsc | MultiCharEsc | catEsc | complEsc )

    [Definition:] Ein Einzelzeichen-Fluchtsymbol kennzeichent eine Menge, die nur ein Zeichen enthält -- üblicherweise weil das jeweilige Zeichen nicht oder nur schwer direkt in einen regulären Ausdruck aufgenommen werden kann.

    Einzelzeichen-Fluchtsymbol
    [24] SingleCharEsc ::= '\' [nrt\|.?*+(){}#x2D#x5B#x5D#x5E]

    Gültige Einzelzeichen-Fluchtsymbole Inhalt der entsprechenden Zeichenmenge C(R)
    \n Das Zeilenvorschub-Zeichen (newline) (#xA)
    \r Das Wagenrücklauf-Zeichen (return) (#xD)
    \t Das Tabulator-Zeichen (tab) (#x9)
    \\ \
    \| |
    \. .
    \- -
    \^ ^
    \? ?
    \* *
    \+ +
    \{ {
    \} }
    \( (
    \) )
    \[ [
    \] ]

    [Definition:] [Unicode Database] spezifiziert eine Reihe von möglichen Werten für die Eigenschaft "General Category" (allgemeine Kategorie) und bietet eine Zuordnung von Zeichenwerten zu bestimmten Zeichen-Eigenschaften. Die Menge aller Zeichen mit der Eigenschaft X kann durch das Kategorie-Fluchtsymbol \p{X} angegeben werden. Das Komplement dieser Menge wird durch das Kategorie-Fluchtsymbol \P{X} angegeben, wobei gilt [\P{X}] = [^\p{X}].

    Kategorie-Fluchtsymbol
    [25] catEsc ::= '\p{' charProp '}'
    [26] complEsc ::= '\P{' charProp '}'
    [27] charProp ::= IsCategory | IsBlock

    Anmerkung:

    [Unicode Database] ist noch in Bearbeitung. Beispielsweise könnte die Gruppierung von Zeichenwerten zu Blocks aktualisiert werden. Alle Prozessoren, die Prozessoren minimaler Unterstützung sind, müssen die Blocks so unterstützen, wie sie von der Version von [Unicode Database] definiert werden, die aktuell war, als diese Spezifikation (XML Schema) eine W3C Empfehlung wurde. Implementierer werden jedoch dazu ermutigt, die von zukünftigen Versionen des Unicode-Standards definierten Blocks zu unterstützen.

    Die folgende Tabelle spezifiziert die für die Eigenschaft "General Category" (allgemeine Kategorie) möglichen Werte.

    Kategorie Eigenschaft Bedeutung
    Letters (Buchstaben) L Alle Buchstaben
    Lu Großbuchstaben (uppercase)
    Ll Kleinbuchstaben (lowercase)
    Lt "Titlecase" (Großschreibung von Substantiven in Überschriften auch im Englischen)
    Lm "Modifier" (Zeichen, die andere Zeichen ändern, zum Beispiel Akzente.)
    Lo sonstige (other)
    Marks (Marken) M Alle Marken
    Mn Marken, die keinen Platz beanspruchen (nonspacing).
    Mc Marken, die mit einem anderen Zeichen kombiniert werden (zum Beispiel Akzente) (spacing combining).
    Me Marken, die ein anderes Zeichen einschließen (zum Beispiel Kreise) (enclosing).
    Numbers (Zahlen) N Alle Zahlen
    Nd Dezimal-Ziffern
    Nl Buchstaben (letter)
    No Sonstige (other)
    Punctuation (Interpunktion) P Alle Satzzeichen
    Pc Verbinder (zum Beispiel Unterstrich) (connector)
    Pd Gedankenstrich (dash)
    Ps Öffnendes Zeichen (zum Beispiel Klammer) (open)
    Pe Schließendes Zeichen (close)
    Pi Öffnendes Anführungszeichen (Verhält sich je nach Anwendung wie Ps oder wie Pe.)
    Pf Schließendes Anführungszeichen (verhält sich je nach Anwendung wie Ps oder wie Pe.)
    Po Sonstige (other)
    Separators (Trennzeichen) Z Alle Trennzeichen
    Zs Leerzeichen (space)
    Zl Zeilenvorschub (line)
    Zp Paragraf
    Symbols (Symbole) S Alle Symbole
    Sm mathematische Symbole
    Sc Währungssymbole (currency)
    Sk "Modifier"
    So Sonstige (other)
    Other (sonstige) C Alle anderen
    Cc Kontrollzeichen (control)
    Cf Formatierung
    Co Reserviert (private use)
    Cn Nicht verwendet (not assigned)
    Kategorien
    [28] IsCategory ::= Letters | Marks | Numbers | Punctuation | Separators | Symbols | Others
    [29] Letters ::= 'L' [ultmo]?
    [30] Marks ::= 'M' [nce]?
    [31] Numbers ::= 'N' [dlo]?
    [32] Punctuation ::= 'P' [cdseifo]?
    [33] Separators ::= 'Z' [slp]?
    [34] Symbols ::= 'S' [mcko]?
    [35] Others ::= 'C' [cfon]?

    Anmerkung:

    Die oben angegebenen Eigenschafen schließen die Eigenschaft Cs nicht ein. Die Eigenschaft Cs kennzeichnet "Surrogat"-Zeichen, welche auf der Ebene der "Zeichen-Abstraktion", auf der XML-Instanz-Dokumente operieren, nicht vorkommen.

    [Definition:] [Unicode Database] fasst Zeichenwerte zu einer Reihe von Blocks zusammen, wie Basic Latin (ASCII), Latin-1 Supplement, Hangul Jamo, CJK Compatibility usw. Die Menge aller Zeichen aus dem Block X (ohne Leerraum) kann durch ein Block-Fluchtsymbol angegeben werden: \p{IsX}. Das Komplement dieser Menge kann durch das Block-Fluchtsymbol \P{IsX} spezifiziert werden, wobei gilt [\P{IsX}] = [^\p{IsX}].

    Block-Fluchtsymbol
    [36] IsBlock ::= 'Is' [a-zA-Z0-9#x2D]+

    Die folgende Tabelle spezifiziert die unterstützten Block-Namen (mehr Information ist in der Datei "Blocks.txt" in [Unicode Database] zu finden).

    Beginn Ende Name des Blocks Beginn Ende Name des Blocks
    #x0000 #x007F BasicLatin #x0080 #x00FF Latin-1Supplement
    #x0100 #x017F LatinExtended-A #x0180 #x024F LatinExtended-B
    #x0250 #x02AF IPAExtensions #x02B0 #x02FF SpacingModifierLetters
    #x0300 #x036F CombiningDiacriticalMarks #x0370 #x03FF Greek
    #x0400 #x04FF Cyrillic #x0530 #x058F Armenian
    #x0590 #x05FF Hebrew #x0600 #x06FF Arabic
    #x0700 #x074F Syriac #x0780 #x07BF Thaana
    #x0900 #x097F Devanagari #x0980 #x09FF Bengali
    #x0A00 #x0A7F Gurmukhi #x0A80 #x0AFF Gujarati
    #x0B00 #x0B7F Oriya #x0B80 #x0BFF Tamil
    #x0C00 #x0C7F Telugu #x0C80 #x0CFF Kannada
    #x0D00 #x0D7F Malayalam #x0D80 #x0DFF Sinhala
    #x0E00 #x0E7F Thai #x0E80 #x0EFF Lao
    #x0F00 #x0FFF Tibetan #x1000 #x109F Myanmar
    #x10A0 #x10FF Georgian #x1100 #x11FF HangulJamo
    #x1200 #x137F Ethiopic #x13A0 #x13FF Cherokee
    #x1400 #x167F UnifiedCanadianAboriginalSyllabics #x1680 #x169F Ogham
    #x16A0 #x16FF Runic #x1780 #x17FF Khmer
    #x1800 #x18AF Mongolian #x1E00 #x1EFF LatinExtendedAdditional
    #x1F00 #x1FFF GreekExtended #x2000 #x206F GeneralPunctuation
    #x2070 #x209F SuperscriptsandSubscripts #x20A0 #x20CF CurrencySymbols
    #x20D0 #x20FF CombiningMarksforSymbols #x2100 #x214F LetterlikeSymbols
    #x2150 #x218F NumberForms #x2190 #x21FF Arrows
    #x2200 #x22FF MathematicalOperators #x2300 #x23FF MiscellaneousTechnical
    #x2400 #x243F ControlPictures #x2440 #x245F OpticalCharacterRecognition
    #x2460 #x24FF EnclosedAlphanumerics #x2500 #x257F BoxDrawing
    #x2580 #x259F BlockElements #x25A0 #x25FF GeometricShapes
    #x2600 #x26FF MiscellaneousSymbols #x2700 #x27BF Dingbats
    #x2800 #x28FF BraillePatterns #x2E80 #x2EFF CJKRadicalsSupplement
    #x2F00 #x2FDF KangxiRadicals #x2FF0 #x2FFF IdeographicDescriptionCharacters
    #x3000 #x303F CJKSymbolsandPunctuation #x3040 #x309F Hiragana
    #x30A0 #x30FF Katakana #x3100 #x312F Bopomofo
    #x3130 #x318F HangulCompatibilityJamo #x3190 #x319F Kanbun
    #x31A0 #x31BF BopomofoExtended #x3200 #x32FF EnclosedCJKLettersandMonths
    #x3300 #x33FF CJKCompatibility #x3400 #x4DB5 CJKUnifiedIdeographsExtensionA
    #x4E00 #x9FFF CJKUnifiedIdeographs #xA000 #xA48F YiSyllables
    #xA490 #xA4CF YiRadicals #xAC00 #xD7A3 HangulSyllables
    #xD800 #xDB7F HighSurrogates #xDB80 #xDBFF HighPrivateUseSurrogates
    #xDC00 #xDFFF LowSurrogates #xE000 #xF8FF PrivateUse
    #xF900 #xFAFF CJKCompatibilityIdeographs #xFB00 #xFB4F AlphabeticPresentationForms
    #xFB50 #xFDFF ArabicPresentationForms-A #xFE20 #xFE2F CombiningHalfMarks
    #xFE30 #xFE4F CJKCompatibilityForms #xFE50 #xFE6F SmallFormVariants
    #xFE70 #xFEFE ArabicPresentationForms-B #xFEFF #xFEFF Specials
    #xFF00 #xFFEF HalfwidthandFullwidthForms #xFFF0 #xFFFD Specials
    #x10300 #x1032F OldItalic #x10330 #x1034F Gothic
    #x10400 #x1044F Deseret #x1D000 #x1D0FF ByzantineMusicalSymbols
    #x1D100 #x1D1FF MusicalSymbols #x1D400 #x1D7FF MathematicalAlphanumericSymbols
    #x20000 #x2A6D6 CJKUnifiedIdeographsExtensionB #x2F800 #x2FA1F CJKCompatibilityIdeographsSupplement
    #xE0000 #xE007F Tags #xF0000 #xFFFFD PrivateUse
    #x100000 #x10FFFD PrivateUse

    Anmerkung:

    [Unicode Database] ist noch in Bearbeitung. Beispielsweise könnte die Gruppierung von Zeichenwerten zu Blocks aktualisiert werden. Alle Prozessoren, die Prozessoren mit minimaler Unterstützung sind, müssen die Blocks so unterstützen, wie sie von der Version von [Unicode Database] definiert werden, die aktuell war, als diese Spezifikation (XML Schema) eine W3C Empfehlung wurde. Implementierer werden jedoch dazu ermutigt, die von zukünftigen Versionen des Unicode-Standards definierten Blocks zu unterstützen.

    Beispielsweise ist \p{IsBasicLatin} das Block-Fluchtsymbol, das die ASCII Zeichen identifiziert.

    [Definition:] Ein Mehr-Zeichen-Fluchtsymbol bietet einen einfachen Weg, eine häufig benutzte Menge von Zeichen zu benennen:

    Mehr-Zeichen-Fluchtsymbol
    [37] MultiCharEsc ::= '.' | ('\' [sSiIcCdDwW])

    Zeichenkette entsprechende Zeichenklasse
    . [^\n\r]
    \s [#x20\t\n\r]
    \S [^\s]
    \i Die Menge ursprünglicher Namens-Zeichen, also diejenigen, die Letter | '_' | ':' entsprechen
    \I [^\i]
    \c Die Menge der Zeichen, die NameChar entsprechen
    \C [^\c]
    \d \p{Nd}
    \D [^\d]
    \w [#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}] (Alle Zeichen, die nicht zu den Zeichenmengen "punctuation" (Satzzeichen), "separator" (Trennzeichen) und "other" (sonstige) gehören.)
    \W [^\w]

    Anmerkung:

    Die Sprache für reguläre Ausdrücke, die hier definiert wird, versucht nicht, eine allgemein gültige Sprache für reguläre Ausdrücke über UCS-Zeichenketten zu bieten. Insbesondere bietet sie keine einfache Möglichkeit, Sequenzen von Unicode-Basiszeichen zu vergleichen und Marken zu kombinieren. Das Ziel der Sprache ist es, "Level 1"-Unicode-Features, wie in [Unicode Regular Expression Guidelines] definiert, zu unterstützen. Wir hoffen, dass zukünftige Versionen dieser Spezifkation Unterstützung für "Level 2" Features bieten werden.

    G Glossar (nicht normativ)

    Die folgende Auflistung fasst zugunsten der Leser der gedruckten Version dieses Dokuments alle Definitionen zusammen, die in diesem Dokument verwendet werden.

    abgeleitet
    Abgeleitete Datentypen sind durch andere Datentypen definiert.
    atomar
    Atomare Datentypen besitzen Werte, die bezüglich dieser Spezifikation als nicht weiter zergliederbar betrachtet werden.
    aus Kompatibilitätsgründen
    Aus Kompatibilitätsgründen (for compatibility)
    Basistyp
    Jeder Datentyp, der durch Einschränkung abgeleitet wurde, ist durch einen anderen Datentyp definiert, der als Basistyp bezeichnet wird. Basistypen können sowohl primitiv als auch abgeleitet sein.
    benutzerdefiniert
    benutzerdefinierte Datentypen sind abgeleitete Datentypen, die von Schema-Designern definiert werden.
    beschränkt
    Ein Datentyp ist beschränkt, wenn sein Wertebereich entweder eine obere inklusive Schranke
    Datentyp
    Ein Datentyp in dieser Spezifikation entspricht einem Tripel, bestehend aus a) einer Menge von verschiedenen Werten -- dem sog. Wertebereich, b) einer Menge von lexikalischen Darstellungen -- dem sog. lexikalischen Bereich und c) einer Menge von Fassetten, die die Charakteristika des Wertebereichs beschreiben, und einigen speziellen Werten oder lexikalischen Einträgen .
    einschränkende Fassette
    Eine einschränkende Fassette ist eine optionale Eigenschaft, die bei einem Datentyp gesetzt werden kann, um seinen Wertebereich einzuschränken.
    Einschränkung
    Man sagt, ein Datentyp ist durch Einschränkung aus einem anderen Datentyp abgeleitet, wenn Werte für null oder mehr einschränkende Fassetten spezifiziert sind, die dazu dienen, den Wertebereich und/oder den lexikalischen Bereich auf eine Untermenge von denen seines Basistyps einzuschränken.
    entsprechen
    entsprechen (match)
    exklusive untere Schranke
    Ein Wert l aus dem geordneten Wertebereich L wird als untere exklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von L), wenn für alle v aus V gilt u < v.
    Fassette
    Eine Fassette ist ein Aspekt der Definition des Wertebereichs. Allgemein gesagt, jede Fassette charakterisiert einen Wertebereich entlang unabhängiger Achsen oder Dimensionen.
    Fehler
    Fehler (error)
    geordnet
    Ein Wertebereich und damit ein Datentyp wird als geordnet bezeichnet, wenn dafür eine Ordnungsbeziehung definiert ist.
    grundlegende Fassette
    Eine grundlegende Fassette ist eine abstrakte Eigenschaft, die dazu dient, den Wert eines Wertebereichs semantisch zu charakterisieren.
    inklusive untere Schranke
    Ein Wert l aus dem geordneten Wertebereich L wird als untere inklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von L), wenn für alle v aus V gilt u <= v.
    itemType
    Der atomare Datentyp, der an der Definition einer Liste beteiligt ist, wird als itemType dieser Liste bezeichnet.
    itemType
    Der atomare oder Vereinigungs-Datentyp, der an der Definition eines Listen-Datentyps beteiligt ist, wird als itemType dieses Listen-Datentyps bezeichnet.
    kann
    kann (may)
    kanonische lexikalische Repräsentation
    Eine kanonische lexikalische Repräsentation ist eine Menge von Literalen aus der Menge von gültigen Werten zu einem Datentyp, die so gewählt ist, dass es eine 1:1-Abbildung zwischen den Literalen der kanonischen lexikalischen Repräsentation und Werten aus dem Wertebereich gibt.
    Kardinalität
    Jeder Wertebereich trägt das Konzept der Kardinalität mit sich. Einige Wertebereiche sind endlich, einige sind abzählbar unendlich, während andere überabzählbar unendlich sein könnten (obwohl in dieser Spezifikation kein überabzählbar unendlicher Wertebereich definiert wird). Man sagt, ein Datentyp hat die Kardinalität seines Wertebereichs.
    Konformität bezüglich der XML Representation von Schemas
    Prozessoren, die Schemata in der Form von XML Dokumenten wie in XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen (§4.1.2) (und anderen wesentlichen Teilen von Datentyp-Komponenten (§4)) beschrieben akzeptieren, sollen zusätzlich konform zur XML-Darstellung von Schemata sein; und sie müssen, wenn sie Schema-Dokumente verarbeiten, vollständig und richtig alle in dieser Spezifikation implementieren. Desweiteren müssen sie genau die Spezifikationen von XML-Repräsentation von Schema-Komponenten zur Definition einfacher Datentypen (§4.1.2) (und anderen relevanten Teilen von Datentyp-Komponenten (§4)) für die Zuordnung des Inhalts solcher Dokumente zu Schemakomponenten, die in der Validierung verwendet werden, einhalten.
    lexikalischer Bereich
    Ein lexikalischer Bereich ist eine Menge von zulässigen Literalen für einen Datentyp.
    Liste
    Listen-Datentypen sind solche, deren Werte Sequenzen einer endlichen (möglicherweise aber auch leeren) Länge von Werten atomarer Datentypen enthalten.
    memberTypes
    Datentypen, die Teil der Definition eines Vereinigungs-Datentyps sind, nennt man memberTypes des Vereinigungs-Datentyps.
    minimale Unterstützung
    Prozessoren mit minimaler Unterstützung müssen die Regeln für Schemata und Validierungsregeln vollständig und richtig implementieren.
    muss
    muss (must)
    nicht numerisch
    Ein Datentyp, dessen Werte nicht numerisch sind, wird als nicht numerisch (non-numeric) bezeichnet.
    numerisch
    Man bezeichnet einen Datentyp als numerisch, wenn seine Werte Begriffe für Quantitäten (in einem beliebigen mathematischen Zahlensystem) darstellen.
    obere exklusive Schranke
    Ein Wert u aus dem geordneten Wertebereich U wird als obere exklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von U), wenn für alle v aus V gilt u > v.
    obere inklusive Schranke
    Ein Wert u aus dem geordneten Wertebereich U wird als obere inklusive Schranke eines Wertebereichs V bezeichnet (V ist eine Untermenge von U), wenn für alle v aus V gilt u >= v.
    Ordnungsbeziehung
    Eine Ordnungsbeziehung auf einem Wertebereich ist eine mathematische Beziehung, die den Mitgliedern des Wertebereichs eine totale Ordnung oder partielle Ordnung auferlegt.
    partielle Ordnung
    Eine partielle Ordnung ist eine Ordnungsbeziehung, die irreflexiv, asymmetrisch und transitiv ist.
    primitiv
    Primitive Datentypen sind nicht durch andere Datentypen definiert; sie existieren von Anfang an.
    Regeln für Schemata
    Regeln für Schemata (constraint on schemas)
    regulärer Ausdruck
    Ein regulärer Ausdruck besteht aus einem oder mehreren Zweigen (branches), getrennt durch das | Zeichen.
    Schema Darstellungsregeln
    Schema-Darstellungsregeln (schema representation constraint)
    totale Ordnung
    Eine totale Ordnung ist eine partielle Ordnung, für die gilt, dass kein a und b angegeben werden kann, für das gilt, a <> b.
    Validierungsregeln
    Validierungsregeln (Validation Rule)
    Vereinigung
    Vereinigungs- Datentypen sind solche, deren Wertebereiche und lexikalische Bereiche die Vereinigung der Wertebereiche und lexikalischen Bereiche von einem oder mehreren anderen Datentypen darstellen.
    vordefiniert
    Vordefinierte (built-in) Datentypen sind jene, die in dieser Spezifikation definiert werden und entweder primitiv oder abgeleitet sein können.
    Wertebereich
    Ein Wertebereich ist eine Menge von Werten zu einem gegebenen Datentyp. Jeder Wert im Wertebereich eines Datentyps ist durch ein oder mehrere Literale im lexikalischen Bereich bezeichnet.

    H Referenzen

    next sub-sectionH.1 Normativ

    Clinger, WD (1990)
    William D. Clinger. How to Read Floating Point Numbers Accurately. In Proceedings of Conference on Programming Language Design and Implementation, pages 92-101. Verfügbar unter: ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps
    IEEE 754-1985
    IEEE. IEEE Standard for Binary Floating-Point Arithmetic. Siehe http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html
    Namespaces in XML
    World Wide Web Consortium. Namespaces in XML.Verfügbar unter: http://www.edition-w3c.de/TR/1999/REC-xml-names-19990114/
    RFC 1766
    H. Alvestrand, ed. RFC 1766: Tags for the Identification of Languages 1995. Verfügbar unter: http://www.ietf.org/rfc/rfc1766.txt
    RFC 2045
    N. Freed and N. Borenstein. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. 1996. Verfügbar unter: http://www.ietf.org/rfc/rfc2045.txt
    RFC 2396
    Tim Berners-Lee, et. al. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax.. 1998. Verfügbar unter: http://www.ietf.org/rfc/rfc2396.txt
    RFC 2732
    RFC 2732: Format for Literal IPv6 Addresses in URLs. 1999. Verfügbar unter: http://www.ietf.org/rfc/rfc2732.txt
    Unicode Database
    The Unicode Consortium. The Unicode Character Database. Verfügbar unter: http://www.unicode.org/Public/3.1-Update/UnicodeCharacterDatabase-3.1.0.html
    XML 1.0 (Second Edition)
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0, Second Edition. Verfügbar unter: http://www.edition-w3c.de/TR/2000/REC-xml-20001006
    XML Linking Language
    World Wide Web Consortium. XML Linking Language (XLink). Verfügbar unter: http://www.edition-w3c.de/TR/2001/REC-xlink-20010627/
    XML Schema Part 1: Structures
    XML Schema Part 1: Structures. Verfügbar unter: http://www.edition-w3c.de/TR/2001/REC-xmlschema-1-20010502/
    XML Schema Requirements
    World Wide Web Consortium. XML Schema Requirements. Verfügbar unter: http://www.edition-w3c.de/TR/1999/NOTE-xml-schema-req-19990215

    previous sub-sectionH.2 Nicht normativ

    Character Model
    Martin J. Dürst and François Yergeau, eds. Character Model for the World Wide Web. World Wide Web Consortium Working Draft. 2001. Verfügbar unter: http://www.edition-w3c.de/TR/2001/WD-charmod-20010126/
    Gay, DM (1990)
    David M. Gay. Correctly Rounded Binary-Decimal and Decimal-Binary Conversions. AT&T Bell Laboratories Numerical Analysis Manuscript 90-10, November 1990. Verfügbar unter: http://cm.bell-labs.com/cm/cs/doc/90/4-10.ps.gz
    HTML 4.01
    World Wide Web Consortium. Hypertext Markup Language, Version 4.01. Verfügbar unter: http://www.edition-w3c.de/TR/1999/REC-html401-19991224/
    IETF INTERNET-DRAFT: IRIs
    L. Masinter and M. Durst. Internationalized Resource Identifiers 2001. Verfügbar unter: http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-07.txt
    International Earth Rotation Service (IERS)
    International Earth Rotation Service (IERS). Siehe http://maia.usno.navy.mil
    ISO 11404
    ISO (International Organization for Standardization). Language-independent Datatypes. Siehe http://www.iso.ch/cate/d19346.html
    ISO 8601
    ISO (International Organization for Standardization). Representations of dates and times, 1988-06-15. Verfügbar unter: http://www.iso.ch/markete/8601.pdf
    ISO 8601 Draft Revision
    ISO (International Organization for Standardization). Representations of dates and times, draft revision, 2000.
    Perl
    The Perl Programming Language. Siehe http://www.perl.com/pub/language/info/software.html
    RDF Schema
    World Wide Web Consortium. RDF Schema Specification. Verfügbar unter: http://www.edition-w3c.de/TR/2000/CR-rdf-schema-20000327/
    Ruby
    World Wide Web Consortium. Ruby Annotation. Verfügbar unter: http://www.edition-w3c.de/TR/2001/WD-ruby-20010216/
    SQL
    ISO (International Organization for Standardization). ISO/IEC 9075-2:1999, Information technology --- Database languages --- SQL --- Part 2: Foundation (SQL/Foundation). [Geneva]: International Organization for Standardization, 1999. Siehe http://www.iso.ch/cate/d26197.html
    U.S. Naval Observatory Time Service Department
    Information about Leap Seconds, Verfügbar unter: http://tycho.usno.navy.mil/leapsec.990505.html
    Unicode Regular Expression Guidelines
    Mark Davis. Unicode Regular Expression Guidelines, 1988. Verfügbar unter: http://www.unicode.org/unicode/reports/tr18/
    XML Schema Language: Part 2 Primer
    World Wide Web Consortium. XML Schema Language: Part 2 Primer. Verfügbar unter: http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/
    XSL
    World Wide Web Consortium. Extensible Stylesheet Language (XSL). Verfügbar unter: http://www.edition-w3c.de/TR/2000/CR-xsl-20001121/

    I Danksagungen (nicht normativ)

    Folgende Personen haben Material in diesen Entwurf eingebracht:

    Die Mitarbeit des Co-editors Ashok Malhotra an dieser Spezifikation von März 1999 bis Februar 2001 wurde von IBM unterstützt.

    Die Editoren danken der XML Schema-Arbeitsgruppe, den Mitgliedern anderer W3C-Arbeitsgruppen, und Sachverständigen aus der Industrie in anderen Foren, die direkt oder indirekt einen Beitrag zur Erstellung oder zum Inhalt dieses Dokuments geleistet haben. Die Arbeitsgruppe ist insbesondere Lotus Development Corp. und IBM zu Dank verpflichtet für das Ausrichten von Telefonkonferenzen.

    Die derzeitigen Mitglieder der XML Schema-Arbeitsgruppe sind:

    Jim Barnette, Defense Information Systems Agency (DISA); Paul V. Biron, Health Level Seven; Don Box, DevelopMentor; Allen Brown, Microsoft; Lee Buck, TIBCO Extensibility; Charles E. Campbell, Informix; Wayne Carr, Intel; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Ugo Corda, Xerox; Roger L. Costello, MITRE; Haavard Danielson, Progress Software; Josef Dietl, Mozquito Technologies; David Ezell, Hewlett-Packard Company; Alexander Falk, Altova GmbH; David Fallside, IBM; Dan Fox, Defense Logistics Information Service (DLIS); Matthew Fuchs, Commerce One; Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd); Paul Grosso, Arbortext, Inc; Martin Gudgin, DevelopMentor; Dave Hollander, Contivo, Inc (co-chair); Mary Holstege, Invited Expert; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Simon Johnston, Rational Software; Bob Lojek, Mozquito Technologies; Ashok Malhotra, Microsoft; Lisa Martin, IBM; Noah Mendelsohn, Lotus Development Corporation; Adrian Michel, Commerce One; Alex Milowski, Invited Expert; Don Mullen, TIBCO Extensibility; Dave Peterson, Graphic Communications Association; Jonathan Robie, Software AG; Eric Sedlar, Oracle Corp.; C. M. Sperberg-McQueen, W3C (co-chair); Bob Streich, Calico Commerce; William K. Stumbo, Xerox; Henry S. Thompson, University of Edinburgh; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, Sun Microsystems; Aki Yoshida, SAP AG; Kongyi Zhou, Oracle Corp.

    Die XML Schema-Arbeitsgruppe hat bei ihrer Arbeit von der Teilnahme und den Eingaben etlicher Leute profitiert, die momentan keine Mitglieder der Arbeitsgruppe mehr sind, unter anderem die im Folgenden aufgeführte Personen. Als Firmenzugehörigkeit ist diejenige Firma angegeben, die zur Zeit ihrer Mitarbeit in der Arbeitsgruppe aktuell war.

    Paula Angerstein, Vignette Corporation; David Beech, Oracle Corp.; Gabe Beged-Dov, Rogue Wave Software; Greg Bumgardner, Rogue Wave Software; Dean Burson, Lotus Development Corporation; Mike Cokus, MITRE; Andrew Eisenberg, Progress Software; Rob Ellman, Calico Commerce; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Dianne Kennedy, Graphic Communications Association; Janet Koenig, Sun Microsystems; Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett-Packard Company; John McCarthy, Lawrence Berkeley National Laboratory; Murata Makoto, Xerox; Eve Maler, Sun Microsystems; Murray Maloney, Muzmo Communication, acting for Commerce One; Chris Olds, Wall Data; Frank Olken, Lawrence Berkeley National Laboratory; Shriram Revankar, Xerox; Mark Reinhold, Sun Microsystems; John C. Schneider, MITRE; Lew Shannon, NCR; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Steph Tryphonas, Microstar