edition W3C.de

XML Schema Teil 1: Strukturen

Deutsche Übersetzung

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

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

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

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



W3C

XML Schema Teil 1: Strukturen

W3C Empfehlung 2. Mai 2001

Diese Version:
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
(in XML (mit eigener DTD, XSL-Stylesheet) und HTML), mit getrennter Bereitstellung des Schemas und der DTD für Schemata, die in diesem Dokument beschrieben sind.
Aktuelle Version:
http://www.w3.org/TR/xmlschema-1/
Vorherige Version:
http://www.w3.org/TR/2001/PR-xmlschema-1-20010330/
Herausgeber:
Henry S. Thompson (University of Edinburgh) <ht@cogsci.ed.ac.uk>
David Beech (Oracle Corporation) <David.Beech@oracle.com>
Murray Maloney (für Commerce One) <murray@muzmo.com>
Noah Mendelsohn (Lotus Development Corporation) <Noah_Mendelsohn@lotus.com>

Zusammenfassung

XML Schema: Strukturen spezifiziert die XML Schema-Definitionssprache, mit der die Struktur von XML 1.0 Dokumenten beschrieben und Bedingungen an deren Inhalt formuliert werden können. Dabei wird auch die Verwendung von XML-Namensräumen spezifiziert. Die Schema-Sprache, die selbst in XML 1.0 dargestellt ist und Namensräume verwendet, hat die Ausdrucksmöglichkeiten der XML 1.0 Dokumenttyp-Definitionen (DTDs) und erweitert diese beträchtlich. Diese Spezifikation verwendet Definitionen aus XML Schema Teil 2: Datentypen.

Dokumentstatus

Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Veröffentlichung. Andere Dokumente können dieses Dokument ersetzen. Die neueste Version dieser Reihe von Dokumenten wird durch das W3C gepflegt.

Dieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten geprüft und vom Direktor als W3C-Empfehlung gebilligt. Es ist ein abgeschlossenes Dokument und darf als Referenzmaterial verwendet oder als normative Referenz von anderen Dokumenten zitiert werden. Die Rolle des W3C bei der Erstellung dieser Empfehlung ist es, die Spezifikation bekannt zu machen und ihre breite Anwendung zu fördern. Dies erhöht die Funktionsfähigkeit und Interoperabilität des Web.

Dieses Dokument wurde von der W3C XML Schema Arbeitsgruppe im Rahmen der XML Activity des W3C erstellt. Die Ziele der XML-Schema-Sprache werden im Dokument XML Schema Anforderungen erläutert. Die Autoren dieses Dokuments sind die Mitglieder der XML Schema Arbeitsgruppe. Unterschiedliche Teile des Dokuments haben unterschiedliche Herausgeber.

In diese Version des Dokuments wurden einige redaktionelle Änderungen aus früheren Versionen eingearbeitet.

Bitte melden Sie Fehler in diesem Dokument an www-xml-schema-comments@w3.org(Archiv). 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/ verfügbar.

Eine Aufstellung aktueller W3C Empfehlungen und anderer technischer Dokumente ist unter http://www.w3.org/TR/ zu finden.

Inhaltsverzeichnis

1 Einleitung
1.1 Zweck
2 Konzeptioneller Rahmen
3 Schemakomponenten im Detail
4 Schemata und Namensräume: Zugriff und Komposition
5 Schemata und Schemagültiger Validierungsprozess

Anhang

A Schema für Schemata (normativ)
B Referenzen (normativ)
C Ergebnis-Tabellen (normativ)
D Erforderliche XML-Information-Set-Einheiten und -Eigenschaften (normativ)
E Schemakomponenten-Diagramm (nicht-normativ)
F Glossar (nicht-normativ)
G DTD für Schemata (nicht-normativ)
H Analyse der Einschränkung eindeutiger Partikel-Zuordnung (nicht-normativ)
I Literatur (nicht-normativ)
J Danksagung (nicht-normativ)

1 Einleitung

In diesem Dokument wird der strukturelle Teil (XML Schema: Strukturen) der XML Schema Definitionssprache beschrieben.

Kapitel 2, Konzeptioneller Rahmen (§2), gibt einen Überblick zu XML Schema und beschreibt die verwendeten Konzepte. Es wird eine Einführung in das abstrakte Datenmodell von XML Schema gegeben sowie in die Fachbegriffe, die in diesem Dokument benutzt werden.

Kapitel 3, Schemakomponenten im Detail (§3), spezifiziert die genaue Semantik jeder Komponente des abstrakten Modells und die Darstellung dieser Komponenten in XML mit Referenz auf eine DTD und ein XML Schema für einen XML Schema Dokumenttyp. Außerdem wird die detaillierte Abbildung zwischen dem Element- und Attribut-Vokabular dieser Darstellung und den Komponenten und Eigenschaften des abstrakten Modells spezifiziert.

Kapitel 4 enthält Schemata und Namensräume: Zugriff und Komposition (§4), einschließlich der Beziehungen zwischen Dokumenten und Schemata wie Import, Inklusion und Neudefinition von Deklarationen und Definitionen sowie die Grundlagen der Gültigkeitsprüfung von Schemata.

Kapitel 5 diskutiert Schemata und Schemagültiger Validierungsprozess (§5), einschließlich des Gesamtansatzes für Schemagültigkeitsprüfung von Dokumenten und Zuständigkeiten von schemafähigen Prozessoren.

Die normativen Anhänge beinhalten ein Schema für Schemata (normativ) (§A) für die XML-Darstellung von Schemata sowie Referenzen (normativ) (§B).

Die nicht-normativen Anhänge beinhalten die DTD für Schemata (nicht-normativ) (§G) und ein Glossar (nicht-normativ) (§F).

Dieses Dokument dient primär als Referenz für die Sprachdefinition. Es enthält zwar einige Beispiele, ist aber nicht vornehmlich dafür ausgelegt, eine motivierende Einführung in den Schema-Entwurf oder eine Anleitung für neue Benutzer zu bieten. Vielmehr enthält es eine sorgfältige und vollständig explizite Definition der Schema-Sprache, so dass es sich als Grundlage für Implementierungen eignet. Für Leser, die eine schrittweise Einführung in den Schema-Entwurf suchen, ist das nicht-normative Dokument [XML Schema: Primer] ein guter Ausgangspunkt.

next sub-section1.1 Zweck

Der Zweck von XML Schema: Strukturen ist die Definition von XML-Schemata und ihrer Komponenten, die Bereitstellung von XML-Auszeichnungs-Konstrukten, mit denen Schemata dargestellt werden können, und die Definition der Anwendung von Schemata auf XML-Dokumente.

Der Zweck eines Schemas XML Schema: Strukturen ist die Definition und Beschreibung einer Klasse von XML-Dokumenten durch Verwendung von Schemakomponenten. Die Schemakomponenten schränken die Bedeutung, den Gebrauch und die Beziehungen der Bestandteile - Datentypen, Elemente und ihr Inhalt, Attribute und ihre Werte - der Schema-(XML)-Dokumente ein und dokumentieren diese. Schemata können auch die Spezifikation zusätzlicher Dokumentinformationen, wie beispielsweise Normalisierung und die Vorgabe von Attribut- und Elementwerten, bieten. Schemata haben Möglichkeiten für die Selbstdokumentation. Folglich kann XML Schema: Strukturen verwendet werden, um XML-Vokabulare für Klassen von XML-Dokumenten zu definieren, zu beschreiben und zu katalogisieren.

Jede Anwendung, die wohlgeformtes XML verarbeitet, kann den Formalismus von XML Schema: Strukturen verwenden, um syntaktische, strukturelle und Wertebereich-Beschränkungen auszudrücken, die auf ihre Dokumentinstanzen anwendbar sind. Der Formalismus von XML Schema: Strukturen ermöglicht das Beschreiben und Implementieren von Beschränkungsprüfungen für ein breites Spektrum von XML-Anwendungen. Die in dieser Spezifikation definierte Sprache stellt allerdings keinen Versuch dar, alle Möglichkeiten, die von einer beliebigen Anwendung benötigt werden könnten, bereitzustellen. Einige Anwendungen erfordern möglicherweise Beschränkungsfähigkeiten, die sich in dieser Sprache nicht ausdrücken lassen. In diesem Fall muss die Anwendung eigene, zusätzliche Validierungen ausführen.

previous sub-section next sub-section1.2 Abhängigkeiten von anderen Spezifikationen

Die Definition von XML Schema: Strukturen hängt von folgenden Spezifikationen ab: [XML-Infoset], [XML-Namespaces], [XPath] und [XML Schemas: Datatypes].

Siehe Erforderliche XML-Information-Set-Einheiten und -Eigenschaften (normativ) (§D) für eine Aufstellung der Informationseinheiten und Eigenschaften, die in [XML-Infoset] spezifiziert sind; die Definitionen in [XML-Infoset] werden von dieser Spezifikation als Vorbedingung für die Schema-konforme Verarbeitung benötigt.

previous sub-section 1.3 Konventionen und Terminologie

In diesem Abschnitt werden die Konventionen und die Typographie erklärt, wie sie in diesem Dokument verwendet werden.

Spezielle Begriffe werden an der Stelle der Einführung im Text definiert. Beispielsweise [Definition:] ein Begriff ist etwas, das mit einer besonderen Bedeutung verwendet wird. Die Definition ist als solche hervorgehoben und der damit definierte Begriff wird fett geschrieben. Das Ende der Definition ist nicht gesondert im angezeigten oder ausgedruckten Text gekennzeichnet. Die definierten Begriffe sind Verweise zu den jeweiligen Definitionen, hervorgehoben mit Punkten, z.B. Begriff.

Nicht-normative Beispiele sind in Kästen gesetzt und durch eine kurze Erklärung ergänzt:

Beispiel
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/meinSchema">
Hier eine Erklärung des Beispiels.

Die Definition jeder Art von Schemakomponente besteht aus einer Liste ihrer Eigenschaften und deren Inhalten, gefolgt von Beschreibungen der Semantik der Eigenschaften:

Schemakomponente: Beispiel
{Beispiel-Eigenschaft}
Definition der Eigenschaft.

Referenzen auf Eigenschaften von Schemakomponenten sind Verweise zur relevanten Definition, wie im obigen Beispiel aufgezeigt, abgesetzt mit geschweiften Klammern, z.B. {Beispiel-Eigenschaft}.

Die Beziehung zwischen einer Element-Informationseinheit, die Teil der XML-Darstellung eines Schemas ist, und einer oder mehrerer Schemakomponenten wird in einer Tabelle dargestellt, welche die betreffende(n) Element-Informationseinheit(en) aufführt. Dem folgt eine Aufstellung der Beziehungen zwischen den Eigenschaften der Komponente und den Eigenschaften der Informationseinheit. Soweit der Kontext bestimmt, um welche der verschiedenen Komponenten es sich handelt, werden mehrere Aufstellungen, d.h. je eine pro Kontext, gegeben. Die Eigenschafts-Beziehungen sind normativ, ebenso wie die XML-Darstellung der Element-Informationseinheiten.

In der XML-Darstellung sind fett hervorgehobene Attributnamen (z.B. anzahl, siehe unten) zwingend anzugebende Attribut-Informationseinheiten, die anderen sind optional. Wenn eine Attribut-Informationseinheit eine Aufzählungs-Typdefinition hat, werden die Werte durch vertikale Striche getrennt, wie z.B. bei größe (siehe unten). Soweit vorhanden werden Vorgabe-Werte nach einem Doppelpunkt dargestellt. Falls eine Attribut-Informationseinheit eine vordefinierte einfache Typdefinition hat, die in [XML Schemas: Datatypes] definiert ist, führt ein Verweis zu der betreffenden Definition.

Der zulässige Inhalt der Informationseinheit ist als Grammatikfragment, unter Verwendung der Kleene-Operatoren ?, * und +, dargestellt. Jeder darin enthaltene Elementname hat einen Verweis auf seine eigene Darstellung.

Anmerkung:

Die Darstellungen werden automatisch vom Schema für Schemata (normativ) (§A) hergeleitet. Im Fall eines offensichtlichen Konflikts hat das Schema für Schemata (normativ) (§A) Vorrang, da es zusammen mit den Bedingungen an die Schema-Darstellung die normative Angabe in Form von XML-Darstellungen zur Verfügung stellt.
Zusammenfassung der XML-Darstellung: Element-Informationseinheit beispiel

<beispiel
anzahl = integer
größe = (groß | mittel | klein) : mittel>
Inhalt: (all | any*)
</beispiel>

Schemakomponente Beispiel
Eigenschaft Darstellung
{Beispiel-Eigenschaft} Beschreibung der Eigenschaft, z.B. Erklärung des Wertes des [Attributs] größe

Referenzen auf Elemente im Text sind Verweise zur relevanten Darstellung, wie im obigen Beispiel, hervorgehoben durch spitze Klammern, z.B. <beispiel>.

Referenzen auf Eigenschaften von Informationseinheiten gemäß Definition in [XML-Infoset] werden als Verweise zum relevanten dortigen Abschnitt angegeben, hervorgehoben durch eckige Klammern, z.B. [Kindelemente].

Eigenschaften, die in dieser Spezifikation für Informationseinheiten definiert werden, werden wie folgt eingeführt:

PSVI-Beiträge für die Informationseinheit beispiel
[neue Eigenschaft]
Der Wert, den die Eigenschaft zugeordnet bekommt.

Referenzen auf Eigenschaften von Informationseinheiten, die in dieser Spezifikation definiert werden, werden als Verweise zu ihrer Einführung aufgeführt, wie im obigen Beispiel, hervorgehoben durch eckige Klammern, z.B. [neue Eigenschaft].

Die folgenden Hervorhebungsarten werden für nicht-normative Kommentare in diesem Dokument verwendet:

Anmerkung:

Allgemeine Kommentare, die sich an alle Leser richten.

Gemäß [XML 1.0 (Second Edition)] haben die Wörter darf und muss innerhalb des normativen Teils dieser Spezifikation folgende Bedeutung:

darf
Konforme Dokumente und schemafähige XML-Prozessoren dürfen sich wie beschrieben verhalten, müssen es aber nicht.
muss
Konforme Dokumente und schemafähige XML-Prozessoren müssen sich wie beschrieben verhalten, andernfalls sind sie fehlerhaft.

Man beachte allerdings, dass diese Spezifikation eine Fehlerdefinition und Zuständigkeiten konformer Prozessoren in Bezug auf Fehler (siehe Schemata und Schemagültiger Validierungsprozess (§5)) enthält, die wesentlich komplexer als diejenige von [XML 1.0 (Second Edition)] ist.

2 Konzeptioneller Rahmen

Dieses Kapitel gibt einen Überblick über XML Schema: Strukturen auf der Ebene des zugrunde liegenden abstrakten Datenmodells. Schemakomponenten im Detail (§3) enthält Einzelheiten über dieses Modell sowie eine normative XML-Darstellung jeder Komponente des Modells. Leser, die vorrangig am Schema-Entwurf interessiert sind, sollten zuerst [XML Schema: Primer] lesen, bevor sie sich mit den Unterabschnitten von Schemakomponenten im Detail (§3) mit der Bezeichnung XML-Darstellung der Schemakomponente ... befassen.

next sub-section2.1 Übersicht zu XML Schema

Ein XML Schema besteht aus Komponenten wie Typdefinitionen und Element-Deklarationen. Mit ihnen kann die Gültigkeit wohlgeformter Element- und Attribut-Informationseinheiten (gemäß Definition in [XML-Infoset]) geprüft werden. Außerdem spezifizieren sie möglicherweise Erweiterungen solcher Informationseinheiten und ihrer Nachkommen. Eine solche Erweiterung macht Informationen explizit, die im Originaldokument möglicherweise implizit vorhanden sind, wie z.B. normalisierte und/oder Vorgabe-Werte für Attribute und Elemente und Typen von Element- und Attribut-Informationseinheiten.

Die Schemagültigkeitsprüfung hat zwei Aspekte:

1 Ermittlung der lokalen Schemagültigkeit, d.h. ob eine Element- oder Attribut-Informationseinheit die Einschränkungen, die in den relevanten Komponenten eines XML Schemas verkörpert sind, erfüllt;
2 Die Ermittlung eines globalen Validierungsergebnisses für die Informationseinheit, wobei die lokale Schemagültigkeit mit den Ergebnissen der Schemagültigkeitsprüfungen ihrer Nachkommen kombiniert wird, falls es solche gibt. Dem Information-Set werden entsprechende Erweiterungen hinzugefügt, um das Validierungsergebnis verfügbar zu machen.

In dieser Spezifikation gilt die [Definition:] Der Begriff gültig und seine Ableitungen werden verwendet, um auf die obige Klausel 1 - Ermittlung der lokalen Schemagültigkeit - zu verweisen.

In dieser Spezifikation gilt die [Definition:] Der Begriff Validierungsprozess wird verwendet, um auf den Gesamtprozess der lokalen Validierung, der Schemagültigkeitsprüfung und der Information-Set-Erweiterung zu verweisen.

previous sub-section next sub-section2.2 Abstraktes Datenmodell

Diese Spezifikation baut auf [XML 1.0 (Second Edition)] und [XML-Namespaces] auf. Die hier verwendeten Konzepte und Definitionen hinsichtlich XML beschränken sich auf die abstrakte Ebene von Informationseinheiten gemäß Definition in [XML-Infoset]. Der Definition zufolge garantiert die Verwendung des Information-Set a prioriWohlgeformtheit (gemäß Definition in [XML 1.0 (Second Edition)]) und Konformität zu Namensräumen (gemäß Definition in [XML-Namespaces]) für alle Validierungskandidaten und für alle Schemadokumente.

Ebenso wie [XML 1.0 (Second Edition)] und [XML-Namespaces] durch Informationseinheiten beschrieben werden können, lassen sich XML Schemata durch ein abstraktes Datenmodell beschreiben. Indem XML Schemata durch ein abstraktes Datenmodell definiert werden, spezifiziert diese Spezifikation genauestens die Informationen, die einem konformen XML-Schema-Prozessor verfügbar gemacht werden müssen. Das abstrakte Modell für Schemata ist lediglich konzeptionell und schreibt keine bestimmte Implementierung oder Darstellung dieser Information vor. Um die Interoperation und gemeinsame Nutzung von Schema-Informationen zu erleichtern, wird ein normatives XML-Austauschformat für Schemata bereitgestellt.

