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.
Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
"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.
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.
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.
Das Dokument [XML Schema Requirements] zeigt auf, welche konkreten Anforderungen durch diese Spezifikation abgedeckt sein müssen. Die Spezifikation muss
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]).
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.
Diese Spezifikation beinhaltet drei Arten normativer Aussagen über Schema-Komponenten, ihre Darstellung in XML und deren Beiträge zur Schema-Validierung:
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.
[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 .
[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.
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: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.
[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.
[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.
[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 .
Es ist sinnvoll, die in dieser Spezifikation definierten Datentypen entlang verschiedener Dimensionen zu kategorisieren und somit eine Menge von Charakterisierungs-Dichotomien zu bilden.
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.
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.
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.
<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.
<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>
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.
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.
<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.
<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.Im Folgenden werden die Unterschiede zwischen primitiven und abgeleiteten Datentypen erläutert.
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.
[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.
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.
Ein Datentyp kann von einem oder mehreren Datentypen abgeleitet werden, in dem man deren Wertebereiche und konsequenterweise auch deren lexikalische Bereichevereinigt.
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.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:
Um zum Beispiel den Datentyp int zu adressieren, lautet der URI
http://www.w3.org/2001/XMLSchema#int
Zusätzlich lässt sich jedes Element, das eine Fassette eines Datentyps definiert, ebenfalls durch einen eindeutigen URI adressieren, der wie folgt aufgebaut ist:
Die Adressierung der maxInclusive-Fassette sieht z. B. folgendermaßen aus:
http://www.w3.org/2001/XMLSchema#maxInclusive
Analog läßt sich jede Verwendung einer Fassette in einer vordefinierten Datentypdefinition durch einen eindeutigen URI adressieren, der folgendermaßen aussieht:
Die Adressierung der Verwendung der maxInclusive-Fassette in der Definition von int sieht z. B. folgendermaßen aus:
http://www.w3.org/2001/XMLSchema#int.maxInclusive
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:
http://www.w3.org/2001/XMLSchema
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:
http://www.w3.org/2001/XMLSchema-datatypes
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]).
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.
[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.string hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von string:
[Definition:] Der Wertebereich von boolean dient dazu, das mathematische Konzept einer zweiwertigen Logik abzubilden: {true, false}.
Eine Instanz des Datentyps boolean kann durch die gültigen Literale {true, false, 1, 0} beschrieben werden.
Die kanonische Repräsentation für boolean ist die Menge der Literale {true, false}.
boolean hat die folgenden beschränkenden Fassetten :
[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.
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
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.
decimal hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von decimal:
[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.
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
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.
float hat die folgenden beschränkenden Fassetten :
[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.
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
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.
double hat die folgenden beschränkenden Fassetten :
[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.
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:
P1347Y, P1347M, P1Y2MT2H | erlaubt |
P0Y1347M, P0Y1347M0D | erlaubt |
P-1347M, P1Y2MT | nicht erlaubt |
-P1347M | erlaubt |
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)).
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 | ... |
Beim Vergleich von duration-Werten, die minInclusive-, minExclusive-, maxInclusive- und maxExclusive-Fassetten besitzen, sollten nicht definierte Vergleiche als "false" angesehen werden.
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.
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>
duration hat die folgenden beschränkenden Fassetten :
[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.
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
.
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.
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.
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:
C. Anderenfalls, falls P eine Zeitzone enthält und Q nicht führe folgende Vergleiche durch:
D. Anderenfalls, falls P keine Zeitzone enthält und Q enthält eine Zeitzone, führe folgende Vergleiche:
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 |
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.
dateTime hat die folgenden beschränkenden Fassetten :
[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.
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).
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.
time hat die folgenden beschränkenden Fassetten :
[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.
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).
date hat die folgenden beschränkenden Fassetten :
[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.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).
gYearMonth hat die folgenden beschränkenden Fassetten :
[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.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).
gYear hat die folgenden beschränkenden Fassetten :
[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.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.
gMonthDay hat die folgenden beschränkenden Fassetten :
[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.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).
gDay hat die folgenden beschränkenden Fassetten :
[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.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).
gMonth hat die folgenden beschränkenden Fassetten :
[Definition:] hexBinary repräsentiert hexadezimal kodierte Daten. Der Wertebereich von hexBinary ist die Menge von Oktettsequenzen endlicher Länge.
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).
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.
hexBinary hat die folgenden beschränkenden Fassetten :
[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.
base64Binary hat die folgenden beschränkenden Fassetten :
[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.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).anyURI hat die folgenden beschränkenden Fassetten :
[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.QName hat die folgenden beschränkenden Fassetten :
[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.
Aus Kompatibilitätsgründen sollte NOTATION nur in Attributen benutzt werden (siehe Terminologie §1.4).
NOTATION hat die folgenden beschränkenden Fassetten :
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).
[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.
normalizedString hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von normalizedString:
[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.
token hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von token:
[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.
language hat die folgenden beschränkenden Fassetten :
[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.
NMTOKEN hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von NMTOKEN:
[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.
NMTOKENS hat die folgenden beschränkenden Fassetten :
[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.
Name hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von Name:
[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.
NCName hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von NCName:
[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.
ID hat die folgenden beschränkenden Fassetten :
[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.
IDREF hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von IDREF:
[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.
IDREFS hat die folgenden beschränkenden Fassetten :
[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.
ENTITY hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von ENTITY:
[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.
ENTITIES hat die folgenden beschränkenden Fassetten :
[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.
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.
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.
integer hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von integer:
[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.
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.
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.
nonPositiveInteger hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von nonPositiveInteger:
[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.
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.
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.
negativeInteger hat die folgenden beschränkenden Fassetten :
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.
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.
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.
long hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von long:
[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.
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.
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.
int hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von int:
[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.
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.
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.
short hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von short:
[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.
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.
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.
byte hat die folgenden beschränkenden Fassetten :
[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.
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.
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.
nonNegativeInteger hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von nonNegativeInteger:
[Definition:] unsignedLong ist von nonNegativeInteger abgeleitet, indem der Wert von maxInclusive fest auf 18446744073709551615 gesetzt wurde. Der Basistyp von unsignedLong ist nonNegativeInteger.
Die lexikalische Repräsentation von unsignedLong besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 12678967543233, +100000.
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.
unsignedLong hat die folgenden beschränkenden Fassetten :
[Definition:] unsignedInt ist von unsignedLong abgeleitet, indem der Wert von maxInclusive fest auf 4294967295 gesetzt wurde. Der Basistyp von unsignedInt ist unsignedLong.
Die lexikalische Repräsentation von unsignedInt besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 1267896754, +100000.
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.
unsignedInt hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von unsignedInt:
[Definition:] unsignedShort ist von unsignedInt abgeleitet, indem der Wert von maxInclusive fest auf 65536 gesetzt wurde. Der Basistyp von unsignedShort ist unsignedInt.
Die lexikalische Repräsentation von unsignedInt besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 12678, 10000.
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.
unsignedShort hat die folgenden beschränkenden Fassetten :
Die folgenden vordefinierten Datentypen sind abgeleitet von unsignedShort:
[Definition:] unsignedByte ist von unsignedShort abgeleitet, indem der Wert von maxInclusive fest auf 255 gesetzt wurde. Der Basistyp von unsignedByte ist unsignedShort.
Die lexikalische Repräsentation von unsignedByte besteht aus einer endlich langen Sequenz von Dezimalziffern (#x30-#x39). Beispiele sind: 0, 126, +100.
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.
unsignedByte hat die folgenden beschränkenden Fassetten :
[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.
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.
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.
positiveInteger hat die folgenden beschränkenden Fassetten :
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)].
Definitionen einfacher Typen legen fest:
Die Komponenten zur Definition einfacher Datentypen besitzen folgende Eigenschaften:
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.
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:
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 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
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.
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
<simpleType name="Sku"> <restriction base="string"> <pattern value="\d{3}-[A-Z]{2}"/> </restriction> </simpleType>
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 | ||||||
---|---|---|---|---|---|---|
|
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.
<simpleType name="listOfFloat"> <list itemType="float"/> </simpleType>
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.
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 | ||||||
---|---|---|---|---|---|---|
|
Ein Vereinigungs-Datentyp kann von einem oder mehreren atomaren, Listen- oder Vereinigungs-Datentypen abgeleitet sein. Das sind die sog. memberTypes dieses Vereinigungs-Datentyps.
<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.
base
- [Attribut] der <restriction> oder aber das simpleType
- [Kindelement] angegeben sein, beide zusammen sind nicht gestattet.
memberTypes
- [Attribut] der
<union> angegeben sein, oder es gibt mindestens
ein simpleType
- [Kindelement].
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:
In jedem Wertebereich gibt es den Begriff der Gleichheit mit den folgenden Regeln:
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.[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:
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:
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,
{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.
[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,
{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.
[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
{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:
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.
[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
{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.
[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:
<simpleType name="tatsächlichen Wert"> <restriction base="string"> <length value="8" fixed="true"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="nicht-leere-Zeichenkette"> <restriction base="string"> <minLength value="1"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name='Formular-Eingabe'> <restriction base="string"> <maxLength value="50"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="US-Postleitzahl"> <restriction base="string"> <pattern value="[0-9]{5}(-[0-9]{4})?"/> </restriction> </simpleType>
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:
pattern
Element Informationseinheit
<pattern
id = ID
value = anySimpleType
{jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
Content: (annotation?)
</pattern>
pattern Schemakomponente | ||||||
---|---|---|---|---|---|---|
|
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.[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:
<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>
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:
enumeration
Element Informationseinheit
<enumeration
id = ID
value = anySimpleType
{jegliche Attribute mit einem Namensraum, der nicht der Schema-Namensraum ist . . .}>
Content: (annotation?)
</enumeration>
enumeration Schemakomponente | ||||||
---|---|---|---|---|---|---|
|
[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}.
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 einhexadezimales A
(Zeilenvorschub); dieser wird als U+000A abgebildet. Die Notation muss
von 

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:
<simpleType name="token"> <restriction base="normalizedString"> <whiteSpace value="collapse"/> </restriction> </simpleType>
{preserve, replace, collapse}
.
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
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].[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:
<simpleType name="hundert-oder-weniger"> <restriction base="integer"> <maxInclusive value="100"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="kleiner-als-hundert-und-eins"> <restriction base="integer"> <maxExclusive value="101"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="mehr-als-neun-und-neunzig"> <restriction base="integer"> <minExclusive value="99"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="hundert-oder-mehr"> <restriction base="integer"> <minInclusive value="100"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="Summe"> <restriction base="decimal"> <totalDigits value="8"/> <fractionDigits value="2" fixed="true"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
[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:
<simpleType name="celsiusKoerperTemp"> <restriction base="decimal"> <totalDigits value="4"/> <fractionDigits value="1"/> <minInclusive value="36.4"/> <maxInclusive value="40.5"/> </restriction> </simpleType>
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.
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:
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
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.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 |
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:
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:
Im lexikalischen Format für duration werden außerdem folgende Buchstaben als Bezeichner verwendet und erscheinen in lexikalischen Formaten als sie selbst:
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.
[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.
Ein optionales Minuszeichen ist ohne Leerzeichen direkt vor der lexikalischen Repräsentation von duration, dateTime, date, gMonth und gYear gestattet.
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.
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 |
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).
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 |
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
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.
[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).
[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.
[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 FormS{,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.
[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.
[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.
[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.
[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".
[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.
[12] |
charClassExpr |
::= |
'[' charGroup ']' |
[Definition:] Eine Zeichengruppe ist entweder eine positive Zeichengruppe, eine negative Zeichengruppe, oder eine Zeichenklassen-Subtraktion.
[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.
[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.
[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
[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.
[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:
[
, ]
und \
sind keine gültigen Zeichen-Bereiche;
^
Zeichen ist nur dann am Anfang einer
positiven Zeichengruppe zulässig, wenn es Teil einer
negativen Zeichengruppe ist;
-
Zeichen ist nur am Anfang einer positiven Zeichengruppe ein gültiger Zeichen-Bereich.
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:
\
;
^
;
\
und nicht [
;
Anmerkung:
Der Zeichenwert eines Einzelzeichen-Fluchtsymbols ist der Zeichenwert des einzelnen Zeichens in der Zeichenmenge, für die das Fluchtsymbol steht.[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).
[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.
[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}]
.
[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) |
[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 EigenschaftCs
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}]
.
[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:
[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.Die folgende Auflistung fasst zugunsten der Leser der gedruckten Version dieses Dokuments alle Definitionen zusammen, die in diesem Dokument verwendet werden.
|
Zeichen.
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