[Definition:] Der generische Begriff Schemakomponente bezeichnet die Bausteine, aus denen das abstrakte Datenmodell des Schemas zusammengesetzt ist.

[Definition:] Ein XML Schema besteht aus einer Menge von Schemakomponenten. Es gibt insgesamt 13 verschiedene Komponenten, die in drei Gruppen aufgeteilt werden. Die primären Komponenten, die Namen haben können (Typdefinitionen) oder müssen (Element- und Attribut-Deklarationen), sind die folgenden:

Die sekundären Komponenten, die Namen haben müssen, sind die Folgenden:

Und schließlich die "Hilfs"komponenten, die Bestandteile anderer Komponenten bilden und damit nicht unabhängig von ihrem Kontext sind:

Während der Validierung werden [Definition:] Deklarations-Komponenten durch einen (qualifizierenden) Namen mit den zu validierenden Informationseinheiten in Verbindung gesetzt.

Andererseits gilt folgende [Definition:] Definitions-Komponenten definieren interne Schemakomponenten, die von anderen Schemakomponenten benutzt werden können.

[Definition:] Deklarationen und Definitionen können Namen haben und damit durch solche identifiziert werden; dies sind NCNamen gemäß Definition in [XML-Namespaces].

[Definition:] Mehrere Arten von Komponenten haben einen Ziel-Namensraum, der entweder nicht verwendet wird oder ein Namensraum-Name, ebenfalls gemäß Definition in [XML-Namespaces], ist. Der Ziel-Namensraum dient der Identifizierung des Namensraums, in dem die Assoziation zwischen der Komponente und ihrem Namen existiert. Im Fall von Deklarationen bestimmt er wiederum den Namen des Namensraums, z.B. der zu validierenden Element-Informationseinheiten.

Anmerkung:

Auf der abstrakten Ebene ist es nicht erforderlich, dass Komponenten eines Schemas einen gemeinsamen Ziel-Namensraum haben. Jedes Schema, das während des Validierungsprozesses von Dokumenten Anwendung findet und Namen aus mehr als einem Namensraum enthält, wird notwendigerweise Komponenten mit unterschiedlichen Ziel-Namensräumen beinhalten. Bei der XML-Darstellung von Komponenten trägt ein Schemadokument im Gegensatz dazu Definitionen und Deklarationen zu einem einzigen Ziel-Namensraum bei.

Validierung (siehe ausführliche Definition in Schemakomponenten im Detail (§3)) ist eine Relation zwischen Informationseinheiten und Schemakomponenten. Eine Attribut-Informationseinheit kann beispielsweise in Bezug auf eine Attribut-Deklaration validieren; eine Liste von Element-Informationseinheiten kann in Bezug auf ein Inhaltsmodell validieren usw. In den folgenden Abschnitten werden die Komponentenarten im abstrakten Schema-Datenmodell sowie wichtige Merkmale des Modells und ihr Beitrag zur Validierung kurz vorgestellt.

2.2.1 Typdefinitions-Komponenten

Das abstrakte Modell definiert zwei Arten von Typdefinitions-Komponenten: einfache und komplexe.

[Definition:] In dieser Spezifikation wird der Ausdruck Typdefinition verwendet, wenn keine Unterscheidung zwischen einfachen und komplexen Typen gemacht wird.

Typdefinitionen bilden eine Hierarchie mit einer einzigen Wurzel. Die nachfolgenden Unterabschnitte beschreiben zuerst die Merkmale dieser Hierarchie; anschließend werden Definitionen des einfachen und komplexen Typs eingeführt.

2.2.1.1 Typhierarchie

[Definition:] Abgesehen von einer speziellen Urtyp-Definition wird jede Typdefinition durch Einschränkung oder Erweiterung einer anderen Typdefinition konstruiert. Das Diagramm dieser Beziehungen bildet einen Baum, der als Typhierarchie bezeichnet wird.

[Definition:] Eine Typdefinition, deren Deklarationen oder Fassetten in einer Eins-zu-eins-Beziehung mit denen einer anderen spezifizierten Typdefinition stehen -- wobei jede die Möglichkeiten der zu ihr in Beziehung stehenden Deklaration oder Fassette einschränkt -- wird als Einschränkung bezeichnet. Die spezifizierten Einschränkungen können eine Einengung des Wertebereichs oder eine Reduzierung von Alternativen beinhalten. Instanzen eines Typs A, dessen Definition eine Einschränkung der Definition eines Typs B ist, sind immer auch Instanzen von Typ B.

[Definition:] Eine komplexe Typdefinition -- die zusätzlich zum Inhaltsmodell einer anderen spezifizierten Typdefinition weiteren Element- oder Attributinhalt zulässt -- wird als Erweiterung bezeichnet.

[Definition:] Jedes XML Schema enthält eine spezielle Urtyp-Definition, die als Wurzel der Typhierarchie des Schemas dient. Die Urtyp-Definition mit dem Namen anyType hat die einzigartige Eigenschaft, dass sie je nach Kontext als Definition eines einfachen oder komplexen Typs fungieren kann. Insbesondere können Einschränkungen der Urtyp-Definition entweder Definitionen eines einfachen oder komplexen Typs sein.

[Definition:] Eine Typdefinition, die als Basis für eine Erweiterung oder Einschränkung verwendet wird, gilt als Basistyp-Definition dieser Definition.

2.2.1.2 Einfache Typdefinition

Eine Definition eines einfachen Typs ist eine Menge von Einschränkungen auf Zeichenketten und Informationen über die damit kodierten Werte. Diese Einschränkungen sind auf den normalisierten Wert einer Attribut-Informationseinheit oder einer Element-Informationseinheit ohne Elementkinder anwendbar. Informell beschrieben gilt diese Typdefinition für Attribut-Werte und den textuellen Inhalt von Elementen.

Jede Definition eines einfachen Typs, der entweder vordefiniert (d.h. in [XML Schemas: Datatypes] definiert) oder benutzerdefiniert ist, ist eine Einschränkung einer bestimmten einfachen Basistyp-Definition. Für die vordefinierten primitiven Typen ist dies die Typdefinition mit dem Namen anySimpleType, die von der Urtyp-Definition abgeleitet ist. anySimpleType wiederum ist eine Einschränkung der Urtyp-Definition. Es können auch einfache Typen definiert werden, deren Mitglieder Elementlisten sind, die selbst durch eine andere einfache Typdefinition eingeschränkt sind oder deren Mitgliedschaft die Vereinigung der Mitgliedschaften mehrerer anderer einfacher Typdefinitionen ist. Definitionen von Listen und Vereinigungen einfachen Typs gelten auch als Einschränkungen der einfachen Urtyp-Definition.

Ausführliche Informationen zur Definition von einfachen Typen sind in Definition einfacher Typen (§3.14) und [XML Schemas: Datatypes] enthalten. Letztere Referenz definiert auch einen umfangreichen Bestand an vordefinierten einfachen Typen.

2.2.1.3 Komplexe Typdefinition

Die Definition eines komplexen Typs ist eine Menge von Attribut-Deklarationen, anwendbar auf die [Attribute], und ein Inhaltstyp, anwendbar auf die [Kindelemente] einer Element-Informationseinheit. Der Inhaltstyp kann Elemente so beschränken, dass die [Kindelemente] weder Element- noch Zeichen-Informationseinheiten enthalten (d.h., dass sie leer sind), eine Zeichenkette enthalten, die zu einem bestimmten einfachen Typ gehört, oder aber eine Folge von Element-Informationseinheiten enthalten, die einer bestimmten Elementgruppe, mit oder ohne Zeichen-Informationseinheiten, entspricht.

Jede komplexe Typdefinition ist entweder

oder

oder

Ein komplexer Typ kann einen anderen Typ erweitern, indem er dessen Inhaltsmodell durch zusätzliche Inhaltsmodell-Partikel und/oder zusätzliche Attribut-Deklarationen erweitert.

Anmerkung:

Diese Spezifikation erlaubt nur das Anhängen, jedoch keine anderen Arten von Erweiterungen. Dies vereinfacht die Anwendungsverarbeitung, die erforderlich ist, um Typkonvertierungen der Instanzen von abgeleiteten Typen in Basistypen vorzunehmen. Künftige Versionen ermöglichen eventuell andere Erweiterungsarten, für die allerdings komplexere Transformationen für Typkonvertierungen erforderlich sind.

Ausführliche Informationen über die Definition komplexer Typen sind in Definition komplexer Typen (§3.4) enthalten.

2.2.2 Deklarations-Komponenten

Es gibt drei Arten von Deklarations-Komponenten: Element, Attribut und Notation. Diese drei Komponenten werden in den folgenden Unterabschnitten beschrieben. Außerdem werden Element-Ersetzungsgruppen diskutiert, die in Verbindung mit Element-Deklarationen angewendet werden können.

2.2.2.1 Element-Deklaration

Eine Element-Deklaration ist die Assoziation eines Namens mit einer Definition eines einfachen oder komplexen Typs, eines (optionalen) Vorgabe-Werts und einer (möglicherweise leeren) Menge von identitätsbeschränkenden Definitionen. Die Assoziation ist entweder global oder beschränkt auf eine enthaltene Definition eines komplexen Typs. Eine Element-Deklaration der obersten Ebene mit dem Namen 'A' ist grob vergleichbar mit einem Paar folgender DTD-Deklarationen, wobei die assoziierte Typdefinition an den vorgesehenen Stellen eingefügt werden muss:

<!ELEMENT A . . .>
<!ATTLIST A . . .>

Element-Deklarationen leisten einen Beitrag zur Validierung als Teil der Elementgruppen-Validierung, wenn ihre Vorgabe-Werte und Typkomponenten mit einer Element-Informationseinheit mit passendem Namen und Namensraum verglichen werden, und durch Auslösung einer Validierung von identitätsbeschränkenden Definitionen.

Ausführliche Informationen über Element-Deklarationen sind in Element-Deklarationen (§3.3) enthalten.

2.2.2.2 Element-Ersetzungsgruppe

In XML 1.0 müssen Name und Inhalt eines Elements genau dem im entsprechenden Inhaltsmodell referenzierten Elementtyp entsprechen.

[Definition:] Durch den neuen Mechanismus der Element-Ersetzungsgruppen bieten XML Schemata ein leistungsstärkeres Modell, das Ersetzung eines benannten Elements durch ein anderes unterstützt. Jede Element-Deklaration der obersten Ebene kann als definierendes Element oder Kopf einer Element-Ersetzungsgruppe dienen. Andere Element-Deklarationen auf der obersten Ebene können ungeachtet des Ziel-Namensraums als Mitglieder der Ersetzungsgruppe bestimmt werden, deren Kopf das betreffende Element ist. In einem geeigneten Inhaltsmodell validiert eine Referenz auf den Kopf nicht nur den Kopf selbst, sondern auch Elemente, die Mitglied der Ersetzungsgruppe sind.

Alle diese Mitglieder müssen Typdefinitionen haben, die entweder die gleichen wie die Typdefinition des Kopfes oder aber Einschränkungen oder Erweiterungen davon sind. Deshalb gilt: Obwohl die Namen von Elementen stark variieren können, wenn man neue Namensräume und Mitglieder der Ersetzungsgruppe definiert, ist der Inhalt von Mitgliedselementen streng eingeschränkt auf die Typdefinition des Kopfes der Ersetzungsgruppe.

Man beachte, dass Element-Ersetzungsgruppen nicht als getrennte Komponenten dargestellt werden. Sie werden in den Eigenschaftswerten für Element-Deklarationen spezifiziert (siehe Element-Deklarationen (§3.3)).

2.2.2.3 Attribut-Deklaration

Eine Attribut-Deklaration ist eine Assoziation zwischen einem Namen und der Definition eines einfachen Typs, zusammen mit Informationen über Häufigkeit und (optional) einem Vorgabe-Wert. Die Assoziation ist in Bezug auf ihre enthaltene komplexe Typdefinition entweder global oder lokal. Attribut-Deklarationen tragen zur Validierung im Rahmen der Validierung komplexer Typdefinitionen bei, wenn ihr Vorkommen, ihre Vorgabe-Werte und Typkomponenten mit einer Attribut-Informationseinheit mit passendem Namen und Namensraum geprüft werden.

Ausführliche Informationen über Attribut-Deklarationen sind in Attribut-Deklarationen (§3.2) enthalten.

2.2.2.4 Notations-Deklaration

Eine Notations-Deklaration ist eine Assoziation zwischen einem Namen und einem Bezeichner für eine Notation. Damit eine Attribut-Informationseinheit in Bezug auf eine NOTATION - eine einfache Typdefinition - gültig ist, muss ihr Wert mit einer Notations-Deklaration deklariert werden.

Ausführliche Informationen über Notations-Deklarationen sind in Notations-Deklarationen (§3.12) enthalten.

2.2.3 Elementgruppen-Komponenten

Elementgruppen-, Partikel- und Wildcard-Komponenten tragen zur Definition eines komplexen Typs bei, die den Inhalt einer Element-Informationseinheit kontrolliert.

2.2.3.1 Elementgruppe

Eine Elementgruppe ist eine Einschränkung in der Form eines Grammatikfragments, das auf Listen mit Element-Informationseinheiten zutrifft. Es besteht aus einer Liste mit Partikeln, d.h. Element-Deklarationen, Wildcards und Elementgruppen. Es gibt drei Varianten von Elementgruppen:

  • Folge (die Element-Informationseinheiten stimmen mit den Partikeln in sequenzieller Reihenfolge) überein;
  • Konjunktion (die Element-Informationseinheiten stimmen mit den Partikeln in jeder beliebigen Reihenfolge überein);
  • Disjunktion (die Element-Informationseinheiten stimmen mit einem Partikel überein).

Ausführliche Informationen über Elementgruppen sind in Elementgruppen (§3.8) enthalten.

2.2.3.2 Partikel

Ein Partikel ist ein Grammatikausdruck für Elementinhalt, bestehend aus einer Element-Deklaration, einer Wildcard oder einer Elementgruppe sowie Häufigkeitsbeschränkungen. Partikel tragen zur Validierung im Rahmen der Validierung komplexer Typdefinitionen bei, wenn sie zwischen keinem und mehreren Element-Informationseinheiten zulassen oder Folgen davon, abhängig von ihren Inhalten und Häufigkeitsbeschränkungen.

[Definition:] Ein Partikel kann in einer komplexen Typdefinition benutzt werden, um die Validierung der [Kindelemente] einer Element-Informationseinheit einzuschränken. Ein solches Partikel wird als Inhaltsmodell bezeichnet.

Anmerkung:

XML Schema: Strukturen-Inhaltsmodelle ähneln den Inhaltsmodellen von [XML 1.0 (Second Edition)], sind aber ausdrucksstärker. Im Gegensatz zu [XML 1.0 (Second Edition)] verwendet XML Schema: Strukturen Inhaltsmodelle für die Validierung von gemischtem und Nur-Element-Inhalt.

Ausführliche Informationen über Partikel sind in Partikel (§3.9) enthalten.

2.2.3.3 Attribut-Verwendung

Eine Attribut-Verwendung spielt eine ähnliche Rolle wie ein Partikel, jedoch für Attribut-Deklarationen: Eine Attribut-Deklaration innerhalb einer komplexen Typdefinition ist in einer Attribut-Verwendung eingebettet, die spezifiziert, ob die Deklaration das Attribut erfordert oder lediglich zulässt und ob es einen Vorgabe- oder festen Wert hat.

2.2.3.4 Wildcard

Eine Wildcard ist eine spezielle Partikelart, die in Verbindung mit Element- und Attribut-Informationseinheiten auftritt, abhängig von deren Namensraum-Namen und unabhängig von deren lokalen Namen.

Ausführliche Informationen über Wildcards sind in Wildcards (§3.10) enthalten.

2.2.4 Komponenten zur Definition von Identitätsbeschränkungen

Eine identitätsbeschränkende Definition ist eine Assoziation zwischen einem Namen und einer von mehreren Varianten von Identitätsbeschränkungen hinsichtlich Eindeutigkeit und Referenz. Alle diese Varianten verwenden [XPath]-Ausdrücke, um Mengen von Informationseinheiten auszuwählen, die in Bezug zu bestimmten Ziel-Element-Informationseinheiten stehen, die eindeutig, ein Schlüssel oder eine gültige Referenz innerhalb eines spezifizierten Bereichs sind. Eine Element-Informationseinheit ist hinsichtlich einer Element-Deklaration mit identitätsbeschränkenden Definitionen nur gültig, wenn diese Definitionen für alle Nachkommen der ausgewählten Element-Informationseinheiten erfüllt sind.

Ausführliche Informationen zu identitätsbeschränkenden Definitionen sind in Identitätsbeschränkungs-Definitionen (§3.11) enthalten.

2.2.5 Gruppen-Definitions-Komponenten

Es werden zwei Arten von „Bequemlichkeitsdefinitionen“ zur Verfügung gestellt, um die Wiederverwendung von Teilen komplexer Typdefinitionen zu ermöglichen: Elementgruppen-Definitionen und Attributgruppen-Definitionen.

2.2.5.1 Elementgruppen-Definition

Eine Elementgruppen-Definition ist eine Assoziation zwischen einem Namen und einer Elementgruppe, die die Wiederverwendung derselben Elementgruppe in mehreren komplexen Typdefinitionen ermöglicht.

Ausführliche Informationen über Elementgruppen-Definitionen sind in Elementgruppen-Definitionen (§3.7) enthalten.

2.2.5.2 Attributgruppen-Definition

Eine Attributgruppen-Definition ist eine Assoziation zwischen einem Namen und einer Menge von Attribut-Deklarationen, die die Wiederverwendung derselben Attributgruppe in mehreren komplexen Typdefinitionen ermöglicht.

Ausführliche Informationen über Attributgruppen-Definitionen sind in Attributgruppen-Definitionen (§3.6) enthalten.

2.2.6 Anmerkungs-Komponenten

Eine Anmerkung ist Information für Personen und/oder für maschinelle Verarbeitung. Die Interpretation einer solchen Information ist in dieser Spezifikation nicht definiert.

Ausführliche Informationen über Anmerkungen sind in Anmerkungen (§3.13) enthalten.

previous sub-section next sub-section2.3 Bedingungen und Validierungsregeln

Die Spezifikation [XML 1.0 (Second Edition)] beschreibt zwei Arten von Bedingungen für XML-Dokumente: Bedingungen hinsichtlich Wohlgeformtheit und Gültigkeit. Informell werden Wohlgeformtheitsbedingungen durch die XML-Definition selbst (z.B. die Regeln für die Verwendung der Zeichen < und > sowie die Regeln für die korrekte Verschachtelung von Elementen) auferlegt. Gültigkeitsbedingungen sind demgegenüber weitere Bedingungen einer bestimmten DTD an die Dokumentstruktur.

Der vorherige Abschnitt konzentrierte sich auf Validierung, d.h. die Einschränkungen auf Informationseinheiten, die Schemakomponenten bereitstellen. In Wirklichkeit bietet diese Spezifikation aber vier verschiedene Arten von normativen Aussagen über Schemakomponenten, ihre Darstellungen in XML und ihren Beitrag zur Validierung von Informationseinheiten:

Schemakomponenten-Bedingungen
[Definition:] Bedingungen für die Schemakomponenten selbst, d.h. Bedingungen, die von Komponenten erfüllt sein müssen, damit sie überhaupt Komponenten sein können. Weitere Informationen hierzu befinden sich im 6. Unterabschnitt von Schemakomponenten im Detail (§3) mit einer Auflistung in Schemakomponenten-Beschränkungen (§C.4) .
Bedingungen an die Schema-Darstellung
[Definition:] Bedingungen für die Darstellung von Schemakomponenten in XML über jene hinaus, die in Schema für Schemata (normativ) (§A) beschrieben sind. Weitere Informationen hierzu befinden sich im 3. Unterabschnitt von Schemakomponenten im Detail (§3) mit einer Auflistung in Schema-Repräsentations-Beschränkungen (§C.3) .
Validierungsregeln
[Definition:] Beiträge zur Validierung in Verbindung mit Schemakomponenten. Weitere Informationen hierzu befinden sich im 4. Unterabschnitt von Schemakomponenten im Detail (§3) mit einer Auflistung in Gültigkeitsregeln (§C.1) .
Beiträge zum Schema Information-Set
[Definition:] Erweiterungen des Post-Schema-Information-Sets, ausgedrückt durch Schemakomponenten, die sich aus der Validierung und/oder dem Validierungsprozess ergeben. Weitere Informationen hierzu befinden sich im 5. Unterabschnitt von Schemakomponenten im Detail (§3) mit einer Auflistung in Beiträge zum Post-Schema-Validierungs-Information-Set (§C.2) nach der Schema-Validierung.

Entgegen einem ersten Eindruck sind die Beiträge zum Schema Information-Set nicht neu. Die XML-1.0-Validierung erweitert das XML-1.0 Information-Set auf ähnliche Weise, z.B. durch Bereitstellung von Werten für Attribute, die in Instanzen nicht vorhanden sind, und durch implizite Ausnutzung von Typinformationen für die Normalisierung oder den Zugriff. (Als Beispiel für den letzten Fall betrachte man die Wirkung von NMTOKENS auf Attribut-Leerraum und die Semantik von ID und IDREF.) Durch Einbeziehung von Beiträgen zum Schema Information-Set macht diese Spezifikation einige Merkmale explizit, die in XML 1.0 implizit blieben.

previous sub-section next sub-section2.4 Konformität

Diese Spezifikation beschreibt drei Konformitätsebenen für schemafähige Prozessoren. Die erste ist für alle Prozessoren erforderlich. Die Unterstützung der anderen beiden hängt von den Anwendungsumgebungen ab, in denen der Prozessor eingesetzt werden soll.

[Definition:] Minimal konforme Prozessoren müssen die Schemakomponenteneinschränkungen, Validierungsregeln und Beiträge zum Schema Information-Set, die in dieser Spezifikation aufgeführt sind, vollständig und korrekt implementieren.

[Definition:] Minimal konforme Prozessoren, die Schemata in der Form von XML-Dokumenten gemäß Schicht 2: Schemadokumente, Namensräume und Komposition (§4.2) akzeptieren, erfüllen zusätzlich die Konformität mit der XML-Darstellung von Schemata. Diese Prozessoren müssen bei der Verarbeitung von Schemadokumenten alle Schema-Darstellungseinschränkungen dieser Spezifikation vollständig und korrekt implementieren und die Spezifikationen in Schemakomponenten im Detail (§3) genauestens einhalten, hinsichtlich der Abbildung der Inhalte solcher Dokumente auf Schemakomponenten für die Verwendung während der Validierung und des Validierungsprozesses.

Anmerkung:

Durch Trennung der Konformitätsanforderungen in Bezug auf die konkrete Syntax von XML-Schemadokumenten gestattet es diese Spezifikation, Prozessoren zuzulassen, die Schemata in optimierten binären Darstellungen oder dynamisch erstellte Schemata verwenden, die als Datenstrukturen einer Programmiersprache dargestellt sind, oder Implementierungen, in denen bestimmte Schemata in ausführbaren Code wie C oder Java kompiliert werden. Solche Prozessoren gelten als minimal konform, erfüllen jedoch nicht notwendigerweise die Konformität mit der XML-Darstellung von Schemata.

[Definition:] Vollständig konforme Prozessoren sind netzwerkfähige Prozessoren, die sowohl minimal konform sind als auch die Konformität mit der XML-Darstellung von Schemata erfüllen und die zusätzlich in der Lage sein müssen, auf Schemadokumente im World Wide Web gemäß Darstellung von Schema-Darstellung im World Wide Web (§2.7) und Finden von Schemadefinitionen im Web (§4.3.2) zuzugreifen.

Anmerkung:

Obwohl diese Spezifikation nur diese drei Standardebenen der Konformität bietet, wird erwartet, dass künftig weitere Konventionen ausgearbeitet werden. Beispielsweise erwägt das World Wide Web Consortium (W3C) Konventionen für die Bereitstellung einer Vielzahl von Ressourcen in Bezug auf individuelle Dokumente und Namensräume im Web. Sollten solche Entwicklungen zu neuen Konventionen für die Darstellung von Schemata oder für den Zugriff derselben im Web führen, können neue Konformitätsebenen zum gegebenen Zeitpunkt festgelegt und benannt werden. Es besteht keine Notwendigkeit, diese Spezifikation zu modifizieren oder neu zu veröffentlichen, um solche zusätzlichen Konformitätsebenen zu definieren.

In Schemata und Namensräume: Zugriff und Komposition (§4) befindet sich eine ausführlichere Erklärung der Mechanismen für die Unterstützung dieser Konformitätsebenen.

previous sub-section next sub-section2.5 Namen und Symbolbereiche

Wie im Abschnitt Abstraktes Datenmodell (§2.2) beschrieben, haben die meisten Schemakomponenten Namen (bzw. dürfen welche haben). Würde man alle diese Namen aus dem gleichen "Pool" zuweisen, wären z.B. eine einfache Typdefinition und eine Element-Deklaration mit dem Namen "Titel" in einem bestimmten Ziel-Namensraum nicht möglich.

[Definition:] Diese Spezifikation führt deshalb den Begriff Symbolbereich ein, um eine Sammlung von Namen zu bezeichnen, die jeweils in Bezug auf andere eindeutig sind. Ein Symbolbereich ähnelt dem nicht-normativen Konzept der in [XML-Namespaces] eingeführten Namensraum-Partitionierung. Innerhalb eines bestimmten Ziel-Namensraums gibt es für jede Art von Definitions- und Deklarationskomponenten, die im Abschnitt Abstraktes Datenmodell (§2.2) definiert sind, einen bestimmten Symbolbereich. Ausnahme sind hierbei die einfachen und komplexen Typdefinitionen, die sich innerhalb eines Ziel-Namensraums einen Symbolbereich teilen. Innerhalb eines bestimmten Symbolbereichs sind Namen eindeutig, jedoch kann der gleiche Name in mehr als einem Symbolbereich erscheinen, ohne dass dadurch ein Konflikt entsteht. Beispielsweise kann der gleiche Name oder eine notwendige Beziehung konfliktfrei sowohl in einer Typdefinition als auch in einer Element-Deklaration erscheinen.

Lokale Attribut- und Element-Deklarationen sind in Bezug auf Symbolbereiche speziell. Jede komplexe Typdefinition definiert ihre eigenen Symbolbereiche für lokale Attribut- und Element-Deklarationen, wobei diese Symbolbereiche sich voneinander und von anderen Symbolbereichen unterscheiden. So können beispielsweise zwei komplexe Typdefinitionen, die den gleichen Ziel-Namensraum haben, eine lokale Attribut-Deklaration für den nicht qualifizierten Namen "Priorität" haben oder eine lokale Element-Deklaration für den Namen "Adresse" enthalten, ohne dass ein Konflikt oder eine Beziehung zwischen den beiden entsteht.

previous sub-section next sub-section2.6 Schema-bezogene Auszeichnungen in Instanzdokumenten

Die XML-Darstellung von Schemakomponenten verwendet ein Vokabular, das durch den Namensraum-Namen http://www.w3.org/2001/XMLSchema identifiziert wird. Der Übersichtlichkeit halber wird für Text und Beispiele in dieser Spezifikation das Präfix xs: verwendet; in der Praxis kann jedes beliebige Präfix benutzt werden.

XML Schema: Strukturen definiert mehrere Attribute für die direkte Verwendung in XML-Dokumenten. Diese Attribute sind in einem zu den Elementen des Instanzdokuments unterschiedlichen Namensraum, der den Namensraum-Namen http://www.w3.org/2001/XMLSchema-instance hat. Der Übersichtlichkeit halber wird für Text und Beispiele in dieser Spezifikation das Präfix xsi: verwendet; in der Praxis kann für diesen Namensraum jedes beliebige Präfix benutzt werden. Alle Schema-Prozessoren haben für die vordefinierten Attribute entsprechende Attribut-Deklarationen; siehe Attribut-Deklaration für das 'type'-Attribut (§3.2.7), Attribut-Deklaration für das 'nil'-Attribut (§3.2.7), Attribut-Deklaration für das 'schemaLocation'-Attribut (§3.2.7) und Attribut-Deklaration für das 'noNamespaceSchemaLocation'-Attribut (§3.2.7)

2.6.1 xsi:type

Die bei der Validierung eines Elements benutzte Einfache Typdefinition (§2.2.1.2) oder Komplexe Typdefinition (§2.2.1.3) wird normalerweise durch Referenz auf die entsprechenden Schemakomponenten bestimmt. Eine Element-Informationseinheit in einer Instanz darf aber explizit ihren Typ mit Hilfe des Attributs xsi:type bestimmen. Der Wert dieses Attributs ist ein QName; siehe QName-Interpretation (§3.15.3) für eine Beschreibung, wie QName mit einer Typdefinition assoziiert wird.

2.6.2 xsi:nil

XML Schema: Strukturen führt einen Mechanismus ein, der anzeigt, dass ein Element als gültig akzeptiert werden sollte, wenn es keinen Inhalt hat, trotz eines Inhaltstyps, der leeren Inhalt nicht erfordert oder sogar nicht notwendigerweise zulässt. Ein Element kann ohne Inhalt gültig sein, wenn es das Attribut xsi:nil mit dem Wert true (wahr) hat. Ein dementsprechend beschriftetes Element muss leer sein, kann aber Attribute enthalten, sofern dies vom entsprechenden komplexen Typ gestattet wird.

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

Die Attribute xsi:SchemaLocation und xsi:noNamespaceSchemaLocation können in einem Dokument verwendet werden, um Hinweise über den physikalischen Ort von Schemadokumenten zu geben, die im Validierungsprozess verwendet werden können. Einzelheiten über die Verwendung dieser Attribute sind in Finden von Schemadefinitionen im Web (§4.3.2) enthalten.

previous sub-section 2.7 Schema-Darstellung im World Wide Web

Im World Wide Web werden Schemata konventionell als XML-Dokumente (vorzugsweise mit MIME-Typ application/xml oder text/xml dargestellt; siehe jedoch Klausel 1.1 in Beschränkungen und Semantik zu Einfügungen (§4.2.1)). Dies ist konform mit den Spezifikationen in Schicht 2: Schemadokumente, Namensräume und Komposition (§4.2). Weitere Informationen über die Darstellung und Verwendung von Schemadokumenten im World Wide Web sind in Standards für die Darstellung von Schemata und Retrieval von Schemadokumenten im Web (§4.3.1) und Finden von Schemadefinitionen im Web (§4.3.2) enthalten.

3 Schemakomponenten im Detail

next sub-section3.1 Einführung

In den folgenden Abschnitten werden ausführliche Einzelheiten über die Komposition aller Schemakomponenten sowie ihre XML-Darstellungen und Beiträge zum Validierungsprozess beschrieben. In jedem Abschnitt werden eine einzelne Komponente und ihre Merkmale behandelt:

  1. Eigenschaften: ihre Werte und deren Bedeutung
  2. XML-Darstellung und die Abbildung auf Eigenschaften
  3. Einschränkungen für die Darstellung
  4. Validierungsregeln
  5. Beiträge des Schema-Validierungsprozesses zum XML Information-Set
  6. Einschränkungen für die Komponenten selbst

Die nachfolgenden Unterabschnitte bieten eine Einführung in die Konventionen und Fachbegriffe, die in den Komponentenabschnitten verwendet werden.

3.1.1 Komponenten und ihre Eigenschaften

Komponenten werden hinsichtlich ihrer Eigenschaften definiert und jede Eigenschaft wird ihrerseits durch Angabe ihres Wertebereichs definiert. Dies kann man als das Definieren eines Schemas als beschrifteten gerichteten Graphen verstehen, wobei die Wurzel das Schema, jeder Knoten eine Schemakomponente oder ein Literal (Zeichenkette, boolescher Wert, Zahl) und jede beschriftete Kante eine Eigenschaft ist. Der Graph ist nicht azyklisch: Es dürfen nicht mehrere Kopien von Komponenten mit dem gleichen Namen im gleichen Symbolbereich existieren. Das heißt, dass in manchen Fällen neu eintretende Ketten von Eigenschaften existieren müssen. Die Gleichheit von Komponenten zum Zweck dieser Spezifikation wird immer als Gleichheit von Namen (einschließlich Ziel-Namensräume) innerhalb von Symbolbereichen definiert.

Anmerkung:

Ein Schema und seine Komponenten gemäß Definition in diesem Kapitel sind eine Idealisierung der Information, die ein schemafähiger Prozessor benötigt: Implementierungen sind nicht dahingehend eingeschränkt, wie sie dies bereitstellen. Insbesondere ergeben sich keine Implikationen hinsichtlich der Einbettung versus Indirektion von Literalen aus der Verwendung der Sprache, z.B. "Eigenschaften ... haben ... Komponenten als Werte".

[Definition:] In dieser Spezifikation wird der Begriff nicht verwendet benutzt, um nicht angegebene Eigenschaftswerte eindeutig zu bezeichnen.

Jede nicht als optional identifizierte Eigenschaft muss zwingend vorhanden sein; optionale Eigenschaften, die nicht vorhanden sind, haben als Wert nicht verwendet. Jede Eigenschaft, die einen Mengen-, Teilmengen- oder Listenwert hat kann einen leeren Wert haben, sofern dies nicht ausdrücklich ausgeschlossen wird. Dies ist nicht das Gleiche wie nicht verwendet. Eine als Super- oder Submenge einer bestimmten Menge identifizierte Eigenschaft kann gleich dieser Menge sein, sofern nicht eine entsprechende Super- oder Submenge ausdrücklich verlangt wird. Mit 'string' in Teil 1 dieser Spezifikation ist eine Folge von ISO-10646-Zeichen gemeint (siehe zulässige XML-Zeichen in [XML 1.0 (Second Edition)]).

3.1.2 XML-Darstellung von Komponenten

Der hauptsächliche Zweck von XML Schema: Strukturen ist die Definition einer Menge von Schemakomponenten, die den Inhalt von Instanzen einschränken und deren Information-Set erweitern. Obwohl für diesen Zweck keine externe Darstellung von Schemata erforderlich ist, werden solche Darstellungen natürlich häufig benutzt. Um dies entsprechend zu unterstützen, bietet diese Spezifikation eine normative XML-Darstellung für Schemata, die jede Art von Schemakomponente bereitstellt. [Definition:] Ein Dokument in dieser Form (d.h. eine Element-Informationseinheit <schema>) ist ein Schemadokument . Für das Schemadokument insgesamt und seine Bestandteile definieren die folgenden Abschnitte Beziehungen zwischen Element-Informationseinheiten (mit Deklarationen in Schema für Schemata (normativ) (§A) und DTD für Schemata (nicht-normativ) (§G)) und Schemakomponenten. Alle Element-Informationseinheiten in der XML-Darstellung eines Schemas müssen sich im XML-Schema-Namensraum befinden, d.h. ihr [Namensraum-Name] muss http://www.w3.org/2001/XMLSchema lauten. Obwohl normalerweise zur Erstellung von XML Information-Sets, die Schemadokumente sind oder solche enthalten, ein XML-Parser verwendet wird, ist dies keine Voraussetzung. Jeder Mechanismus, der konforme XML Information-Sets gemäß Definition in [XML-Infoset] bildet, ist ein möglicher Ausgangspunkt.

Zwei Aspekte der XML-Darstellungen von Komponenten, die in den folgenden Abschnitten beschrieben werden, sind für alle Komponenten gleichbleibend:

  1. Alle erlauben die Qualifizierung von Attributen mit anderen Namensraum-Namen als dem XML-Schema-Namensraum; diese erscheinen als Anmerkungen in der entsprechenden Schemakomponente
  2. Alle erlauben eine <annotation> als ihr erstes Kindelement zur Bereitstellung von für Personen lesbaren Dokumentationen und/oder maschinenlesbaren Informationen.

3.1.3 Die Abbildung zwischen XML-Darstellungen und Komponenten

Für jede Art von Schemakomponente gibt es eine entsprechende normative XML-Darstellung. Die nachfolgenden Abschnitte beschreiben die Beziehungen zwischen den Eigenschaften jeder Schemakomponentenart einerseits und den Eigenschaften von Informationseinheiten in der betreffenden XML-Darstellung andererseits, zusammen mit Einschränkungen für die Darstellung über diejenigen hinaus, die implizit in Schema für Schemata (normativ) (§A) definiert sind.

Die Beschreibung erfolgt so, als ob die Beziehungen Abbildungen von der XML-Darstellung auf die Schemakomponente wären. Die Abbildung in die andere Richtung und damit die Entsprechung im Abstrakten kann aber immer daraus gebildet werden.

Bei der Beschreibung der Abbildung von XML-Darstellungen auf Schemakomponenten wird der Wert einer Komponenteneigenschaft oft durch den Wert einer Attribut-Informationseinheit, eines der [Attribute] einer Element-Informationseinheit, bestimmt. Da Schemadokumente auf Schema für Schemata (normativ) (§A) eingeschränkt sind, steht mit einer solchen Attribut-Informationseinheit immer eine einfache Typdefinition in Verbindung. [Definition:] Der Begriff tatsächlicher Wert wird verwendet, um auf das Mitglied des Wertebereichs der einfachen Typdefinition in Verbindung mit einer Attribut-Informationseinheit, die ihrem normalisierten Wert entspricht, Bezug zu nehmen. Dies wird oft eine Zeichenkette (string) sein, kann aber auch eine Ganzzahl (integer), ein boolescher Wert (boolean), eine URI-Referenz usw. sein. Der Begriff wird auch gelegentlich in Bezug auf Element- oder Attribut-Informationseinheiten in einem zu validierenden Dokument verwendet.

Viele Eigenschaften werden im Folgenden so identifiziert, dass sie andere Schemakomponenten oder Mengen von Komponenten als Werte haben. Der besseren Verständlichkeit halber wird bei den Definitionen in diesem Abschnitt davon ausgegangen, dass alle diese Werte tatsächlich vorhanden sind (sofern die Eigenschaft nicht explizit als optional identifiziert wird). Wenn Schemakomponenten aus XML-Darstellungen gebildet werden, die Referenzen auf Namen anderer Komponenten beinhalten, kann diese Annahme verletzt werden, falls eine oder mehrere Referenzen nicht aufgelöst werden können. Diese Spezifikation greift das Thema fehlender Komponenten auf einheitliche Weise auf; siehe Beschreibung in Fehlende Subkomponenten (§5.3). In den folgenden Beschreibungen der einzelnen Komponenten wird die Behandlung fehlender Komponenten nicht erwähnt.

Vorwärtsreferenzen auf benannte Definitionen und Deklarationen sind zulässig, sowohl innerhalb als auch zwischen Schemadokumenten. Bis die Komponente, die einer XML-Darstellung entspricht und eine Vorwärtsreferenz enthält, tatsächlich für die Validierung benötigt wird, kann eine entsprechend benannte Komponente verfügbar sein, so dass die Referenz nicht mehr gebraucht wird; siehe Einzelheiten hierzu in Schemata und Namensräume: Zugriff und Komposition (§4).

3.1.4 Leerraum-Normalisierung während der Validierung

In dieser Spezifikation gilt die [Definition:] Der initiale Wert einer Attribut-Informationseinheit ist der Wert der Eigenschaft [normalisierter Wert] dieser Informationseinheit. Ebenso ist der initiale Wert einer Element-Informationseinheit die Zeichenkette, die sich (in dieser Reihenfolge) aus dem [Zeichencode] jeder Zeichen-Informationseinheit in den [Kindelementen] dieser Element-Informationseinheit zusammensetzt.

Die obige Definition bedeutet, dass Kommentare und Verarbeitungsanweisungen auch mitten im Text bezüglich aller Validierungs-Zwecke ignoriert werden.

[Definition:] Der normalisierte Wert einer Element- oder Attribut-Informationseinheit ist ein initialer Wert, dessen Leerraum, soweit vorhanden, entsprechend dem Wert der Leerraum-Fassette der einfachen Typdefinition, die bei der Validierung herangezogen wird, normalisiert wurde:

preserve
keine Normalisierung; der Wert ist der normalisierte Wert
replace
Alle Vorkommen von #x9 (Tabulator), #xA (Zeilenvorschub) und #xD (Wagenrücklauf) werden durch #x20 (Leerzeichen) ersetzt.
collapse
Im Anschluss an die unter replace beschriebenen Ersetzungen werden aufeinanderfolgende Folgen von #x20-Vorkommen zu einem einzigen #x20 reduziert und beginnende und/oder endende #x20-Vorkommen werden gelöscht.

Es gibt drei alternative Validierungsregeln, die den nötigen Hintergrund für das Obige liefern können: lokal gültiges Attribut (§3.2.4) (Klausel 3), lokal gültiges Element (Typ) (§3.3.4) (Klausel 3.1.3) oder lokal gültiges Element (komplexer Typ) (§3.4.4) (Klausel 2.2).

Diese drei Normalisierungsebenen entsprechen der in XML 1.0 für Elementinhalt, CDATA-Attributinhalt bzw. Token-Attributinhalt vorgeschriebenen Verarbeitung. Die Attributwert-Normalisierung in [XML 1.0 (Second Edition)] enthält weitere Erklärungen über replace und collapse für Attribute. Die Erweiterung dieser Verarbeitung auf Elementinhalt ist notwendig, um eine konsistente Validierungs-Semantik für einfache Typen sicherzustellen, ungeachtet dessen, ob sie auf Attribute oder Elemente angewandt wird. Die zweimalige Durchführung im Fall von Attributen, deren [normalisierter Wert] bereits einer Ersetzung (replace) oder einer Zusammenfassung (collapse) auf der Grundlage von Informationen in einer DTD unterzogen wurde, ist notwendig, um die konsistente Behandlung von Attributen sicherzustellen, ungeachtet des Umfangs, in dem die DTD-Information während der XML-Information-Set-Erzeugung verwendet wurde.

Anmerkung:

Sogar wenn eine DTD-Information bereits angewandt wurde und die Attributwert-Normalisierung erfolgte, kann die obige Definition von normalisiertem Wert eine weitere Normalisierung bedeuten, beispielsweise, wenn Referenzen auf eine Zeichen-Entity in Attributwerten zu weiteren Leerzeichen führen, zusätzlich zu denen im initialen Wert.

previous sub-section next sub-section3.2 Attribut-Deklarationen

Attribut-Deklarationen werden bereitgestellt für:

Beispiel
<xs:attribute name="alter" type="xs:positiveInteger" use="required"/>
Die XML-Darstellung einer Attribut-Deklaration.

3.2.1 Die Schemakomponente Attribut-Deklaration

Die Attribut-Deklaration für Schemakomponenten hat folgende Eigenschaften:

Schemakomponente: Attribut-Deklaration
{Name}
Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}
Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Typdefinition}
Definition eines einfachen Typs.
{Gültigkeitsbereich}
Optional: entweder global oder die Definition eines komplexen Typs.
{Wertebereich-Beschränkung}
Optional: ein Paar bestehend aus einem Wert und aus default oder fixed.
{Anmerkung}
Optional: eine Anmerkung.

Die Eigenschaft {Name} muss mit dem lokalen Teil der Namen von zu validierenden Attributen übereinstimmen.

Der Wert des Attributs muss mit der bereitgestellten {Typdefinition} konform sein.

Ein Wert der Eigenschaft {Ziel-Namensraum}, der ungleich nicht verwendet ist, sieht die Validierung von Namensraum-qualifizierten Attribut-Informationseinheiten vor (die ausdrücklich mit einem Präfix auf der Ebene der Zeichen von XML-Dokumenten versehen sein müssen). Nicht verwendet-Werte von {Ziel-Namensraum}validieren unqualifizierte Informationseinheiten (ohne Präfix).

Ein {Gültigkeitsbereich}global identifiziert Attribut-Deklarationen, die für die Verwendung in komplexen Typdefinitionen durch das Schema verfügbar sind. Deklarationen des lokalen Bereichs sind nur für die Verwendung innerhalb der Definition eines komplexen Typs verfügbar, die von der Eigenschaft {Gültigkeitsbereich} identifiziert wird. Diese Eigenschaft wird im Fall von Deklarationen innerhalb von Attributgruppen-Definitionen nicht verwendet: Ihr Gültigkeitsbereich wird bestimmt, wenn sie in der Konstruktion von komplexen Typdefinitionen benutzt werden.

{Wertebereich-Beschränkung} reproduziert die Funktionen der Attributwerte default und #FIXED gemäß XML 1.0. Default spezifiziert, dass das Attribut zwingend im Post-Schema-Information-Set nach der Schema-Validierung enthalten sein muss, und zwar mit dem vorgegebenen Wert, falls das Attribut nicht vorhanden ist; fixed bedeutet, dass der Attributwert, falls vorhanden, gleich dem gelieferten Einschränkungswert sein muss oder, falls nicht vorhanden, wie bei default, den vorgegebenen Wert annimmt. Man beachte, dass es Werte und nicht Zeichenketten sind, die vorgegeben und/oder geprüft werden.

Siehe Anmerkungen (§3.13) mit Informationen zur Rolle der Eigenschaft {Anmerkung}.

Anmerkung:

Eine vollständige und formale Präsentation der Semantik von {Name}, {Ziel-Namensraum} und {Wertebereich-Beschränkung} in Verbindung mit anderen Aspekten der Validierung komplexer Typen befindet sich im Abschnitt lokal gültiges Element (komplexer Typ) (§3.4.4).

[XML-Infoset] unterscheidet Attribute mit Namen wie xmlns oder xmlns:xsl von gewöhnlichen Attributen und identifiziert sie damit als [Namensraum-Attribute]. Dementsprechend ist es unnötig und tatsächlich auch gar nicht möglich, dass Schemata Attribut-Deklarationen enthalten, die solchen Namensraum-Deklarationen entsprechen; siehe xmlns nicht erlaubt (§3.2.6). Diese Spezifikation erlaubt es nicht, einen Vorgabe-Wert für eine Namensraum-Deklaration bereitzustellen.

3.2.2 XML-Darstellung der Schemakomponente Attribut-Deklaration

Die XML-Darstellung einer Schemakomponente Attribut-Deklaration ist eine Element-Informationseinheit <attribute>. Sie spezifiziert eine einfache Typdefinition für ein Attribut entweder durch Referenz oder explizit und kann Vorgabe-Informationen bereitstellen. Die Beziehungen zwischen den Eigenschaften der Informationseinheit und den Eigenschaften der Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit attribute

<attribute
default = string
fixed = string
form = (qualified | unqualified)
id = ID
name = NCName
ref = QName
type = QName
use = (optional | prohibited | required) : optional
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (simpleType?))
</attribute>

Falls das Elternelement der Element-Informationseinheit <attribute> <schema> ist, sieht die entsprechende Schemakomponente wie folgt aus:
Schemakomponente Attribut-Deklaration
Eigenschaft Darstellung
{Name} Der tatsächliche Wert des [Attributs] name.
{Ziel-Namensraum} Der tatsächliche Wert des [Attributs] targetNamespace der Elternelement-Informationseinheit <schema> oder nicht verwendet, falls targetNamespace nicht angegeben ist.
{Typdefinition} Die Definition eines einfachen Typs, die, falls angegeben, der Element-Informationseinheit <simpleType> in [Kindelemente] entspricht; sonst, falls angegeben, die einfache Typdefinition, aufgelöst durch den tatsächlichen Wert des [Attributs] type; andernfalls ist es die einfache Urtyp-Definition.
{Gültigkeitsbereich} global.
{Wertebereich-Beschränkung} Gibt es ein [Attribut] default oder fixed, dann ein Paar, bestehend aus dem tatsächlichen Wert dieses [Attributs] (hinsichtlich der {Typdefinition}) und entweder default oder fixed; andernfalls nicht verwendet.
{Anmerkung} Die Anmerkung entsprechend der Element-Informationseinheit <annotation> in [Kindelemente], falls vorhanden; andernfalls nicht verwendet.
Falls die Element-Informationseinheit <attribute> entweder <complexType> oder <attributeGroup> als Vorfahr hat und das [Attribut] ref nicht vorhanden ist, entspricht es einer Attribut-Verwendung mit Eigenschaften wie folgt (es sei denn, use='prohibited'; in diesem Fall gibt es keine Entsprechung für diese Informationseinheit):
Schemakomponente Attribut-Verwendung
Eigenschaft Darstellung
{erforderlich} wahr, falls das [Attribut] use mit dem tatsächlichen Wert required vorhanden ist, andernfalls falsch.
{Attribut-Deklaration} Siehe die untenstehende Abbildung der Attribut-Deklaration.
{Wertebereich-Beschränkung} Gibt es ein [Attribut] default oder fixed, dann ist es ein Paar bestehend aus dem tatsächlichen Wert dieses [Attributs] (in Bezug auf die {Typdefinition} der {Attribut-Deklaration}) und entweder default oder fixed; andernfalls nicht verwendet.
Schemakomponente Attribut-Deklaration
Eigenschaft Darstellung
{Name} Der tatsächliche Wert des [Attributs] name
{Ziel-Namensraum} Falls form vorhanden und der tatsächliche Wert qualified ist oder falls form nicht verwendet wird und der tatsächliche Wert von attributeFormDefault des Vorfahren <schema> qualified ist, dann gilt der tatsächliche Wert des [Attributs] targetNamespace der Elternelement-Informationseinheit <schema> oder nicht verwendet, falls nicht vorhanden; andernfalls nicht verwendet.
{Typdefinition} Die einfache Typdefinition, die der Element-Informationseinheit <simpleType> in [Kindelemente] entspricht, falls vorhanden; andernfalls die einfache Typdefinition, aufgelöst durch den tatsächlichen Wert des [Attributs] type, falls vorhanden; andernfalls die einfache Urtyp-Definition.
{Gültigkeitsbereich} Falls die Element-Informationseinheit <attribute> als Vorfahre <complexType> hat, dann die komplexe Typdefinition entsprechend dieser Einheit; andernfalls (die Element-Informationseinheit <attribute> befindet sich innerhalb einer <attributeGroup>-Definition) nicht verwendet.
{Wertebereich-Beschränkung} nicht verwendet.
{Anmerkung} Die Anmerkung, die der Element-Informationseinheit <annotation> in [Kindelemente] entspricht, falls vorhanden; andernfalls nicht verwendet.
andernfalls (die Element-Informationseinheit <attribute> hat <complexType> oder <attributeGroup> als Vorfahre und das [Attribut] ref ist vorhanden), entspricht sie einer Attribut-Verwendung mit Eigenschaften wie folgt (sofern nicht use='prohibited'; in diesem Fall entspricht der Einheit überhaupt nichts):
Schemakomponente Attribut-Verwendung
Eigenschaft Darstellung
{erforderlich} wahr, falls das [Attribut] use mit dem tatsächlichen Wert required vorhanden ist; andernfalls falsch.
{Attribut-Deklaration} Die vom tatsächlichen Wert von [Attribut] ref aufzulösende Attribut-Deklaration (der obersten Ebene).
{Wertebereich-Beschränkung} Falls es ein [Attribut] default oder fixed gibt, dann ein Paar, bestehend aus dem tatsächlichen Wert dieses [Attributs] (in Bezug auf die {Typdefinition} der {Attribut-Deklaration}) und entweder default oder fixed; andernfalls nicht verwendet.

Attribut-Deklarationen können auf der obersten Ebene eines Schemadokuments oder innerhalb komplexer Typdefinitionen vorkommen, entweder als komplette (lokale) Deklarationen oder durch Referenz auf Deklarationen der obersten Ebene oder innerhalb von Attributgruppen-Definitionen. Für komplette Deklarationen, lokal oder auf der obersten Ebene, wird das Attribut type verwendet, falls die Deklaration eine vordefinierte oder im Voraus deklarierte einfache Typdefinition benutzen kann. Andernfalls wird ein anonymer <simpleType> innerhalb der Deklaration bereitgestellt.

Der Vorgabe-Wert, wenn keine einfache Typdefinition referenziert oder bereitgestellt wird, ist die einfache Urtyp-Definition, die keinerlei Einschränkungen auferlegt.

Die von einer Deklaration der obersten Ebene validierten Attribut-Informationseinheiten müssen mit dem {Ziel-Namensraum} dieser Deklaration qualifiziert werden (falls dieser nicht verwendet wird, muss die Informationseinheit unqualifiziert sein). Die Kontrolle darüber, ob Attribut-Informationseinheiten, die von einer lokalen Deklaration validiert werden, qualifiziert sein müssen oder nicht, wird durch das form-[Attribut] bereitgestellt. Dessen Vorgabe-Wert wird vom [Attribut]attributeFormDefault des einschließenden <schema>, über dessen Festlegung des {Ziel-Namensraum}s, bereitgestellt.

Die Namen der Attribut-Deklarationen der obersten Ebene haben ihren eigenen Symbolbereich. Die Namen von lokalen Attribut-Deklarationen befinden sich im lokalen Symbolbereich der enthaltenden Typdefinition.

3.2.3 Bedingungen an die XML-Darstellung von Attribut-Deklarationen

Bedingung an Schema-Darstellung: korrekte Darstellung von Attribut-Deklarationen
Zusätzlich zu den Bedingungen, die den Element-Informationseinheiten <attribute> durch das Schema für Schemata auferlegt werden, müssen alle folgenden Aussagen wahr sein:
1 default und fixed dürfen nicht beide vorhanden sein.
2 Falls default und use zusammen vorkommen, muss use den tatsächlichen Wert optional haben.
3 Wenn der Elternteil der Informationseinheit nicht <schema> ist, müssen alle folgenden Aussagen wahr sein:
3.1 ref oder name muss vorhanden sein; es dürfen aber nicht beide gleichzeitig vorkommen.
3.2 Wenn ref vorhanden ist, dürfen <simpleType>, form und type nicht verwendet werden.
4 type und <simpleType> dürfen nicht beide vorhanden sein.
5 Die entsprechende Attribut-Deklaration muss die Bedingungen gemäß Bedingungen an die Schemakomponente Attribut-Deklaration (§3.2.6) erfüllen.

3.2.4 Validierungsregeln für Attribut-Deklarationen

Validierungsregel: lokal gültiges Attribut
Damit eine Attribut-Informationseinheit hinsichtlich einer Attribut-Deklaration lokal gültig sein kann, müssen alle folgenden Aussagen wahr sein:
1 Die Deklaration darf nicht nicht verwendet sein (siehe Fehlende Subkomponenten (§5.3) mit Hinweisen, in welchen Fällen dies nicht zutrifft).
2 Ihre {Typdefinition} darf nicht nicht verwendet sein.
3 Der normalisierte Wert der Informationseinheit muss hinsichtlich der {Typdefinition} gemäß gültiger String (§3.14.4) lokal gültig sein.
4 Der tatsächliche Wert der Informationseinheit muss mit dem Wert der {Wertebereich-Beschränkung} übereinstimmen, falls er vorhanden ist und den Zusatz fixed hat.
Validierungsregel: Die Schemagültigkeitsprüfung (Attribut)
Die Schemagültigkeitsprüfung einer Attribut-Informationseinheit hängt allein von ihrer Validierung ab.

[Definition:] Während der Validierung werden Assoziationen zwischen Element- und Attribut-Informationseinheiten unter den [Kindelementen] und [Attributen] einerseits und zwischen Element- und Attribut-Deklarationen andererseits als Seiteneffekt aufgebaut. Solche Deklarationen werden als kontextbestimmte Deklarationen bezeichnet. Siehe Klausel 3.1 (in lokal gültiges Element (komplexer Typ) (§3.4.4)) für Attribut-Deklarationen, Klausel 2 (in lokal gültige Element-Folge (Partikel) (§3.9.4)) für Element-Deklarationen.

Damit die Schemagültigkeit einer Attribut-Informationseinheit geprüft werden kann, müssen alle folgenden Aussagen wahr sein:
1 Eine nicht nicht verwendete-Attribut-Deklaration muss bekannt sein, namentlich eine der folgenden:
1.1 Eine Deklaration, die als ihre kontextbestimmte Deklaration aufgebaut wurde
1.2 Eine Deklaration, die durch ihren [lokalen Namen] und [Namensraum-Namen] gemäß Definition in QName-Auflösung (Instanz) (§3.15.4) aufgelöst wurde und die ihre kontextbestimmte Deklaration zur Verfügung stellt, ist nicht skip.
2 Ihre Gültigkeit hinsichtlich dieser Deklaration muss gemäß lokal gültiges Attribut (§3.2.4) ausgewertet worden sein.
3 Sowohl Klausel 1 als auch Klausel 2 von lokal gültiges Attribut (§3.2.4) müssen erfüllt sein.

[Definition:] Bei Attributen besteht kein Unterschied zwischen normalem Validierungsprozess und strengem Validierungsprozess. Wenn also Obiges zutrifft, wurde die Attribut-Informationseinheit streng validiert .

3.2.5 Beiträge von Attribut-Deklarationen zum XML-Information-Set

Beitrag zum Schema Information Set: Ergebnis des Validierungsprozesses (Attribut)
Wenn die Schemagültigkeit einer Attribut-Informationseinheit gemäß Die Schemagültigkeitsprüfung (Attribut) (§3.2.4) bewertet wurde, dann hat der Post-Schema-Validierungs-Information-Set (PSVI) folgende Eigenschaften:
PSVI-Beiträge für die Informationseinheit Attribut
[Validierungs-Kontext]
Die Element-Informationseinheit des nächsten Vorfahren mit einer Eigenschaft [Schema-Informationen].
[Gültigkeit]
Der zutreffende Fall unter den folgenden:
1 Falls streng validiert wurde, dann der zutreffende Fall unter den folgenden:
1.1 Falls sie gültig war, wie durch lokal gültiges Attribut (§3.2.4) definiert, dann dann gültig;
1.2 Sonst ungültig.
2 Sonst unbekannt.
[versuchte Validierung]
Der zutreffende Fall unter den folgenden:
1 Falls sie streng validiert wurde, dann dann vollständig;
2 Sonst nicht.
[spezifiziertes Schema]
Information-Set. Siehe Vorgabe-Attributwert (§3.4.5) für andere mögliche Werte.
Beitrag zum Schema Information Set: Validierung fehlgeschlagen (Attribut)
Wenn die lokale Gültigkeit gemäß Definition in lokal gültiges Attribut (§3.2.4) einer Attribut-Informationseinheit validiert wurde, hat die Informationseinheit in dem Post-Schema-Validierungs-Information-Set eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Attribut
[Schema-Fehlercode]
Der zutreffende Fall unter den folgenden:
1 Falls die Informationseinheit nicht gültig ist, dann eine Liste. Anwendungen, die Informationen über den bzw. die Gründe für den Validierungs-Fehlschlag bereitstellen wollen, können einen oder mehrere Fehlercodes (siehe Ergebnis-Tabellen (normativ) (§C)) hiermit registrieren.
2 Sonst nicht verwendet.
Beitrag zum Schema Information Set: Attribut-Deklaration
Wenn eine Attribut-Informationseinheit in Bezug auf eine Attribut-Deklaration gemäß lokal gültiges Attribut (§3.2.4) gültig ist, darf die Attribut-Informationseinheit im Post-Schema-Validierungs-Information-Set, nach Wahl des Prozessors, folgende Eigenschaft haben:
PSVI-Beiträge für die Informationseinheit Attribut
[Attribut-Deklaration]
Eine zu ihrer Deklarationskomponente isomorphe Informationseinheit.
Beitrag zum Schema Information Set: Attribut validiert durch den Typ
Falls Klausel 3 von lokal gültiges Attribut (§3.2.4) in Bezug auf eine Attribut-Informationseinheit zutrifft, hat die Attribut-Informationseinheit im Information-Set nach der Schema-Validierung eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Attribut
[Schema-normalisierter Wert]
Der normalisierte Wert der Informationseinheit, wie validiert.
Des Weiteren hat die Informationseinheit eine der folgenden alternativen Eigenschaftsmengen:

Entweder
PSVI-Beiträge für die Informationseinheit Attribut
[Typdefinition]
Eine zu der entsprechenden Komponente {Typdefinition} der Attribut-Deklaration isomorphe Informationseinheit.
[Mengenelement-Typ-Definition]
Genau dann, wenn diese Typdefinition {Sorte} union hat, dann eine zu diesem Mitglied seiner {Mengenelement-Typ-Definition}, das den [normalisierten Wert] der Attribut-Informationseinheit validiert hat, isomorphe Informationseinheit.
oder
PSVI-Beiträge für die Informationseinheit Attribut
[Typ der Typdefinition]
einfach.
[Namensraum der Typdefinition]
Der {Ziel-Namensraum} der Typdefinition.
[anonyme Typdefinition]
wahr, falls der {Name} der Typdefinition nicht verwendet wird; andernfalls falsch.
[Name der Typdefinition]
Der {Name} der Typdefinition, falls er nicht nicht verwendet wird. Falls er nicht verwendet wird, dürfen Schema-Prozessoren einen eindeutigen Wert für die Definition bereitstellen, müssen es aber nicht.
Falls die Typdefinition die {Sorte} union hat, dann wird [Definition:] dieses Mitglied der {Mengenelement-Typ-Definition}, das den normalisierten Wert der Attribut-Informationseinheit validiert hat, die tatsächliche Mengenelement-Typ-Definition genannt und es gibt drei zusätzliche Eigenschaften:
PSVI-Beiträge für die Informationseinheit Attribut
[Namensraum der Mengenelement-Typ-Definition]
Der {Ziel-Namensraum} der tatsächlichen Mengenelement-Typ-Definition.
[anonyme Mengenelement-Typ-Definition]
wahr, falls der {Name} der tatsächlichen Mengenelement-Typ-Definition nicht verwendet wird; andernfalls falsch.
[Name der Mengenelement-Typ-Definition]
Der {Name} der tatsächlichen Mengenelement-Typ-Definition, falls er nicht nicht verwendet wird. Falls er nicht verwendet wird, dürfen Schema-Prozessoren einen eindeutigen Wert für die Definition bereitstellen, müssen es aber nicht.
Die erste der obigen (zur Informationseinheit isomorphen) Alternativen wird für Anwendungen wie Anfrage-Prozessoren bereitgestellt, die Zugriff auf alle Details über den Validierungsprozess einer Informationseinheit benötigen, z.B. die Typhierarchie. Die zweite Alternative ist für einfachere Prozessoren bestimmt, für die die Notwendigkeit der Darstellung der signifikanten Teile der Typhierarchie als Informationseinheiten zu aufwendig sein kann.

Falls die Deklaration zusätzlich eine {Wertebereich-Beschränkung} hat, hat die Informationseinheit eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Attribut
Falls die Attribut-Informationseinheit nicht streng validiert wurde, werden statt der oben spezifizierten Werte folgende Werte verwendet:
1 Die Eigenschaft [Schema-normalisierter Wert] der Informationseinheit hat als Wert den initialen Wert der Einheit
2 Die Eigenschaften [Typdefinition] und [Mengenelement-Typ-Definition] oder ihre Alternativen basieren auf der einfachen Urtyp-Definition.

3.2.6 Bedingungen an die Schemakomponente Attribut-Deklaration

Alle Attribut-Deklarationen (siehe Attribut-Deklarationen (§3.2)) müssen die folgenden Bedingungen erfüllen.

Bedingung an Schemakomponente: Eigenschaften der Attribut-Deklaration
Alle folgenden Aussagen müssen wahr sein:
1 Die Werte der Eigenschaften einer Attribut-Deklaration müssen wie in der Eigenschaftstabelle in Die Schemakomponente Attribut-Deklaration (§3.2.1) beschrieben sein, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).
2 Falls es eine {Wertebereich-Beschränkung} gibt, muss die kanonisch lexikalische Darstellung des Wertes gültig bezüglich der {Typdefinition}, wie in gültiger String (§3.14.4) definiert, sein.
3 Falls die {Typdefinition} ID ist oder von ID abgeleitet ist, darf es keine {Wertebereich-Beschränkung} geben.
Bedingung an Schemakomponente: xmlns nicht erlaubt
Der {Name} einer Attribut-Deklaration darf nicht xmlns enthalten.

Anmerkung:

Der {Name} eines Attributs ist ein NCName, der implizit Attribut-Deklarationen der Form xmlns:* verbietet.
Bedingung an Schemakomponente: xsi: nicht erlaubt
Der {Ziel-Namensraum} einer Attribut-Deklaration, ob lokal oder von der obersten Ebene, darf nicht mit http://www.w3.org/2001/XMLSchema-instance übereinstimmen (außer es handelt sich um eine der im nächsten Abschnitt beschriebenen vier vordefinierten Deklarationen).

Anmerkung:

Dies betont den speziellen Status dieser Attribute, so dass sie nicht nur nicht deklariert werden müssen, um in Instanzen zulässig zu sein, sondern nicht deklariert werden dürfen. Dies verhindert auch jegliche Versuchung, mit der Festlegung von globalen oder festen Werten für beispielsweise xsi:type oder xsi:nil zu experimentieren, was stark irreführend wäre, da sie keine Wirkung hätte.

3.2.7 Vordefinierte Attribut-Deklarationen

In jedem Schema sind per Definition vier Attribut-Deklarationen vorhanden:

Attribut-Deklaration für das 'type'-Attribut
Eigenschaft Wert
{Name} type
{Ziel-Namensraum} http://www.w3.org/2001/XMLSchema-instance
{Typdefinition} Die vordefinierte Definition des einfachen Typs QName
{Gültigkeitsbereich} global
{Wertebereich-Beschränkung} nicht verwendet
{Anmerkung} nicht verwendet
Attribut-Deklaration für das 'nil'-Attribut
Eigenschaft Wert
{Name} nil
{Ziel-Namensraum} http://www.w3.org/2001/XMLSchema-instance
{Typdefinition} Die vordefinierte Definition des einfachen Typs boolean
{Gültigkeitsbereich} global
{Wertebereich-Beschränkung} nicht verwendet
{Anmerkung} nicht verwendet
Attribut-Deklaration für das 'schemaLocation'-Attribut
Eigenschaft Wert
{Name} schemaLocation
{Ziel-Namensraum} http://www.w3.org/2001/XMLSchema-instance
{Typdefinition} Eine anonyme Definition eines einfachen Typs, wie folgt:
Eigenschaft Wert
{Name} nicht verwendet
{Ziel-Namensraum} http://www.w3.org/2001/XMLSchema-instance
{Basistyp-Definition} Die vordefinierte einfache Urtyp-Definition
{Fassetten} nicht verwendet
{Sorte} list
{Listenelement-Typ-Definition} Die vordefinierte Definition des einfachen Typs anyURI
{Anmerkung} nicht verwendet
{Gültigkeitsbereich} global
{Wertebereich-Beschränkung} nicht verwendet
{Anmerkung} nicht verwendet
Attribut-Deklaration für das 'noNamespaceSchemaLocation'-Attribut
Eigenschaft Wert
{Name} noNamespaceSchemaLocation
{Ziel-Namensraum} http://www.w3.org/2001/XMLSchema-instance
{Typdefinition} Die vordefinierte Definition des einfachen Typs anyURI
{Gültigkeitsbereich} global
{Wertebereich-Beschränkung} nicht verwendet
{Anmerkung} nicht verwendet

previous sub-section next sub-section3.3 Element-Deklarationen

Element-Deklarationen werden für Folgendes bereitgestellt:

Beispiel
<xs:element name="Bestellung" type="BestellungTyp"/>

<xs:element name="Geschenk">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="Geburtstag" type="xs:date"/>
   <xs:element ref="Bestellung"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
XML-Darstellung mehrerer Element-Deklarationen unterschiedlicher Form

3.3.1 Die Schemakomponente Element-Deklaration

Die Schemakomponente Element-Deklaration hat die folgenden Eigenschaften:

Schemakomponente: Element-Deklaration
{Name}
Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}
Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Typdefinition}
Entweder die Definition eines einfachen oder eines komplexen Typs.
{Gültigkeitsbereich}
Optional: entweder global oder die Definition eines komplexen Typs.
{Wertebereich-Beschränkung}
Optional: ein Paar bestehend aus einem Wert und aus default oder fixed.
{nullwertfähig}
Ein boolescher Wert.
{Identitätsbeschränkungs-Definitionen}
Eine Menge von einschränkenden Definitionen.
{Ersetzungsgruppen-Zugehörigkeit}
Optional: eine Element-Definition der obersten Ebene.
{Ersetzungsgruppen-Ausschlüsse}
Eine Untermenge von {extension, restriction}.
{Nicht erlaubte Ersetzungen}
Eine Untermenge von {substitution, extension, restriction}.
{abstrakt}
Ein boolescher Wert.
{Anmerkung}
Optional: eine Anmerkung.

Die Eigenschaft {Name} muss mit dem lokalen Teil der Namen von zu validierenden Element-Informationseinheiten übereinstimmen.

Ein {Gültigkeitsbereich}global identifiziert Element-Deklarationen, die zur Verwendung in Inhaltsmodellen innerhalb des Schemas verfügbar sind. Lokal gültige Deklarationen sind nur für die Verwendung innerhalb des komplexen Typs verfügbar, der durch die Eigenschaft {Gültigkeitsbereich} identifiziert wird. Diese Eigenschaft wird im Fall von Deklarationen innerhalb von benannten Elementgruppen nicht verwendet: Ihr {Gültigkeitsbereich} wird bestimmt, wenn sie in der Konstruktion komplexer Typdefinitionen verwendet werden.

Ein Wert der Eigenschaft {Ziel-Namensraum}, der nicht nicht verwendet ist, trägt zur Validierung von Namensraum-qualifizierten Element-Informationseinheiten bei. Nicht verwendete Werte von {Ziel-Namensraum}validieren unqualifizierte Informationseinheiten.

Eine Element-Informationseinheit ist gültig, wenn sie die {Typdefinition} erfüllt. Für eine solche Informationseinheit werden Beiträge zum Schema Information-Set, gemäß {Typdefinition}, der entsprechenden Element-Informationseinheit im Post-Schema-Validierungs-Information-Set hinzugefügt.

Wenn {nullwertfähig}wahr ist, kann ein Element auch gültig sein, wenn es das Namensraum-qualifizierte Attribut mit [lokalem Namen]nil aus dem Namensraum http://www.w3.org/2001/XMLSchema-instance mit dem Wert wahr (siehe xsi:nil (§2.6.2)) besitzt, auch wenn es keinen Text- oder Elementinhalt hat, trotz eines {Inhaltstyp}s, der andernfalls Inhalt voraussetzen würde. Formale Einzelheiten über die Element-Validierung sind in lokal gültiges Element (Element) (§3.3.4) beschrieben.

{Wertebereich-Beschränkung} definiert einen Vorgabe- oder festen Wert für ein Element. Wenn default spezifiziert wurde und das zu validierende Element leer ist, wird die kanonische Form des vorgegebenen Einschränkungswerts zum Schema-normalisierten Wert des validierten Elements im Post-Schema-Validierungs-Information-Set. Wenn fixed spezifiziert wurde, muss der Inhalt des Elements entweder leer sein, wobei sich fixed wie default verhält, oder sein Wert muss mit dem vorgegebenen Einschränkungswert übereinstimmen.

Anmerkung:

Die Bereitstellung von Vorgabe-Werten für Elemente geht über die Möglichkeiten von XML-1.0-DTDs hinaus und entspricht nicht genau den Vorgabe-Werten für Attribute. Insbesondere wird ein Element mit einer nicht leeren {Wertebereich-Beschränkung}, dessen einfache Typdefinition die leere Zeichenkette in ihrem lexikalischen Raum beinhaltet, dennoch nie diesen Wert erhalten, weil er durch die {Wertebereich-Beschränkung} überschrieben wird.

{Identitätsbeschränkungs-Definitionen} drücken Einschränkungen aus, die Eindeutigkeiten und Referenzbeziehungen zwischen den Werten in Beziehung stehender Elemente und Attribute festlegen; siehe Identitätsbeschränkungs-Definitionen (§3.11).

Element-Deklarationen sind Mitglieder der eventuell vorhandenen Ersetzungsgruppe, die durch {Ersetzungsgruppen-Zugehörigkeit} identifiziert wird. Die Mitgliedschaft ist transitiv, aber nicht symmetrisch; eine Element-Deklaration ist Mitglied einer beliebigen Gruppe, wenn die {Ersetzungsgruppen-Zugehörigkeit} der Deklaration Mitglied ist.

Eine leere Eigenschaft {Ersetzungsgruppen-Ausschlüsse} erlaubt es, eine Deklaration als {Ersetzungsgruppen-Zugehörigkeit} anderer Element-Deklarationen zu benennen, die die gleiche {Typdefinition} oder davon abgeleitete Typen haben. Die expliziten Werte von {Ersetzungsgruppen-Ausschlüsse} schließen Element-Deklarationen aus, die Typen haben, die Erweiterungen bzw. Beschränkungen der {Typdefinition} sind. Wenn beide Werte spezifiziert wurden, darf die Deklaration nicht als {Ersetzungsgruppen-Zugehörigkeit} einer anderen Deklaration benannt werden.

Die für {Nicht erlaubte Ersetzungen} gelieferten Werte bestimmen, ob eine Element-Deklaration, die in einem Inhaltsmodell erscheint, von zusätzlich validierenden Element-Deklarationen verhindert werden kann, die (a) einen xsi:type (§2.6.1) haben, der eine Erweiterung oder Beschränkung des Typs des deklarierten Elements bestimmt, und/oder (b) validierende Elemente haben, denen in der Ersetzungsgruppe das deklarierte Element als Ursprungs-Element voransteht. Wenn {Nicht erlaubte Ersetzungen} leer ist, dann sind alle abgeleiteten Typen und Ersetzungsgruppen-Mitglieder zulässig.

Element-Deklarationen, für die {abstrakt}wahr ist, können in Inhaltsmodellen nur erscheinen, wenn eine Ersetzung zulässig ist; solche Deklarationen dürfen nicht zur Validierung von Elementinhalt verwendet werden.

Siehe Anmerkungen (§3.13) für Informationen zur Rolle der Eigenschaft {Anmerkung}.

3.3.2 XML-Darstellung der Schemakomponente Element-Deklaration

Die XML-Darstellung für die Schemakomponente Element-Deklaration ist eine Element-Informationseinheit <element>. Sie spezifiziert eine Typdefinition für ein Element entweder durch Referenz oder explizit und darf Häufigkeits- und Vorgabe-Informationen bereitstellen. Die Beziehungen zwischen den Eigenschaften der Informationseinheiten und den Eigenschaften der entsprechenden Komponenten sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit element

<element
abstract = boolean : false
block = (#all | Liste aus )
default = string
final = (#all | Liste aus (extension | restriction))
fixed = string
form = (qualified | unqualified)
id = ID
maxOccurs = ( | unbounded) : 1
minOccurs = nonNegativeInteger : 1
name = NCName
nillable = boolean : false
ref = QName
substitutionGroup = QName
type = QName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))
</element>

Falls die Element-Informationseinheit <element> <schema> als Elternteil hat, hat die entsprechende Schemakomponente die folgenden Eigenschaften:
Schemakomponente Element-Deklaration
Eigenschaft Darstellung
{Name} Der tatsächliche Wert des [Attributs] name.
{Ziel-Namensraum} Der tatsächliche Wert des [Attributs] targetNamespace der Elternelement-Informationseinheit <schema> oder nicht verwendet, falls targetNamespace nicht angegeben ist.
{Gültigkeitsbereich} global.
{Typdefinition} Die Typdefinition, die der Element-Informationseinheit <simpleType> oder <complexType> in [Kindelemente] entspricht, falls eine der beiden vorhanden ist; andernfalls die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] type; andernfalls die {Typdefinition} der Element-Deklaration aufgelöst durch den tatsächlichen Wert des [Attributs] substitutionGroup, falls vorhanden; andernfalls die Urtyp-Definition.
{nullwertfähig} Der tatsächliche Wert des [Attributs] nillable, falls vorhanden; andernfalls false.
{Wertebereich-Beschränkung} Gibt es ein [Attribut] default oder fixed, dann ein Paar bestehend aus dem tatsächlichen Wert (hinsichtlich der {Typdefinition}, falls es eine einfache Typdefinition ist, oder dem {Inhaltstyp} der {Typdefinition}, falls dieser eine einfache Typdefinition ist; ansonsten bezüglich der vordefinierten einfachen Typdefinition string) des [Attributs] und entweder default bzw. fixed; andernfalls nicht verwendet.
{Identitätsbeschränkungs-Definitionen} Eine Menge bestehend aus den Identitätsbeschränkungs-Definitionen, die den Element-Informationseinheiten <key>, <unique> und <keyref> in [Kindelemente] entsprechen, falls vorhanden; andernfalls die leere Menge.
{Ersetzungsgruppen-Zugehörigkeit} Die Element-Deklaration aufgelöst durch den tatsächlichen Wert des [Attributs] substitutionGroup, falls vorhanden; andernfalls nicht verwendet.
{Nicht erlaubte Ersetzungen} Eine Menge abhängig von dem tatsächlichen Wert des [Attributs] block, falls vorhanden; andernfalls von dem tatsächlichen Wert des [Attributs] blockDefault der Vorfahrenelement-Informationseinheit <schema>, falls vorhanden; andernfalls die leere Zeichenkette. Dies wird mit EBW (für Effektiver Block-Wert) bezeichnet. Dann ist der Wert dieser Eigenschaft der zutreffende Fall unter den folgenden:
1 Falls der EBW die leere Zeichenkette ist, dann die leere Menge
2 Falls der EBW #all ist, dann { extension, restriction, substitution }
3 Sonst eine Menge mit Mengenelementen, die aus obiger Menge entnommen wurden; jedes Mengenelement ist entweder vorhanden oder wird nicht verwendet abhängig davon, ob der tatsächliche Wert (der eine Liste ist) eine gleich benannte Einheit enthält.

Anmerkung:

Obwohl das [Attribut] blockDefault von <schema> andere Werte als extension, restriction oder substitution enthalten kann, werden diese Werte bei der Ermittlung von {Nicht erlaubte Ersetzungen} für Element-Deklarationen ignoriert (sie werden an anderer Stelle verwendet).
{Ersetzungsgruppen-Ausschlüsse} Wie bei {Nicht erlaubte Ersetzungen}, allerdings unter Verwendung der [Attribute] final und finalDefault statt der [Attribute] block und blockDefault und mit der relevanten Menge { extension, restriction }.
{abstrakt} Der tatsächliche Wert des [Attributs] abstract, falls vorhanden; andernfalls false.
{Anmerkung} Die Anmerkung gemäß der Element-Informationseinheit <annotation> in [Kindelemente], falls vorhanden; andernfalls nicht verwendet.
ansonsten, falls die Element-Informationseinheit <element> <complexType> oder <group> als Vorfahren hat und das [Attribut] ref nicht verwendet wird, sind die entsprechenden Schemakomponenten wie folgt (außer minOccurs=maxOccurs=0, in diesem Fall entspricht die Informationseinheit überhaupt keiner Komponente):
Schemakomponente Partikel
Eigenschaft Darstellung
{minimales Vorkommen} Der tatsächliche Wert des [Attributs] minOccurs, falls vorhanden; andernfalls 1.
{maximales Vorkommen} unbounded, falls das [Attribut] maxOccurs den Wert unbounded enthält; andernfalls der tatsächliche Wert des [Attributs] maxOccurs, falls vorhanden; andernfalls 1.
{Term} Eine (lokale) Element-Deklaration wie unten angegeben.
Eine Element-Deklaration wie im obigen ersten Fall, mit Ausnahme ihrer Eigenschaften {Ziel-Namensraum} und {Gültigkeitsbereich}, die wie folgt sind:
Schemakomponente Element-Deklaration
Eigenschaft Darstellung
{Ziel-Namensraum} Falls form vorhanden und sein tatsächlicher Wert qualified ist oder falls form nicht verwendet wird und der tatsächliche Wert von elementFormDefault des Vorfahren <schema> qualified ist, dann der tatsächliche Wert des [Attributs] targetNamespace der Elternelement-Informationseinheit <schema> oder nicht verwendet, falls es keinen gibt; andernfalls nicht verwendet.
{Gültigkeitsbereich} Falls die Element-Informationseinheit <element> als Vorfahren <complexType> hat, die zu dieser Informationseinheit entsprechende komplexe Definition; andernfalls (die Element-Informationseinheit <element> ist innerhalb einer benannten <group>-Definition) nicht verwendet.
andernfalls (die Element-Informationseinheit <element> hat <complexType> oder <group> als Vorfahren und das [Attribut] ref ist vorhanden), ist die entsprechende Schemakomponente wie folgt (außer minOccurs=maxOccurs=0, in diesem Fall entspricht die Informationseinheit überhaupt keiner Komponente):
Schemakomponente Partikel
Eigenschaft Darstellung
{minimales Vorkommen} Der tatsächliche Wert des [Attributs] minOccurs, falls vorhanden; andernfalls 1.
{maximales Vorkommen} unbounded, falls das [Attribut] maxOccurs den Wert unbounded enthält; andernfalls der tatsächliche Wert des [Attributs] maxOccurs, falls vorhanden; andernfalls 1.
{Term} Die Element-Deklaration (der obersten Ebene) aufgelöst durch den tatsächlichen Wert des [Attributs] ref.

<element> entspricht einer Element-Deklaration und ermöglicht, dass die Typdefinition dieser Deklaration entweder durch Referenz oder explizite Inklusion spezifiziert wird.

<element>-Einheiten innerhalb von <schema> erzeugen globale Element-Deklarationen; <element>e innerhalb von <group> oder <complexType> erzeugen entweder Partikel, die globale Element-Deklarationen enthalten (falls es ein Attribut ref gibt) oder (ansonsten) lokale Deklarationen. Für vollständige Deklarationen, Deklarationen der obersten Ebene oder lokale Deklarationen wird das Attribut type verwendet, falls die Deklaration eine vordefinierte oder vordeklarierte Typdefinition verwenden kann. Andernfalls wird ein anonymer <simpleType> oder <complexType> innerhalb der Deklaration zur Verfügung gestellt.

Die von einer Deklaration der obersten Ebene validierten Element-Informationseinheiten müssen mit dem {Ziel-Namensraum} dieser Deklaration qualifiziert werden (falls dieser nicht verwendet wird, muss die Informationseinheit unqualifiziert sein). Die Kontrolle darüber, ob Element-Informationseinheiten durch eine lokale Deklaration validiert werden, muss ähnlich qualifiziert oder nicht qualifiziert sein und wird vom [Attribut]form bereitgestellt, dessen Vorgabe-Wert von einem [Attribut]elementFormDefault im einschließenden <schema> über die Ermittlung von {Ziel-Namensraum} bereitgestellt wird.

Wie oben erwähnt, befinden sich die Namen für Element-Deklarationen der obersten Ebene in einem von den Symbolbereichen für die Namen von Typdefinitionen getrennten Symbolbereich, so dass es eine einfache oder komplexe Typdefinition und ein Element mit gleichen Namen auf oberster Ebene geben kann (aber nicht muss). Wie bei Attributnamen befinden sich die Namen lokaler Element-Deklarationen ohne {Ziel-Namensraum} in lokalen Symbolbereichen der enthaltenden Typdefinition.

Dies ermöglicht zwei Ebenen für die Bereitstellung von Vorgabe-Werten für nicht spezifizierte Typdefinitionen. Ein <element> ohne referenzierte oder eingeschlossene Typdefinition wird einer Element-Deklaration entsprechen, die die gleiche Typdefinition wie die des Ursprungs-Elements seiner Ersetzungsgruppe hat, soweit vorhanden; andernfalls die Urtyp-Definition. Dies führt zu der wichtigen Konsequenz, dass die minimal gültige Element-Deklaration, d.h. eine mit nur einem Attribut name und keinen Inhalten, ebenfalls die generellste ist, die jede Kombination aus Text- und Elementinhalt validiert und beliebige Attribute zulässt.

Siehe XML-Darstellung der Schemakomponente Identitätsbeschränkungs-Definition (§3.11.2) für Informationen über <key>, <unique> und <keyref>.

Beispiel
<xs:element name="Unbeschränkt"/>

<xs:element name="LeeresElement">
 <xs:complexType>
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="Kontext1">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="MeinLokalesElement" type="MeinErsterTyp"/>
   <xs:element ref="GlobalesElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="Kontext2">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="MeinLokalesElement" type="MeinZweiterTyp"/>
   <xs:element ref="GlobalesElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
Das erste Beispiel deklariert ein Element, dessen vorgegebener Typ die Urtyp-Definition ist. Die zweite Deklaration verwendet eine eingeschlossene anonyme komplexe Typdefinition.

Die letzten zwei Beispiele zeigen die Verwendung von lokalen Element-Deklarationen. Instanzen von MeinLokalesElement innerhalb von Kontext1 werden durch MeinErsterTyp beschränkt, während Instanzen des Elements mit gleichen Namen innerhalb von Kontext2 durch MeinZweiterTyp beschränkt werden.

Anmerkung:

Die Möglichkeit, dass abweichende Attribut-Deklarationen und/oder Inhaltsmodelle auf Elemente mit dem gleichen Namen in unterschiedlichen Kontexten angewendet werden können, ist eine Erweiterung, die über die Ausdruckskraft von DTDs in XML 1.0 hinausgeht.
Beispiel
 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>
Ein Beispiel aus einer früheren Version des Schemas für Datentypen. Es wird ein facet-Typ definiert sowie ein facet-Element, das den Typ verwendet. Das facet-Element ist abstrakt definiert - sein Zweck ist es, als Ursprungs-Element einer Ersetzungsgruppe zu fungieren. Die nächsten zwei deklarierten Elemente sind jeweils Mitglieder der facet-Ersetzungsgruppe. Schließlich wird ein Typ definiert, der facet referenziert und damit entweder period oder encoding (oder irgendein anderes Mitglied der Gruppe) erlaubt.

3.3.3 Bedingungen an die XML-Darstellung von Element-Deklarationen

Bedingung an Schema-Darstellung: korrekte Darstellung von Element-Deklarationen
Zusätzlich zu den Bedingungen, die <element>-Element-Informationseinheiten durch das Schema für Schemata auferlegt werden, müssen alle folgenden Aussagen wahr sein:
1 default und fixed dürfen nicht zusammen vorkommen.
2 Falls das Elternelement der Informationseinheit nicht <schema> ist, müssen alle folgenden Aussagen wahr sein:
2.1 Entweder ref oder name muss vorhanden sein.
2.2 Falls ref vorhanden ist, dann dürfen <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block und type nicht verwendet werden, d.h. nur minOccurs, maxOccurs und id sind zusätzlich zu ref gestattet, zusammen mit <annotation>.
3 type und entweder <simpleType> oder <complexType> schließen sich gegenseitig aus.
4 Das entsprechende Partikel und/oder die Element-Deklarationen müssen die Bedingungen erfüllen, die in Bedingungen an die Schemakomponente Element-Deklaration (§3.3.6) und Bedingungen an die Schemakomponente Partikel (§3.9.6) festgelegt sind.

3.3.4 Validierungsregeln für Element-Deklarationen

Validierungsregel: lokal gültiges Element (Element)
Damit eine Element-Informationseinheit hinsichtlich einer Element-Deklaration lokal gültig ist, müssen alle folgenden Aussagen wahr sein:
1 Die Deklaration darf nicht nicht verwendet sein.
2 Ihre Eigenschaft {abstrakt} muss false sein.
3 Der zutreffende Fall unter den folgenden muss wahr sein:
3.1 Falls {nullwertfähig} false ist, dann darf es keine Attribut-Informationseinheit unter den [Attributen] der Element-Informationseinheiten geben, deren [Namensraum-Name] identisch zu http://www.w3.org/2001/XMLSchema-instance ist und deren [lokaler Name] nil ist.
3.2 Falls {nullwertfähig} true ist und es gibt solch eine Attribut-Informationseinheit und ihr tatsächlicher Wert ist true , dann müssen alle folgenden Aussagen wahr sein:
3.2.1 Die Element-Informationseinheit darf keine Zeichenketten- oder Element-Informationseinheiten-[Kindelemente] haben.
3.2.2 Es darf keine {Wertebereich-Beschränkung} fixed geben.
4 Falls es eine Attribut-Informationseinheit unter den [Attributen] der Element-Informationseinheit gibt, deren [Namensraum-Name] identisch zu http://www.w3.org/2001/XMLSchema-instance ist und deren [lokaler Name] type ist, dann müssen alle folgenden Aussagen wahr sein:
4.1 Der normalisierte Wert dieser Attribut-Informationseinheit muss gültig hinsichtlich des vordefinierten einfachen Typs QName sein, gemäß gültiger String (§3.14.4)
4.2 Der lokale Name und Namensraum-Name (gemäß QName-Interpretation (§3.15.3)) des tatsächlichen Wertes der Attribut-Informationseinheit muss zu einer Typdefinition aufgelöst werden, gemäß QName-Auflösung (Instanz) (§3.15.4) - [Definition:] diese Typdefinition wird lokale Typdefinition genannt
4.3 Die lokale Typdefinition muss gültig von der {Typdefinition} abgeleitet sein bei gegebener Vereinigung von {Nicht erlaubte Ersetzungen} und {Verbotene Ersetzungen} von {Typdefinition}, gemäß korrekte Typ-Ableitung (komplexer Typ) (§3.4.6) (falls es eine komplexe Typdefinition ist), oder bei gegebenen {Nicht erlaubte Ersetzungen} gemäß korrekte Typableitung (einfacher Typ) (§3.14.6) (falls es eine einfache Typdefinition ist).
[Definition:] Der Ausdruck tatsächliche Typdefinition wird unten aufgeführt. Falls die obigen drei Klauseln erfüllt sind, sollte dies als Referenzieren auf die lokale Typdefinition verstanden werden, andernfalls auf die {Typdefinition} .
5 Der zutreffende Fall unter den folgenden muss wahr sein:
5.1 Falls die Deklaration eine {Wertebereich-Beschränkung} hat, die Informationseinheit weder Element- noch Zeichen- [Kindelemente] hat und Klausel 3.2 nicht angewendet wurde, dann müssen alle folgenden Aussagen wahr sein:
5.1.2 Die Element-Informationseinheit mit der kanonisch lexikalischen Repräsentation des {Wertebereich-Beschränkung}-Wertes, der als ihr normalisierter Wert verwendet wird, muss gültig bezüglich der tatsächlichen Typdefinition, wie in lokal gültiges Element (Typ) (§3.3.4) definiert, sein.
5.2 Falls die Deklaration keine {Wertebereich-Beschränkung} hat oder die Informationseinheit entweder Element- oder Zeichen-[Kindelemente] hat oder Klausel 3.2 angewendet wurde, dann müssen alle folgenden Aussagen wahr sein:
5.2.1 Die Element-Informationseinheit muss gültig in Bezug auf die tatsächliche Typdefinition sein, wie durch lokal gültiges Element (Typ) (§3.3.4) definiert.
5.2.2 Falls es eine {Wertebereich-Beschränkung} fixed gibt und Klausel 3.2 nicht angewendet wurde, müssen alle folgenden Aussagen wahr sein:
5.2.2.1 Die Element-Informationseinheit darf keine [Kindelemente] haben, die Element-Informationseinheiten sind.
5.2.2.2 Der zutreffende Fall unter den folgenden muss wahr sein:
5.2.2.2.1 Falls der {Inhaltstyp} der tatsächlichen Typdefinition mixed ist, dann muss der initiale Wert der Informationseinheit mit der kanonisch lexikalischen Repräsentation des {Wertebereich-Beschränkung}-Wertes übereinstimmen.
5.2.2.2.2 Falls der {Inhaltstyp} der tatsächlichen Typdefinition eine einfache Typdefinition ist, dann muss der tatsächliche Wert der Informationseinheit mit der kanonisch lexikalischen Repräsentation des {Wertebereich-Beschränkung}-Wertes übereinstimmen.
6 Die Element-Informationseinheit muss gültig bezüglich aller {Identitätsbeschränkungs-Definitionen}, gemäß erfüllte Identitätsbeschränkung (§3.11.4), sein.
7 Falls die Element-Informationseinheit die Validierungswurzel ist, muss sie gültig, gemäß gültige Validierungswurzel (ID/IDREF) (§3.3.4), sein.
Validierungsregel: lokal gültiges Element (Typ)
Damit eine Element-Informationseinheit lokal gültig bezüglich einer Typdefinition ist, müssen alle folgenden Aussagen wahr sein:
1 Die Typdefinition darf nicht nicht verwendet sein
2 Ihre Eigenschaft {abstrakt} muss false sein.
3 Der zutreffende Fall unter den folgenden muss wahr sein:
3.1 Falls die Typdefinition eine einfache Typdefinition ist, dann müssen alle folgenden Aussagen wahr sein:
3.1.1 Die [Attribute] der Element-Informationseinheit müssen leer sein, außer die, deren [Namensraum-Name] identisch zu http://www.w3.org/2001/XMLSchema-instance ist und deren [lokaler Name] entweder type, nil, schemaLocation oder noNamespaceSchemaLocation ist.
3.1.2 Die Element-Informationseinheit darf keine [Kindelemente] haben, die Element-Informationseinheiten sind.
3.1.3 Falls Klausel 3.2 aus lokal gültiges Element (Element) (§3.3.4) nicht angewendet wurde, muss der normalisierte Wert gültig in Bezug auf die Typdefinition, wie durch gültiger String (§3.14.4) definiert, sein.
3.2 Falls die Typdefinition eine komplexe Typdefinition ist, dann muss die Element-Informationseinheit gültig in Bezug auf die Typdefinition, gemäß lokal gültiges Element (komplexer Typ) (§3.4.4), sein.
Validierungsregel: gültige Validierungswurzel (ID/IDREF)
Damit eine Element-Informationseinheit, die die Validierungswurzel ist, gültig ist, müssen alle folgenden Aussagen wahr sein:
1 Es darf keine ID/IDREF-Bindung in der [ID/IDREF-Tabelle] der Informationseinheit geben, deren [Bindung] die leere Menge ist.
2 Es darf keine ID/IDREF-Bindung in der [ID/IDREF-Tabelle] der Informationseinheit geben, deren [Bindung] mehr als ein Mengenelement hat.

Siehe ID/IDREF-Tabelle (§3.15.5) für die Definition von ID/IDREF-Bindung.

Anmerkung:

Die obige erste Klausel wird angewendet, wenn es eine Referenz auf eine undefinierte ID gibt. Die zweite wird angewendet, wenn es mehrfach definierte IDs gibt. Sie sind einzeln aufgeführt, um sicherzustellen, dass unterschiedliche Fehlercodes (siehe Ergebnis-Tabellen (normativ) (§C)) mit diesen beiden Fällen verknüpft werden.

Anmerkung:

Obwohl diese Regel an der Validierungswurzel angewendet wird, können Prozessoren, speziell Datenstrom-Prozessoren, den Klausel 2-Fall dort erkennen und signalisieren, wo er auftritt.

Anmerkung:

Diese Rekonstruktion der ID/IDREF-Funktionalität aus [XML 1.0 (Second Edition)] ist insofern unvollkommen, als, wenn die Validierungswurzel nicht das Dokument-Element eines XML-Dokuments ist, die Ergebnisse nicht notwendigerweise die gleichen sein werden, die ein validierender Parser bei einem Dokument liefern würde, das eine DTD mit äquivalenten Deklarationen hat.
Validierungsregel: Die Schemagültigkeitsprüfung (Element)
Die Schemagültigkeitsprüfung einer Element-Informationseinheit hängt von ihrer Validierung und, falls vorhanden, von der Bewertung ihrer Kindelement-Informationseinheiten und verbundener Attribut-Informationseinheiten ab.

Damit also die Schemagültigkeit einer Element-Informationseinheit validiert werden kann, müssen alle folgenden Aussagen wahr sein:
1 Eine der folgenden Aussagen muss wahr sein:
1.1 Alle folgenden Aussagen müssen wahr sein:
1.1.1 Eine nicht-nicht verwendet Element-Deklaration muss dem Prozessor bekannt sein, weil eine der folgenden Aussagen wahr ist:
1.1.1.1 Eine Deklaration durch den Prozessor festgelegt wurde (siehe Validierung der Schemagültigkeit (§5.2)).
1.1.1.2 Eine Deklaration als die kontextbestimmte Deklaration der Element-Informationseinheit festgelegt wurde.
1.1.1.3 Alle folgenden Aussagen müssen wahr sein:
1.1.1.3.1 Ihre kontextbestimmte Deklaration ist nicht skip.
1.1.1.3.2 Ihr [lokaler Name] und [Namensraum-Name] lösen sich zu einer Element-Deklaration auf, wie in QName-Auflösung (Instanz) (§3.15.4) definiert.
1.1.2 Die Gültigkeit der Element-Informationseinheit in Bezug auf diese Deklaration muss gemäß lokal gültiges Element (Element) (§3.3.4) evaluiert worden sein.
1.1.3 Falls diese Evaluierung die Evaluierung von lokal gültiges Element (Typ) (§3.3.4) einschloss, muss Klausel 1 daraus erfüllt sein.
1.2 Alle folgenden Aussagen müssen wahr sein:
1.2.1 Eine nicht-nicht verwendet Typdefinition muss bekannt sein, weil eine der folgenden Aussagen wahr ist:
1.2.1.1 Eine Typdefinition wurde durch den Prozessor festgelegt (siehe Validierung der Schemagültigkeit (§5.2)).
1.2.1.2 Alle folgenden Aussagen müssen wahr sein:
1.2.1.2.1 Es gibt eine Attribut-Informationseinheit unter den [Attributen] der Element-Informationseinheit, deren [Namensraum-Name] identisch zu http://www.w3.org/2001/XMLSchema-instance und deren [lokaler Name] type ist.
1.2.1.2.2 Der normalisierte Wert dieser Attribut-Informationseinheit ist gültig in Bezug auf den vordefinierten einfachen Typ QName, wie durch gültiger String (§3.14.4) definiert.
1.2.1.2.3 Der lokale Name und der Namensraum-Name (gemäß QName-Interpretation (§3.15.3)) des tatsächlichen Wertes der Attribut-Informationseinheit lösen sich zu einer Typdefinition auf, gemäß QName-Auflösung (Instanz) (§3.15.4) - [Definition:] diese Typdefinition wird lokale Typdefinition genannt.
1.2.1.2.4 Falls es auch eine vom Prozessor festgelegte Typdefinition gibt, muss die lokale Typdefinition gültig von dieser Typdefinition abgeleitet sein bei gegebenen {Verbotene Ersetzungen}, gemäß korrekte Typ-Ableitung (komplexer Typ) (§3.4.6) (falls es eine komplexe Typdefinition ist), oder bei gegebener leerer Menge, gemäß korrekte Typableitung (einfacher Typ) (§3.14.6) (falls es eine einfache Typdefinition ist).
1.2.2 Die Gültigkeit einer Element-Informationseinheit in Bezug auf die lokale Typdefinition (falls vorhanden und gültig abgeleitet) oder die vom Prozessor festgelegte Typdefinition (falls keine lokale Typdefinition vorhanden ist) wurde gemäß lokal gültiges Element (Typ) (§3.3.4) evaluiert.
2 Die Schemagültigkeit aller Element-Informationseinheiten unter ihren [Kindelementen] wurde gemäß Die Schemagültigkeitsprüfung (Element) (§3.3.4) geprüft und die Schemagültigkeit aller Attribut-Informationseinheiten unter ihren [Attributen] wurde gemäß Die Schemagültigkeitsprüfung (Attribut) (§3.2.4) geprüft.

[Definition:] Falls jeder Fall von obiger Klausel 1 zutrifft, wurde die Element-Informationseinheit streng geprüft .

Falls die Einheit nicht streng geprüft werden kann, weil weder Klausel 1.1 noch Klausel 1.2 erfüllt sind, [Definition:] Die Schemagültigkeit einer Element-Informationseinheit kann lax geprüft werden, falls ihre kontextbestimmte Deklaration nicht skip ist, durch Validieren bezüglich der Urtyp-Definition gemäß lokal gültiges Element (Typ) (§3.3.4) .

Anmerkung:

Im Allgemeinen, wenn obige Klausel 1.1 zutrifft, trifft Klausel 1.2 nicht zu und umgekehrt. Wenn ein [Attribut] xsi:type involviert ist, hat jedoch Klausel 1.2 Vorrang, wie es in lokal gültiges Element (Element) (§3.3.4) erklärt wird.

Anmerkung:

Die Eigenschaften {Name} und {Ziel-Namensraum} werden oben nicht erwähnt, weil sie während der Partikel-Validierung überprüft werden, gemäß lokal gültige Element-Folge (Partikel) (§3.9.4).

3.3.5 Beiträge von Element-Deklarationen zum XML-Information-Set

Beitrag zum Schema Information Set: Ergebnis des Validierungsprozesses (Element)
Falls die Schemagültigkeit einer Element-Informationseinheit gemäß Die Schemagültigkeitsprüfung (Element) (§3.3.4) geprüft worden ist, hat der Post-Schema-Validierungs-Information-Set die folgenden Eigenschaften:
PSVI-Beiträge für die Informationseinheit Element
[Validierungs-Kontext]
Die Element-Informationseinheit des nächsten Vorfahren mit einer Eigenschaft [Schema-Informationen] (oder diese Element-Einheit, falls sie eine solche Eigenschaft hat).
[Gültigkeit]
Der zutreffende Fall unter den folgenden:
1 Falls streng validiert wurde, dann der zutreffende Fall unter den folgenden:
1.1 Falls alle folgenden Aussagen wahr sind:
1.1.1
1.1.1.1 Klausel 1.1 aus Die Schemagültigkeitsprüfung (Element) (§3.3.4) angewendet wurde und die Informationseinheit gültig gemäß Definition in lokal gültiges Element (Element) (§3.3.4) ist.
1.1.1.2 Klausel 1.2 aus Die Schemagültigkeitsprüfung (Element) (§3.3.4) angewendet wurde und die Informationseinheit gültig gemäß Definition in lokal gültiges Element (Typ) (§3.3.4) ist.
1.1.2 Weder seine [Kindelemente] noch seine [Attribute] enthalten eine Informationseinheit (Element bzw. Attribut), deren [Gültigkeit] ungültig ist.
1.1.3 Weder seine [Kindelemente] noch seine [Attribute] enthalten eine Informationseinheit (Element bzw. Attribut) mit einer kontextbestimmten Deklaration von mustFind, deren [Gültigkeit] unbekannt ist.
, dann dann gültig;
1.2 Sonst ungültig.
2 Sonst unbekannt.
[versuchte Validierung]
Der zutreffende Fall unter den folgenden:
1 Falls streng geprüft wurde und weder seine [Kindelemente] noch seine [Attribute] eine Informationseinheit (Element bzw. Attribut) enthalten, deren [versuchte Validierung] nicht vollständig ist, dann dann vollständig.
2 Falls nicht streng geprüft wurde und weder seine [Kindelemente] noch seine [Attribute] eine Informationseinheit (Element bzw. Attribut) enthalten, deren [versuchte Validierung] nicht nicht ist, dann dann nicht.
3 Sonst teilweise.
Beitrag zum Schema Information Set: Validierungsfehler (Element)
Wenn die lokale Gültigkeit, gemäß lokal gültiges Element (Element) (§3.3.4) und/oder lokal gültiges Element (Typ) (§3.3.4), einer Element-Informationseinheit geprüft wurde, hat die Informationseinheit im Post-Schema-Validierungs-Information-Set eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Element
[Schema-Fehlercode]
Der zutreffende Fall unter den folgenden:
1 Falls die Informationseinheit nicht gültig ist, dann eine Liste. Anwendungen, die Informationen über den bzw. die Gründe für den Validierungs-Fehlschlag bereitstellen wollen, können einen oder mehrere Fehlercodes (siehe Ergebnis-Tabellen (normativ) (§C)) hiermit registrieren.
2 Sonst nicht verwendet.
Beitrag zum Schema Information Set: Element-Deklaration
Falls eine Element-Informationseinheit gültig bezüglich einer Element-Deklaration gemäß lokal gültiges Element (Element) (§3.3.4) ist, dann muss die Element-Informationseinheit im Post-Schema-Validierungs-Information-Set, je nach Prozessoroption, eine der beiden folgenden Eigenschaften haben:
PSVI-Beiträge für die Informationseinheit Element
[Element-Deklaration]
Eine zu ihrer Deklarations-Komponente isomorphe Informationseinheit.
oder
PSVI-Beiträge für die Informationseinheit Element
[nil]
wahr, falls Klausel 3.2 aus Abschnitt lokal gültiges Element (Element) (§3.3.4) erfüllt ist; andernfalls falsch.
Beitrag zum Schema Information Set: Element validiert durch den Typ
Falls eine Element-Informationseinheit gültig bezüglich einer Typdefinition ist, gemäß lokal gültiges Element (Typ) (§3.3.4), hat die Informationseinheit im Post-Schema-Validierungs-Information-Set eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Element
[Schema-normalisierter Wert]
Der zutreffende Fall unter den folgenden:
1 Falls Klausel 3.2 aus lokal gültiges Element (Element) (§3.3.4) und Vorgegebener Elementwert (§3.3.5) nicht angewandt wurde und entweder die Typdefinition oder ihr {Inhaltstyp} eine einfache Typdefinition ist, dann der normalisierte Wert der Informationseinheit, wie validiert.
2 Sonst nicht verwendet.
Desweiteren hat die Informationseinheit eine der folgenden alternativen Eigenschaftsmengen:

Entweder
PSVI-Beiträge für die Informationseinheit Element
[Typdefinition]
Ein zu der Typdefinitions-Komponente isomorphe Informationseinheit.
[Mengenelement-Typ-Definition]
Genau dann, wenn diese Typdefinition eine einfache Typdefinition mit {Sorte} union ist oder eine komplexe Typdefinition, deren {Inhaltstyp} eine einfache Typdefinition mit {Sorte} union ist, dann eine zu diesem Mitglied der {Mengenelement-Typ-Definition} der Vereinigung isomorphe Informationseinheit, die eigentlich den normalisierten Wert der Element-Informationseinheit validiert.
oder
PSVI-Beiträge für die Informationseinheit Element
[Typ der Typdefinition]
einfach oder komplex, abhängig von der Typdefinition.
[Namensraum der Typdefinition]
Der {Ziel-Namensraum} der Typdefinition.
[anonyme Typdefinition]
wahr, falls der {Name} der Typdefinition nicht verwendet wird; andernfalls falsch.
[Name der Typdefinition]
Der {Name} der Typdefinition, falls er nicht nicht verwendet wird. Falls er nicht verwendet wird, können Schema-Prozessoren einen in der Definition eindeutigen Wert bereitstellen, müssen es aber nicht.
Falls die Typdefinition oder ihr {Inhaltstyp} eine einfache Typdefinition ist und diese Typdefinition {Sorte} union hat, dann [Definition:] wird das Mengenelement der {Mengenelement-Typ-Definition}, das tatsächlich den normalisierten Wert der Element-Informationseinheit validiert, tatsächliche Mengenelement-Typdefinition genannt und es gibt drei zusätzliche Eigenschaften:
PSVI-Beiträge für die Informationseinheit Element
[Namensraum der Mengenelement-Typ-Definition]
Der {Ziel-Namensraum} der tatsächlichen Mengenelement-Typdefinition.
[anonyme Mengenelement-Typ-Definition]
wahr falls der {Name} der tatsächlichen Mengenelement-Typdefinition nicht verwendet wird; andernfalls falsch.
[Name der Mengenelement-Typ-Definition]
Der {Name} der tatsächlichen Mengenelement-Typdefinition, falls er nicht nicht verwendet wird. Falls er nicht verwendet wird, können Schema-Prozessoren einen in der Definition eindeutigen Wert bereitstellen, müssen es aber nicht.
Die erste obige (isomorphe Informationseinheit-) Alternative wird für Applikationen wie Anfrageprozessoren bereitgestellt, die Zugriff auf alle Details über den Validierungsprozess einer Informationseinheit benötigen, z.B. die Typhierarchie. Die zweite Alternative ist für einfachere Prozessoren bestimmt, für die die Notwendigkeit der Darstellung der signifikanten Teile der Typhierarchie als Informationseinheiten zu aufwendig sein kann.

Falls die Deklaration eine Eigenschaft {Wertebereich-Beschränkung} hat, hat die Informationseinheit außerdem eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Element
Beachten Sie, dass wenn ein Element lax geprüft wird, die Eigenschaften von [Typdefinition] und [Mengenelement-Typ-Definition], oder die ihrer Alternativen, auf der Urtyp-Definition basieren.
Beitrag zum Schema Information Set: Vorgegebener Elementwert
Falls die lokale Gültigkeit, gemäß lokal gültiges Element (Element) (§3.3.4), einer Element-Informationseinheit geprüft wurde, hat die Informationseinheit im Post-Schema-Validierungs-Information-Set eine Eigenschaft:
PSVI-Beiträge für die Informationseinheit Element
[durch Schema spezifiziert]
Der zutreffende Fall unter den folgenden:
1 Falls die Einheit gültig bezüglich einer Element-Deklaration gemäß lokal gültiges Element (Element) (§3.3.4) ist und die {Wertebereich-Beschränkung} vorhanden ist, aber Klausel 3.2 aus lokal gültiges Element (Element) (§3.3.4) nicht erfüllt ist und die Einheit keine [Kindelemente] hat, die Element- oder Zeichen-Informationseinheiten sind, dann dann Schema. Außerdem ergibt sich der Wert der Eigenschaft [Schema-normalisierter Wert] der Informationseinheit im Post-Schema-Validierungs-Information-Set aus der kanonisch lexikalischen Repräsentation des {Wertebereich-Beschränkung}-Wertes.
2 Sonst Information-Set.

3.3.6 Bedingungen an die Schemakomponente Element-Deklaration

Alle Element-Deklarationen (siehe Element-Deklarationen (§3.3)) müssen die folgenden Bedingungen erfüllen.

Bedingung an Schemakomponente: Eigenschaften der Element-Deklaration
Alle folgenden Aussagen müssen wahr sein:
1 Die Eigenschaftswerte einer Element-Deklaration müssen so sein, wie in der Eigenschaftstabelle in Die Schemakomponente Element-Deklaration (§3.3.1) beschrieben, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).
3 Falls es eine {Ersetzungsgruppen-Zugehörigkeit} gibt, muss die {Typdefinition} der Element-Deklaration gültig von der {Typdefinition} der {Ersetzungsgruppen-Zugehörigkeit} abgeleitet sein, bei gegebenem Wert der {Ersetzungsgruppen-Ausschlüsse} von {Ersetzungsgruppen-Zugehörigkeit}, gemäß korrekte Typ-Ableitung (komplexer Typ) (§3.4.6) (falls die {Typdefinition} komplex ist) oder gemäß korrekte Typableitung (einfacher Typ) (§3.14.6) (falls die {Typdefinition} einfach ist).
4 Falls die {Typdefinition} oder der {Inhaltstyp} der {Typdefinition} ID ist oder von ID abgeleitet ist, darf es keine {Wertebereich-Beschränkung} geben.

Anmerkung:

Die Verwendung von ID als Typdefinition für Elemente geht über XML 1.0 hinaus und sollte, falls Rückwärts-Kompatibilität gewünscht ist, vermieden werden.

Die folgenden Bedingungen definieren Beziehungen, die sich auf andere Stellen in dieser Spezifikation berufen.

Bedingung an Schemakomponente: gültiges Vorgabe-Element (Unmittelbar)
Damit eine Zeichenkette eine gültige Vorgabe bezüglich einer Typdefinition ist, muss der zutreffende Fall unter den folgenden wahr sein:
1 Falls die Typdefinition eine einfache Typdefinition ist, dann muss die Zeichenkette gültig bezüglich dieser Definition sein, wie durch gültiger String (§3.14.4) definiert.
2 Falls die Typdefinition eine komplexe Typdefinition ist, dann müssen alle folgenden Aussagen wahr sein:
2.1 ihr {Inhaltstyp} muss eine einfache Typdefinition oder mixed sein.
2.2 Der zutreffende Fall unter den folgenden muss wahr sein:
2.2.1 Falls der {Inhaltstyp} eine einfache Typdefinition ist, dann muss die Zeichenkette gültig in Bezug auf diese einfache Typdefinition sein, wie durch gültiger String (§3.14.4) definiert.
2.2.2 Falls der {Inhaltstyp} mixed ist, dann muss das Partikel des {Inhaltstyp} inhaltsfrei-fähig sein, wie durch Partikel leerbar (§3.9.6) definiert.
Bedingung an Schemakomponente: korrekte Ersetzungsgruppe (Transitiv)
Damit eine Element-Deklaration (hier D genannt) zusammen mit einer blockierenden Bedingung (eine Untermenge aus {substitution, extension, restriction}, d.h. ein Wert aus {Nicht erlaubte Ersetzungen}), durch eine andere Element-Deklaration gültig ersetzbar ist (hier C genannt), müssen alle folgenden Aussagen wahr sein:
1 Die blockierende Bedingung beinhaltet nicht substitution.
2 Es gibt eine Kette aus {Ersetzungsgruppen-Zugehörigkeit}en von D nach C, d.h. entweder die {Ersetzungsgruppen-Zugehörigkeit} von D ist C, oder die {Ersetzungsgruppen-Zugehörigkeit} der {Ersetzungsgruppen-Zugehörigkeit} von D ist C, oder . . .
3 Die Menge aller in der Ableitung der {Typdefinition} von D aus der {Typdefinition} von C involvierten {Ableitungsmethode}n schneidet nicht die Vereinigung der blockierenden Bedingung, der {Verbotene Ersetzungen} von C (falls C komplex ist, andernfalls die leere Menge) und der {Verbotene Ersetzungen} (bzw. die leere Menge) von beliebigen Zwischen-{Typdefinition}en im Ableitungsprozess der {Typdefinition} von D aus der {Typdefinition} von C.
Bedingung an Schemakomponente: Ersetzungsgruppe
[Definition:] Jede Element-Deklaration in den {Element-Deklarationen} eines Schemas definiert eine Ersetzungsgruppe, die eine Untermenge dieser {Element-Deklarationen} ist, wie folgt:
1 Die Element-Deklaration selbst ist in der Gruppe
2 Die Gruppe ist abgeschlossen in Bezug auf die {Ersetzungsgruppen-Zugehörigkeit}, d.h. falls eine beliebige Element-Deklaration in {Element-Deklarationen} eine {Ersetzungsgruppen-Zugehörigkeit} in der Gruppe hat, dann ist sie auch in der Gruppe.

previous sub-section next sub-section3.4 Definition komplexer Typen

Komplexe Typdefinitionen bieten Folgendes:

Beispiel
<xs:complexType name="BestellungTyp">
  <xs:sequence>
   <xs:element name="Lieferadresse" type="DeAdresse"/>
   <xs:element name="Rechnungsadresse" type="DeAdresse"/>
   <xs:element ref="Kommentar" minOccurs="0"/>
   <xs:element name="Waren"  type="WarenTyp"/>
  </xs:sequence>
  <xs:attribute name="bestelldatum" type="xs:date"/>
 </xs:complexType>
Die XML-Darstellung einer komplexen Typdefinition.

3.4.1 Die Schemakomponente Definition eines komplexen Typs

{Name}
Optional: ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}
Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Basistyp-Definition}
Entweder eine einfache oder eine komplexe Typdefinition.
{Ableitungsmethode}
Entweder extension oder restriction.
{abgeschlossen}
Eine Untermenge von {extension, restriction}.
{abstrakt}
Ein boolescher Wert.
{Attribut-Verwendungen}
Eine Menge von "use"-Attributen.
{Attribut-Wildcard}
Optional: eine Wildcard.
{Inhaltstyp}
Entweder leer, eine einfache Typdefinition oder ein Paar, das aus einem Inhaltsmodell (d.h. einem Partikel (§2.2.3.2)) und aus mixed oder element-only besteht.
{Verbotene Ersetzungen}
Eine Untermenge von {extension, restriction}.
{Anmerkungen}
Eine Menge von Anmerkungen.

Komplexe Typdefinitionen, sofern sie keine anonymen komplexen Typdefinitionen (ohne {Name}n) sind, werden durch ihren {Name}n und {Ziel-Namensraum} identifiziert. Da Typdefinitionen (d.h. einfache und komplexe Typdefinitionen zusammen genommen) eindeutig innerhalb eines XML Schemas identifiziert werden müssen, kann keine komplexe Typdefinition den gleichen Namen wie eine andere einfache oder komplexe Typdefinition haben. Komplexe Typ-Namen und Ziel-Namensräume werden zur Referenzierung aus Instanzen (siehe xsi:type (§2.6.1)) und für die Verwendung in der XML-Repräsentation von Schemakomponenten (insbesondere in <element>) bereitgestellt. Siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) für die Verwendung von Komponenten-Bezeichnern beim Importieren eines Schemas in ein anderes.

Anmerkung:

Der {Name} eines komplexen Typs ist nicht automatisch der [(lokale) Name] der Element-Informationseinheiten, die durch diese Definition validiert wurden. Die Verbindung zwischen einem Namen und einer Typdefinition wird in Element-Deklarationen (§3.3) beschrieben.

Wie in Typhierarchie (§2.2.1.1) beschrieben, ist jeder komplexe Typ von einer {Basistyp-Definition} abgeleitet, die wiederum entweder eine Einfache Typdefinition (§2.2.1.2) oder eine Komplexe Typdefinition (§2.2.1.3) ist. {Ableitungsmethode} spezifiziert entweder extension oder restriction als Methode zur Ableitung (siehe Typhierarchie (§2.2.1.1)).

Ein komplexer Typ mit einer leeren Spezifikation für {abgeschlossen} kann als {Basistyp-Definition} für andere Typen verwendet werden, die entweder durch Erweiterung oder Restriktion abgeleitet werden; die expliziten Werte extension und restriction verhindern weitere Ableitungen durch Erweiterung bzw. Restriktion. Falls beide Werte spezifiziert wurden, dann gilt: [Definition:] Ein komplexer Typ wird abgeschlossen genannt, weil keine weiteren Ableitungen möglich sind. Abgeschlossen wird nicht geerbt, d.h. eine Typdefinition, die von einer Typdefinition durch Restriktion abgeleitet wurde, aber von der Erweiterungen nicht zulässig sind, ist keinesfalls für Ableitungen eingeschränkt, es sei denn, sie hat selbst ein explizites final-Attribut.

Komplexe Typen, für die {abstrakt}wahr ist, dürfen nicht als {Typdefinition} für die Validierung von Element-Informationseinheiten verwendet werden. Folglich dürfen sie nicht von einem Attribut xsi:type (§2.6.1) in einem Instanzdokument referenziert werden. Abstrakte komplexe Typen können als {Basistyp-Definition}en verwendet werden oder sogar als {Typdefinition}en von Element-Deklarationen, sofern in jedem Fall eine konkrete abgeleitete Typdefinition entweder über xsi:type (§2.6.1) oder das Verfahren einer Ersetzungsgruppe für die Validierung bereitgestellt wird.

{Attribut-Verwendungen} sind eine Menge von Attribut-Verwendungen. Siehe lokal gültiges Element (komplexer Typ) (§3.4.4) und lokal gültiges Attribut (§3.2.4) für Details der Attribut-Validierung.

{Attribut-Wildcard}s stellen eine flexiblere Spezifikation der Validierung für Attribute bereit, die nicht explizit in {Attribut-Verwendungen} eingeschlossen sind. Informell werden die spezifischen Werte aus {Attribut-Wildcard} wie folgt interpretiert:

  • any: [Attribute] können Attribute mit einem beliebigen qualifizierten oder unqualifizierten Namen beinhalten.
  • Eine Menge, deren Mengenelemente entweder Namensraum-Namen sind oder nicht verwendet werden: [Attribute] können beliebige Attribute aus dem/den spezifizierten Namensraum/-räumen beinhalten. Falls nicht verwendet in der Menge enthalten ist, sind (auch) beliebige unqualifizierte Attribute erlaubt.
  • 'not' und ein Namensraum-Name: [Attribute] können keine Attribute aus dem spezifizierten Namensraum beinhalten.
  • 'not' und nicht verwendet: [Attribute] können unqualifizierte Attribute beinhalten.

Siehe lokal gültiges Element (komplexer Typ) (§3.4.4) und Wildcard erlaubt Namensraum-Namen (§3.10.4) für formale Details über Attribut-Wildcard-Validierung.

{Inhaltstyp} legt die Validierung der [Kindelemente] von Element-Informationseinheiten fest. Informell:

{Verbotene Ersetzungen} legt fest, ob eine Element-Deklaration, die in einem Inhaltsmodell vorkommt, daran gehindert wird, zusätzlich Element-Einheiten zu validieren, die ein Attribut xsi:type (§2.6.1) haben, das eine komplexe Typdefinition identifiziert und durch extension oder restriction von dieser Definition abgeleitet ist, oder die sich in einer Ersetzungsgruppe befinden, deren Typdefinition ebenso abgeleitet wird. Falls {Verbotene Ersetzungen} leer ist, sind alle diese Ersetzungen zulässig, andernfalls ist/sind die benannte(n) Ableitungsmethode(n) nicht zulässig.

Siehe Anmerkungen (§3.13) für Informationen zur Rolle der Eigenschaft {Anmerkungen}.

3.4.2 XML-Darstellung der komplexen Typdefinition

Die XML-Darstellung der Schemakomponente komplexe Typdefinition ist eine Element-Informationseinheit <complexType>.

Die XML-Darstellung für komplexe Typdefinitionen mit dem {Inhaltstyp} einfache Typdefinition ist signifikant anders als die mit anderen {Inhaltstyp}en. Dies schlägt sich auch in unten stehender Darstellung nieder, die zuerst die Elemente zeigt, die in den ersten Fall involviert sind und dann diese für den zweiten. Die Abbildung der Eigenschaften wird für jeden Fall einmal gezeigt.

Zusammenfassung der XML-Darstellung: Element-Informationseinheit complexType

<complexType
abstract = boolean : false
block = (#all | Liste aus (extension | restriction))
final = (#all | Liste aus (extension | restriction))
id = ID
mixed = boolean : false
name = NCName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))
</complexType>

Unabhängig vom gewählten Inhalt für <complexType> treffen die folgenden Abbildungen der Eigenschaften zu:
Schemakomponente Komplexe Typdefinition
Eigenschaft Darstellung
{Name} Der tatsächliche Wert des [Attributs] name, falls vorhanden; andernfalls nicht verwendet.
{Ziel-Namensraum} Der tatsächliche Wert des [Attributs] targetNamespace der Vorfahrenelement-Informationseinheit <schema>, falls vorhanden; andernfalls nicht verwendet.
{abstrakt} Der tatsächliche Wert des [Attributs] abstract, falls vorhanden; andernfalls false.
{Verbotene Ersetzungen} Eine Menge, die dem tatsächlichen Wert des [Attributs] block entspricht, falls vorhanden, andernfalls dem tatsächlichen Wert des [Attributs] blockDefault der Vorfahrenelement-Informationseinheit <schema>, falls vorhanden, andernfalls der leeren Zeichenkette. Dies wird als EBW (für Effektiver Blockwert) bezeichnet. Dann ist der Wert dieser Eigenschaft der zutreffende Fall unter den folgenden:
1 Falls der EBW die leere Zeichenkette ist, dann die leere Menge
2 Falls der EBW #all ist, dann { extension, restriction }
3 Sonst eine Menge mit Mengenelementen, die aus obiger Menge entnommen wurden; jedes Mengenelement ist entweder vorhanden oder nicht verwendet, abhängig davon, ob der tatsächliche Wert (der eine Liste ist) eine gleich benannte Einheit enthält.

Anmerkung:

Obwohl das [Attribut] blockDefault von <schema> andere Werte als restriction oder extension enthalten kann, werden diese Werte bei der Ermittlung von {Verbotene Ersetzungen} für komplexe Typdefinitionen ignoriert (sie werden an anderer Stelle verwendet).
{abgeschlossen} Wie bei {Verbotene Ersetzungen}, allerdings unter Verwendung der [Attribute] final und finalDefault statt der [Attribute] block und blockDefault.
{Anmerkungen} Die Anmerkungen, die der Element-Informationseinheit <annotation> in [Kindelemente] entsprechen, falls vorhanden, in den [Kindelementen] <simpleContent> und <complexContent>, falls vorhanden, und in deren [Kindelementen] <restriction> und <extension>, falls vorhanden, andernfalls nicht verwendet.
Wenn die Alternative <simpleContent> gewählt wird, sind die folgenden Elemente relevant und die restlichen Eigenschaftsabbildungen sind wie untenstehend. Man beachte, dass entweder <restriction> oder <extension> als Inhalt für <simpleContent> gewählt werden muss.

<simpleContent
id = ID
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (restriction | extension))
</simpleContent>

<restriction
base = QName
id = ID
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>

<extension
base = QName
id = ID
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</extension>