XML Schema Teil 1: Strukturen

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.

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

3 Schemakomponenten im Detail

3.1 Einführung

3.1.1 Komponenten und ihre Eigenschaften

3.1.2 XML-Darstellung von Komponenten

3.1.3 Die Abbildung zwischen XML-Darstellungen und Komponenten

3.1.4 Leerraum-Normalisierung während der Validierung

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:

Eigenschaften: ihre Werte und deren Bedeutung
XML-Darstellung und die Abbildung auf Eigenschaften
Einschränkungen für die Darstellung
Validierungsregeln
Beiträge des Schema-Validierungsprozesses zum XML Information-Set
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:

Alle erlauben die Qualifizierung von Attributen mit anderen Namensraum-Namen als dem XML-Schema-Namensraum; diese erscheinen als Anmerkungen in der entsprechenden Schemakomponente
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.

3.2 Attribut-Deklarationen

3.2.1 Die Schemakomponente Attribut-Deklaration

3.2.2 XML-Darstellung der Schemakomponente Attribut-Deklaration

3.2.3 Bedingungen an die XML-Darstellung von Attribut-Deklarationen

3.2.4 Validierungsregeln für Attribut-Deklarationen

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

3.2.6 Bedingungen an die Schemakomponente Attribut-Deklaration

3.2.7 Vordefinierte Attribut-Deklarationen

Attribut-Deklarationen werden bereitgestellt für:

Lokale Validierung von Werten für Attribut-Informationseinheiten unter Verwendung einer einfachen Typdefinition;
Spezifikation von Vorgabe- oder festen Werten für Attribut-Informationseinheiten.

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

[voreingestelltes Schema]: Die kanonisch lexikalische Darstellung des Wertes {Wertebereich-Beschränkung} der Deklaration.

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

3.3 Element-Deklarationen

3.3.1 Die Schemakomponente Element-Deklaration

3.3.2 XML-Darstellung der Schemakomponente Element-Deklaration

3.3.3 Bedingungen an die XML-Darstellung von Element-Deklarationen

3.3.4 Validierungsregeln für Element-Deklarationen

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

3.3.6 Bedingungen an die Schemakomponente Element-Deklaration

Element-Deklarationen werden für Folgendes bereitgestellt:

Lokales Validieren der Werte von Element-Informationseinheiten unter Verwendung einer Typdefinition;
Spezifizieren von Vorgabe- oder festen Werten für Element-Informationseinheiten;
Etablieren von Eindeutigkeits- und Referenz-Beziehungen zwischen den Werten in Beziehung stehender Elemente und Attribute;
Kontrollieren der Ersetzbarkeit von Elementen durch den Element-Ersetzungsgruppen-Mechanismus.

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.1 Falls die tatsächliche Typdefinition eine lokale Typdefinition ist, muss die kanonisch lexikalische Repräsentation des Wertes für {Wertebereich-Beschränkung} eine gültige Vorgabe für die tatsächliche Typdefinition, gemäß gültiges Vorgabe-Element (Unmittelbar) (§3.3.6), 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

[voreingestelltes Schema]: Die kanonisch lexikalische Darstellung des Wertes {Wertebereich-Beschränkung} der Deklaration.

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).

2 Falls es eine {Wertebereich-Beschränkung} gibt, muss die kanonisch lexikalische Repräsentation ihres Wertes gültig in Bezug auf die {Typdefinition} sein, gemäß gültiges Vorgabe-Element (Unmittelbar) (§3.3.6).

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.

3.4 Definition komplexer Typen

3.4.1 Die Schemakomponente Definition eines komplexen Typs

3.4.2 XML-Darstellung der komplexen Typdefinition

3.4.3 Bedingungen an die XML-Darstellung von komplexen Typdefinitionen

3.4.4 Validierungsregeln für komplexe Typdefinitionen

3.4.5 Beiträge von komplexen Typdefinitionen zum XML-Information-Set

3.4.6 Bedingungen an die Schemakomponente komplexe Typdefinition

3.4.7 Vordefinierte komplexe Typdefinitionen

Komplexe Typdefinitionen bieten Folgendes:

Einschränkung von Element-Informationseinheiten durch Bereitstellung von Attribut-Deklaration (§2.2.2.3), die das Erscheinen und den Inhalt von [Attributen] steuert.
Einschränkung von [Kindelementen], die Element-Informationseinheiten sind, dahingehend, dass sie leer sind oder dass sie einem spezifizierten Inhaltsmodell mit nur Elementen oder gemischtem Inhalt entsprechen; ansonsten Einschränkung der Zeichen-Informationseinheiten-[Kindelemente] auf Konformität mit einer spezifizierten einfachen Typdefinition.
Verwendung der Mechanismen aus Typhierarchie (§2.2.1.1) zur Ableitung eines komplexen Typs aus einem anderen einfachen oder komplexen Typ.
Spezifikation von Beiträgen zum Post-Schema-Validierungs-Information-Set für Elemente.
Begrenzung der Fähigkeit, zusätzliche Typen von einem gegebenen komplexen Typ abzuleiten.
Kontrolle der Erlaubnis zur Ersetzung innerhalb einer Instanz von Elementen eines abgeleiteten Typs für Elemente, die in einem Inhaltsmodell eines gegebenen komplexen Typs deklariert sind.

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

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:

Ein {Inhaltstyp} mit einem unterscheidbaren Wert leer validiert Elemente ohne Zeichen- oder Element-Informationseinheiten-[Kindelemente].
Ein {Inhaltstyp}, der eine Einfache Typdefinition (§2.2.1.2) ist, validiert Elemente mit Nur-Zeichen-[Kindelementen].
Ein {Inhaltstyp} element-only validiert Elemente, deren [Kindelemente] dem gelieferten Inhaltsmodell entsprechen.
Ein {Inhaltstyp} mixed validiert Elemente, deren Element-[Kindelemente] dem gelieferten Inhaltsmodell entsprechen (d.h. ausdrückliches Ignorieren anderer [Kindelemente] wie Zeichen-Informationseinheiten).

{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>

<attributeGroup
id = ID
ref = QName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</attributeGroup>

<anyAttribute
id = ID
namespace = ((##any | ##other) | Liste aus ) : ##any
processContents = (lax | skip | strict) : strict
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</anyAttribute>

Schemakomponente Komplexe Typdefinition mit einfachem Inhalt

Eigenschaft	Darstellung
{Basistyp-Definition}	Die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] `base`
{Ableitungsmethode}	Falls die Alternative <restriction> gewählt wird, dann restriction; andernfalls (die Alternative <extension> wird gewählt) extension.
{Attribut-Verwendungen}	Eine Vereinigung von Attribut-Verwendungs-Mengen wie folgt: 1 Eine Menge von Attribut-Verwendungen, die den <attribute>-[Kindelementen] entspricht, falls welche vorhanden sind. 2 Die {Attribut-Verwendung} der Attributgruppen aufgelöst durch die tatsächlichen Wertee des [Attributs] `ref` der <attributeGroup>-[Kindelemente], falls welche vorhanden sind. 3 Falls die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] `base` eine komplexe Typdefinition ist, die {Attribut-Verwendungen} dieser Typdefinition, außer es wurde die Alternative <restriction> gewählt. In diesem Fall können einige Mengenmitglieder dieser {Attribut-Verwendungen} der Typdefinition nicht enthalten sein, nämlich jene, deren {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} gleich sind zu einer der folgenden Möglichkeiten: 3.1 Der {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} einer Attribut-Verwendung in der Menge gemäß Klausel 1 oder Klausel 2. 3.2 Der {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} einer Attribut-Verwendung in der Menge gemäß Klausel 1, aber für den tatsächlichen Wert des [Attributs] `use` der relevanten verbotenen <attribute>-[Kindelemente] von <restriction>.
{Attribut-Wildcard}	[Definition:] Die lokale Wildcard sei definiert als der zutreffende Fall unter den folgenden: 1 Falls es ein <anyAttribute> gibt, dann eine Wildcard basierend auf den tatsächlichen Werten der [Attribute] `namespace` und `processContents` und den <annotation>- [Kindelementen], genau wie für die Wildcard, die einem Element <any> entspricht, wie in XML-Darstellung der Schemakomponente Wildcard (§3.10.2) dargelegt; 2 Sonst nicht verwendet. [Definition:] Die vollständige Wildcard sei definiert als der zutreffende Fall unter den folgenden: 1 Falls es keine <attributeGroup>-[Kindelemente] gibt, die Attributgruppen mit {Wildcard-Attribut}en entsprechen, welche nicht nicht verwendet sind, dann die lokale Wildcard. 2 Falls es ein oder mehrere <attributeGroup>- [Kindelemente] gibt, die Attributgruppen mit {Wildcard-Attribut}en entsprechen, welche nicht nicht verwendet sind, dann der zutreffende Fall unter den folgenden: 2.1 Falls es ein <anyAttribute> gibt, dann eine Wildcard, deren Eigenschaften {Prozessinhalte} und {Anmerkung} die der lokalen Wildcard sind und deren {Namensraum-Beschränkung} die intensionale Schnittmenge der {Namensraum-Beschränkung} der lokalen Wildcard mit den {Namensraum-Beschränkung}en der nicht-nicht verwendet {Wildcard-Attribut}e der Attributgruppen, die den <attributeGroup>-[Kindelementen] entsprechen, ist, gemäß Wildcard-Attribut-Schnitt (§3.10.6). 2.2 Falls es kein <anyAttribute> gibt, dann eine Wildcard mit folgenden Eigenschaften: {Prozessinhalte} Die {Prozessinhalte} des ersten nicht-nicht verwendet {Wildcard-Attribut}s einer Attributgruppe unter den Attributgruppen, die den <attributeGroup>-[Kindelementen] entsprechen. {Namensraum-Beschränkung} Die intensionale Schnittmenge der {Namensraum-Beschränkung}en aller nicht-nicht verwendet {Wildcard-Attribut}e der Attributgruppen, die den <attributeGroup>-[Kindelementen] entsprechen, gemäß Wildcard-Attribut-Schnitt (§3.10.6). {Anmerkung} nicht verwendet. Der Wert wird dann festgelegt durch den zutreffenden Fall unter den folgenden: 1 Falls die Alternative <restriction> gewählt wird, dann die vollständige Wildcard; 2 Falls die Alternative <extension> gewählt wird, dann [Definition:] sei Basis-Wildcard definiert als der zutreffende Fall unter den folgenden: 2.1 Falls die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] `base` eine komplexe Typdefinition mit einem {Attribut-Wildcard} ist, dann dieses {Attribut-Wildcard}. 2.2 Sonst nicht verwendet. Der Wert wird dann festgelegt durch den zutreffenden Fall unter den folgenden: 2.1 Falls die Basis-Wildcard nicht-nicht verwendet wird, dann der zutreffende Fall unter den folgenden: 2.1.1 Falls die vollständige Wildcard nicht verwendet wird, dann die Basis-Wildcard. 2.1.2 Sonst eine Wildcard deren Eigenschaften {Prozessinhalte} und {Anmerkung} die der effektiven Wildcard, und deren {Namensraum-Beschränkung} die intensionale Schnittmenge der {Namensraum-Beschränkung} der effektiven Wildcard und der Basis-Wildcard sind, wie in Wildcard-Attribut-Vereinigung (§3.10.6) definiert.
{Inhaltstyp}	1 Falls die durch den tatsächlichen Wert des [Attributs] `base` aufgelöste Typdefinition eine komplexe Typdefinition ist (deren eigener {Inhaltstyp} eine einfache Typdefinition sein muss, s.u.) und die Alternative <restriction> gewählt wird, dann ausgehend von entweder 1.1 der einfachen Typdefinition, die dem <simpleType> unter den <restriction>-[Kindelementen] entspricht, falls es einen gibt; 1.2 andernfalls (<restriction> hat keinen <simpleType> unter seinen [Kindelementen]), die einfache Typdefinition, die der {Inhaltstyp} der durch den tatsächlichen Wert des [Attributs] `base` aufgelösten Typdefinition ist eine einfache Typdefinition, die diese einfache Typdefinition mit einer Menge von Fassetten-Komponenten einschränkt. Die Typdefinition muss den Element-Informationseinheiten unter den <restriction>-[Kindelementen] entsprechen (d.h. jenen, die Fassetten spezifizieren, falls es welche gibt), wie in Einschränkung des einfachen Typs (Fassetten) (§3.14.3) definiert. 2 Andernfalls, falls die durch den tatsächlichen Wert des [Attributs] `base` aufgelöste Typdefinition eine komplexe Typdefinition ist (deren eigener {Inhaltstyp} eine einfache Typdefinition sein muss, s.u.) und die Alternative <extension> gewählt wird, der {Inhaltstyp} dieser komplexen Typdefinition; 3 Andernfalls (die durch den tatsächlichen Wert des [Attributs] `base` aufgelöste Typdefinition ist eine einfache Typdefinition und die Alternative <extension> wird gewählt) diese einfache Typdefinition.

Wenn die Alternative <complexContent> gewählt wird, sind die folgenden Elemente relevant (genauso wie die <attributeGroup>- und <anyAttribute>-Elemente, die hier nicht wiederholt werden), und die zusätzlichen Eigenschaftsabbildungen sind wie unten dargestellt. Zu beachten ist, dass entweder <restriction> oder <extension> als Inhalt von <complexContent> gewählt werden muss. Allerdings sind ihre Inhaltsmodelle im Vergleich zum obigen Fall unterschiedlich, wenn sie als Kindelemente von <simpleContent> erscheinen.

Die nachfolgenden Eigenschaftsabbildungen werden auch in jenem Fall verwendet, in dem die dritte Alternative (weder <simpleContent> noch <complexContent>) gewählt wird. Dieser Fall dient als Kurzform für komplexen Inhalt, der die Urtyp-Definition einschränkt. Die Einzelheiten der Abbildungen sollten je nach Notwendigkeit modifiziert werden.

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

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

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

Schemakomponente Komplexe Typdefinition mit komplexem Inhalt

Eigenschaft	Darstellung
{Basistyp-Definition}	Die durch den tatsächlichen Wert des [Attributs] `base` aufgelöste Typdefinition.
{Ableitungsmethode}	Falls die Alternative <restriction> gewählt wird, der Wert restriction; andernfalls (die Alternative <extension> wird gewählt) extension.
{Attribut-Verwendungen}	Eine Vereinigung von Attribut-Verwendungs-Mengen wie folgt: 1 Die Attribut-Verwendungs-Menge, die den <attribute>-[Kindelementen] entspricht, falls welche vorhanden. 2 Die {Attribut-Verwendung} der durch die tatsächlichen Werte des [Attributs] `ref` aufgelösten Attributgruppen der <attributeGroup>-[Kindelemente], falls welche vorhanden. 3 Die {Attribut-Verwendungen} der durch den tatsächlichen Wert des [Attributs] `base` aufgelösten Typdefinition, es sei denn, die Alternative <restriction> wird gewählt. In diesem Fall können einige Mengenmitglieder dieser {Attribut-Verwendungen} der Typdefinition nicht enthalten sein, nämlich jene, deren {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} gleich sind zu einer der folgenden Möglichkeiten: 3.1 Der {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} einer Attribut-Verwendung in der Menge nach obiger Klausel 1 oder Klausel 2 3.2 Was der {Name} und {Ziel-Namensraum} der {Attribut-Deklaration} einer Attribut-Verwendung in der Menge nach obiger Klausel 1 gewesen wäre, aber für den tatsächlichen Wert des `use`-[Attributs] der relevanten verbotenen <attribute>-[Kindelemente] von <restriction>.
{Attribut-Wildcard}	Wie für die obige Alternative <simpleContent>.
{Inhaltstyp}	Der zutreffende Fall unter den folgenden: 1 Falls die Alternative <restriction> gewählt wird, dann der zutreffende Fall unter den folgenden: 1.1 Falls eine der folgenden Aussagen wahr ist: 1.1.1 Es gibt kein <group>, <all>, <choice> oder <sequence> unter den [Kindelementen]. 1.1.2 Es gibt ein <all> oder <sequence> unter den [Kindelementen], die selber keine [Kindelemente] haben, mit Ausnahme von <annotation>. 1.1.3 Es gibt ein <choice> unter den [Kindelementen], die selber keine [Kindelemente] haben, mit Ausnahme von <annotation>, dessen [Attribut] `minOccurs` den tatsächlichen Wert `0` hat , dann dann leer. 1.2 Sonst ein Paar bestehend aus 1.2.1 der zutreffende Fall unter den folgenden: 1.2.1.1 Falls <complexContent> ein [Attribut] `mixed` hat und dessen tatsächlicher Wert `true` ist, dann dann mixed, andernfalls elementOnly. 1.2.1.2 Falls <complexType> ein [Attribut] `mixed` hat und dessen tatsächlicher Wert `true` ist, dann dann mixed; 1.2.1.3 Sonst elementOnly. 1.2.2 Das Partikel, das den [Kindelementen] <all>, <choice>, <group> oder <sequence> entspricht. 2 Falls die Alternative <extension> gewählt wird, dann [Definition:] sei der explizite Inhalt leer, falls eine beliebige Subklausel von obiger Klausel 1.1 zutrifft; andernfalls das Partikel, das den [Kindelementen] <all>, <choice>, <group> oder <sequence> entspricht. Dann der zutreffende Fall unter den folgenden: 2.1 Falls der explizite Inhalt leer ist, dann der {Inhaltstyp} der durch den tatsächlichen Wert aufgelösten Typdefinition des [Attributs] `base`. 2.2 Falls die Typdefinition, zu der der tatsächliche Wert des [Attributs] `base` aufgelöst wird, einen leeren {Inhaltstyp} hat, dann ein Paar aus mixed oder elementOnly (festgelegt nach obiger Klausel 1.2.1) und dem expliziten Inhalt. 2.3 Sonst ein Paar aus mixed oder elementOnly (festgelegt nach obiger Klausel 1.2.1) und einem Partikel dessen Eigenschaften wie folgt sind: {minimales Vorkommen} `1` {maximales Vorkommen} `1` {Term} Eine Elementgruppe, deren {Verbund} eine Folge ist und deren {Partikel} die Partikel des {Inhaltstyp}s der Typdefinition sind, zu der der tatsächliche Wert des [Attributs] `base` aufgelöst wurde, gefolgt vom expliziten Inhalt.

Anmerkung:

Neben den einfachen Zusammenhangs-Anforderungen, die durch obige Festlegungen erzwungen werden, wird das Einschränken von als Restriktion identifizierten Typdefinitionen, d.h. eine Untermenge der Einheiten zu validieren, die durch ihre Basistyp-Definition validiert werden, in Bedingungen an die Schemakomponente komplexe Typdefinition (§3.4.6) erzwungen.

Anmerkung:

Die einzige substanzielle Funktion des Wertes prohibited für das Attribut use eines Elements <attribute> ist das Bilden einer Beziehung zwischen einem komplexen Typ, der durch Restriktion definiert ist, und seiner XML-Darstellung. Es dient dem Verhindern der Vererbung einer identisch benannten Attribut-Verwendung von {Basistyp-Definition}. Solch ein Element <attribute> entspricht keiner Komponente und deshalb gibt es keine Interaktion mit entweder expliziten oder vererbten Wildcards in der Verarbeitung von Validierungsregeln für komplexe Typdefinitionen (§3.4.4) oder Bedingungen an die Schemakomponente komplexe Typdefinition (§3.4.6).

Eine genaue Betrachtung der obigen konkreten Syntax offenbart, dass eine Typdefinition aus nichts weiter als einem Namen bestehen kann, d.h. dass <complexType name="anyThing"/> erlaubt ist.

Beispiel

<xs:complexType name="Länge1">
 <xs:simpleContent>
  <xs:extension base="xs:nonNegativeInteger">
   <xs:attribute name="einheit" type="xs:NMTOKEN"/>
  </xs:extension>
 </xs:simpleContent>
</xs:complexType>

<xs:element name="Breite" type="Länge1"/>

  <Breite einheit="cm">25</Breite>

<xs:complexType name="Länge2">
 <xs:complexContent>
  <xs:restriction base="xs:anyType">
   <xs:sequence>
    <xs:element name="Größe" type="xs:nonPositiveInteger"/>
    <xs:element name="Einheit" type="xs:NMTOKEN"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="Tiefe" type="Länge2"/>

  <Tiefe>
   <Größe>25</Größe><Einheit>cm</Einheit>
  </Tiefe>

<xs:complexType name="Länge3">
 <xs:sequence>
  <xs:element name="Größe" type="xs:non-positive-integer"/>
  <xs:element name="Einheit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>

Drei Ansätze, einen Typ für Länge zu definieren. Ansatz 1: ein Element mit Zeichendaten-Inhalt, das durch eine Referenz auf einen vordefinierten Typ beschränkt ist und ein Attribut. Die anderen beiden Ansätze verwenden zwei Elemente. Länge3 ist eine alternative Kurzform zu Länge2, da beide identische Typdefinitions-Komponenten haben.

Beispiel

<xs:complexType name="Personenname">
 <xs:sequence>
  <xs:element name="Titel" minOccurs="0"/>
  <xs:element name="Vorname" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="Nachname"/>
 </xs:sequence>
</xs:complexType>

<xs:complexType name="ErweiterterName">
 <xs:complexContent>
  <xs:extension base="Personenname">
   <xs:sequence>
    <xs:element name="Geschlecht" minOccurs="0"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

<xs:element name="Empfänger" type="ErweiterterName"/>

  <Empfänger>
   <Vorname>Lieschen</Vorname>
   <Vorname>Lotte</Vorname>
   <Nachname>Müller</Nachname>
   <Geschlecht>weiblich</Geschlecht>
  </Empfänger>

Eine Typdefinition für persönliche Namen und eine durch Erweiterung abgeleitete Typdefinition ErweiterterName, die ein Element hinzufügt. Anschließend eine Element-Deklaration, die ErweiterterName referenziert, und eine zugehörige gültige Instanz.

Beispiel

<xs:complexType name="EinfacherName">
 <xs:complexContent>
  <xs:restriction base="Personenname">
   <xs:sequence>
    <xs:element name="Vorname" minOccurs="1" maxOccurs="1"/>
    <xs:element name="Nachname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="Wer" type="EinfacherName"/>

   <Wer>
    <Vorname>Lieschen</Vorname>
    <Nachname>Müller</Nachname>
   </Wer>

Eine vereinfachte Typdefinition, abgeleitet durch Restriktion vom Basistyp des vorherigen Beispiels. Es wird das optionale Tochterelement Titel eliminiert und das Element Vorname so angepasst, dass es genau einmal vorkommen muss. Anschließend wird ein Element deklariert, das den definierten Typ referenziert, sowie eine zugehörige gültige Instanz.

Beispiel

<xs:complexType name="paraType" mixed="true">
 <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element ref="emph"/>
  <xs:element ref="strong"/>
 </xs:choice>
 <xs:attribute name="version" type="xs:number"/>
</xs:complexType>

Eine weitere Darstellung der gekürzten Form, bei der complexType das mixed-Attribut hat.

3.4.3 Bedingungen an die XML-Darstellung von komplexen Typdefinitionen

Bedingung an Schema-Darstellung: korrekte Darstellung der komplexen Typdefinition

Zusätzlich zu den Bedingungen, die den Element-Informationseinheiten <complexType> durch das Schema für Schemata auferlegt werden, müssen alle folgenden Aussagen wahr sein:

1 Falls die Alternative <complexContent> gewählt wird, muss die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] base, eine komplexe Typdefinition sein.

2 Falls die Alternative <simpleContent> gewählt wird, muss die Typdefinition aufgelöst durch den tatsächlichen Wert des [Attributs] base, entweder eine komplexe Typdefinition sein, deren {Inhaltstyp} eine einfache Typdefinition ist, oder, nur falls auch die Alternative <extension> gewählt wird, eine einfache Typdefinition.

3 Die entsprechende Komponente der Definition eines komplexen Typs muss die Bedingungen, die in Bedingungen an die Schemakomponente komplexe Typdefinition (§3.4.6) dargelegt sind, erfüllen.

4 Falls Klausel 2.1 oder Klausel 2.2 in der entsprechenden obigen Spezifikation für {Attribut-Wildcard} erfüllt ist, muss die intensionale Schnittmenge ausdrückbar sein, gemäß Wildcard-Attribut-Schnitt (§3.10.6).

3.4.4 Validierungsregeln für komplexe Typdefinitionen

Validierungsregel: lokal gültiges Element (komplexer Typ)

Damit eine Element-Informationseinheit lokal gültig bezüglich einer komplexen Typdefinition ist, müssen alle folgenden Aussagen wahr sein:

1 {abstrakt} ist falsch.

2 Falls Klausel 3.2 von lokal gültiges Element (Element) (§3.3.4) nicht zutrifft, dann muss der zutreffende Fall unter den folgenden wahr sein:

2.1 Falls der {Inhaltstyp} leer ist, dann hat die Element-Informationseinheit keine Zeichen- oder Element-Informationseinheit-[Kindelemente].

2.2 Falls der {Inhaltstyp} eine einfache Typdefinition ist, dann hat die Element-Informationseinheit keine Element-Informationseinheiten-[Kindelemente], und der normalisierte Wert der Element-Informationseinheit ist gültig in Bezug auf diese einfache Typdefinition, wie durch gültiger String (§3.14.4) definiert.

2.3 Falls der {Inhaltstyp} element-only ist, dann hat die Element-Informationseinheit keine anderen Zeichen-Informationseinheiten-[Kindelemente] als jene, deren [Zeichencode] als Leerraum in [XML 1.0 (Second Edition)] definiert ist.

2.4 Falls der {Inhaltstyp} element-only oder mixed ist, dann ist die Folge der Element-Informationseinheiten-[Kindelemente] der Element-Informationseinheit, falls es welche gibt, in der gegebenen Reihenfolge, gültig bezüglich des Partikels von {Inhaltstyp}, wie in lokal gültige Element-Folge (Partikel) (§3.9.4) definiert.

3 Für jede Attribut-Informationseinheit in den [Attributen] der Element-Informationseinheit außer denen, deren [Namensraum-Name] identisch zu http://www.w3.org/2001/XMLSchema-instance ist und deren [lokaler Name] type, nil, schemaLocation oder noNamespaceSchemaLocation ist, muss der zutreffende Fall unter den folgenden wahr sein:

3.1 Falls es unter den {Attribut-Verwendungen} eine Attribut-Verwendung mit einer {Attribut-Deklaration} gibt, deren {Name} mit dem [lokalen Namen] der Attribut-Informationseinheit übereinstimmt und deren {Ziel-Namensraum} identisch zum [Namensraum-Namen] der Attribut-Informationseinheit ist (wobei ein nicht verwendet-{Ziel-Namensraum} als identisch zu einem [Namensraum-Namen] ohne Wert angenommen wird), dann muss die Attribut-Informationseinheit gültig in Bezug auf diese Attribut-Verwendung sein, gemäß lokal gültiges Attribut (Verwendung) (§3.5.4). In diesem Fall ist die {Attribut-Deklaration} dieser Attribut-Verwendung die kontextbestimmte Deklaration für die Attribut-Informationseinheit, in Bezug auf Die Schemagültigkeitsprüfung (Attribut) (§3.2.4) und Ergebnis des Validierungsprozesses (Attribut) (§3.2.5).

3.2 Sonst müssen alle folgenden Aussagen wahr sein:

3.2.1 Es muss ein {Attribut-Wildcard} vorhanden sein.

3.2.2 Die Attribut-Informationseinheit muss in Bezug darauf gültig sein, wie in gültige Informationseinheit (Wildcard) (§3.10.4) definiert.

4 Die {Attribut-Deklaration} jeder Attribut-Verwendung in den {Attribut-Verwendungen}, deren Eigenschaft {erforderlich} wahr ist, stimmt mit einer der Attribut-Informationseinheiten in den [Attributen] der Element-Informationseinheit überein, gemäß obiger Klausel 3.1.

5 Seien [Definition:] die Wildcard-IDs die Menge aller Attribut-Informationseinheiten, auf welche Klausel 3.2 zutrifft und deren Validierung eine kontextbestimmte Deklaration von mustFind zum Ergebnis hat oder überhaupt keine kontextbestimmte Deklaration und deren [lokaler Name] und [Namensraum-Name] zu (wie durch QName-Auflösung (Instanz) (§3.15.4) definiert) einer Attribut-Deklaration aufgelöst werden, deren {Typdefinition} ID oder davon abgeleitet ist. Dann müssen alle folgenden Aussagen wahr sein:

5.1 Es darf nicht mehr als eine Einheit in Wildcard-IDs geben.

5.2 Falls Wildcard-IDs nicht leer ist, darf es keine Attribut-Verwendungen unter den {Attribut-Verwendungen} geben, deren {Typdefinition} der {Attribut-Deklaration} ID oder davon abgeleitet ist.

Anmerkung:

Diese Klausel dient dazu sicherzustellen, dass auch bei Verwendung von Attribut-Wildcards keine Elemente mehr als ein Attribut vom Typ ID haben und dass sogar, wenn ein Element rechtmäßig kein deklariertes Attribut vom Typ ID hat, ein Wildcard-validiertes Attribut es auch nicht zur Verfügung stellen darf. D.h., falls ein Element einen Typ hat, dessen Attribut-Deklarationen ein Attribut vom Typ ID beinhalten, hat es entweder dieses Attribut oder kein Attribut vom Typ ID.

Anmerkung:

Wenn ein {Attribut-Wildcard} vorhanden ist, führt das nicht zu einer Mehrdeutigkeit in Bezug darauf, wie Attribut-Informationseinheiten, für die eine Attribut-Verwendung unter den {Attribut-Verwendungen} vorhanden ist, deren Name und Ziel-Namensraum übereinstimmen, geprüft werden. In solchen Fällen haben die Attribut-Verwendungen immer Vorrang und der Validierungsprozess solcher Einheiten steht und fällt völlig auf der Basis von Attribut-Verwendungen und ihrer {Attribut-Deklaration}. Dies folgt aus den Details von Klausel 3.

3.4.5 Beiträge von komplexen Typdefinitionen zum XML-Information-Set

Beitrag zum Schema Information Set: Vorgabe-Attributwert

Für jede Attribut-Verwendung in den {Attribut-Verwendungen}, deren Eigenschaft {erforderlich} falsch ist und deren {Wertebereich-Beschränkung} nicht nicht verwendet ist, aber deren {Attribut-Deklaration} nicht mit einer der Attribut-Informationseinheiten in den [Attributen] der Element-Informationseinheit übereinstimmt, gemäß obiger Klausel 3.1 von lokal gültiges Element (komplexer Typ) (§3.4.4), hat der Post-Schema-Validierungs-Information-Set eine zu den [Attributen] der Element-Informationseinheit zusätzliche Attribut-Informationseinheit, deren Eigenschaften wie untenstehend definiert sind.

[lokaler Name]: Der {Name} der {Attribut-Deklaration}.
[Namensraum-Name]: Der {Ziel-Namensraum} der {Attribut-Deklaration}.
[Schema-normalisierter Wert]: Die kanonisch lexikalische Repräsentation des Wertes {Wertebereich-Beschränkung}.
[voreingestelltes Schema]: Die kanonisch lexikalische Repräsentation des Wertes {Wertebereich-Beschränkung}.
[Validierungs-Kontext]: Die nächste Vorfahrenelement-Informationseinheit mit einer Eigenschaft [Schema-Informationen].
[Gültigkeit]: gültig.
[versuchte Validierung]: vollständig.
[spezifiziertes Schema]: Schema.

Die hinzugefügten Einheiten sollten auch entweder die Eigenschaft [Typdefinition] (und [Mengenelement-Typ-Definition] falls passend) haben oder ihre leichtgewichtigeren Alternativen, wie in Attribut validiert durch den Typ (§3.2.5) spezifiziert.

3.4.6 Bedingungen an die Schemakomponente komplexe Typdefinition

Alle komplexen Typdefinitionen (siehe Definition komplexer Typen (§3.4)) müssen die folgenden Bedingungen erfüllen.

Bedingung an Schemakomponente: Eigenschaften der komplexen Typdefinition

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften einer komplexen Typdefinition müssen wie in der Eigenschaftstabelle Die Schemakomponente Definition eines komplexen Typs (§3.4.1) beschrieben sein, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

2 Falls die {Basistyp-Definition} eine einfache Typdefinition ist, muss die {Ableitungsmethode} extension sein.

3 Zirkuläre Definitionen sind nicht erlaubt, außer für die Urtyp-Definition. D.h., es muss möglich sein, die Urtyp-Definition durch wiederholtes Verfolgen der {Basistyp-Definition} zu erreichen.

4 {Name} und {Ziel-Namensraum} zweier unterschiedlicher Attribut-Deklarationen in {Attribut-Verwendungen} dürfen nicht identisch sein.

5 Zwei unterschiedliche Attribut-Deklarationen in den {Attribut-Verwendungen} dürfen keine {Typdefinition}n haben, die ID oder davon abgeleitet sind.

Bedingung an Schemakomponente: gültige Ableitung (Erweiterung)

Falls die {Ableitungsmethode} extension ist, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls die {Basistyp-Definition} eine komplexe Typdefinition ist, dann müssen alle folgenden Aussagen wahr sein:

1.1 Die Eigenschaft {abgeschlossen} der {Basistyp-Definition} darf nicht extension beinhalten.

1.2 Ihre {Attribut-Verwendungen} müssen eine Untermenge der {Attribut-Verwendungen} der komplexen Typdefinition sein, d.h., für jede Attribut-Verwendung in den {Attribut-Verwendungen} der {Basistyp-Definition} muss es eine Attribut-Verwendung in den {Attribut-Verwendungen} der komplexen Typdefinition geben, deren {Attribut-Deklaration} den gleichen {Name}n, {Ziel-Namensraum} und die gleiche {Typdefinition} hat wie die Attribut-Deklaration der Attribut-Verwendung der {Basistyp-Definition}.

1.3 Falls es eine {Attribut-Wildcard} gibt, muss die komplexe Typdefinition auch eine haben, und die Eigenschaft {Namensraum-Beschränkung} der {Attribut-Wildcard}s der Basistyp-Definition muss eine Untermenge der Eigenschaft {Namensraum-Beschränkung} der {Attribut-Wildcard}s der komplexen Typdefinition sein, wie durch Wildcard-Untermenge (§3.10.6) definiert.

1.4 Eine der folgenden Aussagen muss wahr sein:

1.4.1 Der {Inhaltstyp} der {Basistyp-Definition} und der {Inhaltstyp} der komplexen Typdefinition müssen die gleiche einfache Typdefinition sein.

1.4.2 Alle folgenden Aussagen müssen wahr sein:

1.4.2.1 Der {Inhaltstyp} der komplexen Typdefinition muss ein Partikel spezifizieren.

1.4.2.2 Eine der folgenden Aussagen muss wahr sein:

1.4.2.2.1 Der {Inhaltstyp} der {Basistyp-Definition} muss leer sein.

1.4.2.2.2 Alle folgenden Aussagen müssen wahr sein:

1.4.2.2.2.1 Beide {Inhaltstyp}en müssen entweder mixed oder element-only sein.

1.4.2.2.2.2 Das Partikel der komplexen Typdefinition muss eine gültige Erweiterung des Partikels der {Basistyp-Definition} sein, wie in gültige Partikel (Erweiterung) (§3.9.6) definiert.

1.5 Es muss im Prinzip möglich sein, die komplexe Typdefinition in zwei Schritten, erstens durch eine Erweiterung und zweitens durch eine Einschränkung (möglicherweise ausdruckslos), von der Typdefinition unter ihren Vorfahren, deren {Basistyp-Definition} die Urtyp-Definition ist, abzuleiten.

Anmerkung:

Diese Anforderung stellt sicher, dass etwas durch eine Einschränkung Entferntes nicht nachfolgend durch eine Erweiterung wieder hinzugefügt wird. Es ist einfach zu überprüfen, ob die besagte Erweiterung die einzige Erweiterung in der Ableitungskette ist oder, falls es keine Einschränkungen gibt, die erste nach der Urtyp-Definition.

Das Konstruieren der Zwischen-Typdefinition zur Überprüfung dieser Randbedingung ist einfach: man ordne die Ableitung einfach so um, dass alle Erweiterungs-Schritte zuerst kommen. Dann lege man sie zu einer einzigen Erweiterung zusammen. Falls die resultierende Definition die Basis für eine gültige Einschränkung zu der gewünschten Definition sein kann, ist die Randbedingung erfüllt.

2 Falls die {Basistyp-Definition} eine einfache Typdefinition ist, dann müssen alle folgenden Aussagen wahr sein:

2.1 Der {Inhaltstyp} muss die gleiche einfache Typdefinition sein.

2.2 Die Eigenschaft {abgeschlossen} der {Basistyp-Definition} darf extension nicht beinhalten.

[Definition:] Falls die Einschränkung gültige Ableitung (Erweiterung) (§3.4.6) für eine komplexe Typdefinition zutrifft, ist die Typdefinition eine gültige Erweiterung ihrer {Basistyp-Definition}.

Bedingung an Schemakomponente: gültige Ableitung (Einschränkung, komplexer Typ)

Falls die {Ableitungsmethode} restriction ist, müssen alle folgenden Aussagen wahr sein:

1 Die {Basistyp-Definition} muss eine komplexe Typdefinition sein, deren Eigenschaft {abgeschlossen} nicht restriction beinhaltet.

2 Für jede Attribut-Verwendung (R genannt) in den {Attribut-Verwendungen} muss der zutreffende Fall unter den folgenden wahr sein:

2.1 Falls es eine Attribut-Verwendung in den {Attribut-Verwendungen} der {Basistyp-Definition} gibt (B genannt), deren {Attribut-Deklaration} den gleichen {Name}n und {Ziel-Namensraum} hat, dann müssen alle folgenden Aussagen wahr sein:

2.1.1 Eine der folgenden Aussagen muss wahr sein:

2.1.1.1 {erforderlich} von B ist falsch.

2.1.1.2 {erforderlich} von R ist wahr.

2.1.2 Die {Typdefinition} der {Attribut-Deklaration} von R muss gültig von der {Typdefinition} von B abgeleitet sein, bei gegebener leerer Menge, wie in korrekte Typableitung (einfacher Typ) (§3.14.6) definiert.

2.1.3 [Definition:] Die effektive Wertebereich-Beschränkung einer Attribut-Verwendung sei ihre {Wertebereich-Beschränkung}, falls vorhanden, andernfalls die {Wertebereich-Beschränkung} ihrer {Attribut-Deklaration} . Dann muss eine der folgenden Aussagen wahr sein:

2.1.3.1 Die effektive Wertebereich-Beschränkung von B hat den Wert nicht verwendet oder default.

2.1.3.2 Die effektive Wertebereich-Beschränkung von R hat den Wert fixed mit der gleichen Zeichenkette wie die von B.

2.2 Sonst muss die {Basistyp-Definition} eine {Attribut-Wildcard} haben und der {Ziel-Namensraum} der {Attribut-Deklaration} von R muss gültig in Bezug auf diese Wildcard sein, wie in Wildcard erlaubt Namensraum-Namen (§3.10.4) definiert.

3 Für jede Attribut-Verwendung in den {Attribut-Verwendungen} der {Basistyp-Definition}, deren Eigenschaft {erforderlich} wahr ist, muss es eine Attribut-Verwendung mit einer {Attribut-Deklaration} mit gleichem {Name}n und {Ziel-Namensraum} wie bei der {Attribut-Deklaration} in den {Attribut-Verwendungen} der komplexen Typdefinition geben, deren Eigenschaft {erforderlich} wahr ist.

4 Falls es eine {Attribut-Wildcard} gibt, müssen alle folgenden Aussagen wahr sein:

4.1 Die {Basistyp-Definition} muss auch eine haben.

4.2 Die {Namensraum-Beschränkung} der {Attribut-Wildcard}s der komplexen Typdefinition muss eine Untermenge der {Namensraum-Beschränkung} der {Attribut-Wildcard}s der {Basistyp-Definition} sein, wie durch Wildcard-Untermenge (§3.10.6) definiert.

5 Der zutreffende Fall unter den folgenden muss wahr sein:

5.1 Falls der {Inhaltstyp} der komplexen Typdefinition eine einfache Typdefinition ist, dann muss eine der folgenden Aussagen wahr sein:

5.1.1 Der {Inhaltstyp} der {Basistyp-Definition} muss eine einfache Typdefinition sein, bei der der {Inhaltstyp} eine gültige Einschränkung ist, wie in gültige Ableitung (Einschränkung, einfacher Typ) (§3.14.6) definiert.

5.1.2 Die {Basistyp-Definition} muss mixed sein und ein Partikel haben, der inhaltsfrei-fähig ist, wie in Partikel leerbar (§3.9.6) definiert.

5.2 Falls der {Inhaltstyp} des komplexen Typs leer ist, dann muss eine der folgenden Aussagen wahr sein:

5.2.1 Der {Inhaltstyp} der {Basistyp-Definition} muss auch leer sein.

5.2.2 Der {Inhaltstyp} der {Basistyp-Definition} muss elementOnly oder mixed sein und ein Partikel haben, der inhaltsfrei-fähig ist, wie in Partikel leerbar (§3.9.6) definiert.

5.3 Falls der {Inhaltstyp} der {Basistyp-Definition} mixed oder der {Inhaltstyp} der komplexen Typdefinition element-only ist, dann muss das Partikel der komplexen Typdefinition eine gültige Einschränkung des Partikels des {Inhaltstyp}s der {Basistyp-Definition} sein, wie in gültige Partikel (Einschränkung) (§3.9.6) definiert.

[Definition:] Falls die Einschränkung gültige Ableitung (Einschränkung, komplexer Typ) (§3.4.6) für eine komplexe Typdefinition zutrifft, ist die Typdefinition eine gültige Einschränkung ihrer {Basistyp-Definition}.

Anmerkung:

Um eine komplexe Typdefinition mit einer einfachen Basistyp-Definition auf leer einzuschränken, wird eine einfache Typdefinition mit der leeren Zeichenkette als fester Wert definiert: dies erhält die Typ-Information.

Die folgende Beschränkung definiert eine Beziehung, die an anderer Stelle in dieser Spezifikation von Belang ist.

Bedingung an Schemakomponente: korrekte Typ-Ableitung (komplexer Typ)

Damit eine komplexe Typdefinition (sie sei A, für abgeleitet, genannt), bei gegebener Untermenge aus {extension, restriction}, gültig von einer Typdefinition (sie sei B, für Basis, genannt) abgeleitet werden kann, müssen alle folgenden Aussagen wahr sein:

1 Falls B und A nicht die gleichen Typdefinitionen sind, darf die {Ableitungsmethode} von A nicht in der Untermenge sein.

2 Eine der folgenden Aussagen muss wahr sein:

2.1 B und A müssen die gleiche Typdefinition sein.

2.2 B muss die {Basistyp-Definition} von A sein.

2.3 Alle folgenden Aussagen müssen wahr sein:

2.3.1 Die {Basistyp-Definition} von A darf nicht die Urtyp-Definition sein.

2.3.2 Der zutreffende Fall unter den folgenden muss wahr sein:

2.3.2.1 Falls die {Basistyp-Definition} von A komplex ist, dann muss sie gültig von B, bei gegebener Untermenge wie durch diese Bedingung definiert, abgeleitet sein.

2.3.2.2 Falls die {Basistyp-Definition} von A einfach ist, dann muss sie gültig von B, bei gegebener Untermenge wie in korrekte Typableitung (einfacher Typ) (§3.14.6) definiert, abgeleitet sein.

Anmerkung:

Diese Randbedingung wird verwendet, um zu überprüfen, ob ein Typ in einem Kontext verwendet wird, in dem ein anderer Typ erwartet wurde (entweder durch xsi:type oder Ersetzungsgruppen), der verwendete Typ tatsächlich vom erwarteten Typ abgeleitet ist und ob diese Ableitung nicht eine Ableitungsform involviert, die durch den erwarteten Typ ausgeschlossen wurde.

3.4.7 Vordefinierte komplexe Typdefinitionen

Es gibt eine komplexe Typdefinition nahezu äquivalent zu der Urtyp-Definition, die in jedem Schema per Definition vorhanden ist. Sie hat die folgenden Eigenschaften:

komplexe Typdefinition des Urtyps

Eigenschaft

Wert

{Name}

anyType

{Ziel-Namensraum}

http://www.w3.org/2001/XMLSchema

{Basistyp-Definition}

sich selbst

{Ableitungsmethode}

restriction

{Inhaltstyp}

Ein Paar bestehend aus mixed und einem Partikel mit den folgenden Eigenschaften:

Eigenschaft

Wert

{minimales Vorkommen}

{maximales Vorkommen}

{Term}

eine Elementgruppe mit den folgenden Eigenschaften:

Eigenschaft

Wert

{Verbund}

Folge

{Partikel}

eine Liste, die ein Partikel mit den folgenden Eigenschaften beinhaltet:

Eigenschaft	Wert
{minimales Vorkommen}	0
{maximales Vorkommen}	unbounded
{Term}	eine Wildcard mit einer {Namensraum-Beschränkung} any

{Attribut-Verwendungen}

die leere Menge

{Attribut-Wildcard}

{Namensraum-Beschränkung} ist any

{abgeschlossen}

die leere Menge

{Verbotene Ersetzungen}

die leere Menge

{abstrakt}

false

Die mixed-Inhalts-Spezifikation zusammen mit dem unbeschränkten Wildcard-Inhaltsmodell und der Attribut-Spezifikation schafft die definierende Eigenschaft für die Urtyp-Definition, d.h., dass jede komplexe Typdefinition (schließlich) eine Restriktion der Urtyp-Definition ist: Ihre Möglichkeiten und Anforderungen sind die am wenigsten restriktiven.

Anmerkung:

Diese Spezifikation stellt keinen Bestand an vordefinierten komplexen Typdefinitionen zur Verwendung in Benutzer-Schemata zur Verfügung. Eine vorläufige Bibliothek von komplexen Typdefinitionen ist verfügbar, die mathematische (z.B. rational) und Hilfs- (z.B. array) Typdefinitionen enthält. Im Speziellen gibt es eine Typdefinition text, die zur Verwendung als Typdefinition in Element-Deklarationen, die für allgemeinen Textinhalt gedacht sind, empfohlen wird, da sie sinnvolle Festlegungen für verschiedene Aspekte der Internationalisierung gestattet. Für mehr Details siehe das Schemadokument für die Typ-Bibliothek an der Adresse: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.

3.5 Attribut-Verwendungen

3.5.1 Die Schemakomponente Attribut-Verwendung

3.5.2 XML-Darstellung der Komponente Attribut-Verwendung

3.5.3 Bedingungen an die XML-Darstellung der Attribut-Verwendungs-Komponente

3.5.4 Validierungsregeln für Attribut-Verwendungen

3.5.5 Beiträge von Attribut-Verwendungen zum XML-Information-Set

3.5.6 Bedingungen an die Schemakomponente Attribut-Verwendung

Eine Attribut-Verwendung ist eine Hilfs-Komponente, die das Vorkommen und das vorgegebene Verhalten von Attribut-Deklarationen kontrolliert. Sie spielt die gleiche Rolle für Attribut-Deklarationen in komplexen Typen wie Partikel für Element-Deklarationen.

Beispiel

<xs:complexType>
 . . .
 <xs:attribute ref="xml:lang" use="required"/>
 <xs:attribute ref="xml:space" default="preserve"/>
 <xs:attribute name="version" type="xs:number" fixed="1.0"/>
</xs:complexType>

XML-Darstellungen mit Attribut-Verwendungen, die Möglichkeiten aufzeigen, wie das Erscheinen der Attribute kontrolliert werden kann.

3.5.1 Die Schemakomponente Attribut-Verwendung

Die Schemakomponente Attribut-Verwendung hat die folgenden Eigenschaften:

Schemakomponente: Attribut-Verwendung

{erforderlich}: Ein boolescher Wert.
{Attribut-Deklaration}: Eine Attribut-Deklaration.
{Wertebereich-Beschränkung}: Optional: ein Paar bestehend aus einem Wert und aus default oder fixed.

{erforderlich} legt fest, ob diese Verwendung einer Attribut-Deklaration es erfordert, dass eine entsprechende Attribut-Informationseinheit vorhanden ist, oder es lediglich erlaubt.

{Attribut-Deklaration} stellt die Attribut-Deklaration zur Verfügung, was wiederum die verwendete einfache Typdefinition festlegt.

{Wertebereich-Beschränkung} erlaubt die lokale Spezifikation von Vorgabe- oder festen Werten. Diese muss konsistent mit der von {Attribut-Deklaration} sein. Wenn dort die {Attribut-Deklaration} einen festen Wert spezifiziert, ist die einzige erlaubte {Wertebereich-Beschränkung} der gleiche feste Wert.

3.5.2 XML-Darstellung der Komponente Attribut-Verwendung

Attribut-Verwendungen beziehen sich auf alle Verwendungen von <attribute>, die ein use-Attribut gestatten. Dies bezieht sich wiederum in jedem Fall auf zwei Komponenten, eine Attribut-Verwendung und die {Attribut-Deklaration} des Attributs (obwohl Letztere nicht neu ist, wenn die Attribut-Verwendung eine Referenz auf eine Attribut-Deklaration der obersten Ebene ist). Die entsprechende Abbildung ist in XML-Darstellung der Schemakomponente Attribut-Deklaration (§3.2.2) beschrieben.

3.5.3 Bedingungen an die XML-Darstellung der Attribut-Verwendungs-Komponente

Keine.

3.5.4 Validierungsregeln für Attribut-Verwendungen

Validierungsregel: lokal gültiges Attribut (Verwendung)

Damit eine Attribut-Informationseinheit gültig in Bezug auf eine Attribut-Verwendung ist, muss ihr normalisierter Wert mit der kanonisch lexikalischen Repräsentation des Wertes der {Wertebereich-Beschränkung} der Attribut-Verwendung übereinstimmen, falls er vorhanden und fixed ist.

3.5.5 Beiträge von Attribut-Verwendungen zum XML-Information-Set

Keine.

3.5.6 Bedingungen an die Schemakomponente Attribut-Verwendung

Alle Attribut-Verwendungen (siehe Attribut-Verwendungen (§3.5)) müssen die folgenden Bedingungen erfüllen:

Bedingung an Schemakomponente: Attribut-Verwendung

Alle folgenden Aussagen müssen wahr sein:

1 Die Eigenschaftswerte einer Attribut-Verwendung müssen wie in der Eigenschaftstabelle, beschrieben in Die Schemakomponente Attribut-Verwendung (§3.5.1), sein, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

2 Falls die {Attribut-Deklaration} eine {Wertebereich-Beschränkung} fixed hat und falls die Attribut-Verwendung eine {Wertebereich-Beschränkung} hat, muss diese auch fixed sein und ihr Wert muss mit der {Wertebereich-Beschränkung} der {Attribut-Deklaration} übereinstimmen.

3.6 Attributgruppen-Definitionen

3.6.1 Die Schemakomponente Attributgruppen-Definition

3.6.2 XML-Darstellung der Schemakomponente Attributgruppen-Definition

3.6.3 Bedingungen an die XML-Darstellung von Attributgruppen-Definitionen

3.6.4 Validierungsregeln für Attributgruppen-Definitionen

3.6.5 Beiträge von Attributgruppen-Definitionen zum XML-Information-Set

3.6.6 Bedingungen an die Schemakomponente Attributgruppen-Definition

Ein Schema kann eine Gruppe von Attribut-Deklarationen benennen, so dass sie als Gruppe in komplexe Typdefinitionen integriert werden dürfen. Attributgruppen-Definitionen nehmen nicht an der Validierung als solche teil, vielmehr dürfen die {Attribut-Verwendungen} und {Attribut-Wildcards} einer oder mehrerer komplexer Typdefinitionen ganz oder teilweise mittels Referenz auf eine Attributgruppe konstruiert werden. Folglich bieten Attributgruppen-Definitionen die Ablösung einiger Verwendungen der XML-Funktionalität Parameter-Entity. Attributgruppen-Definitionen werden primär zur Referenz aus der XML-Darstellung von Schemakomponenten (siehe <complexType> und <attributeGroup>) bereitgestellt

Beispiel

<xs:attributeGroup name="meineAttributGruppe">
    <xs:attribute . . ./>
    . . .
</xs:attributeGroup>

<xs:complexType name="meinElement">
    . . .
    <xs:attributeGroup ref="meineAttributGruppe"/>
</xs:complexType>

XML-Darstellung für Attributgruppen-Definition. Der Effekt ist so, als wären die Attribut-Deklarationen der Gruppe innerhalb der Typ-Definition.

3.6.1 Die Schemakomponente Attributgruppen-Definition

Die Attributgruppen-Definition für Schemakomponenten hat folgende Eigenschaften:

Schemakomponente: Attributgruppen-Definition

{Name}: Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}: Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Attribut-Verwendung}: Eine Menge von "use"-Attributen.
{Wildcard-Attribut}: Optional: eine Wildcard.
{Anmerkung}: Optional: eine Anmerkung.

Attributgruppen werden nach ihrem {Namen} und {Ziel-Namensraum} definiert; Attributgruppen-Identitäten müssen innerhalb eines XML Schemas eindeutig sein. Siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) hinsichtlich der Verwendung von Komponenten-Bezeichnern beim Import eines Schemas in ein anderes.

{Attribut-Verwendungen} sind eine Menge von Attributverwendungen, die eine lokale Spezifikation von Vorkommen und Default- oder festen Werten erlauben.

{Attribut-Wildcard} bietet eine Attribut-Wildcard für die Einbeziehung in eine Attributgruppe. Siehe Definition komplexer Typen (§3.4) (§3.4) hinsichtlich der Interpretation von Attribut-Wildcards während der Validierung.

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

3.6.2 XML-Darstellung der Schemakomponente Attributgruppen-Definition

Die XML-Darstellung einer Attributgruppen-Definition für Schemakomponenten ist eine Element-Informationseinheit <attributeGroup>. Sie bietet die Benennung einer Gruppe von Attribut-Deklarationen und eine Attribut-Wildcard zur Verwendung als Referenz in der XML-Darstellung komplexer Typdefinitionen und anderer Attributgruppen-Definitionen. Die Entsprechungen zwischen den Eigenschaften der Informationseinheiten und den Eigenschaften der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit attributeGroup

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

Wenn eine <attributeGroup> als Kindelement von <schema> oder <redefine> erscheint, entspricht sie einer Attributgruppen-Definition (siehe unten). Wenn sie als Tochter von <complexType> oder <attributeGroup> erscheint, entspricht sie keiner Komponente als solche.

Schemakomponente Attribute Group Definition

Eigenschaft	Darstellung
{Name}	Der tatsächliche Wert von `name` [attribute]
{Ziel-Namensraum}	Der tatsächliche Wert von `targetNamespace` [Attribut] der `schema` Elternelement-Informationseinheit.
{Attribut-Verwendung}	Die Vereinigung der Menge der Attributverwendungen, die zu den <attribute>-[Kindelementen] gehören, soweit vorhanden, wobei die {Attribut-Verwendung}en der Attributgruppen mittels des tatsächlichen Wertes des `ref`-[Attributs] der <attributeGroup>-[Kindelemente] aufgelöst werden, falls vorhanden.
{Wildcard-Attribut}	vollständige Wildcard, gemäß Definition in XML-Darstellung der komplexen Typdefinition (§3.4.2).
{Anmerkung}	Die Anmerkung, die der Element-Informationseinheit <annotation> in den [Kindelementen] entspricht, falls vorhanden; andernfalls nicht verwendet.

Das obige Beispiel illustriert ein Muster, das in der XML-Darstellung von Schemata wiederholt vorkommt: Das gleiche Element, in diesem Fall Attributgruppe, dient sowohl der Definition als auch der Einbeziehung nach Referenz. Im ersten Fall wird das Attribut name benötigt, im zweiten das Attribut ref, und zusätzlich muss das Element leer sein. Diese beiden Bedingungen schließen sich gegenseitig aus und hängen auch vom Kontext ab: Die definierende Form mit name muss auf der obersten Ebene eines Schemas vorkommen, während die referenzierende Form ref innerhalb einer komplexen Typdefinition oder einer Attributgruppen-Definition vorkommen muss.

3.6.3 Bedingungen an die XML-Darstellung von Attributgruppen-Definitionen

Bedingung an Schema-Darstellung: korrekte Darstellung der Attributgruppen-Definition

Zusätzlich zu den Bedingungen, die <attributeGroup>-Element-Informationseinheiten durch das Schema für Schemata auferlegt werden, müssen alle folgenden Aussagen wahr sein:

1 Die entsprechende Attributgruppen-Definition, falls vorhanden, muss die Bedingungen in Bedingungen an die Schemakomponente Attributgruppen-Definition (§3.6.6) erfüllen.

2 Wenn Klausel 2.1 oder Klausel 2.2 in der entsprechenden Spezifikation XML-Darstellung der komplexen Typdefinition (§3.4.2) für das oben beschriebene {Attribut-Wildcard} erfüllt wird, muss die intensionale Schnittmenge gemäß Definition in Wildcard-Attribut-Schnitt (§3.10.6) ausdrückbar sein.

3 Eine zirkuläre Gruppenreferenz ist außerhalb von <redefine> nicht zulässig. Das heißt, sofern das Elternteil dieser Element-Informationseinheit nicht <redefine> ist, darf in den [Kindelementen], falls vorhanden, keine <attributeGroup> mit ref-[Attribut] sein, das sich in die Komponente entsprechend dieser <attributeGroup> auflösen lässt.

3.6.4 Validierungsregeln für Attributgruppen-Definitionen

Keine.

3.6.5 Beiträge von Attributgruppen-Definitionen zum XML-Information-Set

Keine.

3.6.6 Bedingungen an die Schemakomponente Attributgruppen-Definition

Alle Attributgruppen-Definitionen (siehe Attributgruppen-Definitionen (§3.6)) müssen die folgende Regel erfüllen:

Bedingung an Schemakomponente: Eigenschaften der Attributgruppen-Definition

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften einer Attributgruppen-Definition müssen so sein, wie in der Eigenschaftsaufstellung in Die Schemakomponente Attributgruppen-Definition (§3.6.1) beschrieben, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

2 Zwei getrennte Mitglieder der {Attribut-Verwendung} dürfen keine {Attribut-Deklaration}en haben, deren {Name}n gleich sind und deren Ziel-Namensräume identisch sind.

3 Zwei getrennte Mitglieder der {Attribut-Verwendung} dürfen keine {Attribut-Deklaration}en haben, deren {Typdefinition} ID ist oder daraus abgeleitet wurde.

3.7 Elementgruppen-Definitionen

3.7.1 Die Schemakomponente Elementgruppen-Definition

3.7.2 XML-Darstellung der Schemakomponente Elementgruppen-Definition

3.7.3 Bedingungen an die XML-Darstellung von Elementgruppen-Definitionen

3.7.4 Validierungsregeln für Elementgruppen-Definitionen

3.7.5 Beiträge von Elementgruppen-Definitionen zum XML-Information-Set

3.7.6 Bedingungen an die Schemakomponente Elementgruppen-Definition

Eine Elementgruppen-Definition assoziiert einen Namen und optionale Anmerkungen mit einer Elementgruppe (§2.2.3.1). Durch Referenz auf den Namen kann die gesamte Elementgruppe nach Referenz in XML-Darstellung der komplexen Typdefinition (§3.4.2) eingebunden werden.

Elementgruppen-Definitionen werden primär zur Referenz von der XML-Darstellung komplexer Typdefinitionen (§3.4.2) (siehe <complexType> und <group>) bereitgestellt. Folglich bieten Elementgruppen-Definitionen die Ablösung einiger Verwendungen der XML-Funktionalität Parameter-Entity.

Beispiel

<xs:group name="meineElementgruppe">
 <xs:sequence>
  <xs:element ref="Irgendetwas"/>
  . . .
 </xs:sequence>
</xs:group>

<xs:complexType name="EinfacheVerwendung">
 <xs:group ref="meineElementgruppe"/>
 <xs:attribute .../>
</xs:complexType>

<xs:complexType name="ErweiterteVerwendung">
 <xs:choice>
  <xs:element ref="einAnderesElement"/>
  <xs:group ref="meineElementgruppe"/>
 </xs:choice>
 <xs:attribute .../>
</xs:complexType>

Eine minimale Elementgruppe wird definiert und durch Referenz verwendet, zuerst als das gesamte Inhaltsmodell, danach als Alternative innerhalb einer Auswahl.

3.7.1 Die Schemakomponente Elementgruppen-Definition

Die Elementgruppen-Schemakomponente hat die folgenden Eigenschaften:

Schemakomponente: Elementgruppen-Definition

{Name}: Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}: Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Elementgruppe}: Eine Elementgruppe.
{Anmerkung}: Optional: eine Anmerkung.

Elementgruppen-Definitionen werden durch ihren {Namen} und {Ziel-Namensraum} identifiziert; Elementgruppen-Identitäten müssen innerhalb eines XML Schemas eindeutig sein. Siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) hinsichtlich der Verwendung von Komponenten-Bezeichnern beim Import eines Schemas in ein anderes.

Elementgruppen-Definitionen per se nehmen nicht an der Validierung teil, aber der {Term} eines Partikels kann ganz oder teilweise einer Elementgruppe aus einer Elementgruppen-Definition entsprechen. {Elementgruppe} ist die Elementgruppe (§2.2.3.1), für die von der Elementgruppen-Definition ein Name bereitstellt wird.

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

3.7.2 XML-Darstellung der Schemakomponente Elementgruppen-Definition

Die XML-Darstellung für eine Elementgruppen-Definition einer Schemakomponente ist eine Element-Informationseinheit <group>. Sie bietet die Benennung einer Elementgruppe zur Verwendung nach Referenz in der XML-Darstellung komplexer Typdefinitionen und Elementgruppen. Die Entsprechungen zwischen den Eigenschaften der Informationseinheiten und denen der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit group

<group
name = NCName>
Inhalt: (annotation?, (all | choice | sequence))
</group>

Wenn es ein [Attribut] name gibt (in welchem Fall <schema> oder <redefine> der Elternteil der Einheit ist), entspricht die Einheit einer Elementgruppen-Definitionskomponente mit den folgenden Eigenschaften:

Schemakomponente Elementgruppen-Definition

Eigenschaft	Darstellung
{Name}	Der tatsächliche Wert des [Attributs] `name`.
{Ziel-Namensraum}	Der tatsächliche Wert des [Attributs] `targetNamespace` der Elternelement-Informationseinheit `schema`.
{Elementgruppe}	Eine Elementgruppe, die der {Term} eines Partikels ist und die <all>, <choice> oder <sequence> in den [Kindelementen] (es muss eines geben) entspricht.
{Anmerkung}	Die Anmerkung, die der Element-Informationseinheit <annotation> in den [Kindelementen] entspricht, falls vorhanden, andernfalls nicht verwendet.

Andernfalls hat die Einheit ein ref-[Attribut], in welchem Fall es einer Partikelkomponente mit den folgenden Eigenschaften entspricht (sofern nicht minOccurs=maxOccurs=0, in diesem Fall entspricht die Einheit überhaupt keiner Komponente):

Schemakomponente Partikel

Eigenschaft	Darstellung
{minimales Vorkommen}	Der tatsächliche Wert des `minOccurs`-[Attributs], wenn vorhanden; andernfalls `1`.
{maximales Vorkommen}	unbounded, wenn das `maxOccurs`-[Attribut] gleich unbounded ist, andernfalls der tatsächliche Wert des `maxOccurs` [Attributs], falls vorhanden; andernfalls `1`.
{Term}	Die {Elementgruppe} der Elementgruppen-Definition aufgelöst durch den tatsächlichen Wert des `ref`-[Attributs].

Die Bezeichnung dieses Abschnitts ist leicht irreführend, weil der zweite unbenannte obige Fall (mit einem ref und keinem name-Attribut) eigentlich überhaupt keine benannte Elementgruppe, sondern eine Referenz auf eine ist. Man beachte außerdem, dass im ersten (benannten) obigen Fall keine Referenz auf minOccurs oder maxOccurs gemacht wird. Dies liegt daran, dass das Schema für Schemata kein Kindelement von <group> erlaubt, wenn es benannt ist. Der Grund ist, dass {minimales Vorkommen} und {maximales Vorkommen} der Partikel zählen, die die Definition referenzieren.

Angesichts der Einschränkungen auf ihr Erscheinen in Inhaltsmodellen sollte ein <all> nur als der einzige Teil in [Kindelemente] einer benannten Elementgruppen-Definition oder eines Inhaltsmodells vorkommen: siehe Bedingungen an die Schemakomponente Elementgruppe (§3.8.6).

3.7.3 Bedingungen an die XML-Darstellung von Elementgruppen-Definitionen

Bedingung an Schema-Darstellung: korrekte Darstellung der Elementgruppen-Definition

Zusätzlich zu den Bedingungen, die <group>-Element-Informationseinheiten vom Schema für Schemata auferlegt werden, muss die entsprechende Elementgruppen-Definition, falls vorhanden, die Bedingungen in Bedingungen an die Schemakomponente Elementgruppe (§3.8.6) erfüllen.

3.7.4 Validierungsregeln für Elementgruppen-Definitionen

Keine.

3.7.5 Beiträge von Elementgruppen-Definitionen zum XML-Information-Set

Keine.

3.7.6 Bedingungen an die Schemakomponente Elementgruppen-Definition

Alle Elementgruppen-Definitionen (siehe Elementgruppen-Definitionen (§3.7)) müssen die folgende Bedingung erfüllen.

Bedingung an Schemakomponente: Eigenschaften der Elementgruppen-Definition

Die Werte der Eigenschaften einer Elementgruppen-Definition müssen so sein, wie in der Eigenschaftsaufstellung in Die Schemakomponente Elementgruppen-Definition (§3.7.1) beschrieben, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

3.8 Elementgruppen

3.8.1 Die Schemakomponente Elementgruppe

3.8.2 XML-Darstellung der Schemakomponente Elementgruppe

3.8.3 Bedingungen an die XML-Darstellung von Elementgruppen

3.8.4 Validierungsregeln für Elementgruppen

3.8.5 Beiträge von Elementgruppen zum XML-Information-Set

3.8.6 Bedingungen an die Schemakomponente Elementgruppe

Wenn die [Kindelemente] von Element-Informationseinheiten nicht auf leer oder die Referenz auf eine einfache Typdefinition (Definition einfacher Typen (§3.14)) eingeschränkt sind, darf die Folge des Inhalts von [Kindelement]-Informationseinheiten ausführlicher mit einer Elementgruppe spezifiziert werden. Da die Eigenschaft {Term} eines Partikels eine Elementgruppe sein kann und Elementgruppen Partikel enthalten, können Elementgruppen indirekt andere Elementgruppen enthalten; die Grammatik für Inhaltsmodelle ist deshalb rekursiv.

Beispiel

<xs:all>
 <xs:element ref="Katzen"/>
 <xs:element ref="Hunde"/>
</xs:all>

<xs:sequence>
 <xs:choice>
  <xs:element ref="Links"/>
  <xs:element ref="Rechts"/>
 </xs:choice>
 <xs:element ref="Markierung"/>
</xs:sequence>

XML-Darstellungen für die drei Arten von Elementgruppen, die dritte ist innerhalb der zweiten geschachtelt.

3.8.1 Die Schemakomponente Elementgruppe

Die Elementgruppe hat die folgenden Eigenschaften:

Schemakomponente: Elementgruppe

{Verbund}: Entweder all, choice oder sequence.
{Partikel}: Eine Partikelliste.
{Anmerkung}: Optional: eine Anmerkung.

{Verbund} spezifiziert eine sequentielle (sequence), disjunktive (choice) oder konjunktive (all) Interpretation der {Partikel}. Dies bestimmt wiederum, ob die von der Elementgruppe validierte Element-Informationseinheit [Kindelemente] folgendes erfüllen muss:

(sequence) muss dem spezifizierten {Partikel} in der angegebenen Reihenfolge entsprechen
(choice) muss genau einem der spezifizierten {Partikel} entsprechen
(all) muss alle Elemente und nur genau null oder eines von jedem in {Partikel} spezifizierten Element enthalten. Die Elemente können in jeder Reihenfolge auftreten. Um die Komplexität der Implementierung zu reduzieren, wird {Partikel} in diesem Fall so eingeschränkt, dass es nur lokale und Element-Deklarationen der obersten Ebene enthält, wobei {minimales Vorkommen} =0 oder 1, {maximales Vorkommen} =1.

Wenn zwei oder mehr Partikel, die direkt oder indirekt in {Partikel} einer Elementgruppe enthalten sind, identisch benannte Element-Deklarationen als ihren {Term} haben, müssen die Typdefinitionen dieser Deklarationen gleich sein. Mit „indirekt“ sind Partikel innerhalb der {Partikel} einer Gruppe gemeint, die selbst der {Term} eines direkt enthaltenen Partikels sind und rekursiv so weiter.

Siehe Anmerkungen (§3.13) hinsichtlich Informationen über die Rolle der Eigenschaft {Anmerkung}.

3.8.2 XML-Darstellung der Schemakomponente Elementgruppe

Die XML-Darstellung einer Elementgruppen-Schemakomponente ist entweder eine <all>-, <choice>- oder <sequence>-Element-Informationseinheit. Die Entsprechungen zwischen den Eigenschaften dieser Informationseinheiten und denen der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit all

<all
id = ID
maxOccurs = 1 : 1
minOccurs = (0 | 1) : 1
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, element*)
</all>

<choice
id = ID
maxOccurs = ( | unbounded) : 1
minOccurs = nonNegativeInteger : 1
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (element | group | choice | sequence | any)*)
</choice>

<sequence
id = ID
maxOccurs = ( | unbounded) : 1
minOccurs = nonNegativeInteger : 1
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (element | group | choice | sequence | any)*)
</sequence>

Jedes der oben aufgeführten Elemente entspricht einem Partikel, das eine Elementgruppe enthält, deren Eigenschaften die folgenden sind (solange nicht minOccurs=maxOccurs=0, in diesem Fall entspricht das Element überhaupt keiner Komponente):

Schemakomponente Partikel

Eigenschaft	Darstellung
{minimales Vorkommen}	Der tatsächliche Wert des `minOccurs`-[Attributes], wenn vorhanden, andernfalls `1`.
{maximales Vorkommen}	unbounded, wenn das `maxOccurs`-[Attribut] gleich unbounded ist; andernfalls der tatsächliche Wert des `maxOccurs`-[Attributes], falls vorhanden; andernfalls `1`.
{Term}	Eine Elementgruppe, wie untenstehend angegeben.

Schemakomponente Elementgruppe

Eigenschaft	Darstellung
{Verbund}	Eines von all, choice, sequence, je nach Element-Informationseinheit.
{Partikel}	Eine Folge von Partikeln, die allen <all>-, <choice>-, <sequence>-, <any>-, <group>- oder <element>-Elementen in den [Kindelementen] in dieser Reihenfolge entsprechen.
{Anmerkung}	Die Anmerkung, die der Element-Informationseinheit <annotation> in den [Kindelementen] entspricht, falls vorhanden; andernfalls nicht verwendet.

3.8.3 Bedingungen an die XML-Darstellung von Elementgruppen

Bedingung an Schema-Darstellung: Darstellung der Elementgruppe

Zusätzlich zu den Bedingungen, die den Element-Informationseinheiten <all>, <choice> und <sequence> durch das Schema für Schemata auferlegt werden, müssen die entsprechenden Partikel und die Elementgruppe die Bedingungen in Bedingungen an die Schemakomponente Elementgruppe (§3.8.6) und Bedingungen an die Schemakomponente Partikel (§3.9.6) erfüllen.

3.8.4 Validierungsregeln für Elementgruppen

Validierungsregel: gültige Elementfolge

[Definition:] Definiere eine Partition eine Folge als eine Folge von Teilfolgen, von denen einige oder alle leer sein dürfen, so dass die Verkettung aller Teilfolgen die Originalfolge ergibt.

Damit eine (möglicherweise leere) Folge von Element-Informationseinheiten hinsichtlich einer Elementgruppe lokal gültig sein kann, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls der {Verbund} sequence ist , dann muss es eine Partition der Folge in n Teilfolgen geben, wobei n die Länge von {Partikel} ist, so dass jede Teilfolge in der Reihenfolge hinsichtlich der entsprechenden Partikel in {Partikel} gemäß Definition in lokal gültige Element-Folge (Partikel) (§3.9.4) lokal gültig ist.

2 Falls der {Verbund} choice ist, dann muss es in {Partikel} ein Partikel geben, so dass die Folge gültig ist hinsichtlich der entsprechenden Partikel gemäß Definition in lokal gültige Element-Folge (Partikel) (§3.9.4).

3 Falls der {Verbund} all ist, dann muss es eine partition der Folge in n Teilfolgen geben, wobei n die Länge von {Partikel} ist, so dass es eine Eins-zu-Eins-Abbildung zwischen den Teilfolgen und {Partikel} gibt, wobei jede Teilfolge bezüglich des entsprechenden Partikel gültig gemäß Definition in lokal gültige Element-Folge (Partikel) (§3.9.4) ist.

Nichts in der obigen Definition sollte so verstanden werden, dass Gruppen ausgeschlossen sind, deren {Partikel} leer ist, obwohl keine Folge hinsichtlich einer solchen Gruppe gültig sein kann, deren {Verbund} choice ist; vielmehr ist die leere Folge hinsichtlich leerer Gruppen, deren {Verbund} sequence oder all ist, gültig.

Anmerkung:

Die obige Definition ist implizit nicht deterministisch und sollte nicht als Rezept für Implementierungen verwendet werden. Man beachte insbesondere: Wenn {Verbund} all ist, dann sind die Partikel auf eine Liste mit lokalen Element-Deklarationen und Element-Deklarationen der obersten Ebene beschränkt (siehe Bedingungen an die Schemakomponente Elementgruppe (§3.8.6)). Im Vergleich zu einer Implementierung, die aus einer wörtlichen Interpretation der obigen Definition entstehen würde, ist eine viel einfachere Implementierung möglich. Informell ist der Inhalt gültig, wenn jedes deklarierte Element genau einmal (oder höchstens einmal, wenn {minimales Vorkommen} 0 ist) vorkommt und jedes hinsichtlich seiner entsprechenden Deklaration gültig ist. Die Elemente können in einer beliebigen Reihenfolge vorkommen.

3.8.5 Beiträge von Elementgruppen zum XML-Information-Set

Keine.

3.8.6 Bedingungen an die Schemakomponente Elementgruppe

Alle Elementgruppen (siehe Elementgruppen (§3.8)) müssen die folgenden Bedingungen erfüllen:

Bedingung an Schemakomponente: Elementgruppe

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften einer Elementgruppe müssen so sein, wie in der Eigenschaftsaufstellung in Die Schemakomponente Elementgruppe (§3.8.1) beschrieben, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

2 Zirkuläre Gruppen sind nicht zulässig. Das heißt, innerhalb der {Partikel} einer Gruppe darf es nirgends und auf keiner Ebene ein Partikel geben, dessen {Term} die Gruppe selbst ist.

Bedingung an Schemakomponente: Einschränkungen der 'All'-Gruppe

Wenn eine Elementgruppe einen {Verbund} all hat, müssen alle folgenden Aussagen wahr sein:

1 Eine der folgenden Aussagen muss wahr sein:

1.1 Sie erscheint als die Elementgruppe einer Elementgruppen-Definition.

1.2 Sie erscheint in einem Partikel mit {minimales Vorkommen} = {maximales Vorkommen} =1 und dieses Partikel muss Teil eines Paares sein, das den {Inhaltstyp} einer komplexen Typdefinition bildet.

2 Die Eigenschaft {maximales Vorkommen} aller Partikel in den {Partikeln} der Gruppe muss 0 oder 1 sein.

Bedingung an Schemakomponente: konsistente Element-Deklarationen

Wenn {Partikel} entweder direkt, indirekt (d.h. rekursiv innerhalb von {Partikel} einer enthaltenen Elementgruppe) oder implizit zwei oder mehr Element-Deklarationspartikel mit dem gleichen {Name}n und {Ziel-Namensraum} enthält, dann müssen alle ihre Typdefinitionen die gleiche Definition der obersten Ebene sein, d.h. müssen alle folgenden Aussagen wahr sein:

1 Alle ihre {Typdefinition}en dürfen nicht einen Namen mit Wert nicht verwendet haben.

2 Alle ihre {Typdefinition}en müssen den gleichen Namen haben.

3 Alle ihre {Typdefinition}en müssen den gleichen Ziel-Namensraum haben.

[Definition:] Eine Liste mit Partikeln enthält implizit eine Element-Deklaration, wenn ein Mitglied der Liste diese Element-Deklaration in seiner Ersetzungsgruppe enthält.

Bedingung an Schemakomponente: Eindeutige Partikel-Zuordnung

Ein Inhaltsmodell muss so gebildet werden, dass während der Validierung einer Folge von Element-Informationseinheiten die direkt, indirekt oder implizit darin enthaltenen Partikel, mit denen die Validierung jedes Elements der Folge nacheinander versucht wird, eindeutig bestimmt werden können, ohne den Inhalt oder Attribute des jeweiligen Folgen-Elements zu prüfen, und ohne jegliche Informationen über Elemente im Rest der Folge.

Anmerkung:

Diese Einschränkung rekonstruiert die entsprechenden Einschränkungen der XML-Schemata von [XML 1.0 (Second Edition)] und SGML. Angesichts der Präsenz von Elementersetzungsgruppen und Wildcards ist der knappe Ausdruck dieser Einschränkung schwierig; siehe Analyse der Einschränkung eindeutiger Partikel-Zuordnung (nicht-normativ) (§H).

Anmerkung:

Da lokale Element-Deklarationen möglicherweise einen {Ziel-Namensraum} haben, ist der Bereich von Deklarationen nicht relevant, um eine der beiden vorstehenden Einschränkungen zu erzwingen.

Bedingung an Schemakomponente: Tatsächlicher Gesamtbereich (all und sequence)

Der effektive Gesamtbereich eines Partikels, dessen {Term} eine Gruppe ist, deren {Verbund} all oder sequence ist, ist ein Paar aus Minimum und Maximum wie folgt:

minimum: Das Produkt der {minimales Vorkommen}-Eigenschaft des Partikel und die Summe von {minimales Vorkommen} jedes Wildcard- oder Element-Deklarationspartikels in {Partikel} der Gruppe und der Minimumteil des effektiven Gesamtbereichs jedes Gruppenpartikels in {Partikel} (oder 0, falls es keine {Partikel} gibt).
maximum: unbounded, wenn {maximales Vorkommen} einer Wildcard oder eines Element-Deklarationspartikels in {Partikel} der Gruppe oder dem maximalen Teil des effektiven Gesamtbereichs eines Gruppenpartikels in den {Partikeln} der Gruppe unbounded ist oder wenn eine davon nicht Null und {maximales Vorkommen} des Partikels unbounded ist; andernfalls das Produkt aus {maximales Vorkommen} des Partikels und dem Maximum der {maximales Vorkommen} jeder Wildcard oder jedes Element-Deklarationspartikels in den {Partikeln} der Gruppe und der maximale Teil des effektiven Gesamtbereichs jedes Gruppenpartikels in {Partikel} der Gruppe (oder 0, wenn es keine {Partikel} gibt).

Bedingung an Schemakomponente: Tatsächlicher Gesamtbereich (choice)

Der effektive Gesamtbereich eines Partikels, dessen {Term} eine Gruppe ist, deren {Verbund} choice ist, ist ein Paar aus Minimum und Maximum wie folgt:

minimum: Das Produkt der {minimales Vorkommen}-Eigenschaft von Partikel und des Minimums von {minimales Vorkommen} jeder Wildcard oder jedes Element-Deklarationspartikels in {Partikel} der Gruppe und der Minimumteil des effektiven Gesamtbereichs jedes Gruppenpartikels in {Partikel} der Gruppe (oder 0, wenn es keine {Partikel} gibt).
maximum: unbounded, wenn {maximales Vorkommen} eines Wildcard- oder Element-Deklarationspartikels in {Partikel} der Gruppe oder der Maximumteil des effektiven Gesamtbereichs eines Gruppenpartikels in {Partikel} der Gruppe unbounded ist oder wenn eine davon nicht Null ist und {maximales Vorkommen} des Partikels unbounded ist; andernfalls das Produkt aus {maximales Vorkommen} des Partikels und dem Maximum von {maximales Vorkommen} jedes Wildcard- oder Element-Deklarationspartikels in {Partikel} der Gruppe und der Maximumteil des effektiven Gesamtbereichs jedes Gruppenpartikels in {Partikel} der Gruppe (oder 0, wenn es keine {Partikel} gibt).

3.9 Partikel

3.9.1 Die Schemakomponente Partikel

3.9.2 XML-Darstellung von Partikel-Komponenten

3.9.3 Bedingungen an die XML-Darstellungen von Partikeln

3.9.4 Validierungsregeln für Partikel

3.9.5 Beiträge von Partikeln zum XML-Information-Set

3.9.6 Bedingungen an die Schemakomponente Partikel

Wie in Elementgruppen (§3.8) beschrieben, tragen Partikel zur Definition von Inhaltsmodellen bei.

Beispiel

<xs:element ref="Ei" minOccurs="12" maxOccurs="12"/>

<xs:group ref="Omelett" minOccurs="0"/>

<xs:any maxOccurs="unbounded"/>

XML-Darstellungen, die Partikel verwenden, zeigen einige Möglichkeiten, das Erscheinen der Elemente zu kontrollieren.

3.9.1 Die Schemakomponente Partikel

Die Schemakomponente Partikel hat die folgenden Eigenschaften:

Schemakomponente: Partikel

{minimales Vorkommen}: Ein nicht-negativer Integer.
{maximales Vorkommen}: Entweder ein nicht-negativer Integer oder unbounded.
{Term}: Entweder eine Elementgruppe, eine Wildcard oder eine Element-Deklaration.

Im Allgemeinen können mehrere [Kind]-Element-Informationseinheiten, möglicherweise mit intervenierendem Charakter der [Kindelemente], wenn der Inhaltstyp gemischt ist, in Bezug auf ein einziges Partikel validiert werden. Wenn der {Term} eine Element-Deklaration oder eine Wildcard ist, bestimmt {minimales Vorkommen} die Mindestzahl dieser [Kindelemente]-Elemente, die vorkommen kann. Die Zahl solcher Kindelemente muss größer als oder gleich {minimales Vorkommen} sein. Wenn {minimales Vorkommen} 0 ist, dann ist das Vorkommen solcher Kindelemente optional.

Wenn der {Term} eine Element-Deklaration oder eine Wildcard ist, muss die Anzahl dieser [Kindelemente]-Elemente kleiner als oder gleich der numerischen Spezifikation von {maximales Vorkommen} sein; wenn {maximales Vorkommen} ungebunden ist, gibt es keine obere Grenze hinsichtlich der Anzahl solcher Kindelemente.

Wenn {Term} eine Elementgruppe ist, wird der zulässige Vorkommensbereich durch eine Kombination von {minimales Vorkommen} und {maximales Vorkommen} und den Vorkommensbereichen von {Partikel} des {Terms} bestimmt.

3.9.2 XML-Darstellung von Partikel-Komponenten

Partikel entsprechen allen drei Elementen (<element> nicht unmittelbar innerhalb von <schema>, <group> nicht unmittelbar innerhalb von <schema> und <any>), so dass minOccurs- und maxOccurs-Attribute erlaubt sind. Diese entsprechen wiederum den beiden Komponenten in jedem Fall, d.h. einem Partikel und seinem {Term}. Die entsprechende Abbildung ist in XML-Darstellung der Schemakomponente Element-Deklaration (§3.3.2), XML-Darstellung der Schemakomponente Elementgruppe (§3.8.2) bzw. XML-Darstellung der Schemakomponente Wildcard (§3.10.2) beschrieben.

3.9.3 Bedingungen an die XML-Darstellungen von Partikeln

Keine.

3.9.4 Validierungsregeln für Partikel

Validierungsregel: lokal gültige Element-Folge (Partikel)

Damit eine Folge von (möglicherweise leeren) Element-Informationseinheiten hinsichtlich eines Partikels lokal gültig sein kann, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls der {Term} eine Wildcard ist, dann müssen alle folgenden Aussagen wahr sein:

1.1 Die Länge der Folge muss größer oder gleich {minimales Vorkommen} sein.

1.2 Wenn {maximales Vorkommen} eine Zahl ist, muss die Länge der Folge kleiner oder gleich {maximales Vorkommen} sein.

1.3 Jede Element-Informationseinheit in der Folge muss in Bezug auf die Wildcard gemäß Definition in gültige Informationseinheit (Wildcard) (§3.10.4) gültig sein.

2 Falls {Term} eine Element-Informationseinheit ist, dann müssen alle folgenden Aussagen wahr sein:

2.1 Die Länge der Folge muss größer oder gleich {minimales Vorkommen} sein.

2.2 Wenn {maximales Vorkommen} eine Zahl ist, muss die Länge der Folge kleiner oder gleich {maximales Vorkommen} sein.

2.3 Für jede Element-Informationseinheit in der Folge muss eine der folgenden Aussagen wahr sein:

2.3.1 Die Element-Deklaration ist lokal (d.h. ihr {Gültigkeitsbereich} darf nicht global sein), ihre Eigenschaft {abstrakt} ist false, der [Namensraum-Name] ist identisch mit dem {Ziel-Namensraum} (wobei ein abwesender {Ziel-Namensraum} als identisch mit einem [Namensraum-Name] ohne Wert angenommen wird) und der [lokale Name] der Element-Informationseinheit passt zur Eigenschaft {Name} der Element-Deklaration.

In diesem Fall ist die Element-Deklaration die kontextbestimmte Deklaration für die Element-Informationseinheit hinsichtlich Die Schemagültigkeitsprüfung (Element) (§3.3.4) und Ergebnis des Validierungsprozesses (Element) (§3.3.5).

2.3.2 Die Element-Deklaration ist eine der obersten Ebene (d.h. ihr {Gültigkeitsbereich} ist global), {abstrakt} ist false, der [Namensraum-Name] der Element-Informationseinheit ist identisch mit dem {Ziel-Namensraum} der Element-Deklaration (wobei ein abwesender {Ziel-Namensraum} als identisch mit einem [Namensraum-Name] ohne Wert angenommen wird) und der [lokale Name] passt zur Eigenschaft {Name} der Element-Deklaration.

In diesem Fall ist die Element-Deklaration die kontextbestimmte Deklaration für die Element-Informationseinheit bezüglich Die Schemagültigkeitsprüfung (Element) (§3.3.4) und Ergebnis des Validierungsprozesses (Element) (§3.3.5).

2.3.3 Die Element-Deklaration ist eine der obersten Ebene (d.h. ihr {Gültigkeitsbereich} ist global), ihre Eigenschaft {Nicht erlaubte Ersetzungen} enthält keine Ersetzung, der [lokale Name] und [Namensraum-Name] der Element-Informationseinheit lösen in eine Element-Deklaration auf, gemäß Definition in QName-Auflösung (Instanz) (§3.15.4) - [Definition:] Wir nennen diese Deklaration die ersetzende Deklaration ; die ersetzende Deklaration zusammen mit {Nicht erlaubte Ersetzungen} der Element-Deklaration des Partikels ist durch die Element-Deklaration des Partikels gültig substituierbar, gemäß Definition in korrekte Ersetzungsgruppe (Transitiv) (§3.3.6).

In diesem Fall ist die ersetzende Deklaration die kontextbestimmte Deklaration für die Element-Informationseinheit bezüglich Die Schemagültigkeitsprüfung (Element) (§3.3.4) und Ergebnis des Validierungsprozesses (Element) (§3.3.5).

3 Falls {Term} eine Elementgruppe ist, dann müssen alle folgenden Aussagen wahr sein:

3.1 Es gibt einePartition der Folge in n Teilfolgen, so dass n größer gleich {minimales Vorkommen} ist.

3.2 Wenn {maximales Vorkommen} eine Zahl ist, muss n kleiner oder gleich {maximales Vorkommen} sein.

3.3 Jede Teilfolge in der Partition ist hinsichtlich dieser Elementgruppe gültig gemäß Definition in gültige Elementfolge (§3.8.4).

Anmerkung:

Klausel 1 und Klausel 2.3.3 interagieren nicht: Eine durch eine Deklaration mit einem Kopf einer Ersetzungsgruppe in einem anderen Namensraum validierbare Element-Informationseinheit ist nicht von einer Wildcard validierbar, die den Namensraum des Kopfes, aber nicht seinen eigenen akzeptiert

3.9.5 Beiträge von Partikeln zum XML-Information-Set

Keine

3.9.6 Bedingungen an die Schemakomponente Partikel

Alle Partikel (siehe Partikel (§3.9)) müssen die folgenden Bedingungen erfüllen:

Bedingung an Schemakomponente: Partikel

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften eines Partikels müssen der Beschreibung in der Eigenschaftsaufstellung in Die Schemakomponente Partikel (§3.9.1) entsprechen, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

2 Wenn {maximales Vorkommen} nicht unbounded ist, d.h. einen numerischen Wert hat, dann müssen alle folgenden Aussagen wahr sein:

2.1 {minimales Vorkommen} darf nicht größer als {maximales Vorkommen} sein.

2.2 {maximales Vorkommen} muss größer oder gleich 1 sein.

Die folgenden Bedingungen definieren Beziehungen, die an anderer Stelle in der Spezifikation von Belang sind.

Bedingung an Schemakomponente: gültige Partikel (Erweiterung)

[Definition:] Damit ein Partikel (man nenne es E, für Erweiterung) eine gültige Erweiterung eines anderen Partikels (man nenne es B, für Basis) sein kann, muss eine der folgenden Aussagen wahr sein:

1 Sie sind das gleiche Partikel.

2 Für E gilt: {minimales Vorkommen}={maximales Vorkommen} =1 und sein {Term} ist eine sequence-Gruppe, deren erstes Mitglied ihrer {Partikel} ein Partikel ist, dessen Eigenschaften allesamt rekursiv mit denen von B identisch sind, mit Ausnahme der {Anmerkung}-Eigenschaften.

Der hier beschriebene Ansatz für die Definition eines Typs durch Beschränkung einer anderen Typdefinition soll sicherstellen, dass Typen, die auf diese Weise definiert wurden, garantiert eine Teilmenge des Typs sind, den sie beschränken. Dies wird durch die Anforderung einer klaren Abbildung zwischen den Komponenten der Basistyp-Definition und der beschränkenden Typdefinition erreicht. Zulässige Abbildungen werden unten in Zusammenhang mit einer Reihe rekursiver Definitionen beschrieben, wobei die offensichtlichen Fälle ausgegrenzt werden, z.B. wenn eine (beschränkte) Element-Deklaration einer anderen (Basis)Element-Deklaration mit gleichem Namen und Typ, jedoch dem gleichen oder einem breiteren Vorkommensbereich entspricht.

Anmerkung:

Der hier beschriebene Ansatz der strukturellen Entsprechung für die Sicherstellung der Teilmengenbeziehung ist umständlich in der Verwendung, hat aber den Vorteil, dass er leicht überprüft werden kann. Die Arbeitsgruppe bittet um Rückmeldungen darüber, wie schwierig dies in der Praxis ist und ob andere realisierbare Ansätze gefunden wurden.

Bedingung an Schemakomponente: gültige Partikel (Einschränkung)

[Definition:] Damit ein Partikel (man nenne es R, für Restriktion [Beschränkung]) eine gültige Beschränkung eines anderen Partikels (man nenne es B, für Basis) ist, muss eine der folgenden Aussagen wahr sein:

1 Sie sind die gleichen Partikel.

2 Je nach Art des Partikels, entsprechend den Qualifikationen in der unten folgenden Tabelle, müssen alle folgenden Aussagen wahr sein:

2.1 Jedes Partikel einer Element-Deklaration der obersten Ebene (in R oder B), welche die {Ersetzungsgruppen-Zugehörigkeit} von einer oder mehreren anderen Element-Deklarationen ist, wird so behandelt, als handle es sich um eine choice-Gruppe, deren {minimales Vorkommen} und {maximales Vorkommen} jene des Partikels sind, und dessen {Partikel} aus einem Partikel mit {minimales Vorkommen} und {maximales Vorkommen} = 1 für die Element-Deklaration der obersten Ebene und für jede Deklaration in ihrer Ersetzungsgruppe besteht.

2.2 Alle überflüssigen Vorkommen von <sequence>, <choice> oder <all> werden ignoriert, wobei 'überflüssig' wie folgt zu verstehen ist:

<sequence>: Eine der folgenden Aussagen muss wahr sein:

2.2.1 {Partikel} ist leer.

2.2.2 Alle folgenden Aussagen müssen wahr sein:

2.2.2.1 Das Partikel, in dem diese <sequence> erscheint, hat {maximales Vorkommen} und {minimales Vorkommen} = 1.

2.2.2.2 Eine der folgenden Aussagen muss wahr sein:

2.2.2.2.1 {Partikel} von <sequence> hat nur ein Mitglied.

2.2.2.2.2 Das Partikel innerhalb dieser <sequence> erscheint, als ob es selbst zur Eigenschaft {Partikel} einer <sequence> gehören würde.
<all>: Eine der folgenden Aussagen muss wahr sein:

2.2.1 {Partikel} ist leer.

2.2.2 {Partikel} hat nur ein Mitglied.
<choice>: Eine der folgenden Aussagen muss wahr sein:

2.2.1 {Partikel} ist leer und das Partikel, das in <choice> erscheint, hat {minimales Vorkommen} = 0.

2.2.2 Alle folgenden Aussagen müssen wahr sein:

2.2.2.1 Das Partikel, in dem <choice> erscheint, hat {maximales Vorkommen} und {minimales Vorkommen} = 1.

2.2.2.2 Eine der folgenden Aussagen muss wahr sein:

2.2.2.2.1 {Partikel} von <choice> hat nur ein Mitglied.

2.2.2.2.2 Das Partikel, in dem dieses <choice> erscheint, befindet sich selbst unter {Partikel} eines <choice>-Konstruktes.

		Basis-Partikel
		elt	any	all	choice	sequence
Abgeleiteter Partikel	elt	NameAnd- TypeOK	NSCompat	Recurse- AsIfGroup	Recurse- AsIfGroup	RecurseAs- IfGroup
	any	Verboten	NSSubset	Verboten	Verboten	Verboten
	all	Verboten	NSRecurse- CheckCardinality	Recurse	Verboten	Verboten
	choice	Verboten	NSRecurse- CheckCardinality	Verboten	RecurseLax	Verboten
	seq- uence	Verboten	NSRecurse- CheckCardinality	Recurse- Unordered	MapAndSum	Recurse

Bedingung an Schemakomponente: korrekter Vorkommensbereich

Damit der Vorkommensbereich eines Partikels eine gültige Beschränkung des Vorkommensbereichs eines anderen sein kann, müssen alle folgenden Aussagen wahr sein:

1 Sein {minimales Vorkommen} ist größer oder gleich {minimales Vorkommen} des anderen.

2 Eine der folgenden Aussagen muss wahr sein:

2.1 {maximales Vorkommen} des anderen Partikels ist unbounded.

2.2 Beide Eigenschaften {maximales Vorkommen} sind Zahlen und die eines Partikels ist kleiner oder gleich der des anderen.

Bedingung an Schemakomponente: korrekte Partikel-Einschränkung (Elt:Elt - NameAndTypeOK)

Damit ein Element-Deklarationspartikel eine gültige Beschränkung eines anderen Element-Deklarationspartikels sein kann, müssen alle folgenden Aussagen wahr sein:

1 {Name} und {Ziel-Namensraum} der Deklarationen sind gleich.

2 Entweder ist {nullwertfähig} von B true oder {nullwertfähig} von R ist false.

3 Rs Vorkommensbereich ist eine gültige Einschränkung von Bs Vorkommensbereich gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

4 Entweder ist die {Wertebereich-Beschränkung} der Deklaration von B nicht vorhanden oder nicht fixed oder die {Wertebereich-Beschränkung} der Deklaration von R ist fixed mit demselben Wert.

5 Die {Identitätsbeschränkungs-Definitionen} der Deklaration von R sind eine Teilmenge der {Identitätsbeschränkungs-Definitionen} der Deklarationen von B, falls vorhanden.

6 Die Eigenschaft {Nicht erlaubte Ersetzungen} der Deklaration von R ist eine Supermenge der Eigenschaft {Nicht erlaubte Ersetzungen} der Deklaration von B.

7 Die {Typdefinition} von R wird gültig über {extension, list, union} von Bs {Typdefinition} abgeleitet, gemäß Definition in korrekte Typ-Ableitung (komplexer Typ) (§3.4.6) oder korrekte Typableitung (einfacher Typ) (§3.14.6), je nach Situation.

Anmerkung:

Die obige Einschränkung einer {Typdefinition} bedeutet, dass bei der Ableitung eines Typs durch Beschränkung eventuell enthaltene Typdefinitionen selbst explizit durch Beschränkung aus den entsprechenden Typdefinitionen der Basisdefinition abgeleitet werden müssen.

Bedingung an Schemakomponente: korrekte Partikel-Ableitung (Elt:Any - NSCompat)

Damit ein Element-Deklarationspartikel eine gültige Einschränkung eines Wildcard-Partikels sein kann, müssen alle folgenden Aussagen wahr sein:

1 Der {Ziel-Namensraum} der Element-Deklaration ist hinsichtlich der {Namensraum-Beschränkung} gültig, gemäß Definition in Wildcard erlaubt Namensraum-Namen (§3.10.4).

2 Rs Vorkommensbereich ist eine gültige Beschränkung von Bs Vorkommensbereich gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

Bedingung an Schemakomponente: korrekte Partikel-Ableitung (Elt:All/Choice/Sequence - RecurseAsIfGroup)

Damit ein Element-Deklarationspartikel eine gültige Beschränkung eines Gruppenpartikels (all, choice oder sequence) sein kann, muss ein Gruppenpartikel in der Variante, die der von B entspricht, mit {minimales Vorkommen} und {maximales Vorkommen} = 1 und mit {Partikel} bestehend aus einem einzigen Partikel, wie die Element-Deklaration eine gültige Beschränkung der Gruppe sein, gemäß Definition in Partikel-Ableitung (All:All,Sequence:Sequence - Recurse) (§3.9.6), Partikel-Ableitung (Choice:Choice - RecurseLax) (§3.9.6) oder Partikel-Ableitung (All:All,Sequence:Sequence - Recurse) (§3.9.6), je nachdem, ob die Gruppe all, choice or sequence ist.

Bedingung an Schemakomponente: korrekte Partikel-Ableitung (Any:Any - NSSubset)

Damit ein Wildcard-Partikel eine gültige Beschränkung eines anderen Wildcard-Partikels sein kann, müssen alle folgenden Aussagen wahr sein:

1 Rs lokaler Vorkommensbereich muss eine gültige Beschränkung des Vorkommensbereichs von B sein, gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

2 Die {Namensraum-Beschränkung} von R muss eine intensionale Schnittmenge der {Namensraum-Beschränkung} von B sein, gemäß Definition in Wildcard-Untermenge (§3.10.6).

Bedingung an Schemakomponente: Partikel-Ableitung (All/Choice/Sequence:Any - NSRecurseCheckCardinality)

Damit ein Gruppenpartikel eine gültige Beschränkung eines Wildcard-Partikels sein kann, müssen alle folgenden Aussagen wahr sein:

1 Jedes Mitglied von {Partikel} der Gruppe ist eine gültige Beschränkung die Wildcard, gemäß Definition in gültige Partikel (Einschränkung) (§3.9.6).

2 Der effektive Gesamtbereich der Gruppe gemäß Definition in Tatsächlicher Gesamtbereich (all und sequence) (§3.8.6) (wenn die Gruppe all oder sequence ist) oder Tatsächlicher Gesamtbereich (choice) (§3.8.6) (wenn es choice ist) ist eine gültige Einschränkung des Vorkommensbereichs von B gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

Bedingung an Schemakomponente: Partikel-Ableitung (All:All,Sequence:Sequence - Recurse)

Damit ein all- oder sequence-Gruppenpartikel eine gültige Beschränkung eines anderen Gruppenpartikels mit demselben {Verbund} sein kann, müssen alle folgenden Aussagen wahr sein:

1 Der Vorkommensbereich von R ist eine gültige Beschränkung des Vorkommensbereiches von B, gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

2 Es gibt eine komplette die Reihenfolge bewahrende Abbildung der Partikel in {Partikel} von R auf die Partikel in {Partikel} von B, so dass alle folgenden Aussagen wahr sein müssen:

2.1 Jedes Partikel in {Partikel} von R ist eine gültige Beschränkung des Partikels in {Partikel} von B, das es abbildet, gemäß Definition in gültige Partikel (Einschränkung) (§3.9.6).

2.2 Alle Partikel in {Partikel} von B, die nicht von einem Partikel in {Partikel} von R abgebildet werden, sind leerbar, gemäß Definition in Partikel leerbar (§3.9.6).

Anmerkung:

Obwohl die Validierungssemantik einer all-Gruppe nicht von der Reihenfolge ihrer Partikel abhängt, sind abgeleitete all-Gruppen erforderlich, die zur Reihenfolge ihrer Basis passen, um die Prüfung der Richtigkeit dieser Ableitung zu vereinfachen.

[Definition:] Eine komplette funktionale Abbildung ist Reihenfolge-bewahrend, wenn jedes Partikel r in der Domäne R auf ein Partikel b im Bereich B abgebildet wird, das dem Partikel (nicht unbedingt unmittelbar) im Bereich B folgt, auf das der Vorgänger von r abgebildet wird, falls vorhanden, wobei „Vorgänger“ und „folgt“ hinsichtlich der Reihenfolge der Listen definiert sind, aus denen sich R und B zusammensetzen.

Bedingung an Schemakomponente: Partikel-Ableitung (Choice:Choice - RecurseLax)

Damit ein choice-Gruppenpartikel eine gültige Beschränkung eines anderen choice-Gruppenpartikels sein kann, müssen alle folgenden Aussagen wahr sein:

1 Der Vorkommensbereich von R ist eine gültige Beschränkung des Vorkommensbereichs von B gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

2 Es gibt eine komplette Reihenfolge bewahrende funktionale Abbildung der Partikel in {Partikel} von R auf die Partikel in {Partikel} von B, so dass jedes Partikel in {Partikel} von R eine gültige Beschränkung des Partikels in {Partikel} von B ist, auf das es abgebildet wird, gemäß Definition in gültige Partikel (Einschränkung) (§3.9.6).

Anmerkung:

Obwohl die Validierungssemantik einer choice-Gruppe nicht von der Reihenfolge ihrer Partikel abhängt, sind abgeleitete choice-Gruppen erforderlich, die zur Reihenfolge ihrer Basis passen, um die Prüfung der Richtigkeit dieser Ableitung zu vereinfachen.

Bedingung an Schemakomponente: korrekte Partikel-Ableitung (Sequence:All - RecurseUnordered)

Damit ein sequence-Gruppenpartikel eine gültige Beschränkung eines all-Gruppenpartikels ist, müssen alle folgenden Aussagen wahr sein:

1 Der Vorkommensbereich von R ist eine gültige Beschränkung des Vorkommensbereichs von B gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

2 Es gibt eine komplette funktionale Abbildung das Partikel in {Partikel} von R auf die Partikel in {Partikel} von B, so dass alle folgenden Aussagen wahr sein müssen:

2.1 Kein Partikel in {Partikel} von R wird auf mehr als einen Partikel in {Partikel} von B abgebildet.

2.2 Jedes Partikel in {Partikel} von R, das auf einen Partikel in {Partikel} von B abgebildet wird, ist eine gültige Beschränkung, gemäß Definition in gültige Partikel (Einschränkung) (§3.9.6).

2.3 Alle Partikel in {Partikel} von B, die von keinem Partikel in {Partikel} von R abgebildet werden, sind leerbar, gemäß Definition in Partikel leerbar (§3.9.6).

Anmerkung:

Obwohl diese Klausel die Umordnung der Reihenfolge erlaubt, kann der Prüfprozess auf Grund der Inhalts-Begrenzung von all-Gruppen deterministisch sein.

Bedingung an Schemakomponente: korrekte Partikel-Ableitung (Sequence:Choice - MapAndSum)

Damit ein sequence-Gruppenpartikel eine gültige Beschränkung eines choice-Gruppenpartikels ist, müssen alle folgenden Aussagen wahr sein:

1 Es gibt eine komplette funktionale Abbildung des Partikels in {Partikel} von R auf die Partikel in {Partikel} von B, so dass jedes Partikel in {Partikel} von R eine gültige Beschränkung des Partikels in {Partikel} von B ist, das abgebildet wird, gemäß Definition in gültige Partikel (Einschränkung) (§3.9.6).

2 Das Paar, bestehend aus dem Produkt von {minimales Vorkommen} von R und der Länge seiner {Partikel} und unbounded, wenn {maximales Vorkommen} unbounded ist, andernfalls dem Produkt von {maximales Vorkommen} von R und der Länge seiner {Partikel}, ist eine gültige Beschränkung des Vorkommensbereichs von B, gemäß Definition in korrekter Vorkommensbereich (§3.9.6).

Anmerkung:

Diese Klausel ist im Prinzip restriktiver als unbedingt nötig, deckt in der Praxis aber alle wahrscheinlichen Fälle ab und lässt sich viel leichter als die volle allgemeine Version spezifizieren.

Anmerkung:

Dieser Fall erlaubt das "Entfalten" von iterierten Disjunktionen zu Folgen. Dies mag besonders nützlich sein, wenn die Disjunktion implizit ist und aus der Verwendung von Ersetzungsgruppen entsteht.

Bedingung an Schemakomponente: Partikel leerbar

[Definition:] Damit ein Partikel leerbar sein kann, muss eine der folgenden Aussagen wahr sein:

1 Sein {minimales Vorkommen} ist 0.

2 Sein {Term} ist eine Gruppe und der Minimumteil des effektiven Gesamtbereichs dieser Gruppe ist 0, gemäß Definition in Tatsächlicher Gesamtbereich (all und sequence) (§3.8.6) (falls die Gruppe all oder sequence ist) oder Tatsächlicher Gesamtbereich (choice) (§3.8.6) (wenn es choice ist).

3.10 Wildcards

3.10.1 Die Schemakomponente Wildcard

3.10.2 XML-Darstellung der Schemakomponente Wildcard

3.10.3 Bedingungen an die XML-Darstellung von Wildcards

3.10.4 Validierungsregeln für Wildcards

3.10.5 Beiträge von Wildcards zum XML-Information-Set

3.10.6 Bedingungen an die Schemakomponente Wildcard

Um das volle Potenzial bezüglich Erweiterbarkeit und Namensräumen, das von XML geboten wird, ausnutzen zu können, braucht es mehr als DTDs für gezielte Flexibilität in Inhaltsmodellen und Attribut-Deklarationen bieten. Eine Wildcard bietet beispielsweise die Validierung von Attributen und Element-Informationseinheiten, je nach ihrem Namensraum-Namen, jedoch unabhängig von ihrem lokalen Namen.

Beispiel

<xs:any processContents="skip"/>

<xs:any namespace="##other" processContents="lax"/>

<xs:any namespace="http://www.w3.org/1999/XSL/Transform"/>

<xs:any namespace="##targetNamespace"/>

<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>

XML-Darstellungen der vier grundlegenden Wildcard-Typen und eine Attribut-Wildcard.

3.10.1 Die Schemakomponente Wildcard

Die Schemakomponente Wildcard hat die folgenden Eigenschaften:

Schemakomponente: Wildcard

{Namensraum-Beschränkung}: Entweder any, ein Paar bestehend aus not und einem Namensraum-Namen oder nicht verwendet oder eine Menge, deren Mitglieder entweder Namensraum-Namen sind oder nicht verwendet.
{Prozessinhalte}: Entweder skip, lax oder strict.
{Anmerkung}: Optional: eine Anmerkung.

{Namensraum-Beschränkung} bietet die Validierung von Attributen und Elementeinheiten, die:

(any) jeden beliebigen Namensraum haben oder nicht für Namensräume qualifiziert sind;
(not und ein Namensraum-Name) jeden beliebigen Namensraum haben, der nicht der spezifizierte Namensraum-Name ist oder die nicht für Namensräume qualifiziert sind.
(not und nicht verwendet) für Namensräume qualifiziert sind
(eine Menge, deren Mitglieder entweder Namensraum-Namen haben oder nicht verwendet sind) jeden beliebigen der spezifizierten Namensräume haben und/oder, falls nicht verwendet, in der Menge enthalten und unqualifiziert sind.

{Prozessinhalte} kontrolliert die Auswirkungen auf den Validierungsprozess der Informationseinheiten, die von Wildcards zugelassen sind, folgendermaßen:

strict: Es muss eine Top-Level-Deklaration verfügbar sein oder die Einheit muss ein xsi:type haben und gültig sein, je nach zutreffendem Fall.
skip: Keinerlei Einschränkungen: Das Element muss nur wohlgeformtes XML sein.
lax: Falls die Einheit oder irgendwelche Informationseinheiten ihrer [Kindelemente] eine Element-Informationseinheit sind und dafür eine eindeutig bestimmte Deklaration verfügbar ist, muss sie hinsichtlich dieser Definition gültig sein, d.h. man validiere, wo man kann, und sorge sich nicht, wenn man nicht kann.

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

3.10.2 XML-Darstellung der Schemakomponente Wildcard

Die XML-Darstellung einer Wildcard-Schemakomponente ist eine Element-Informationseinheit <any> oder <anyAttribute>. Die Entsprechungen zwischen den Eigenschaften einer <any>-Informationseinheit und den Eigenschaften der betreffenden Komponenten sind wie folgt (siehe <complexType> und <attributeGroup> für die Entsprechungen von <anyAttribute>):

Zusammenfassung der XML-Darstellung: Element-Informationseinheit any

<any
id = ID
maxOccurs = ( | unbounded) : 1
minOccurs = nonNegativeInteger : 1
namespace = ((##any | ##other) | Liste aus ) : ##any
processContents = (lax | skip | strict) : strict
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</any>

Ein Partikel, das eine Wildcard enthält, mit den folgenden Eigenschaften (es sei denn, minOccurs=maxOccurs=0, in diesem Fall entpricht die Einheit keiner Komponente):

Schemakomponente Partikel

Eigenschaft	Darstellung
{minimales Vorkommen}	Der tatsächliche Wert des `minOccurs`-[Attributs], wenn vorhanden, andernfalls `1`.
{maximales Vorkommen}	unbounded, wenn das `maxOccurs`-[Attribut] unbounded ist; andernfalls der tatsächliche Wert des `maxOccurs`-[Attributs], falls vorhanden; andernfalls `1`.
{Term}	Eine Wildcard wie unten gegeben:

Schemakomponente Wildcard

Eigenschaft	Darstellung
{Namensraum-Beschränkung}	Abhängig vom tatsächlichen Wert des `namespace`-[Attributs]: wenn abwesend, dann any, andernfalls wie folgt: ##any any ##other Ein Paar von not und dem tatsächlichen Wert des `targetNamespace`-[Attributs] der Vorfahrenelement-Informationseinheit <schema>, falls vorhanden; andernfalls nicht verwendet. *Andernfalls* Eine Menge, deren Mitglieder Namensraum-Namen sind, die den räumlich abgegrenzten Teilketten der Zeichenkette entsprechen, außer 1 Wenn eine solche Teilkette `##targetNamespace` ist, ist das entsprechende Mitglied der tatsächliche Wert des `targetNamespace`-[Attributs] der Vorfahrenelement-Informationseinheit <schema>, falls vorhanden; andernfalls nicht verwendet. 2 Wenn eine solche Teilkette `##local` ist, dann ist das entsprechende Mitglied nicht verwendet.
{Prozessinhalte}	Der tatsächliche Wert des `processContents`-[Attributs], wenn vorhanden, andernfalls strict.
{Anmerkung}	Die Anmerkung, die der <annotation>-Element-Informationseinheit in den [Kindelementen] entspricht, falls vorhanden; andernfalls nicht verwendet.

Wildcards unterliegen denselben Zweideutigkeitseinschränkungen (Eindeutige Partikel-Zuordnung (§3.8.6)) wie andere Inhaltsmodell-Partikel: Wenn ein Instanzelement entweder zu einem expliziten Partikel und einer Wildcard oder einer von zwei Wildcards innerhalb des Inhaltsmodells eines Typs passen könnte, ist dieses Modell fehlerhaft.

3.10.3 Bedingungen an die XML-Darstellung von Wildcards

Bedingung an Schema-Darstellung: korrekte Wildcard-Darstellung

Zusätzlich zu den Bedingungen, die <any>-Element-Informationseinheiten vom Schema für Schemata auferlegt werden, müssen das entsprechende Partikel und die Elementgruppe die in Bedingungen an die Schemakomponente Elementgruppe (§3.8.6) und Bedingungen an die Schemakomponente Partikel (§3.9.6) beschriebenen Bedingungen erfüllen.

3.10.4 Validierungsregeln für Wildcards

Validierungsregel: gültige Informationseinheit (Wildcard)

Damit eine Element- oder Attribut-Informationseinheit hinsichtlich einer Wildcard-Einschränkung lokal gültig sein kann, muss ihr [Namensraum-Name] gültig in Bezug auf die Wildcard-Einschränkung gemäß Definition in Wildcard erlaubt Namensraum-Namen (§3.10.4) sein.

Wenn diese Einschränkung zutrifft, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls {Prozessinhalte} lax ist, dann hat die Informationseinheit keine kontextbestimmte Deklaration in Bezug auf Ergebnis des Validierungsprozesses (Element) (§3.3.5), Die Schemagültigkeitsprüfung (Element) (§3.3.4) und Die Schemagültigkeitsprüfung (Attribut) (§3.2.4).

2 Falls {Prozessinhalte} strict ist, dann ist die kontextbestimmte Deklaration der Einheit mustFind.

3 Falls {Prozessinhalte} skip ist, dann ist die kontextbestimmte Deklaration der Einheit skip.

Validierungsregel: Wildcard erlaubt Namensraum-Namen

Damit ein Wert, der entweder ein Namensraum-Name oder nicht verwendet ist, in Bezug auf eine Wildcard-Einschränkung (der Wert einer {Namensraum-Beschränkung}) gültig sein kann, muss eine der folgenden Aussagen wahr sein:

1 Die Einschränkung muss any sein.

2 Alle folgenden Aussagen müssen wahr sein:

2.1 Die Einschränkung ist ein Paar bestehend aus not und einem Namensraum-Namen oder nicht verwendet ([Definition:] Man nenne dies den Namensraum-Test).

2.2 Der Wert darf nicht mit dem Namensraum-Test identisch sein.

2.3 Der Wert darf nicht nicht verwendet sein.

3 Die Einschränkung ist eine Menge und der Wert ist identisch mit einem der Mitglieder der Menge.

3.10.5 Beiträge von Wildcards zum XML-Information-Set

Keine.

3.10.6 Bedingungen an die Schemakomponente Wildcard

Alle Wildcards (siehe Wildcards (§3.10)) müssen die folgende Bedingung erfüllen.

Bedingung an Schemakomponente: Eigenschaften von Wildcard

Die Werte der Eigenschaften einer Wildcard müssen der Beschreibung in der Eigenschaftsaufstellung in Die Schemakomponente Wildcard (§3.10.1) entsprechen, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3).

Die folgenden Bedingungen definieren eine Beziehung, die an anderer Stelle in dieser Spezifikation behandelt wird.

Bedingung an Schemakomponente: Wildcard-Untermenge

Damit eine Namensraum-Einschränkung (man nenne sie sub) eine intensionale Schnittmenge einer anderen Namensraum-Einschränkung (man nenne sie super) sein kann, muss eine der folgenden Aussagen wahr sein:

1 super muss any sein.

2 Alle folgenden Aussagen müssen wahr sein:

2.1 sub muss ein Paar bestehend aus not und einem Namensraum-Namen oder nicht verwendet sein.

2.2 super muss ein Paar bestehend aus not und dem gleichen Wert sein.

3 Alle folgenden Aussagen müssen wahr sein:

3.1 sub muss eine Menge sein, deren Mitglieder entweder Namensraum-Namen bzw. nicht verwendet sind.

3.2 Eine der folgenden Aussagen muss wahr sein:

3.2.1 super muss die gleiche Menge oder eine Supermenge davon sein.

3.2.2 super muss ein Paar bestehend aus not und einem Namensraum-Namen oder nicht verwendet sein und dieser Wert darf nicht in der sub-Menge vorkommen.

Bedingung an Schemakomponente: Wildcard-Attribut-Vereinigung

Damit der {Namensraum-Beschränkung}s-Wert einer Wildcard eine intensionale Schnittmenge zweier solcher Werte (man nenne sie O1 und O2) ist, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls O1 und O2 derselbe Wert sind, dann muss dieser Wert der Wert sein.

2 Falls entweder O1 oder O2 any ist, dann muss any der Wert sein.

3 Falls sowohl O1 und O2 Mengen von Namensraum-Namen bzw. nicht verwendet) sind, dann dann muss die Vereinigung dieser Mengen der Wert sein.

4 Falls die beiden Werte Negationen verschiedener Namensraum-Namen sind, dann ist die Schnittmenge nicht ausdrückbar.

5 Falls entweder O1 oder O2 ein Paar bestehend aus not und einem Namensraum-Namen ist und der jeweils andere eine Menge von Namensraum-Namen bzw. nicht verwendet ist, dann muss der zutreffende Fall unter den folgenden wahr sein:

5.1 Falls die Menge den negierten Namensraum-Namen beinhaltet, dann muss any der Wert sein.

5.2 Falls die Menge den negierten Namensraum-Namen nicht beinhaltet, dann muss O1 oder O2 der Wert sein, je nachdem, welcher ein Paar bestehend aus not und einem Namensraum-Namen ist.

Für den Fall, dass es mehr als zwei Werte gibt, wird die intensionale Schnittmenge folgendermassen festgelegt: Es wird die intensionale Schnittmenge wie oben beschrieben von zwei Werten ermittelt, danach die intensionale Schnittmenge dieses Wertes mit dem dritten Wert (vorausgesetzt, dass die erste Schnittmenge ausdrückbar war) und so weiter, je nach Erfordernis.

Bedingung an Schemakomponente: Wildcard-Attribut-Schnitt

Damit der {Namensraum-Beschränkung}s-Wert einer Wildcard die intensionale Schnittmenge zweier anderer solcher Werte (man nenne sie O1 und O2) sein kann, muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls O1 und O2 der gleiche Wert sind, dann ist dieser Wert der Wert.

2 Falls entweder O1 oder O2 any ist, dann muss der andere der Wert sein.

3 Falls entweder O1 oder O2 ein Paar bestehend aus not und einem Namensraum-Namen und der jeweils andere eine Menge von Namensraum-Namen bzw. nicht verwendet ist, dann muss diese Menge, abzüglich des negierten Namensraum-Namens, falls dieser in der Menge war, der Wert sein.

4 Falls sowohl O1 und O2 Mengen von Namensraum-Namen bzw. nicht verwendet sind, dann muss die Schnittmenge dieser Mengen der Wert sein.

5 Falls die beiden Werte Negationen verschiedener Namensraum-Namen sind, dann ist die Schnittmenge nicht ausdrückbar.

3.11 Identitätsbeschränkungs-Definitionen

3.11.1 Die Schemakomponente Identitätsbeschränkungs-Definition

3.11.2 XML-Darstellung der Schemakomponente Identitätsbeschränkungs-Definition

3.11.3 Bedingungen an die XML-Darstellung von Identitätsbeschränkungs-Definitionen

3.11.4 Validierungsregeln für Identitätsbeschränkungs-Definitionen

3.11.5 Beiträge von Identitätsbeschränkungs-Definitionen zum XML-Information-Set

3.11.6 Bedingungen an die Schemakomponente Identitätsbeschränkungs-Definition

Identitätseinschränkende Definitionen für Komponenten bieten Eindeutigkeit und Referenzeinschränkungen in Bezug auf die Inhalte mehrerer Elemente und Attribute.

Beispiel

<xs:key name="NamenSchlüssel">
 <xs:selector xpath=".//Person"/>
 <xs:field xpath="Vorname"/>
 <xs:field xpath="Nachname"/>
</xs:key>

<xs:keyref name="PersonenRef" refer="NamenSchlüssel">
 <xs:selector xpath=".//PersonenZeiger"/>
 <xs:field xpath="@vorname"/>
 <xs:field xpath="@nachname"/>
</xs:keyref>

<xs:unique name="uniqueId">
 <xs:selector xpath=".//*"/>
 <xs:field xpath="@id"/>
</xs:unique>

XML-Darstellungen der drei Formen von Identitätsbeschränkungs-Definitionen.

3.11.1 Die Schemakomponente Identitätsbeschränkungs-Definition

Die identitätseinschränkende Definition einer Schemakomponente weist folgende Eigenschaften auf:

Schemakomponente: Identitätsbeschränkungs-Definition

{Name}: Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}: Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Identitätsbeschränkungs-Kategorie}: Entweder key, keyref oder unique.
{Selektor}: Ein eingeschränkter XPath-Ausdruck ([XPath]).
{Felder}: Eine nicht-leere Liste eingeschränkter XPath-Ausdrücke ([XPath]).
{referenzierter Schlüssel}: Erforderlich, falls {Identitätsbeschränkungs-Kategorie} keyref ist, andernfalls nicht erlaubt. Eine Identitätsbeschränkungs-Definition, wobei {Identitätsbeschränkungs-Kategorie} den Wert key oder unique hat.
{Anmerkung}: Optional: eine Anmerkung.

Identitätseinschränkende Definitionen werden nach ihrem {Namen} und {Ziel-Namensraum} identifiziert; identitätseinschränkende Definitionsidentitäten müssen innerhalb eines XML Schemas eindeutig sein; siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) mit Informationen zur Verwendung von Komponenten-Bezeichnern beim Import eines Schemas in ein anderes.

Informell identifiziert {identitätseinschränkende Kategorie} die identitätseinschränkende Definition in einer der folgenden drei Rollen:

(unique) Die identitätseinschränkende Definition sichert Eindeutigkeit hinsichtlich des vom {Selektor} identifizierten Inhalts der Tupel, die sich aus der Auswertung des XPath-Ausdrucks (bzw. der XPath-Ausdrücke) in {Felder} ergibt.
(key) Die identitätseinschränkende Definition sichert Eindeutigkeit wie bei unique. key sichert weiterhin, dass der gesamte gewählte Inhalt tatsächlich solche Tupel hat.
(keyref) Die identitätseinschränkende Definition sichert eine Entsprechung hinsichtlich des vom {Selektor} identifizierten Inhalts der Tupel, die sich aus der Auswertung des XPath-Ausdrucks (bzw. der XPath-Ausdrücke) in {Felder} mit denen des {referenzierter Schlüssel}s ergeben.

Diese Einschränkungen werden zusammen mit der Spezifikation von Typen für die betroffenen Attribute und Elemente spezifiziert, d.h. etwas als Typ integer (Ganzzahl) Spezifiziertes kann auch als Schlüssel dienen. Jede Einschränkungs-Deklaration hat einen Namen, der in einem gesonderten Symbolraum für Einschränkungen existiert. Die Gleichheits- und Ungleichheitsbedingungen, die bei der Prüfung dieser Einschränkungen greifen, sind auf den Wert der gewählten Felder anwendbar, so dass z.B. 3.0 und 3 unvereinbare Schlüssel wären, wenn sie beide eine Zahl (number) sind, jedoch vereinbar, wenn sie beide Zeichenketten (strings) sind oder wenn einer eine Zeichenkette und der andere eine Zahl ist. Werte eines unterschiedlichen Typs können nur gleich sein, wenn ein Typ vom anderen abgeleitet wird und der Wert sich im Werteraum beider befindet.

Insgesamt gibt es folgende Erweiterungen für den ID/IDREF-Mechanismus von XML:

Die Funktionsweise als Teil einer Identitätseinschränkung ist zusätzlich zu einem Typ und nicht anstelle eines Typs zu verstehen.
Nicht nur Attributwerte, sondern auch Elementinhalte und Kombinationen von Werten und Inhalten können als eindeutig erklärt werden.
Identitätseinschränkungen werden innerhalb eines Bereichs bestimmter Elemente spezifiziert.
(Kombinationen von) Attributwerte(n) und/oder Elementinhalte(n) können als Schlüssel deklariert werden, d.h. nicht nur eindeutig, sondern immer vorhanden und nicht nullifizierbar.
Der Vergleich zwischen keyref-{Felder}n und key- oder unique-{Felder}n erfolgt nach Wert- und nicht nach Zeichenkettengleichheit.

{Selektor} spezifiziert einen beschränkten XPath-Ausdruck (Bedingungen an die Schemakomponente Identitätsbeschränkungs-Definition (§3.11.6)) in Bezug auf Instanzen des zu deklarierenden Elements. Der XPath-Ausdruck muss eine Knotenmenge aus untergeordneten (d.h. innerhalb des deklarierten Elements eingeschränkten) Elementen identifizieren, auf die die Einschränkung angewandt wird.

{Felder} spezifiziert XPath-Ausdrücke in Bezug auf jedes von einem {Selektor} gewählte Element. Dies muss einen einzelnen Knoten (Element oder Attribut) identifizieren, dessen Inhalt oder Wert, der ein einfacher Typ sein muss, in der Einschränkung benutzt wird. Es ist möglich, eine geordnete Liste von {Feldern} zu spezifizieren, um Schlüssel mit mehreren Feldern, Schlüsselreferenzen (keyrefs) und Eindeutigkeitseinschränkungen zu unterstützen.

Um den Entwicklern, insbesondere denjenigen, die Streaming-Prozessoren implementieren, die Aufgabe zu vereinfachen, sind in {Selektor} und {Felder} nur beschränkte Teilmengen von XPath-Ausdrücken zulässig. Einzelheiten werden in [XPath] beschrieben.

Anmerkung:

Die Bereitstellung von Schlüsseln mit mehreren Feldern usw. geht über die unterstützenden Möglichkeiten von xsl:key hinaus.

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

3.11.2 XML-Darstellung der Schemakomponente Identitätsbeschränkungs-Definition

Die XML-Darstellung einer identitätsbeschränkenden Definition für eine Schemakomponente ist entweder eine Element-Informationseinheit <key>, <keyref> oder <unique>. Die Entsprechungen zwischen den Eigenschaften dieser Informationseinheiten und den Eigenschaften der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit unique

<unique
id = ID
name = NCName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (selector, field+))
</unique>

<key
id = ID
name = NCName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (selector, field+))
</key>

<keyref
id = ID
name = NCName
refer = QName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (selector, field+))
</keyref>

<selector
id = ID
xpath = Untermenge der XPath-Mächtigkeit, Näheres siehe unten
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</selector>

<field
id = ID
xpath = Untermenge der XPath-Mächtigkeit, Näheres siehe unten
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</field>

Schemakomponente Identitätsbeschränkungs-Definition

Eigenschaft	Darstellung
{Name}	Der tatsächliche Wert des [Attributs] `name`.
{Ziel-Namensraum}	Der tatsächliche Wert des [Attributs] `targetNamespace` der Elternelement-Informationseinheit `schema`.
{Identitätsbeschränkungs-Kategorie}	Entweder key, keyref oder unique, je nach Einheit.
{Selektor}	Ein beschränkter XPath-Ausdruck, der dem tatsächlichen Wert des `xpath`-[Attributs] der <selector>-Element-Informationseinheit in [Kindelemente] entspricht.
{Felder}	Eine Folge von XPath-Ausdrücken, die den tatsächlichen Werten des `xpath`-[Attributs] der <field>-Element-Informationseinheit in [Kindelemente] in deren angegebener Reihenfolge entspricht.
{referenzierter Schlüssel}	Wenn die Einheit ein <keyref> ist, wird die identitätseinschränkende Definition vom tatsächlichen Wert des `refer`-[Attributs] aufgelöst; andernfalls nicht verwendet.
{Anmerkung}	Die Anmerkung, die der Element-Informationseinheit <annotation> in [Kindelemente] entspricht, falls vorhanden; andernfalls nicht verwendet.

Beispiel

<xs:element name = "Fahrzeug">
   <xs:complexType>
      . . .
      <xs:attribute name = "nummernschild" 
                type = "NummernschildTyp"/>
      <xs:attribute name = "staat" 
                    type = "ZweiBuchstabenCode"/>
   </xs:complexType>
</xs:element>

<xs:element name = "Staat">
   <xs:complexType>
      <xs:sequence>
         <xs:element name = "Länderkennung" 
                     type = "ZweiBuchstabenCode"/>
         <xs:element ref = "Fahrzeug" 
                     maxOccurs = "unbounded"/>
         <xs:element ref = "Person" 
                     maxOccurs = "unbounded"/>
      </xs:sequence>
   </xs:complexType>

   <!-- Der Schlüssel von Fahrzeug innerhalb eines Staates ist das Nummernschild. -->
   <xs:key name = "NummernschildSchlüssel">
      <xs:selector xpath = ".//Fahrzeug"/>
      <xs:field xpath = "@nummernschild"/>
   </xs:key>
</xs:element>

<xs:element name = "Registratur">                                 
   <xs:complexType>
      <xs:sequence>
         . . . 
         <xs:element ref = "Staat" 
                 maxOccurs = "unbounded"/>
       . . .
      </xs:sequence>
   </xs:complexType>

   <!-- Länderkennung ist Schlüssel für Staat -->
   <xs:key name = "LänderkennungSchlüssel">
      <xs:selector xpath = ".//Staat"/>
      <xs:field xpath = "Länderkennung"/>
   </xs:key>

   <!-- jedes Fahrzeug referenziert seinen zulassenden Staat -->
   <xs:keyref name = "FahrzeugStaatRef" 
          refer = "LänderkennungSchlüssel">
      <xs:selector xpath = ".//Fahrzeug"/>
      <xs:field xpath = "@staat"/>
   </xs:keyref>

   <!-- der Schlüssel für Fahrzeug ist die Kombination aus 
   zulassenden Staat und Nummernschild -->
   <xs:key name = "FahrzeugSchlüssel">
      <xs:selector xpath = ".//Fahrzeug"/>
      <xs:field xpath = "@staat"/>
      <xs:field xpath = "@nummernschild"/>
   </xs:key>

   <!-- die Autos von Personen referenzieren die in einem
    Staat zugelassenen Fahrzeuge -->
   <xs:keyref name = "AutoRef" refer = "FahrzeugSchlüssel">
      <xs:selector xpath = ".//Auto"/>
      <xs:field xpath = "@regStaat"/>
      <xs:field xpath = "@regNummernschild"/>
   </xs:keyref>
</xs:element>

<xs:element name = "Person">
   <xs:complexType>
      <xs:sequence>
         . . .
         <xs:element name = "Auto">
            <xs:complexType>
               <xs:attribute name = "regStaat" 
                         type = "ZweiBuchstabenCode"/>
               <xs:attribute name = "regNummernschild" 
                             type = "NummernschildTyp"/>
             </xs:complexType>
       </xs:element>
      </xs:sequence>
   </xs:complexType>
</xs:element>

Es wird ein Element Staat definiert, das ein Länderkennungs-Kindelement sowie Fahrzeug- und Personen-Kindelemente enthält. Ein Fahrzeug hat ein Nummernschild-Attribut vom NummernschildTyp und ein Attribut staat. Länderkennungen sind Schlüssel für die Staat-Elemente innerhalb des Dokuments. Die Nummernschilder der Fahrzeuge sind Schlüssel innerhalb von Staat, und Staat und Nummernschild zusammen sind Schlüssel für Fahrzeug innerhalb des Gesamtdokuments. Weiterhin haben Personen-Elemente ein leeres Kindelement Auto mit den Attributen regStaat und regNummernschild, die zusammen via AutoRef-Schlüsselreferenz Fahrzeuge referenzieren. Die Anforderung, dass der Staat eines Fahrzeugs mit den Länderkennungen des zulassenden Staates übereinstimmt, wird nicht ausgedrückt.

3.11.3 Bedingungen an die XML-Darstellung von Identitätsbeschränkungs-Definitionen

Bedingung an Schema-Darstellung: korrekte Darstellung der Identitätsbeschränkungs-Definition

Zusätzlich zu den Bedingungen, die den Element-Informationseinheiten <key>, <keyref> und <unique> vom Schema für Schemata auferlegt werden, muss die entsprechende identitätseinschränkende Definition die in Bedingungen an die Schemakomponente Identitätsbeschränkungs-Definition (§3.11.6) beschriebenen Bedingungen erfüllen.

3.11.4 Validierungsregeln für Identitätsbeschränkungs-Definitionen

Validierungsregel: erfüllte Identitätsbeschränkung

Damit eine Element-Informationseinheit in Bezug auf eine Identitätsbeschränkung lokal gültig sein kann, müssen alle folgenden Aussagen wahr sein:

1 Der {Selektor} mit der Element-Informationseinheit als Kontextknoten wird auf die Knotenmenge (gemäß Definition in [XPath]) ausgewertet. [Definition:] Man nenne dies die Zielknotenmenge .

2 Jeder Knoten in der Zielknotenmenge ist ein Elementknoten unter den Abkömmlingen des Kontextknotens.

3 Für jeden Knoten in der Zielknotenmenge werden alle {Felder} mit diesem Knoten als Kontextknoten entweder zu einer leeren Knotenmenge oder einer Knotenmenge mit genau einem Mitglied, das einen einfachen Typ haben muss, ausgewertet. [Definition:] Man nenne die Folge der Typ-bestimmten Werte (gemäß Definition in [XML Schemas: Datatypes]) des [Schema-normalisierten Wertes] der Element- und/oder Attribut-Informationseinheiten in diesen geordneten Knotenmengen, die Schlüsselfolge des Knotens.

4 [Definition:] Man nenne die Teilmenge der Zielknotenmenge, für die alle {Felder} auf eine Knotenmenge mit genau einem Mitglied, das ein Element- oder Attributknoten mit einem einfachen Typ ist, ausgewertet werden, die qualifizierte Knotenmenge . Der zutreffende Fall unter den folgenden muss wahr sein:

4.1 Falls die {Identitätsbeschränkungs-Kategorie} unique ist, dann haben keine zwei Mitglieder der qualifizierten Knotenmenge Schlüsselfolgen, deren Mitglieder paarweise gleich sind, gemäß Definition in Gleich in [XML Schemas: Datatypes].

4.2 Falls die {Identitätsbeschränkungs-Kategorie} key ist, dann müssen alle folgenden Aussagen wahr sein:

4.2.1 Die Zielknotenmenge und die qualifizierte Knotenmenge sind gleich, d.h. jedes Mitglied der Zielknotenmenge ist auch ein Mitglied der qualifizierten Knotenmenge und umgekehrt.

4.2.2 Keine zwei Mitglieder der qualifizierten Knotenmenge haben Schlüsselfolgen, deren Mitglieder paarweise gleich sind, gemäß Definition in Gleich in [XML Schemas: Datatypes].

4.2.3 Kein Elementmitglied der Schlüsselfolge eines Mitglieds der qualifizierten Knotenmenge wurde durch Referenz auf eine Element-Deklaration, deren {nullwertfähig} true ist, als gültig ermittelt.

4.3 Falls die {Identitätsbeschränkungs-Kategorie} keyref ist, dann muss es für jedes Mitglied der qualifizierten Knotenmenge (man nenne dies das keyref-Mitglied) eine Knotentabelle in Verbindung mit dem referenzierten Schüssel ({referenzierter Schlüssel}) in der [Identitätsbeschränkungs-Tabelle] der Element-Informationseinheit geben (siehe Identitätsbeschränkungs-Tabelle (§3.11.5), was als logisch vorhergehend zu dieser Klausel dieser Einschränkung verstanden werden muss) und es muss in dieser Tabelle einen Eintrag geben, dessen Schlüsselfolge gleich der Schlüsselfolge des keyref-Mitglieds ist. Dies gilt für jedes Mitglied gemäß Definition in Gleich in [XML Schemas: Datatypes].

Anmerkung:

Die Verwendung von [Schema-normalisierter Wert] in der Definition von Schlüsselfolge in der obigen Definition bedeutet, dass default- oder fixed-Werteinschränkungen eine Rolle in Schlüsselfolgen spielen können.

Anmerkung:

Obwohl diese Spezifikation einen Beitrag für den XML-Information-Set nach der Schema-Validierung definiert, der es schemabewussten Prozessoren ermöglicht, die obige Klausel 4.2.3 (Element-Deklaration (§3.3.5)) zu implementieren, wird dies von Prozessoren nicht gefordert. Diese Klausel kann man so interpretieren, dass der Wert der relevanten {nullwertfähig}-Eigenschaft verfügbar sein muss.

3.11.5 Beiträge von Identitätsbeschränkungs-Definitionen zum XML-Information-Set

Beitrag zum Schema Information Set: Identitätsbeschränkungs-Tabelle

[Definition:] Eine geeignete Identitätseinschränkung einer Element-Informationseinheit ist dergestalt, dass Klausel 4.1 oder Klausel 4.2 von erfüllte Identitätsbeschränkung (§3.11.4) in Bezug auf diese Einheit und diese Einschränkung erfüllt wird, oder dergestalt, dass ein beliebiges der Element-Informationseinheiten-[Kindelemente] dieser Einheit eine Eigenschaft [Identitätsbeschränkungs-Tabelle] hat, deren Wert einen Eintrag für diese Einschränkung hat.

[Definition:] Eine Knotentabelle ist eine Menge von Paaren, die jeweils aus einer Schlüsselfolge und einem Elementknoten bestehen.

Wenn eine Element-Informationseinheit eine oder mehrere geeignete Identitätsbeschränkungen im Information-Set nach der Schema-Validierung hat, dann hat diese Element-Informationseinheit eine der folgenden Eigenschaften:

PSVI-Beiträge für die Informationseinheit Element

[Identitätsbeschränkungs-Tabelle]

Eine Identitätsbeschränkungs-Bindungs-Informationseinheit für jede geeignete Identitätseinschränkung mit folgenden Eigenschaften:

PSVI-Beiträge für die Informationseinheit Identitätsbeschränkungs-Bindung

[Definition]: Die geeignete Identitätseinschränkung.
[Knotentabelle]: Eine Knotentabelle mit einem Eintrag für jede Schlüsselfolge (man nenne sie k) und Knoten (man nenne ihn n), so dass eine der folgenden Aussagen wahr sein muss:

1 In einer der Knotentabellen gibt es einen Eintrag in Verbindung mit der [Definition] in einer Identitätsbeschränkungs-Bindungs-Element-Informationseinheit in mindestens einer der [Identitätsbeschränkungs-Tabelle]n der [Kind-]Informationseinheiten, deren Schlüsselfolge k und deren Knoten n ist.

2 n erscheint mit einer key-sequence k in der qualifizierten Knotenmenge der [Definition].

Voraussetzung ist, dass keine zwei Einträge die gleiche key-sequence, aber unterschiedliche Knoten haben. Potenzielle Konflikte werden dadurch gelöst, dass keine Konflikteinträge, deren Einbeziehung auf die obige Klausel 1 zurückzuführen ist, einbezogen werden. Man beachte, dass überhaupt kein Eintrag für die verletzende Schlüsselfolge erscheinen würde, wenn alle Konflikteinträge gemäß der obigen Klausel 1 vorkommen würden.

Anmerkung:

Die Komplexität der obigen Bedingung entsteht aus der Tatsache, dass die keyref-Identitätseinschränkung für Domains definiert werden kann, die sich von der eingebetteten Domain der referenzierten Identitätseinschränkung unterscheiden, oder die Domains sind möglicherweise die gleichen, jedoch auf irgendeiner Tiefe selbsteinbettend. In jedem der beiden Fälle muss die Knotentabelle der referenzierten Identitätseinschränkung nach oben propagieren und mögliche Konflikte müssen aufgelöst werden.

Die Identitätsbeschränkungs-Bindungs-Informationseinheit ist im Gegensatz zu anderen in dieser Spezifikation im Wesentlichen ein interner Buchhaltungsmechanismus. Er wird eingeführt, um die Definition von erfüllte Identitätsbeschränkung (§3.11.4) zu unterstützen. Dementsprechend können konforme Prozessoren sie über Eigenschaften der [Identitätsbeschränkungs-Tabelle] im Information-Set nach der Schema-Validierung ausweisen, müssen dies aber nicht. Anders ausgedrückt können die obigen Einschränkungen als Validierung von identitätsbeschränkenden Vorgängen interpretiert werden, als ob solche Informationseinheiten existieren würden.

3.11.6 Bedingungen an die Schemakomponente Identitätsbeschränkungs-Definition

Alle Identitätsbeschränkungs-Definitionen (siehe Identitätsbeschränkungs-Definitionen (§3.11)) müssen die folgenden Bedingungen erfüllen.

Bedingung an Schemakomponente: Eigenschaften der Identitätsbeschränkungs-Definition

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften einer identitätsbeschränkenden Definition müssen der Beschreibung in der Eigenschaftentabelle in Die Schemakomponente Identitätsbeschränkungs-Definition (§3.11.1), vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3), entsprechen.

2 Wenn die {Identitätsbeschränkungs-Kategorie} keyref ist, muss die Kardinalität der {Felder} gleich der {Felder} des referenzierten Schlüssels sein.

Bedingung an Schemakomponente: korrekter Selektorwert

Alle folgenden Aussagen müssen wahr sein:

1 Der {Selektor} muss ein gültiger XPath-Ausdruck gemäß Definition in [XPath] sein.

2 Eine der folgenden Aussagen muss wahr sein:

2.1 Er muss der folgenden erweiterten Backus-Naur Form (EBNF) entsprechen:

Selektor-XPath-Ausdrücke

`[1]`	`Selector`	`::=`	`Path ( '\|' Path )*`
`[2]`	`Path`	`::=`	`('.//')? Step ( '/' Step )*`
`[3]`	`Step`	`::=`	`'.' \| NameTest`
`[4]`	`NameTest`	`::=`	`QName \| '' \| NCName ':' ''`

2.2 Er muss ein XPath-Ausdruck sein, der die Kind-Achse beinhaltet, deren abgekürzte Form oben aufgeführt wurde.

Für erleichterte Lesbarkeit darf in Selektor-XPath-Ausdrücken Leerraum eingesetzt werden, obwohl dies nicht ausdrücklich durch die Grammatik erlaubt ist. Leerraum (whitespace) darf nach Belieben vor oder nach Token eingesetzt werden.

[5] token ::= '.' | '/' | '//' | '|' | '@' | NameTest

[6] whitespace ::= S

Beim Zerteilen in Token wird immer das längstmögliche Token zurückgegeben.

Bedingung an Schemakomponente: korrekte Feldwerte

Alle folgenden Aussagen müssen wahr sein:

1 Jedes Mitglied der {Felder} muss ein gültiger XPath-Ausdruck gemäß Definition in [XPath] sein.

2 Eine der folgenden Aussagen muss wahr sein:

2.1 Er muss der erweiterten BNF entsprechen, die oben für Selector aufgeführt wurde, mit der folgenden Modifikation:

Pfad in XPath-Ausdrücken von Feldern

[7] Path ::= ('.//')? ( Step '/' )* ( Step | '@' NameTest )

Diese Produktion unterscheidet sich von der obigen dahingehend, dass der letzte Schritt zu einem Attributknoten passen darf.

2.2 Er muss ein XPath-Ausdruck sein, der die Kind- und/oder Attribut-Achse beinhaltet, deren abgekürzte Form oben aufgeführt wurde.

Zur besseren Lesbarkeit darf in Pfaden in XPath-Ausdrücken von Feldern Leerraum verwendet werden, obwohl dies nicht ausdrücklich in der Grammatik erlaubt wird. Leerraum darf frei vor und nach Token eingesetzt werden.

Beim Zerteilen in Token wird immer das längstmögliche Token zurückgegeben.

3.12 Notations-Deklarationen

3.12.1 Die Schemakomponente Notations-Deklaration

3.12.2 XML-Darstellung der Schemakomponente Notations-Deklaration

3.12.3 Bedingungen an die XML-Darstellung von Notations-Deklarationen

3.12.4 Validierungsregeln für Notations-Deklarationen

3.12.5 Beiträge von Notations-Deklarationen zum XML-Information-Set

3.12.6 Bedingungen an die Schemakomponente Notations-Deklaration

Notations-Deklarationen rekonstruieren Deklarationen gemäß XML-1.0-NOTATION.

Beispiel

<xs:notation name="jpeg" 
                  public="image/jpeg" 
                  system="bildbetrachter.exe">

Die XML-Darstellung einer Notations-Deklaration.

3.12.1 Die Schemakomponente Notations-Deklaration

Die Notationsdeklaration für Schemakomponenten weist folgende Eigenschaften auf:

Schemakomponente: Notations-Deklaration

{Name}: Ein NCName wie in [XML-Namespaces] definiert.
{Ziel-Namensraum}: Entweder nicht verwendet oder ein Namensraum-Name, wie in [XML-Namespaces] definiert.
{Systembezeichner}: Optional, falls {öffentlicher Bezeichner} vorhanden ist; eine URI-Referenz.
{öffentlicher Bezeichner}: Optional, falls {Systembezeichner} vorhanden ist; ein öffentlicher Bezeichner, wie in [XML 1.0 (Second Edition)] definiert.
{Anmerkung}: Optional: eine Anmerkung.

Notations-Deklarationen nehmen nicht an der Validierung an sich teil. Sie werden im Verlauf der Validierung von Zeichenketten als Mitglieder des einfachen Typs NOTATION referenziert.

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

3.12.2 XML-Darstellung der Schemakomponente Notations-Deklaration

Die XML-Darstellung einer Notations-Deklaration für Schemakomponenten ist eine Element-Informationseinheit <notation>. Die Entsprechungen zwischen den Eigenschaften dieser Informationseinheiten und den Eigenschaften der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit notation

<notation
id = ID
name = NCName
public = anyURI
system = anyURI
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</notation>

Schemakomponente Notations-Deklaration

Eigenschaft	Darstellung
{Name}	Der tatsächliche Wert des [Attributs] `name`.
{Ziel-Namensraum}	Der tatsächliche Wert des [Attributs] `targetNamespace` des Eltern-Informationseinheit `schema`.
{Systembezeichner}	Der tatsächliche Wert des [Attributs] `system`, falls vorhanden; andernfalls nicht verwendet.
{öffentlicher Bezeichner}	Der tatsächliche Wert des [Attributs] `public`.
{Anmerkung}	Die Anmerkung, die der Element-Informationseinheit <annotation> in [Kindelemente] entspricht, falls vorhanden; andernfalls nicht verwendet.

Beispiel

<xs:notation name="jpeg"
             public="image/jpeg" system="bildbetrachter.exe" />

<xs:element name="Bild">
 <xs:complexType>
  <xs:simpleContent>
   <xs:extension base="xs:hexBinary">
    <xs:attribute name="bildFormat">
     <xs:simpleType>
      <xs:restriction base="xs:NOTATION">
       <xs:enumeration value="jpeg"/>
       <xs:enumeration value="png"/>
       . . .
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>
</xs:element>

<Bild bildFormat="jpeg">...</Bild>

3.12.3 Bedingungen an die XML-Darstellung von Notations-Deklarationen

Bedingung an Schema-Darstellung: korrekte Darstellung der Notations-Definition

Zusätzlich zu den Bedingungen, die <notation>-Element-Informationseinheiten durch das Schema für Schemata auferlegt werden, muss die entsprechende Definition den in Bedingungen an die Schemakomponente Notations-Deklaration (§3.12.6) beschriebenen Bedingungen genügen.

3.12.4 Validierungsregeln für Notations-Deklarationen

3.12.5 Beiträge von Notations-Deklarationen zum XML-Information-Set

Beitrag zum Schema Information Set: Validiert mit Notation

Wenn eine Attribut-Informationseinheit gültig ist in Bezug auf eine NOTATION, hat ihre Elternelement-Informationseinheit im XML-Information-Set nach der Schema-Validierung eine der folgenden Eigenschaften:

PSVI-Beiträge für die Informationseinheit Element

[Notation]: Eine zu der Notations-Deklaration isomorphe Informationseinheit, deren {Name} und {Ziel-Namensraum} mit dem lokalen Namen und dem Namensraum-Nameen (gemäß Defintion in QName-Interpretation (§3.15.3)) des tatsächlichen Wertes der Attribut-Informationseinheit übereinstimmen.

oder weist folgendes Eigenschaftspaar auf:

PSVI-Beiträge für die Informationseinheit Element

[System-Notation]: Der Wert von {Systembezeichner} dieser Notations-Deklaration.
[öffentliche Notation]: Der Wert von {öffentlicher Bezeichner} dieser Notations-Deklaration.

Anmerkung:

Zum Zwecke der Kompatibilität sollte in einem bestimmten Element nur ein solches Attribut erscheinen. Wenn dennoch mehr als ein solches Attribut erscheint, ist zu klären, welches die Information-Set-Eigenschaft liefert; andernfalls werden die obigen Eigenschaften nicht definiert.

3.12.6 Bedingungen an die Schemakomponente Notations-Deklaration

Alle Notations-Deklarationen (siehe Notations-Deklarationen (§3.12)) müssen die folgende Bedingung erfüllen:

Bedingung an Schemakomponente: Notations-Deklaration

Die Werte der Eigenschaften einer Notations-Deklaration müssen der Beschreibung in der Eigenschaftentabelle in Die Schemakomponente Notations-Deklaration (§3.12.1), vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3) entsprechen.

3.13 Anmerkungen

3.13.1 Die Schemakomponente Anmerkung

3.13.2 XML-Darstellung der Schemakomponente Anmerkung

3.13.3 Bedingungen an die XML-Darstellung von Anmerkungs-Komponenten

3.13.4 Validierungsregeln für Anmerkungs-Komponenten

3.13.5 Beiträge von Anmerkungs-Komponenten zum XML-Information-Set

3.13.6 Bedingungen an die Schemakomponente Anmerkung

Anmerkungen sind hier von Personen und Maschinen lesbare Anmerkungen für Schemakomponenten.

Beispiel

<xs:simpleType fn:note="special">
  <xs:annotation>
   <xs:documentation>Ein Typ für Experten</xs:documentation>
   <xs:appinfo>
    <fn:specialHandling>prüfePrimzahlenEigenschaft</fn:specialHandling>
   </xs:appinfo>
  </xs:annotation>

XML-Darstellungen der drei Formen von Anmerkungen.

3.13.1 Die Schemakomponente Anmerkung

Schemakomponente: Anmerkung

{Applikations-Informationen}: Eine Folge von Element-Informationseinheiten.
{Benutzer-Informationen}: Eine Folge von Element-Informationseinheiten.
{Attribute}: Eine Folge von Attribut-Informationseinheiten.

{Benutzer-Informationen} dient dem Gebrauch durch Personen, {Applikations-Informationen} dient der automatischen Verarbeitung. In beiden Fällen wird eine optionale URI-Referenz als Ergänzung der lokalen Information als Wert des Attributs source der betreffenden Element-Informationseinheiten bereitgestellt. Validierung beinhaltet nicht die Auflösung der Referenzen auf diese URIs, wenn vorhanden. Im Fall von {Benutzer-Informationen} sollte ein Hinweis auf die Identität der in den Inhalten benutzten Sprache mit Hilfe des Attributs xml:lang gegeben werden.

{Attribute} stellt sicher, dass falls durch Schema-Autoren die Möglichkeit des Hinzufügens von Attributen genutzt wird, welche nicht aus XML-Schema-Namensräumen stammen, diese Attribute innerhalb der Komponenten verfügbar sind, die den Element-Informationseinheiten, in denen diese Attribute erscheinen, entsprechen.

Anmerkungen nehmen nicht an der Validierung an sich teil. Sofern eine Anmerkung selbst alle relevanten Schemakomponenten-Bedingungen erfüllt, darf sie sich nicht auf die Validierung von Element-Informationseinheiten auswirken.

3.13.2 XML-Darstellung der Schemakomponente Anmerkung

Anwendungs- und Benutzerinformationen für Schemata und Schemakomponenten sind am Anfang der meisten wichtigen Schema-Elemente und überall auf oberster Ebene von Schemata zugelassen. Die XML-Darstellung einer Anmerkungs-Schemakomponente ist eine Element-Informationseinheit <annotation>. Die Entsprechungen zwischen den Eigenschaften dieser Informationseinheiten und den Eigenschaften der betreffenden Komponente sind wie folgt:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit annotation

<annotation
id = ID
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (appinfo | documentation)*
</annotation>

<appinfo
source = anyURI>
Inhalt: ({any})*
</appinfo>

<documentation
source = anyURI
xml:lang = language>
Inhalt: ({any})*
</documentation>

Schemakomponente Anmerkung

Eigenschaft	Darstellung
{Applikations-Informationen}	Eine Folge von <appinfo>-Element-Informationseinheiten aus den [Kindelementen] in der angegebenen Reihenfolge, falls zutreffend; andernfalls die leere Folge.
{Benutzer-Informationen}	Eine Folge von <documentation>-Element-Informationseinheiten aus den [Kindelementen], in der angegebenen Reihenfolge, falls zutreffend; andernfalls die leere Folge
{Attribute}	Eine Folge von Attribut-Informationseinheiten, nämlich jene, die durch das Attribut-Wildcard in der Typdefinition der <annotation>-Einheit oder für die einschließenden Einheiten, die der Komponente entsprechen, innnerhalb der sich die Anmerkungs-Komponente befindet, zugelassen sind.

Die Anmerkungs-Komponente, die dem Element <annotation> im obigen Beispiel entspricht, hat eine Element-Informationseinheit in jedem ihrer {Benutzer-Informationen} und {Applikations-Informationen} und eine Attribut-Informationseinheit in ihren {Attribute}n.

3.13.3 Bedingungen an die XML-Darstellung von Anmerkungs-Komponenten

Bedingung an Schema-Darstellung: korrekte Darstellung der Anmerkungs-Definition

Zusätzlich zu den Bedingungen, die <annotation>-Element-Informationseinheiten durch das Schema für Schemata auferlegt werden, muss die entsprechende Anmerkung die in Bedingungen an die Schemakomponente Anmerkung (§3.13.6) beschriebenen Bedingungen erfüllen.

3.13.4 Validierungsregeln für Anmerkungs-Komponenten

Keine.

3.13.5 Beiträge von Anmerkungs-Komponenten zum XML-Information-Set

Als solche keine vorhanden: Die Hinzufügung von Anmerkungen zum XML-Information-Set nach der Schema-Validierung ist durch die Beiträge zu den Information-Sets nach der Schema-Validierung der einschließenden Komponenten abgedeckt.

3.13.6 Bedingungen an die Schemakomponente Anmerkung

Alle Anmerkungen (siehe Anmerkungen (§3.13)) müssen die folgende Bedingung erfüllen.

Bedingung an Schemakomponente: Anmerkung

Die Werte der Eigenschaften einer Anmerkung müssen der Beschreibung in der Eigenschaftsaufstellung in Die Schemakomponente Anmerkung (§3.13.1), vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3), entsprechen.

3.14 Definition einfacher Typen

3.14.1 (nicht-normativ) Die Schemakomponente Definition eines einfachen Typs

3.14.2 (nicht-normativ) XML-Darstellung der Schemakomponente Definition eines einfachen Typs

3.14.3 (nicht-normativ) Bedingungen an die XML-Darstellung von einfachen Typdefinitionen

3.14.4 Validierungsregeln für einfache Typdefinitionen

3.14.5 Beiträge von einfachen Typdefinitionen zum XML-Information-Set

3.14.6 Bedingungen an die Schemakomponente Definition eines einfachen Typs

3.14.7 Vordefinierte einfache Typdefinitionen

Anmerkung:

Dieser Abschnitt besteht aus einer Kombination von nicht-normativen Versionen von normativem Material aus [XML Schemas: Datatypes] zum Zwecke lokaler Querverweise und normativem Material in Bezug auf die Schnittstelle zwischem Schemakomponenten, die in dieser Spezifikation definiert sind, und der einfachen Typdefinitionskomponente.

Einfache Typdefinitionen bieten die Einschränkung von Zeichen-Informationseinheiten-[Kindelementen] von Element- und Attribut-Informationseinheiten.

Beispiel

<xs:simpleType name="CelciusWasserTemp">
 <xs:restriction base="xs:number">
  <xs:fractionDigits value="2"/>
  <xs:minExclusive value="0.00"/>
  <xs:maxExclusive value="100.00"/>
 </xs:restriction>
</xs:simpleType>

Die XML-Darstellung einer einfachen Typdefinition.

3.14.1 (nicht-normativ) Die Schemakomponente Definition eines einfachen Typs

Die Schemakomponente Definition eines einfachen Typs hat die folgenden Eigenschaften:

Schemakomponente: einfache Typdefinition

{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}: Eine einfache Typdefinition, die eine einfache Urtyp-Definition sein kann.
{Fassetten}: Eine Menge einschränkender Fassetten.
{grundlegende Fassetten}: Eine Menge fundamentaler Fassetten.
{abgeschlossen}: Eine Untermenge von {extension, list, restriction, union}.
{Sorte}: Ein Wert aus {atomic, list, union}. Abhängig vom Wert der Eigenschaft {Sorte} sind weitere Eigenschaften wie folgt definiert:
{Anmerkung}: Optional: eine Anmerkung.

Einfache Typen werden durch ihren {Namen} und {Ziel-Namensraum} identifiziert, abgesehen von anonymen einfachen Typen (jene ohne {Namen}). Weil Typdefinitionen (d.h. sowohl einfache als auch komplexe Typdefinitionen zusammengenommen) innerhalb eines XML Schemas eindeutig identifiziert werden müssen, darf keine einfache Typdefinition den gleichen Namen wie eine andere einfache oder komplexe Typdefinition haben. {Namen} und {Zielnamensräume} von einfachen Typen bieten Referenzen auf Instanzen (siehe xsi:type (§2.6.1)) und Verwendung in der XML-Darstellung von Schemakomponenten (insbesondere in <element> und <attribute>). Siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) in Bezug auf die Verwendung von Komponenten-Bezeichnern beim Import eines Schemas in ein anderes.

Anmerkung:

Der {Name} eines einfachen Typs ist nicht ipso facto der [(lokale) Name] der Element- oder Attribut-Informationseinheit, die von dieser Definition validiert wird. Die Verbindung zwischen einem Namen und einer Typdefinition wird in Element-Deklarationen (§3.3) und Attribut-Deklarationen (§3.2) beschrieben.

Eine einfache Typdefinition mit einer leeren Spezifikation für {abgeschlossen} kann als {Basistyp-Definition} für andere Typen benutzt werden, die entweder mit Erweiterung oder Beschränkung abgeleitet werden, oder als {Listenelement-Typ-Definition} in der Definition einer Liste, oder in den {Mengenelement-Typ-Definition}en einer Vereinigung. Die expliziten Werte Erweiterung, Beschränkung, Liste und Vereinigung verhindern weitere Ableitungen durch Erweiterung (um einen komplexen Typ zu gewinnen) und Beschränkung (um einen einfachen Typ zu gewinnen) und Verwendung in der Konstruktion von Listen bzw. Vereinigungen.

{Sorte} bestimmt, ob der einfache Typ einem Typ atomar, Liste oder Vereinigung gemäß Definition in [XML Schemas: Datatypes] entspricht.

Wie in Typhierarchie (§2.2.1.1) beschrieben, ist jede einfache Typdefinition eine Einschränkung eines anderen einfachen Typs (der {Basistyp-Definition}), der die einfache Urtyp-Definition ist, falls die fragliche Typdefinition einer der vordefinierten primitiven Datentypen oder eine Listen- oder Vereinigungs-Typdefinition ist. Jeder einfache Typ ist letztendlich eine Beschränkung von genau einer solchen vordefinierten einfachen {Primitiv-Typ-Definition}.

{Fassetten} werden für jede einfache Typdefinition aus denen ausgewählt, die in [XML Schemas: Datatypes] definiert sind. Für atomare Definitionen sind sie auf jene eingeschränkt, die sich für die entsprechende {primitive Typdefinition} eignen. Deshalb werden der Werteraum und der lexikalische Raum (d.h., was von einem atomaren einfachen Typ validiert wird) von einem Paar ({primitive Typdefinition}, {Fassetten}) bestimmt.

Wie in [XML Schemas: Datatypes] spezifiziert, validieren einfache list-Typdefinitionen durch Leerzeichen getrennte Tokens, die jeweils mit einer spezifizierten einfachen Typdefinition, der {Listenelement-Typ-Definition}, konform sind. Der spezifizierte Informationseinheit-Typ darf selbst kein Liste-Typ sein und muss einer der in [XML Schemas: Datatypes] identifizierten Typen sein, also ein geeigneter Informationseinheit-Typ für einen einfachen Liste-Typ. In diesem Fall sind die {Fassetten} auf die Liste selbst anwendbar und auf diejenigen für Listen eingeschränkt.

Eine einfache Typdefinition Vereinigung validiert Zeichenketten, die mindestens eine ihrer {Mengenelement-Typ-Definition} erfüllen. Wie im Fall von Liste sind die {Fassetten} auf die Vereinigung selbst anwendbar und auf diejenigen für Vereinigungen eingeschränkt.

Wie in Typhierarchie (§2.2.1.1) beschrieben, funktioniert die Urtyp-Definition bei Benutzung als Basistyp-Definition als einfacher Typ für die vordefinierten primitiven Datentypen und für Liste- und Vereinigung-Typdefinitionen. Sie hat einen uneingeschränkten lexikalischen Raum und einen Werteraum, der aus der Vereinigung der Werteräume aller vordefinierten primitiven Datentypen und der Menge aller Listen aller Mitglieder der Werteräume aller vordefinierten primitiven Datentypen besteht.

Die einfache Urtyp-Definition darf nicht als die Basistyp-Definition von benutzerdefinierten einfachen Typen benutzt werden. Da sie keine einschränkenden Fassetten hat, wäre dies nicht kohärent.

Siehe Anmerkungen (§3.13) in Bezug auf Informationen zur Rolle der Eigenschaft {Anmerkung}.

3.14.2 (nicht-normativ) XML-Darstellung der Schemakomponente Definition eines einfachen Typs

Anmerkung:

Dieser Abschnitt reproduziert eine Version von Material aus [XML Schemas: Datatypes], zum Zwecke lokaler Querverweise.

Zusammenfassung der XML-Darstellung: Element-Informationseinheit simpleType

<simpleType
final = (#all | (list | restriction | union))
id = ID
name = NCName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (restriction | list | union))
</simpleType>

<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)*))
</restriction>

<list
id = ID
itemType = QName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (simpleType?))
</list>

<union
id = ID
memberTypes = Liste aus QName
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?, (simpleType*))
</union>

Schemakomponente Einfache 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.
{Basistyp-Definition}	Der zutreffende Fall unter den folgenden: 1 Falls die <restriction>-Alternative gewählt wird, dann die Typdefinition aufgelöst durch den tatsächlichen Wert des `base`-[Attributs] von <restriction>, falls vorhanden; andernfalls die Typdefinition, die dem <simpleType> unter den [Kindelementen] von <restriction> entspricht. 2 Falls die Alternative <list> oder <union> gewählt wird, dann die einfache Urtyp-Definition.
{abgeschlossen}	Wie für die Eigenschaft {Verbotene Ersetzungen} von komplexen Typdefinitionen, jedoch unter Verwendung der `final`- und `finalDefault`-[Attribute] anstelle der `block`- und `blockDefault`-[Attribute] und mit der relevanten Menge `{` extension, restriction, list, union `}`.
{Sorte}	Wenn die <list>-Alternative gewählt wird, dann list, wenn die <union>-Alternative gewählt wird, dann union, andernfalls (d.h. <restriction>-Alterative wird gewählt), die {Sorte} der {Basistyp-Definition}.

Wenn die {Sorte} atomic ist, sind auch die zusätzlichen Eigenschaftsabbildungen anwendbar:

Schemakomponente Einfache Typedefinition Atomar

Eigenschaft	Darstellung
{Primitiv-Typ-Definition}	Die vordefinierte primitive Typdefinition wird aus der {Basistyp-Definition} abgeleitet.
{Fassetten}	Eine Menge von Fassetten-Komponenten, die eine Beschränkung bilden, nämlich die {Fassetten} der {Basistyp-Definition} in Bezug auf eine Menge von Fassetten-Komponenten, die den zutreffenden [Kindelement]-Informationseinheiten von <restriction> (d.h. jene, die Fassetten spezifizieren, falls vorhanden) entsprechen, siehe Definition in Einschränkung des einfachen Typs (Fassetten) (§3.14.3).

Wenn die {Sorte} list ist, sind auch die folgenden zusätzlichen Eigenschaftsabbildungen anwendbar:

Schemakomponente Einfache Typdefinition Liste

Eigenschaft Darstellung

{Listenelement-Typ-Definition}

Der zutreffende Fall unter den folgenden:

1 Falls die <list>-Alternative gewählt wird, dann die Typdefinition aufgelöst durch den tatsächlichen Wert des itemType-[Attributs] <list>, falls vorhanden; andernfalls die Typdefinition, die dem <simpleType> in den [Kindelementen] von <list> entspricht.

2 Falls die <restriction>-Alternative gewählt wird, dann die {Listenelement-Typ-Definition} der {Basistyp-Definition}.

{Fassetten} Wenn die <restriction>-Alternative gewählt wird, eine Menge von Fassetten-Komponenten, die eine Beschränkung der {Fassetten} der {Basistyp-Definition} in Bezug auf eine Menge von Fassetten-Komponenten bilden, die den zutreffenden Element-Informationseinheiten in [Kindelemente] von <restriction> entsprechen (d.h. jene, die Fassetten spezifizieren, falls vorhanden), siehe Definition in Einschränkung des einfachen Typs (Fassetten) (§3.14.3); andernfalls die leere Menge.

Wenn die {Sorte} union ist, sind auch die folgenden zusätzlichen Eigenschaftsabbildungen anwendbar:

Schemakomponente Einfache Typdefinition Vereinigung

Eigenschaft Darstellung

{Mengenelement-Typ-Definition}

Der zutreffende Fall unter den folgenden:

1 Falls die Alternative <union> gewählt wird, dann [Definition:] seien die expliziten Mitglieder definiert als die Typdefinitionen aufgelöst durch die tatsächlichen Werte der Informationseinheiten des memberTypes-[Attributs], falls zutreffend. Der tatsächliche Wert wird dann durch Ersetzen einer Vereinigungs-Typdefinition in den expliziten Mitgliedern durch die Mitglieder ihrer {Mengenelement-Typ-Definition} in der angegebenen Reihenfolge gebildet.

2 Falls die Option <restriction> gewählt wird, dann die {Mengenelement-Typ-Definition} der {Basistyp-Definition}.

{Fassetten} Wenn die Alternative <restriction> gewählt wird, eine Menge von Fassetten-Komponenten, die eine Beschränkung der {Fassetten} der {Basistyp-Definition} in Bezug auf eine Menge von Fassetten-Komponenten bilden, die den zutreffenden Element-Informationseinheiten in [Kindelemente] von <restriction> (d.h. jene, die Fassetten spezifizieren, falls vorhanden) entsprechen, siehe Definition in Einschränkung des einfachen Typs (Fassetten) (§3.14.3); andernfalls die leere Menge.

3.14.3 (nicht-normativ) Bedingungen an die XML-Darstellung von einfachen Typdefinitionen

Bedingung an Schema-Darstellung: korrekte Darstellung der einfachen Typdefinition

Zusätzlich zu den Bedingungen, die Element-Informationseinheiten von <simpleType> vom Schema für Schemata auferlegt werden, müssen alle folgenden Aussagen wahr sein:

1 Die entsprechende einfache Typdefinition, falls vorhanden, muss die in Bedingungen an die Schemakomponente Definition eines einfachen Typs (§3.14.6) beschriebenen Bedingungen erfüllen.

2 Wenn die Alternative <restriction> gewählt wird, muss sie entweder ein base-[Attribut] oder einen <simpleType> in ihren [Kindelementen], aber nicht beides haben.

3 Wenn die Alternative <list> gewählt wird, muss sie entweder ein itemType-[Attribut] oder ein <simpleType> in ihren [Kindelementen] haben, aber nicht beides.

4 Zirkuläre Vereinigungs-Typdefinitionen sind unzulässig. D.h., wenn die Alternative <union> gewählt wird, darf es keine Einträge im memberTypes-[Attribut] auf irgendeiner Ebene geben, die auf die Komponente auflösen, die dem <simpleType> entspricht.

Bedingung an Schema-Darstellung: Einschränkung des einfachen Typs (Fassetten)

Damit eine einfache Typdefinition (man nenne sie R) eine andere einfache Typdefinition (man nenne sie B) mit einer Menge von Fassetten (man nenne sie S) beschränken kann, müssen alle folgenden Aussagen wahr sein:

1 Die {Sorte} und {Primitiv-Typ-Definition} von R sind die gleichen wie die von B.

2 Die {Fassetten} von R sind die Vereinigung von S mit den {Fassetten} von B, wodurch Duplikate vermieden werden. Wenn eine Fassette der gleichen Art sowohl in S als auch in den {Fassetten} von B vorkommt, wird diejenige in den {Fassetten} von B nicht einbezogen, mit Ausnahme der Fassetten enumeration und pattern, die mehrmals mit unterschiedlichen Werten vorkommen dürfen, um Duplikate zu vermeiden.

[Definition:] Wenn die obige Klausel 2 zutrifft, bilden die {Fassetten} von R eine Beschränkung der {Fassetten} von B in Bezug auf S .

3.14.4 Validierungsregeln für einfache Typdefinitionen

Validierungsregel: gültiger String

Eine Zeichenkette ist lokal gültig in Bezug auf eine einfache Typdefinition, wenn sie Schema-gültig hinsichtlich dieser Definition gemäß Definition in gültiger Datentyp in [XML Schemas: Datatypes] ist.

3.14.5 Beiträge von einfachen Typdefinitionen zum XML-Information-Set

Keine.

3.14.6 Bedingungen an die Schemakomponente Definition eines einfachen Typs

Alle einfachen Typdefinitionen (siehe Definition einfacher Typen (§3.14)) müssen die folgenden Bedingungen erfüllen:

Bedingung an Schemakomponente: Eigenschaften der einfachen Typdefinition

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften einer einfachen Typdefinition müssen der Beschreibung in der Eigenschaftsaufstellung in Definition Datentyp, vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3), entsprechen.

2 Zirkuläre Definitionen sind unzulässig. Das heißt, es muss möglich sein, einen vordefinierten primitiven Datentyp oder die einfache Urtyp-Definition zu ermitteln, indem die {Basistyp-Definition} wiederholt verfolgt wird.

3 Die Eigenschaft {abgeschlossen} der {Basistyp-Definition} darf kein restriction enthalten.

4 Wenn die {Basistyp-Definition} nicht die einfache Urtyp-Definition ist, müssen alle folgenden Aussagen wahr sein:

4.1 Die Definition muss eine gültige Beschränkung gemäß Definition in gültige Ableitung (Einschränkung, einfacher Typ) (§3.14.6) sein.

4.2 Wenn {Sorte} nicht atomic ist, dann muss der zutreffende Fall unter den folgenden wahr sein:

4.2.1 Falls die {Sorte} list ist, dann darf {abgeschlossen} der {Basistyp-Definition} nicht list enthalten.

4.2.2 Falls die {Sorte} union ist, dann darf {abgeschlossen} der {Basistyp-Definition} nicht union enthalten.

Bedingung an Schemakomponente: gültige Ableitung (Einschränkung, einfacher Typ)

Der zutreffende Fall unter den folgenden muss wahr sein:

1 Falls die {Sorte} atomic ist, dann müssen alle folgenden Aussagen wahr sein:

1.1 Die {Basistyp-Definition} muss eine atomare einfache Typdefinition oder ein vordefinierter primitiver Datentyp sein.

1.2 {abgeschlossen} der {Basistyp-Definition} darf nicht restriction enthalten.

1.3 Für jede Fassette in den {Fassetten} muss es eine Fassette der gleichen Art wie in den {Fassetten} der {Basistyp-Definition} geben, deren {Wert} für den fraglichen {Wert} der Fassette eine gültige Beschränkung gemäß Definition in [XML Schemas: Datatypes] sein muss.

2 Falls die {Sorte} list ist, dann müssen alle folgenden Aussagen wahr sein:

2.1 Die {Listenelement-Typ-Definition} muss eine {Sorte} vom Typ atomic oder union haben (in welchem Fall alle {Mengenelement-Typ-Definition}en atomic sein müssen).

2.2 Nur length-, minLength-, maxLength-, pattern- und enumeration-Fassetten-Komponenten sind in den {Fassetten} zugelassen.

2.3 Wenn die {Basistyp-Definition} nicht die einfache Urtyp-Definition ist, dann müssen alle folgenden Aussagen wahr sein:

2.3.1 Die {Basistyp-Definition} muss eine {Sorte} list haben.

2.3.2 {abgeschlossen} der {Basistyp-Definition} darf restriction nicht enthalten.

2.3.3 Für jede Fassette in den {Fassetten} muss es eine Fassette der gleichen Art in den {Fassetten} der {Basistyp-Definition} geben, deren {Wert} im {Wert} der fraglichen Fassette eine gültige Beschränkung gemäß Definition in [XML Schemas: Datatypes] sein muss.

3 Falls die {Sorte} union ist, dann müssen alle folgenden Aussagen wahr sein:

3.1 Die {Mengenelement-Typ-Definition}en müssen die {Sorte} atomic oder list haben.

3.2 Nur pattern- und enumeration-Fassetten-Komponenten sind in {Fassetten} zugelassen.

3.3 Wenn die {Basistyp-Definition} nicht die einfache Urtyp-Definition ist, dann müssen alle folgenden Aussagen wahr sein:

3.3.1 Die {Basistyp-Definition} muss die {Sorte} union haben.

3.3.2 {abgeschlossen} der {Basistyp-Definition} darf nicht restriction enthalten.

3.3.3 Für jede Fassette in den {Fassetten} muss es eine Fassette der gleichen Art in den {Fassetten} der {Basistyp-Definition} geben, deren {Wert} im {Wert} der fraglichen Fassette eine gültige Beschränkung gemäß Definition in [XML Schemas: Datatypes] sein muss.

[Definition:] Wenn die Einschränkung gültige Ableitung (Einschränkung, einfacher Typ) (§3.14.6) auf eine einfache Typdefinition zutrifft, ist sie eine gültige Einschränkung ihrer Basis-Typdefinition.

Bedingung an Schemakomponente: korrekte Typableitung (einfacher Typ)

Damit eine einfache Typdefinition (man nenne sie D, für abgeleitet (derived)) von einer einfachen Typdefinition (man nenne sie B, für Basis) mit einer Teilmenge von {extension, restriction, list, union} (von denen eigentlich nur restriction relevant ist) gültig abgeleitet werden kann, muss eine der folgenden Aussagen wahr sein:

1 Sie sind die gleiche Typdefinition.

2 Alle folgenden Aussagen müssen wahr sein:

2.1 restriction ist nicht in der Teilmenge oder im {abgeschlossen} der eigenen {Basistyp-Definition} enthalten.

2.2 Eine der folgenden Aussagen muss wahr sein:

2.2.1 Ds Basistypdefinition ist B.

2.2.2 Ds Basistypdefinition ist nicht die einfache Urtyp-Definition und wurde von B mit der Teilmenge gültig abgeleitet, wie von dieser Einschränkung definiert.

2.2.3 Ds {Sorte} ist list oder union und B ist die einfache Urtyp-Definition.

2.2.4 Bs {Sorte} ist union und D wurde von einer Typdefinition in Bs {Mengenelement-Typ-Definition} mit der Teilmenge gültig abgeleitet, wie von dieser Einschränkung definiert.

3.14.7 Vordefinierte einfache Typdefinitionen

Es gibt eine einfache Typdefinition, die mit der einfachen Version der Urtyp-Definition, die in jedem Schema nach Definition enthalten ist, nahezu identisch ist. Sie weist folgende Eigenschaften auf:

Einfache Typdefinition des Urtyps

Eigenschaft	Wert
{Name}	anySimpleType
{Ziel-Namensraum}	http://www.w3.org/2001/XMLSchema
{Basistyp-Definition}	die Urtyp-Definition
{abgeschlossen}	die leere Menge
{Sorte}	nicht verwendet

Einfache Typdefinitionen für alle vordefinierten primitiven Datentypen, d.h. string, boolean, float, double, number, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (siehe Primitive Datentypen in [XML Schemas: Datatypes]), sowie für die einfachen und komplexen Urtyp-Definitionen (wie zuvor beschrieben) sind per Definition in jedem Schema vorhanden. Alle befinden sich im XML-Schema-{Ziel-Namensraum} (Namensraum-Name http://www.w3.org/2001/XMLSchema), haben eine atomare {Sorte} mit einer leeren {Fassette}, die einfache Urtyp-Definition als ihre Basistyp-Definition und gelten selbst als {primitive Typdefinition}.

Ebenso sind einfache Typdefinitionen für alle vordefinierten abgeleiteten Datentypen (siehe Abgeleitete Datentypen in [XML Schemas: Datatypes]) per Definition in jedem Schema vorhanden und weisen Eigenschaften auf, die in [XML Schemas: Datatypes] spezifiziert und in XML in Schema für Schemata (normativ) (§A) dargestellt sind.

3.15 Schemata in ihrer Gesamtheit

3.15.1 Das Schema

3.15.2 XML-Darstellung von Schemata

3.15.3 Bedingungen an die XML-Darstellung von Schemata

3.15.4 Validierungsregeln für Schemata in ihrer Gesamtheit

3.15.5 Beiträge von Schemata zum XML-Information-Set

3.15.6 Bedingungen an Schemata in ihrer Gesamtheit

Beispiel

<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/beispiel">
  . . .
</xs:schema>

Die XML-Darstellung eines Schema-Gerüstes.

3.15.1 Das Schema

Auf der abstrakten Ebene ist das Schema lediglich ein Container für seine Komponenten. Die Schemakomponente:

Schemakomponente: Schema

{Typdefinitionen}: Eine Menge benannter einfacher oder komplexer Typdefinitionen.
{Attribut-Deklarationen}: Eine Menge benannter (top-level) Attribut-Deklarationen.
{Element-Deklarationen}: Eine Menge benannter (top-level) Element-Deklarationen.
{Attributgruppen-Definitionen}: Eine Menge benannter Attributgruppen-Definitionen.
{Elementgruppen-Definitionen}: Eine Menge benannter Elementgruppen-Definitionen.
{Notations-Deklarationen}: Eine Menge benannter Notations-Deklarationen.
{Anmerkungen}: Eine Menge von Anmerkungen.

3.15.2 XML-Darstellung von Schemata

Ein Schema wird in XML durch ein oder mehrere Schemadokumente, d.h. durch eine oder mehrere <schema>-Element-Informationseinheiten dargestellt. Ein Schemadokument enthält Darstellungen für eine Sammlung von Schemakomponenten, z.B. Typdefinitionen und Element-Deklarationen, die einen gemeinsamen {Ziel-Namensraum} haben. Ein Schemadokument, das eine oder mehrere <import>-Element-Informationseinheiten hat, entspricht einem Schema mit Komponenten mit mehr als einem {Ziel-Namensraum}, siehe Beschränkungen und Semantik zu Import (§4.2.3).

Zusammenfassung der XML-Darstellung: Element-Informationseinheit schema

<schema
attributeFormDefault = (qualified | unqualified) : unqualified
blockDefault = (#all | Liste aus ) : ''
elementFormDefault = (qualified | unqualified) : unqualified
finalDefault = (#all | Liste aus (extension | restriction)) : ''
id = ID
targetNamespace = anyURI
version = token
xml:lang = language
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)
</schema>

Schemakomponente Schema

Eigenschaft	Darstellung
{Typdefinitionen}	Die einfachen und komplexen Typdefinitionen, die allen <simpleType>- und <complexType>-Element-Informationseinheiten in den [Kindelementen] entsprechen, falls vorhanden, sowie möglicherweise enthaltene oder importierte Deklarationen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Attribut-Deklarationen}	Die Attribut-Deklarationen (der obersten Ebene), die allen <attribute>-Element-Informationseinheiten in den [Kindelementen]entsprechen, falls vorhanden, sowie möglicherweise enthaltene oder importierte Deklarationen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Element-Deklarationen}	Die Element-Deklarationen (der obersten Ebene), die allen <element>-Element-Informationseinheiten in den [Kindelementen] entsprechen, falls vorhanden, sowie möglicherweise enthaltene oder importierte Deklarationen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Attributgruppen-Definitionen}	Die Attributgruppen-Definitionen, die allen <attributeGroup>-Element-Informationseinheiten in [Kindelemente] entsprechen, falls vorhanden, sowie möglicherweise enthaltene und importierte Definitionen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Elementgruppen-Definitionen}	Die Elementgruppen-Definitionen, die allen <group>-Element-Informationseinheiten in den [Kindelementen] entsprechen, falls vorhanden, sowie möglicherweise enthaltene oder importierte Definitionen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Notations-Deklarationen}	Die Notations-Deklarationen, die allen <notation>-Element-Informationseinheiten in den [Kindelementen] entsprechen, falls vorhanden, sowie möglicherweise enthaltene oder importierte Deklarationen; siehe Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) und Referenzen auf Schemakomponenten in Namensräumen (§4.2.3).
{Anmerkungen}	Die Anmerkungen, die allen <annotation>-Element-Informationseinheiten in den [Kindelementen] entsprechen, falls vorhanden.

Man beachte, dass keine der oben gezeigten Attribut-Informationseinheiten direkt den Eigenschaften von Schemata entspricht. Die Attribute blockDefault, finalDefault, attributeFormDefault, elementFormDefault und targetNamespace werden in den obigen Unterabschnitten erwähnt, weil sie globale Informationen liefern, die auf viele Darstellungs-/ Komponentenen-Beziehungen anwendbar sind. Die anderen Attribute (id und version) dienen der Bequemlichkeit des Benutzers und diese Spezifikation definiert keine Semantik für diese Attribute.

Die Definition des abstrakten Datenmodells für Schemata in Abstraktes Datenmodell (§2.2) macht deutlich, dass die meisten Komponenten einen {Ziel-Namensraum} haben. Die meisten Komponenten, die Darstellungen innerhalb einer bestimmten <schema>-Element-Informationseinheit entsprechen, haben einen {Ziel-Namensraum}, der dem Attribut targetNamespace entspricht.

Da die leere Zeichenkette kein legaler Namensraum-Name ist, ist die Bereitstellung einer leeren Zeichenkette für Ziel-Namensraum nicht kohärent und nicht das Gleiche, als würde man überhaupt keinen spezifizieren. Die zutreffende Form von Schemadokumenten, die einem Schema entspricht, dessen Komponenten keinen {Ziel-Namensraum} haben, ist eine, in der überhaupt kein Attribut-Ziel-Namensraum spezifiziert ist.

Anmerkung:

In der Empfehlung für XML-Namensräume wird nur die Syntax von Instanzdokumenten für Elemente und Attribute diskutiert. Sie bietet daher kein direktes Framework für die Verwaltung der Namen von Typdefinitionen, Attributgruppen-Definitionen usw. Dennoch verwendet die Spezifikation die Ziel-Namensraum-Funktionalität gleichförmig für alle Schemakomponenten, d.h. nicht nur Deklarationen, sondern auch Definitionen haben einen {Ziel-Namensraum}.

Obwohl das Beispielschema am Anfang dieses Abschnitts ein komplettes XML-Dokument sein kann, muss <schema> nicht unbedingt das Dokumentelement sein, sondern kann innerhalb anderer Dokumente erscheinen. Tatsächlich besteht keine Anforderung, dass ein Schema einem (Text-)Dokument entspricht: Es kann einer „manuell“ erstellten Element-Informationseinheit für eine Instanz über ein DOM-konformes API entsprechen.

Abgesehen von <include> und <import>, die nicht direkt einer Schemakomponente entsprechen, entspricht jede der Element-Informationseinheiten, die im Inhalt von <schema> erscheinen, einer Schemakomponente, und alle außer <annotation> haben Namen. Alle diese Informationseinheiten werden nacheinander mit den entsprechenden Komponenten in den folgenden Abschnitten behandelt.

3.15.2.1 Referenzierung von Schemakomponenten

Referenzen auf Schemakomponenten aus einem Schemadokument werden einheitlich verwaltet, ungeachtet dessen, ob die Komponente einer Element-Informationseinheit aus dem gleichen Schemadokument entspricht oder aus einem externen Schema (das einem tatsächlichen Schemadokument entsprechen kann, aber nicht muss) importiert wurde; siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3). Alle diese Referenzen haben die Form QName.

[Definition:] Ein QName ist ein Name mit einer optionalen Namensraumqualifikation gemäß Definition in [XML-Namespaces]. Bei Verwendung in Verbindung mit der XML-Darstellung von Schemakomponenten oder Referenzen darauf bezieht sich dies auf den einfachen Typ QName gemäß Definition in [XML Schemas: Datatypes].

[Definition:] Ein NCName ist ein Name ohne Doppelpunkt, gemäß Definition in [XML-Namespaces]. Bei Verwendung in Verbindung mit der XML-Darstellung von Schemakomponenten in dieser Spezifikation bezieht sich dies auf den einfachen Typ NCName gemäß Definition in [XML Schemas: Datatypes].

In jeder der nachfolgend aufgeführten XML-Darstellungen wird ein Attribut mit Typ QName gezeigt, sofern es auf eine Schemakomponente verweist.

Beispiel

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xhtml="http://www.w3.org/1999/xhtml"
            xmlns="http://www.example.com"
            targetNamespace="http://www.example.com">
  . . .

  <xs:element name="Elem1" type="Adresse"/>

  <xs:element name="Elem2" type="xhtml:blockquote"/>

  <xs:attribute name="attr1"
                type="xsl:quantity"/>
  . . .
</xs:schema>

Die erste Element-Deklaration enthält höchstwahrscheinlich eine lokale Typreferenz, d.h. eine Referenz auf eine Element-Informationseinheit <complexType>, die in diesem Schemadokument definiert ist. Die anderen beiden Deklarationen referenzieren Typdefinitionen aus Schemata für andere Namensräume, für die Import-Anweisungen deklariert sein müssen. Siehe Referenzen auf Schemakomponenten in Namensräumen (§4.2.3) für eine Diskussion zum Importieren von Schemata.

3.15.2.2 Referenzierung von externen Schemakomponenten

Die Namen von Schemakomponenten wie beispielsweise Typdefinitionen und Element-Deklarationen sind nicht vom Typ ID: Sie sind nicht innerhalb eines Schemas, sondern nur innerhalb eines Symbolraums eindeutig. Dies bedeutet, dass einfache Fragment-Bezeichner nicht immer funktionieren, um auf Schemakomponenten außerhalb des Kontextes von Schemadokumenten zu referenzieren. Derzeit wird der MIME-Typ text/xml in der Definition der Interpretation von Fragment-Bezeichnern nicht unterstützt. Dies ist der MIME-Typ für Schemata für Referenzen auf Schemakomponenten als solche. Allerdings bietet [XPointer] einen Mechanismus, der sich gut auf das Konzept von Symbolräumen abbilden lässt, weil er in der XML-Darstellung von Schemakomponenten enthalten ist. Ein Fragment-Bezeichner in der Form #xpointer(xs:Schema/xs:Element[@name="person"]) identifiziert die Darstellung einer Element-Deklaration der obersten Ebene mit dem Namen person eindeutig, und ähnliche Fragment-Bezeichner können natürlich für die anderen globalen Symbolräume gebildet werden.

Außerdem können in manchen Fällen Fragment-Bezeichner in Kurzform benutzt werden, d.h. wenn eine DTD oder ein XML-Schema für das fragliche Schema verfügbar ist und die Bereitstellung eines id-Attributs für die Darstellungen aller primären und sekundären Schemakomponenten vom Typ ID ausgeschöpft wurde.

Den Anwendungen bleibt die Spezifikation überlassen, ob sie Referenzen auf Dokumentebene entweder als eine der obigen Varianten auf die relevanten Element-Informationseinheiten (d.h. ohne spezielle Erkennung der Beziehung zwischen Schemadokumenten und Schemakomponenten) oder als eine auf die entsprechende Schemakomponente interpretieren.

3.15.3 Bedingungen an die XML-Darstellung von Schemata

Bedingung an Schema-Darstellung: QName-Interpretation

Wenn der Typ einer Attribut-Informationseinheit in einem Dokument, das der Validierung unterzogen wurde, als QName identifiziert wurde, setzt sich sein tatsächlicher Wert aus einem [Definition:] lokalen Namen und einem [Definition:] Namensraum-Namen zusammen . Sein tatsächlicher Wert wird auf der Grundlage seines normalisierten Wertes und den [bereichsinternen Namensräumen] der enthaltenden Element-Informationseinheiten gemäß [XML-Namespaces] bestimmt:

Der zutreffende Fall unter den folgenden muss wahr sein:

1 Falls sein normalisierter Wert einen Präfix hat, dann müssen alle folgenden Aussagen wahr sein:

1.1 In den [bereichsinternen Namensräumen] muss es einen Namensraum geben, dessen [Präfix] zum Präfix passt.

1.2 Sein Namensraum-Name ist der [Namensraum-Name] dieses Namensraums.

1.3 Sein lokaler Name ist die Einheit seines normalisierten Wertes nach dem Doppelpunkt (':').

2 Sonst (sein normalisierter Wert hat keinen Präfix) müssen alle folgenden Aussagen wahr sein:

2.1 Sein lokaler Name ist sein normalisierter Wert.

2.2 Der zutreffende Fall unter den folgenden muss wahr sein:

2.2.1 Falls es in den [bereichsinternen Namensräumen] einen Namensraum gibt, dessen [Präfix] keinen Wert hat, dann ist sein Namensraum-Name der [Namensraum-Name] dieses Namensraumes.

2.2.2 Sonst ist sein Namensraum-Name nicht verwendet.

In Abwesenheit der Eigenschaft [bereichsinterne Namensräume] im Information-Set des fraglichen Schemadokuments müssen Prozessoren gleichwertige Informationen nach Bedarf mit Hilfe der [Namensraum-Attribute] der enthaltenen Element-Informationseinheiten und seinen Vorfahren rekonstruieren.

[Definition:] An allen Stellen, an denen in diesem Kapitel das Wort auflösen in irgendeiner Form in diesem Kapitel in Verbindung mit einem QName in einem Schemadokument verwendet wird, sollte es gemäß der Definition QName-Auflösung (Schemadokument) (§3.15.3) verstanden werden.

Bedingung an Schema-Darstellung: QName-Auflösung (Schemadokument)

Damit ein QName auf eine Schemakomponente einer spezifizierten Art auflösen kann, müssen alle folgenden Aussagen wahr sein:

1 Diese Komponente ist ein Mitglied des Werts der entsprechenden Eigenschaft des Schemas, das dem Schemadokument entspricht, in dem der QName erscheint, d.h. es muss der zutreffende Fall unter den folgenden wahr sein:

1.1 Falls die spezifizierte Art eine einfache oder komplexe Typdefinition ist, dann sind die {Typdefinitionen} die Eigenschaft.

1.2 Falls die spezifizierte Art Attribut-Deklaration ist, dann sind die {Attribut-Deklarationen} die Eigenschaft.

1.3 Falls die spezifizierte Art Element-Deklaration ist, dann sind die {Element-Deklarationen} die Eigenschaft.

1.4 Falls die spezifizierte Art Attributgruppe ist, dann sind die {Attributgruppen-Definitionen} die Eigenschaft.

1.5 Falls die spezifizierte Art Elementgruppe ist, dann sind die {Elementgruppen-Definitionen} die Eigenschaft.

1.6 Falls die spezifizierte Art Notations-Deklaration ist, dann sind die {Notations-Deklarationen} die Eigenschaft.

2 Ihr {lokaler Name} passt zum lokalen Namen von QName.

3 Ihr {Ziel-Namensraum} ist identisch mit dem Namensraum-Namen von QName.

4 Ihr Namensraum-Name ist entweder der Ziel-Namensraum des Schemadokuments, das QName enthält, oder das Schemadokument enthält eine <import>-Element-Informationseinheit, deren tatsächlicher Wert des Namensraum-[Attribut] mit diesem Namensraum-Namen identisch ist.

3.15.4 Validierungsregeln für Schemata in ihrer Gesamtheit

Wie aus der Diskussion in Schemakomponenten im Detail (§3) deutlich wird, gibt es auf der Ebene von Schemakomponenten und Validierung normalerweise keine Namens-Referenzen auf Komponenten. In wenigen Fällen müssen qualifizierte Namen aber, die in zu validierenden Informationseinheiten erscheinen, durch Namens-Referenzen auf Schemakomponenten aufgelöst werden. In diesen Fällen wird die folgende Einschränkung angewendet:

Validierungsregel: QName-Auflösung (Instanz)

Ein Paar aus einem lokalen Namen und einem Namensraum-Namen (oder nicht verwendet) wird in eine Schemakomponente einer spezifizierten Art im Kontext der Validierung aufgelöst, indem die entsprechende Eigenschaft des für die Prüfung benutzten Schemata herangezogen wird. Jede dieser Eigenschaften indiziert Komponenten durch Namen. Die zu benutzende Eigenschaft wird durch die Art der spezifizierten Komponente bestimmt, d.h. es muss der zutreffende Fall unter den folgenden wahr sein:

1 Falls die spezifizierte Art eine einfache oder komplexe Typdefinition ist, dann sind die {Typdefinitionen} die Eigenschaft.

2 Falls die spezifizierte Art eine Attribut-Deklaration ist, dann sind die {Attribut-Deklarationen} die Eigenschaft.

3 Falls die spezifizierte Art eine Element-Deklaration ist, dann sind die {Element-Deklarationen} die Eigenschaft.

4 Falls die spezifizierte Art eine Attributgruppe ist, dann sind die {Attributgruppen-Definitionen} die Eigenschaft.

5 Falls die spezifizierte Art eine Elementgruppe ist, dann sind die {Elementgruppen-Definitionen} die Eigenschaft.

6 Falls die spezifizierte Art eine Notations-Deklaration ist, dann sind die {Notations-Deklarationen} die Eigenschaft.

Die aufgelöste Komponente ist der Eintrag in der Tabelle, dessen {lokaler Name} zum lokalen Namen des Paars passt und dessen {Ziel-Namensraum} mit dem Namensraum-Namen des Paars identisch ist.

3.15.5 Beiträge von Schemata zum XML-Information-Set

Beitrag zum Schema Information Set: Schema-Information

Schemakomponenten bieten eine Fülle von Informationen über die Basis der Prüfung, die auch für die anschließende Verarbeitung relevant sein können. Die Widerspiegelung einer Komponentenstruktur in einer Form, die für die Einbeziehung in das Information-Set nach der Schema-Validierung geeignet ist, ist eine der Möglichkeiten, die diese Spezifikation bietet, um solche Informationen zur Verfügung zu stellen.

Dementsprechend gilt die [Definition:] Mit der isomorphen Einheit einer Komponente ist eine Informationseinheit gemeint, deren Typ demjenigen der Komponente entspricht, mit einer Eigenschaft pro Eigenschaft der Komponente, mit dem gleichen Namen und mit einem Wert, der entweder der gleiche atomare Wert oder eine Informationseinheit ist, die auf die gleiche Weise seinem Komponentenwert entspricht, je nach Bedarf rekursiv.

Prozessoren müssen nach der Schema-Validierung eine Eigenschaft aus dem Infoset zu der Element-Informationseinheit hinzufügen, bei der die Prüfung begann, und zwar wie folgt:

PSVI-Beiträge für die Informationseinheit Element

[Schema-Informationen]

Eine Menge von Informationseinheiten Namensraum-Schema-Informationen, eine für jeden Namensraum-Namen, der als {Ziel-Namensraum} einer Schemakomponente in dem Schema erscheint, das für diese Prüfung verwendet wird, und eine für nicht verwendet, falls eine Schemakomponente in dem Schema keinen {Ziel-Namensraum} hat. Jede Informationseinheit Namensraum-Schema-Information hat die folgenden Eigenschaften und Werte:

PSVI-Beiträge für die Informationseinheit Namensraum-Schema-Informationen

[Schema-Namensraum]

Ein Namensraum-Name oder nicht verwendet.

[Schemakomponenten]

Eine (möglicherweise leere) Menge von Schemakomponenten-Informationseinheiten, von denen jede eine isomorphe Einheit einer Komponente ist, deren {Ziel-Namensraum} die obige Eigenschaft [Schema-Namensraum] aus dem für Prüfung benutzten Schema ist.

[Schemadokumente]

Eine (möglicherweise leere) Menge von Schemadokument-Informationseinheiten mit den folgenden Eigenschaften und Werten für jedes Schemadokument, das Komponenten zu dem Schema beigetragen hat und dessen targetNamespace mit der obigen [Schema-Namensraum]-Eigenschaft übereinstimmt (oder dessen targetNamespace nicht verwendet ist, das aber Komponenten zu diesem Namensraum durch <include>-Anweisungen in einem Schemadokument mit diesem targetNamespace gemäß Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten (§4.2.1) beigetragen hat):

PSVI-Beiträge für die Informationseinheit Schemadokument

[Dokument-Ort]: Entweder eine URI-Referenz, falls verfügbar, andernfalls nicht verwendet
[Dokument]: Eine Dokument-Informationseinheit, falls verfügbar, andernfalls nicht verwendet.

Die {Schemakomponenten}-Eigenschaft wird für Prozessoren bereitgestellt, die einen einzigen Zugriffspunkt auf die Komponenten des Schemas, das während der Prüfung benutzt wird, bieten wollen. Einfachen Prozessoren steht es frei, dies leer zu lassen. Wenn sie aber nicht bereitgestellt wird, müssen mindestens alle Komponenten der obersten Ebene (d.h. benannte) bereitgestellt werden, die tatsächlich in der Prüfung vorgekommen sind, und zwar direkt oder indirekt (weil eine anonyme Komponente, die in der Prüfung vorkam, darin enthalten ist).

Beitrag zum Schema Information Set: ID/IDREF-Tabelle

Im Infoset von Informationseinheiten nach der Schema-Validierung ist eine Menge von Informationseinheiten ID/IDREF-Bindung mit der Element-Informationseinheit Validierungs-Wurzel assoziiert:

PSVI-Beiträge für die Informationseinheit Element

[ID/IDREF-Tabelle]: Eine (möglicherweise leere) Menge von ID/IDREF-Bindungs-Informationseinheiten, gemäß unten folgender Spezifikation.

[Definition:] Die geeignete Einheiten-Menge sei die Menge, die aus jeder Attribut- oder Element-Informationseinheit besteht, für die alle folgenden Aussagen wahr sind:

1 Ihr [Validierungskontext] ist Validierungs-Wurzel;

2 Sie wurde erfolgreich hinsichtlich einer Attribut-Deklaration validiert gemäß lokal gültiges Attribut (§3.2.4) oder Element-Deklaration gemäß lokal gültiges Element (Element) (§3.3.4) (je nach zutreffendem Fall), deren Attribut {Typdefinition} oder Element {Typdefinition} die vordefinierte einfache Typdefinition ID, IDREF oder IDREFS oder ein davon abgeleiteter Typ ist.

Dann gibt es eine ID/IDREF-Bindung in der [ID/IDREF-Tabelle] für jede Zeichenkette, die eine der folgenden ist:

1 der tatsächliche Wert eines Mitglieds der geeigneten Einheiten-Menge, deren Typdefinition ID oder IDREF ist oder daraus abgeleitet wurde;

2 eine der Einheiten im tatsächlichen Wert eines Mitglieds der geeigneten Einheiten-Menge, deren Typdefinition IDREFS ist oder daraus abgeleitet wurde

Jede ID/IDREF-Bindung hat folgende Eigenschaften:

PSVI-Beiträge für die Informationseinheit ID/IDREF-Bindung

[id]: Die oben identifizierte Zeichenkette.
[Bindung]: Eine Menge, bestehend aus jeder Element-Informationseinheit, für die alle folgenden Aussagen wahr sind:

1 Ihr [Validierungs-Kontext] ist das Ausgangselement der Validierung.

2 Sie hat eine Attribut-Informationseinheit in ihren [Attributen] oder eine Element-Informationseinheit in ihren [Kindelementen], die durch die vordefinierte einfache Typdefinition ID oder einem daraus abgeleiteten Typ validiert wurde, dessen [Schema-normalisierter Wert] die [id] dieser ID/IDREF-Bindung ist.

Dies hat die Nettowirkung, dass es einen Eintrag für jede als ID verwendete Zeichenkette gibt, entweder durch Deklaration oder durch Referenz, assoziiert mit den Elementen, soweit vorhanden, die diese ID tatsächlich haben. In gültige Validierungswurzel (ID/IDREF) (§3.3.4) wird die Validierungsregel beschrieben, die hier auf Fehler prüft.

Anmerkung:

Die Informationseinheit ID/IDREF-Bindung ist im Gegensatz zu den meisten anderen Aspekten dieser Spezifikation im Wesentlichen ein interner Speichermechanismus. Er wird eingeführt, um die obige Definition von gültige Validierungswurzel (ID/IDREF) (§3.3.4) zu unterstützen. Dementsprechend können konforme Prozessoren sie in ihrem Infoset nach der Validierung ausweisen, müssen dies aber nicht. Mit anderen Worten, die obige Einschränkung kann so interpretiert werden, dass man die Prüfung fortführt, als ob solch ein Infoset existieren würde.

3.15.6 Bedingungen an Schemata in ihrer Gesamtheit

Alle Schemata (siehe Schemata in ihrer Gesamtheit (§3.15)) müssen folgende Bedingung erfüllen:

Bedingung an Schemakomponente: Schema-Eigenschaften

Alle folgenden Aussagen müssen wahr sein:

1 Die Werte der Eigenschaften eines Schemas müssen der Beschreibung in der Eigenschaftsaufstellung in Das Schema (§3.15.1), vorbehaltlich der Auswirkung von Fehlende Subkomponenten (§5.3) entsprechen.

2 Keine der {Typdefinitionen}, {Element-Deklarationen}, {Attributgruppen-Definitionen}, {Elementgruppen-Definitionen} und {Notations-Deklarationen} darf zwei oder mehr Schemakomponenten mit dem gleichen {Namen} und {Ziel-Namensraum} enthalten.

4 Schemata und Namensräume: Zugriff und Komposition

In diesem Kapitel werden die Mechanismen definiert, durch welche diese Spezifikation die nötige Vorbedingung für den Validierungsprozess aufstellt, nämlich den Zugriff auf eines oder mehrere Schemata. Außerdem werden in diesem Kapitel die Beziehung zwischen Schemata und Namensräumen und die Mechanismen für die Modularisierung von Schemata, einschließlich der Bereitstellung von Integrationsmechanismen für Definitionen und Deklarationen, möglicherweise mit Modifikationen, von einem Schema in ein anderes ausführlich beschrieben.

In Konformität (§2.4) werden drei Ebenen der Konformität für Schema-Prozessoren beschrieben, und Schemata und Schemagültiger Validierungsprozess (§5) bieten eine formelle Definition des Validierungsprozesses. In diesem Abschnitt wird die dreischichtige Architektur, die von den drei Konformitätsebenen impliziert wird, detailliert behandelt. Die Schichten sind:

Der Kern des Validierungsprozesses, der sich auf Schemakomponenten und Instanz-Informationseinheiten bezieht
Schema-Repräsentation: Die Verbindungen zwischen XML-Repräsentationen und Schemakomponenten, einschließlich der Beziehungen zwischen Namensräumen und Schemakomponenten
Richtlinien für die Web-Interoperabilität von XML-Schemata: Instanz->Schema- und Schema->Schema-Verbindungen für das WWW.

Schicht 1 spezifiziert die Art, in der ein aus Schemakomponenten bestehendes Schema im Validierungsprozess einer Instanz-Element-Informationseinheit angewandt werden kann. Schicht 2 spezifiziert die Verwendung von <schema>-Elementen in XML-Dokumenten als die XML-Standardrepräsentation für Schema-Informationen in dem breiten Gebiet von Computersystemen und Ausführungsumgebungen. Um Interoperabilität über das World Wide Web zu unterstützen, bietet Schicht 3 eine Reihe von Konventionen für Schema-Referenzen im Web. Weitere Einzelheiten über alle drei Schichten werden in späteren Abschnitten beschrieben.

4.1 Schicht 1: Übersicht über den Kern der Schemagültigkeitsprüfung

Der grundlegende Zweck des Validierungsprozess-Kerns ist die Definition des Validierungsprozesses für eine einzelne Element-Informationseinheit und ihre Nachfahren in Bezug auf die Definition eines komplexen Typs. Alle Prozessoren müssen diesen Kern auf eine Weise implementieren, die genau dieser Spezifikation entspricht.

Ein Validierungsprozess ist in Bezug auf ein XML Schema (man beachte: nicht auf ein Schemadokument) definiert, das aus (mindestens) der Menge von Schemakomponenten (Definitionen und Deklarationen) besteht, die für den betreffenden Validierungsprozess erforderlich sind. Dies ist keine zirkuläre Definition, sondern vielmehr eine post-facto-Feststellung: Keine Element-Informationseinheit kann voll validiert werden, solange nicht alle erforderlichen Komponenten, die durch irgendeinen Aspekt des (potenziell rekursiven) Validierungsprozesses benötigt werden, im Schema selbst vorhanden sind.

Wie oben spezifiziert, steht jede Schemakomponente direkt oder indirekt mit einem Ziel-Namensraum oder explizit mit keinem Namensraum in Verbindung. Im Fall von Dokumenten mit mehreren Namensräumen werden Komponenten mit mehr als einem Ziel-Namensraum in einem Schema koexistieren.

Prozessoren haben die Option, das gesamte Schema vor Beginn eines Validierungsprozesses zu assemblieren (und vielleicht zu optimieren oder vorab zu kompilieren) oder das Schema locker zusammenzustellen und einzelne Komponenten nach Bedarf zu assemblieren. In allen Fällen ist Folgendes erforderlich:

Der Prozessor muss mit dem transitiven Auffinden der Schemakomponenten, die für die Fertigstellung eines Validierungsprozesses erforderlich sind, erfolgreich sein (man beachte, dass von Schemakomponenten abgeleitete Komponenten mit anderweitig erhaltenen Komponenten integriert werden können).
Keine Definition oder Deklaration darf sich ändern, nachdem sie einmal aufgestellt wurde.
Falls der Prozessor sich dafür entscheidet, Deklarationen und Definitionen dynamisch zu erfassen, darf es bei einer solchen dynamischen Erfassung keine Seiteneffekte geben, durch die sich die Ergebnisse des Validierungsprozesses von der Vorgehensweise unterscheiden würden, bei der die gleichen Schemakomponenten alle auf einmal erfasst werden.

Anmerkung:

Der Kern des Validierungsprozesses wird in Bezug auf Schemakomponenten auf einer abstrakten Ebene definiert und die Syntax der Schemadefinition (d.h. <schema>) wird nicht erwähnt. Obwohl viele Prozessoren wahrscheinlich Schemata in diesem Format erfassen, arbeiten andere möglicherweise mit kompilierten Darstellungen, mit einer programmatischen Darstellung wie in manchen Programmiersprachen, usw.

Ein schemafähiger Prozessor ist, was den Kern des Validierungsprozesses anbelangt, verpflichtet, eine oder mehrere Optionen für den Validierungsprozess wie unten in Validierung der Schemagültigkeit (§5.2) aufgeführt zu implementieren. Im Bereich dieser Spezifikation liegen weder die Auswahl von Element-Informationseinheiten für diesen Validierungsprozess, noch die Mittel, die für die Initiierung des Validierungsprozesses benutzt werden.

Obwohl der Validierungsprozess rekursiv definiert wird, soll er auch in stream-verarbeitenden Prozessoren implementierbar sein. Solche Prozessoren bevorzugen es möglicherweise, das Schema während der Verarbeitung inkrementell zu assemblieren, z.B. um neue Namensräume zu berücksichtigen. Die Auswirkung der oben ausgedrückten Regeln ist die, dass eine solche inkrementelle Assemblierung zu dem gleichen Ergebnis des Validierungsprozesses führen muss, wie bei der Durchführung des Validierungsprozesses mit dem endgültigen, voll assemblierten Schema.

4.2 Schicht 2: Schemadokumente, Namensräume und Komposition

4.2.1 Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten

4.2.2 Einfügung von modifizierten Komponenten-Definitionen

4.2.3 Referenzen auf Schemakomponenten in Namensräumen

Die Unterabschnitte von Schemakomponenten im Detail (§3) definieren eine XML-Darstellung für Typdefinitionen und Element-Deklarationen usw., wobei ihr Ziel-Namensraum spezifiziert in Schemadokumenten erfasst wird. Die beiden folgenden Abschnitte beziehen sich auf die Assemblierung eines kompletten Schemas für den Validierungsprozess aus mehreren Quellen. Sie sollten nicht als eine Form der Textersetzung, sondern vielmehr als Bereitstellung von Mechanismen für die verteilte Definition von Schemakomponenten mit einer entsprechenden schemaspezifischen Semantik verstanden werden.

Anmerkung:

Die Architektur des Kerns des Validierungsprozesses setzt voraus, dass ein komplettes Schema mit allen notwendigen Deklarationen und Definitionen verfügbar ist. Dies kann die Auflösung von Instanz->Schema- und Schema->Schema-Referenzen voraussetzen. Wie unter Konformität (§2.4) erwähnt, wird erwartet, dass sich die genauen Mechanismen für die Auflösung solcher Referenzen im Lauf der Zeit entwickeln. Zur Unterstützung einer solchen Evolution beachtet diese Spezifikation das Designprinzip, dass Referenzen von einem Schemadokument auf ein Schema Mechanismen anwenden, die direkt mit denen vergleichbar sind, die für die Referenz eines Schemas von einem Instanzdokument aus benutzt werden.

Anmerkung:

In den unten folgenden Abschnitten gehört "SchemaLocation" eigentlich zu Schicht 3. Der Bequemlichkeit halber wird dieses Thema aber mit den Mechanismen der Schicht 2, d.h. import und include, dokumentiert, weil es mit diesen eng verbunden ist.

4.2.1 Assemblierung eines Schemas für einen einzelnen Ziel-Namensraum aus mehreren Schema-Definitionsdokumenten

Schemakomponenten für einen einzelnen Ziel-Namensraum können aus mehreren Schemadokumenten, d.h. mehreren <schema>-Element-Informationseinheiten assembliert werden:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit include

<include
id = ID
schemaLocation = anyURI
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</include>

Eine <schema>-Informationseinheit kann eine beliebige Zahl von <include>-Elementen beinhalten. Ihre schemaLocation-Attribute, bestehend aus einer URI-Referenz, identifizieren andere Schemadokumente, d.h. <schema>-Informationseinheiten.

Das XML Schema, das <schema> entspricht, enthält nicht nur die Komponenten, die ihrer Definition und Deklaration nach [Kindelemente]n entsprechen, sondern auch alle Komponenten aller XML Schemata, die einem <include>-Schemadokument entsprechen. Solche eingefügten Schemadokumente müssen entweder (a) den gleichen targetNamespace wie das Schemadokument, in welchem das <include> aufgerufen wurde, oder (b) überhaupt keinen targetNamespace haben. In letzterem Fall wird das <include>-Schemadokument in den targetNamespace des Schemadokuments konvertiert, von dem das <include> ausging.

Bedingung an Schema-Darstellung: Beschränkungen und Semantik zu Einfügungen

Zusätzlich zu den Bedingungen, die den <include>-Element-Informationseinheiten durch das Schema für Schemata auferlegt sind, müssen alle folgenden Aussagen wahr sein:

1 Falls der tatsächliche Wert des schemaLocation-[Attribut]s erfolgreich aufgelöst wird, muss eine der folgenden Aussagen wahr sein:

1.1 Er wird aufgelöst in (einem Fragment) eine Ressource, welche ein XML-Dokument (des Typs application/xml oder text/xml mit einer XML-Deklaration als Präferenz, aber dies ist nicht erforderlich) ist. Diese Ressource korrespondiert mit einer <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, die wiederum mit einem gültigen Schema korrespondiert.

1.2 Er wird aufgelöst in eine <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, welche wiederum mit einem gültigen Schema korrespondiert.

In beiden Fällen benennt man die <include> (eingefügte) <schema>-Einheit SII, das gültige Schema I und die das <include> aufrufende Eltern-<schema>-Einheit SII’.

2 Eine der folgenden Aussagen muss wahr sein:

2.1 SII hat ein targetNamespace-[Attribut] und dessen tatsächlicher Wert ist identisch mit dem tatsächlichen Wert des targetNamespace-[Attribut]s des SII’ (welches solch ein [Attribut] haben muss).

2.2 Weder SII noch SII’ haben ein targetNamespace-[Attribut].

2.3 SII hat kein targetNamespace-[Attribut] (aber SII’ hat eines).

3 Der zutreffende Fall unter den folgenden muss wahr sein:

3.1 Falls Klausel 2.1 oder Klausel 2.2 oben erfüllt wird, dann muss das Schema, welches mit SII’ korrespondiert, nicht nur die Definitionen oder Deklarationen, die zu den entsprechenden Mitgliedern ihrer eigenen [Kindelemente] gehören, einfügen, sondern auch die Komponenten, die mit all den Schemakomponenten von I identisch sind.

3.2 Falls Klausel 2.3 oben erfüllt ist, dann muss das Schema, welches mit dem <include> (eingefügten) Eltern-<schema> korrespondiert, nicht nur die Definitionen oder Deklarationen, die zu den entsprechenden Mitgliedern ihrer eigenen [Kindelemente] gehören, einfügen, sondern auch die Komponenten, die mit all den Schemakomponenten von I identisch sind. Ausgenommen davon ist, wenn irgendwo der Ziel-Namensraum-Name nicht verwendet wird, so wird der tatsächliche Wert des targetNamespace-[Attribut]s von SII’ benutzt. Insbesondere ersetzt dieser den nicht verwendeten Ziel-Namensraum-Namen in folgenden Fällen:

3.2.1 Den {Ziel-Namensraum} von benannten Schemakomponenten, sowohl auf oberster Ebene als auch (im Fall von verschachtelten Typdefinitionen, verschachtelten Attributen und Element-Deklarationen, deren code qualifiziert ist) innerhalb von Definitionen.

3.2.2 Die {Namensraum-Beschränkung} einer Wildcard, sei sie negiert oder nicht.

Es ist kein Fehler für den tatsächlichen Wert des schemaLocation-[Attribut]s wenn keine Auflösung möglich ist. In diesem Fall wird dann keine entsprechende Einfügung durchgeführt. Es ist jedoch ein Fehler, wenn zwar aufgelöst werden kann, aber der zweite Teil des obigen Falls 1 nicht erfüllt wird. Bei Auflösungsfehlern können die Validierungsergebnisse selbstverständlich nicht vollständig sein.

Anmerkung:

Wie in Fehlende Subkomponenten (§5.3) beschrieben, schlägt die Auflösung von QNamen in XML-Darstellungen möglicherweise fehl, was dazu führt, dass Komponenten auf Grund fehlender Subkomponenten unvollständig und unbrauchbar sind. Während der Schemakonstruktion dürften Implementierungen der QNamen-Werte für solche Referenzen beibehalten werden für den Fall, dass sie in anschließenden Verarbeitungsschritten referenziert werden. Nicht verwendete Ziel-Namensraum-Namen von vorläufig unaufgelösten Referenz-QNamen in <include>-Komponenten sollten ebenfalls konvertiert werden, wenn Klausel 3.2 erfüllt wird.

Anmerkung:

Der obige Wortlaut ist vorsichtig gewählt, so dass mehrfaches <include> (Einfügen) des gleichen Schemadokuments keine Verletzung von Klausel 2 in Schema-Eigenschaften (§3.15.6) darstellt. Anwendungen ist es jedoch erlaubt bzw. es wird sogar empfohlen, mehrfaches <include> (Enfügen) des gleichen Schemadokuments zu vermeiden, um der Notwendigkeit vorzubeugen, Identität von Komponente zu Komponente herstellen zu müssen.

4.2.2 Einfügung von modifizierten Komponenten-Definitionen

Um eine gewisse Unterstützung für künftige Weiterentwicklungen und Versionsbildungen zu bieten, ist es möglich, Komponenten zu integrieren, die einem Schemadokument mit Modifikationen entsprechen. Die Modifikationen haben eine durchdringende Auswirkung, d.h. es werden nur die neudefinierten Komponenten benutzt, auch wenn sie von anderen integrierten Komponenten referenziert werden, ungeachtet dessen, ob diese neu definiert sind oder nicht.

Zusammenfassung der XML-Darstellung: Element-Informationseinheit redefine

<redefine
id = ID
schemaLocation = anyURI
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation | (simpleType | complexType | group | attributeGroup))*
</redefine>

Eine <schema>-Informationseinheit kann eine beliebige Anzahl von <redefine>-Elementen enthalten. Ihre schemaLocation-Attribute, bestehend aus einer URI-Referenz, identifizieren andere Schemadokumente, d.h. <schema>-Informationseinheiten.

Das XML Schema, das <schema> entspricht, enthält nicht nur die Komponenten, die ihrer Definition und Deklaration nach [Kindelemente] entsprechen, sondern auch alle Komponenten aller XML Schemata, die irgendeinem <redefine> (neu definierten) Schemadokument entsprechen. Solche Schemadokumente müssen entweder (a) den gleichen targetNamespace wie das <redefine> (neu definierte) Schemadokument oder (b) überhaupt keinen targetNamespace haben. Im letzteren Fall wird dann das <redefine> (neu definierte) Schemadokument in den targetNamespace des Schemadokuments konvertiert, in dem das <redefine> aufgerufen wurde.

Die Definitionen innerhalb des <redefine>-Elements selbst sind in Bezug auf sich selbst auf Redefinitionen von Komponenten des <redefine> (neu definierten) Schemadokuments eingeschränkt. Das heißt:

Typdefinitionen müssen sich selbst als ihre Basistyp-Definition benutzen.
Attributgruppen-Definitionen und Elementgruppen-Definitionen müssen Obermengen oder Teilmengen ihrer ursprünglichen Definitionen sein, entweder durch Einfügung genau einer Referenz auf sich selbst oder dadurch, dass sie ausschließlich (möglicherweise beschränkte) Komponenten enthalten, die auf entsprechende Weise in ihrer <redefine>-Version (neuen Definition) erscheinen.

Nicht alle Komponenten des <redefine> (neu definierten) Schemadokuments müssen neudefiniert werden.

Dieser Mechanismus dient der Bereitstellung einer deklarativen und modularen Vorgehensweise für die Schema-Modifikation, wobei sich die Funktionalität nicht unterscheidet, außer in dem Umfang, der sich ergeben würde, wenn man globalen Text kopiert und durch Editieren neu definiert. Insbesondere ist die Neudefinition eines Typs nicht mit Sicherheit frei von Nebeneffekten: Dies kann unerwartete Auswirkungen auf andere Typdefinitionen haben, die auf der Neudefinition dieses Typs basieren, sogar in dem Umfang, dass einige dieser Definitionen ihre Wohlgeformtheit verlieren.

Anmerkung:

Die durchdringende Auswirkung von Neudefinitionen bestärkt die Notwendigkeit, dass Implementierungen eine gewisse lässige Form oder eine 'Just-in-Time-Vorgehensweise' bei der Komponentenkonstruktion umsetzen, was auch nötig ist, um unangebrachte Abhängigkeiten von der Reihenfolge, in der Definitionen und Referenzen in Schemadokumenten (bzw. Ansammlungen davon) erscheinen, zu vermeiden.

Beispiel

v1.xsd:
 <xs:complexType name="personName">
  <xs:sequence>
   <xs:element name="title" minOccurs="0"/>
   <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:element name="addressee" type="personName"/>

v2.xsd:
 <xs:redefine schemaLocation="v1.xsd">
  <xs:complexType name="personName">
   <xs:complexContent>
    <xs:extension base="personName">
     <xs:sequence>
      <xs:element name="generation" minOccurs="0"/>
     </xs:sequence>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:redefine>

 <xs:element name="author" type="personName"/>

In dem Schema, das v2.xsd entspricht, ist alles gemäß v1.xsd spezifiziert, wobei der Typ personName neu definiert ist, sowie alles, das er selbst spezifiziert. Diesem Schema zufolge können Elemente, die durch den Typ personName eingeschränkt sind, mit einem Element generation enden. Dies beinhaltet nicht nur das Element author, sondern auch das Element addressee.

Bedingung an Schema-Darstellung: Beschränkungen und Semantik zu Neudefinitionen

Zusätzlich zu den Bedingungen, die den <redefine>-Element-Informationseinheiten durch das Schema für Schemata auferlegt sind, müssen alle folgenden Aussagen wahr sein:

1 Falls es irgendwelche anderen Element-Informationseinheiten unter den [Kindelemente]n gibt als <annotation>, dann muss der tatsächliche Wert des schemaLocation-[Attribut]s erfolgreich aufgelöst werden.

2 Falls der tatsächliche Wert des schemaLocation-[Attribut]s erfolgreich aufgelöst wird, muss eine der folgenden Aussagen wahr sein:

2.1 Er wird aufgelöst zu (einem Fragment) einer Ressource, welche ein XML-Dokument (siehe Klausel 1.1) ist. Diese Ressource korrespondiert mit einer <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, welches wiederum mit einem gültigen Schema korrespondiert.

2.2 Er wird aufgelöst zu einer <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, welches wiederum mit einem gültigen Schema korrespondiert.

In beiden Fällen benennt man die <redefine> (neu definierte) <schema>-Einheit SII, das gültige Schema I und die das <redefine> aufrufende Eltern-<schema>-Einheit SII’.

3 Eine der folgenden Aussagen muss wahr sein:

3.1 SII hat ein targetNamespace-[Attribut] und dessen tatsächlicher Wert ist identisch mit dem tatsächlichen Wert des targetNamespace-[Attribut]s des SII’ (welches solch ein [Attribut] haben muss).

3.2 Weder SII noch SII’ haben ein targetNamespace-[Attribut].

3.3 SII hat kein targetNamespace-[Attribut] (aber SII’ hat eines).

4 Der zutreffende Fall unter den folgenden muss wahr sein:

4.1 Falls Klausel 3.1 oder Klausel 3.2 oben erfüllt wird, dann muss das Schema, welches mit SII’ korrespondiert, nicht nur die Definitionen oder Deklarationen, die zu den entsprechenden Mitgliedern ihrer eigenen [Kindelemente] gehören, einfügen, sondern auch die Komponenten, die zu all den Schemakomponenten von I identisch sind, mit der Ausnahme derer, die explizit neu definiert wurden (siehe Individuelle Komponenten Neudefinition (§4.2.2) unten).

4.2 Falls Klausel 3.3 oben erfüllt ist, dann muss das Schema, welches mit SII’ korrespondiert, nicht nur die Definitionen oder Deklarationen, die zu den entsprechenden Mitgliedern ihrer eigenen [Kindelemente] gehören, einfügen, sondern auch die Komponenten, die mit all den Schemakomponenten von I identisch sind, mit der Ausnahme derer die explizit neu definiert wurden (siehe Individuelle Komponenten Neudefinition (§4.2.2) unten). Ausgenommen davon ist, wenn irgendwo der Ziel-Namensraum-Name nicht verwendet wird, so wird der tatsächliche Wert des targetNamespace-[Attribut]s von SII’ benutzt (für Details siehe Klausel 3.2 in Beschränkungen und Semantik zu Einfügungen (§4.2.1)).

5 Innerhalb der [Kindelemente] muss jeder <simpleType> ein <restriction> unter seinen [Kindelemente]n haben und jeder <complexType> muss ein restriction oder ein extension unter seinen [Enkel-Elemente]n haben; der tatsächliche Wert dieses base-[Attribut]s muss derselbe Wert wie der tatsächliche Wert seines eigenen name-Attributs plus dem Ziel-Namensraum sein.

6 Innerhalb der [Kindelemente] muss für jedes der passende Fall unter den folgenden wahr sein:

6.1 Falls ein Element <group> als Inhalt auf derselben Ebene wie der tatsächliche Wert existiert, dessen ref-[Attribut] dasselbe ist wie der tatsächliche Wert seines eigenen name-Attributs plus dem Ziel-Namensraum, dann müssen alle folgenden Aussagen wahr sein:

6.1.1 Es muss genau eine solche Gruppe besitzen.

6.1.2 Der tatsächliche Wert der beiden [Attribut]e minOccurs und maxOccurs dieser Gruppe muss 1 (oder er darf nicht vorhanden) sein.

6.2 Falls es keine solche Selbst-Referenz hat, dann müssen alle folgenden Aussagen wahr sein:

6.2.1 Der tatsächliche Wert seines eigenen name-Attributs plus dem Ziel-Namensraum muss erfolgreich in eine Elementgruppen-Definition in I aufgelöst werden.

6.2.2 Die {Elementgruppe} der Elementgruppen-Definition, die mit ihr über die XML-Darstellung der Schemakomponente Elementgruppen-Definition (§3.7.2) korrespondiert, muss eine gültige Einschränkung der {Elementgruppe} dieser Elementgruppen-Definition in I haben, wie in gültige Partikel (Einschränkung) (§3.9.6) definiert ist.

7 Innerhalb der [Kindelemente]

7.1 ein <attributeGroup> unter den Inhalten des tatsächlichen Wertes existiert, dessen ref-[Attribut] dasselbe wie der tatsächliche Wert seines eigenen name-Attributs plus dem Ziel-Namensraum ist

muss es genau eine solche Gruppe geben.

7.2 es keine solche Selbst-Referenz hat

müssen alle folgenden Aussagen wahr sein:

7.2.1 Der tatsächliche Wert seines eigenen name-Attributs plus dem Ziel-Namensraum muss erfolgreich in eine Attributgruppen-Definition in I auflösen.

7.2.2 Die {Attribut-Verwendung} und das {Wildcard-Attribut} der Attributgruppen-Definition, die mit ihr über die XML-Darstellung der Schemakomponente Attributgruppen-Definition (§3.6.2) korrespondiert, müssen eine gültige Einschränkung der {Attribut-Verwendung} und des {Wildcard-Attribut}s dieser Attributgruppen-Definition in I sein, wie es in Klausel 2, Klausel 3 und Klausel 4 des Paragraphen gültige Ableitung (Einschränkung, komplexer Typ) (§3.4.6) (wobei die Referenzen zur Basistyp-Definition als Referenzen zu der Attributgruppen-Definition in I verstanden werden) definiert ist.

Anmerkung:

Eine Attributgruppe, die restriktiv gemäß Klausel 7.2 neu definiert ist, korrespondiert mit einer Attributgruppe, deren {Attribut-Verwendung} ausschließlich aus den Attribut-Verwendungen besteht, die den <attribute>-Elementen entsprechen, die explizit unter den [Kindelemente]n der <redefine> (neu definierten) <attributeGroup> vorhanden sind. Es gibt keine Vererbung von der <redefine> (neu definierten) Attributgruppe. Ihr {Wildcard-Attribut} basiert ebenfalls ausschließlich auf einem expliziten <anyAttribute>, falls vorhanden.

Bedingung an Schema-Darstellung: Individuelle Komponenten Neudefinition

Zu jedem nicht-<annotation>-Mitgliedselement der [Kindelemente] eines <redefine> gibt es entsprechend ein oder zwei Schemakomponenten in dem <redefine> (neu definierten) Schema:

1 Die [Kindelemente]-Informationseinheiten <simpleType> und <complexType> korrespondieren beide mit zwei Komponenten:

1.1 Eine Komponente, die der Definition auf der obersten Ebene mit demselben name in dem <redefine> (neu definierten) Schemadokument entspricht, wie es in Schemakomponenten im Detail (§3) definiert ist; ausgenommen, ihr {name} wird nicht verwendet

1.2 Eine Komponente, die mit der Informationseinheit selbst korrespondiert, wie in Schemakomponenten im Detail (§3) definiert; ausgenommen, ihre {Basistyp-Definition} ist die in 1.1 oben definierte Komponente.

Diese Paarung sichert zu, dass die Kohärenz-Beschränkungen bezüglich Typ-Definitionen respektiert werden, während zur selben Zeit die gewünschte Wirkung dadurch erreicht wird, dass sich Referenzen zu Namen von neu definierten Komponenten in beiden, den <redefine>ing (neu zu definierenden) und <redefine>d (neu definierten) Schemadokumenten zu der neu definierten Komponente, wie sie in 1.2 oben spezifiziert ist, auflösen.

2 Die <group>- und <attributeGroup>-[Kindelemente] korrespondieren jeweils mit einer einzelnen Komponente, wie in Schemakomponenten im Detail (§3) definiert; ausgenommen für den Fall, dass eine Selbst-Referenz, die auf einem ref-[Attribut] basiert und deren tatsächlicher Wert derselbe ist wie der name der Informationseinheit inklusive dem aufgelösten Ziel-Namensraum, einer Komponente, die mit der definierten Informationseinheit desselben Namens auf oberster Ebene korrespondiert und der in I benutzten Art entspricht.

In allen Fällen muss es auf der obersten Ebene eine Definition des entsprechenden Namens und der Art in dem <redefine>d (neu definierten) Schemadokument geben.

Anmerkung:

Der obige Wortlaut ist vorsichtig genug, so dass mehrere äquivalente <redefine> (Neu-Definitionen) des gleichen Schemadokuments keine Verletzung von Klausel 2 in Schema-Eigenschaften (§3.15.6) bilden. Anwendungen ist es jedoch erlaubt bzw. es wird sogar empfohlen, <redefine> (Neu-Definitionen) des gleichen Schemadokuments auf demselben Weg mehr als einmal zu vermeiden, um der Notwendigkeit vorzubeugen, Identität von Komponente zu Komponente aufstellen zu müssen (obwohl dies für die individuellen Neudefinitionen selbst getan werden muss).

4.2.3 Referenzen auf Schemakomponenten in Namensräumen

Wie in Abstraktes Datenmodell (§2.2) beschrieben, steht jede Schemakomponente der obersten Ebene mit einem Ziel-Namensraum (oder explizit mit keinem) in Verbindung. In diesem Abschnitt werden der genaue Mechanismus und die Syntax in XML-Form der Schemadefinition beschrieben, durch die eine Referenz auf eine fremde Komponente erfolgt, d.h. eine Komponente mit einem unterschiedlichen Ziel-Namensraum als demjenigen der referenzierenden Komponente.

Zwei Dinge sind erforderlich: nicht nur ein Mittel der Adressierung solcher fremden Komponenten, sondern auch ein Signal für schemabewusste Prozessoren, dass ein Schemadokument solche Referenzen enthält:

Zusammenfassung der XML-Darstellung: Element-Informationseinheit import

<import
id = ID
namespace = anyURI
schemaLocation = anyURI
{weitere Attribute, die nicht im Schema-Namensraum sind . . .}>
Inhalt: (annotation?)
</import>

Die Element-Informationseinheit <import> identifiziert Namensräume, die in externen Referenzen benutzt werden, d.h. in jenen, deren QName identifiziert, dass sie aus einem anderen Namensraum (oder keinem) als dem einschließenden targetNamespace des Schemadokuments stammen. Der tatsächliche Wert seines namespace-[Attribut]s weist darauf hin, dass das enthaltende Schemadokument qualifizierte Referenzen auf Schemakomponenten in diesem Namensraum (über ein oder mehrere Präfixe, die auf übliche Weise mit Namensraum-Deklarationen deklariert werden) enthalten kann. Wenn dieses Attribut nicht verwendet wird, dann erlaubt der Import unqualifizierte Referenzen auf Komponenten ohne Ziel-Namensraum. Man beachte, dass zu importierende Komponenten nicht unbedingt die Form eines Schemadokuments haben müssen. Dem Prozessor steht es frei, Mittel nach eigener Wahl anzuwenden, um auf Komponenten zuzugreifen oder Komponenten zu bilden.

Der tatsächliche Wert von schemaLocation, falls vorhanden, liefert einen Hinweis darauf, wo eine Serialisierung eines Schemadokuments mit Deklarationen und Definitionen für diesen Namensraum (oder keinen) gefunden werden kann. Wenn kein schemaLocation-[Attribut] vorhanden ist, überlässt der Schema-Autor die Identifikation dieses Schemas der Instanz, der Anwendung oder dem Benutzer, und zwar über die in Schicht 3: Zugriff auf Schemadokumente und Web-Interoperabilität (§4.3) beschriebenen Mechanismen. Wenn eine schemaLocation vorhanden ist, muss sie eine einzelne URI-Referenz enthalten, mit welcher der Schema-Autor sicherstellt, dass eine Auflösung in eine Serialisierung eines Schemadokuments erfolgt, das die Komponenten des <import>ierten Namensraums enthält, auf die anderswo im enthaltenden Schemadokument referenziert wird.

Anmerkung:

Da sowohl das namespace- als auch das schemaLocation-[Attribut] optional sind, ist eine leere import-Informationseinheit erlaubt. Dadurch werden einfache unqualifizierte Referenzen auf fremde Komponenten ohne Ziel-Namensraum und ohne jeglichen Hinweis, wo sie zu finden sind, erlaubt.

Beispiel

Derselbe Namensraum kann für beides benutzt werden, für reelle Arbeiten und für die Fälle, in denen Schemakomponenten durch externe Komponenten definiert werden:

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:html="http://www.w3.org/1999/xhtml"
        targetNamespace="uri:mywork" xmlns:my="uri:mywork">

 <import namespace="http://www.w3.org/1999/xhtml"/>

 <annotation>
  <documentation>
   <html:p>[Einige Dokumentationen für mein Schema]</html:p>
  </documentation>
 </annotation>

 . . .

 <complexType name="myType">
  <sequence>
   <element ref="html:p" minOccurs="0"/>
  </sequence>
  . . .
 </complexType>

 <element name="myElt" type="my:myType"/>
</schema>

Die Behandlung von Referenzen als QNamen impliziert, dass ohne massive Neudeklaration des voreingestellten Namensraums entweder interne Referenzen auf die zu definierenden Namen in einem Schemadokument oder die Schemadeklarations- und -definitionselemente selbst explizit qualifiziert sein müssen, weil sich der Ziel-Namensraum und der XML-Schema-Namensraum unterscheiden (mit Ausnahme des Schemas für Schemata). Bei diesem Beispiel wurde die erste Option gewählt; die meisten anderen Beispiele in dieser Spezifikation verwenden die zweite.

Bedingung an Schema-Darstellung: Beschränkungen und Semantik zu Import

Zusätzlich zu den Bedingungen, die den <import>-Element-Informationseinheiten durch das Schema für Schemata auferlegt sind, müssen alle folgenden Aussagen wahr sein:

1 Der zutreffende Fall unter den folgenden muss wahr sein:

1.1 Falls das namespace-[Attribut] vorhanden ist, dann muss dessen tatsächlicher Wert nicht mit dem tatsächlichen Wert des umhüllenden <schema>-targetNamespace-[Attribut] übereinstimmen.

1.2 Falls das namespace-[Attribut] nicht vorhanden ist, dann muss das umhüllende <schema> ein targetNamespace [Attribut] haben.

2 Falls die Anwendung die Strategie verfolgt, Schemareferenzen über die tatsächlichen Werte der schemaLocation- und namespace-[Attribute] zu benutzen, stellt sie eine Referenz zur Verfügung, wie sie in Strategie für Schemadokument-Standorte (§4.3.2) definiert wird, muss eine der folgenden Aussagen wahr sein:

2.1 Die Referenz ist (ein Fragment) eine(r) Ressource, die ein XML-Dokument (siehe Klausel 1.1) ist. Diese Ressource korrespondiert mit einer <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, die wiederum mit einem gültigen Schema korrespondiert.

2.2 Die Referenz ist eine <schema>-Element-Informationseinheit in einem wohlgeformten XML-Information-Set, die wiederum mit einem gültigen Schema korrespondiert.

In beiden Fällen benennt man die <schema>-Einheit SII und das gültige Schema I.

3 Der zutreffende Fall unter den folgenden muss wahr sein:

3.1 Falls ein namespace-[Attribut] existiert, dann muss sein tatsächlicher Wert identisch mit dem tatsächlichen Wert des targetNamespace-[Attribut]s von SII sein.

3.2 Falls kein namespace-[Attribut] existiert, dann darf SII kein targetNamespace-[Attribut] haben

Es ist kein Fehler für die Anwendung, wenn die Strategie zur Schemareferenzierung misslingt. Es ist jedoch ein Fehler auszulösen, aber der Rest der Klausel 2 oben kann nicht erfüllt werden. Das Misslingen, eine Referenz zu finden, kann natürlich keine vollständigen Validierungsprozess-Ergebnisse nach sich ziehen.

Die Schemakomponenten (das heißt {Typdefinitionen}, {Attribut-Deklarationen}, {Element-Deklarationen}, {Attributgruppen-Definitionen}, {Elementgruppen-Definitionen}, {Notations-Deklarationen}) eines Schemas, welche mit einer <schema>-Element-Informationseinheit mit einer oder mehreren <import>-Element-Informationseinheiten korrespondieren, müssen nicht nur Definitionen und Deklarationen korrespondierend mit ihren entsprechenden Elementmitgliedern ihrer [Kindelemente] einfügen, sondern auch für jede der <import>-Element-Informationseinheiten, für die Klausel 2 oben erfüllt ist, eine Menge von Schemakomponenten, die identisch mit allen Schemakomponenten von I sind.

Anmerkung:

Der obige Wortlaut ist vorsichtig, so dass die mehrfache Verwendung von <import> des gleichen Schemadokuments keine Verletzung von Klausel 2 der Schema-Eigenschaften (§3.15.6) darstellt. Anwendungen ist es jedoch erlaubt bzw. es wird sogar empfohlen, die mehrfache Verwendung von <import> bezüglich desselben Schemadokuments vermeiden, um der Notwendigkeit vorzubeugen, die Identität komponentenweise aufstellen zu müssen. Angesichts der Tatsache, dass das schemaLocation-[Attribut] lediglich ein Hinweis ist, steht es Anwendungen frei, alles außer dem ersten <import> für einen vorgegebenen Namensraum zu ignorieren, ungeachtet des tatsächlichen Werts von schemaLocation. Mit dieser Strategie wird allerdings riskiert, nützliche Informationen zu verlieren, wenn man neue schemaLocations bereitstellt.

4.3 Schicht 3: Zugriff auf Schemadokumente und Web-Interoperabilität

4.3.1 Standards für die Darstellung von Schemata und Retrieval von Schemadokumenten im Web

4.3.2 Finden von Schemadefinitionen im Web

Die Schichten 1 und 2 bieten ein Rahmenwerk für den Validierungsprozess und die XML-Definition von Schemata in einer breiten Vielfalt von Umgebungen. Im Laufe der Zeit werden vielleicht Standards und Konventionen entwickelt, um Interoperabilität von XML-Schema-Implementierungen im World Wide Web zu unterstützen. Schicht 3 definiert den Mindestumfang an Funktionen, die alle konformen Prozessoren für die Operation im Web unterstützen müssen: Es wird beabsichtigt, im Laufe der Zeit künftige Standards (z.B. XML Packages) für die Interoperabilität im Web und in anderen Umgebungen einzuführen, ohne diese Spezifikation nochmals neu veröffentlichen zu müssen.

4.3.1 Standards für die Darstellung von Schemata und Retrieval von Schemadokumenten im Web

Zum Zweck der Interoperabilität können serialisierte Schemadokumente ebenso wie alle übrigen Web-Ressourcen durch URI identifiziert und mit Hilfe der Standardmechanismen des Web (z.B. http, https, usw.) abgerufen werden. Solche Dokumente im Web müssen Teil von XML-Dokumenten sein (siehe Klausel 1.1) und sie werden im Standardformat für XML-Schemadefinitionen präsentiert, das für Schicht 2 beschrieben ist (d.h. <schema>-Element-Informationseinheiten).

Anmerkung:

Es wird oft vorkommen, dass ein Schemadokument ein komplettes XML-1.0-Dokument ist, dessen Dokumentelement <schema> ist. In anderen Fällen werden <schema>-Teile in anderen Dokumenten enthalten sein, auf die möglicherweise mittels Fragment- und/oder XPointer-Notation referenziert wird.

Anmerkung:

Die Variationen zwischen Serversoftware und Administrations-Policies von Websites erschweren es oft, einen bestimmten Ansatz für das Retrieval von Anfragen zu empfehlen, um serialisierte Schemadokumente abzurufen. Ein vernünftiger Ausgangspunkt ist vielleicht die Verwendung des Accept-Headers

application/xml,
                     text/xml; q=0.9, */*

4.3.2 Finden von Schemadefinitionen im Web

Wie in Schicht 1: Übersicht über den Kern der Schemagültigkeitsprüfung (§4.1) beschrieben, sind Prozessoren dafür verantwortlich, die Schemakomponenten (Definitionen und Deklarationen) bereitzustellen, die für den Validierungsprozess notwendig sind. In diesem Abschnitt werden normative Konventionen eingeführt, um die Interoperabilität für Instanz- und Schemadokumente, die vom Web abgerufen und verarbeitet werden, zu erleichtern.

Anmerkung:

Wie in Schicht 2: Schemadokumente, Namensräume und Komposition (§4.2) oben beschrieben, kann es auch andere Web-fremde Mechanismen für die Bereitstellung von Schemata für den Validierungsprozess geben; diese liegen allerdings nicht im Bereich dieser Spezifikation.

Prozessoren steht es im Web frei, einen Validierungsprozess mit beliebigen Schemata auf eine der in Validierung der Schemagültigkeit (§5.2) beschriebenen Arten durchzuführen. Allerdings ist eine gemeinsame Konvention hilfreich, um das zu verwendende Schema zu bestimmen. Dementsprechend müssen sich universelle schemabewusste Prozessoren (d.h. diejenigen, die nicht auf bestimmte Schemata fixiert sind) bei dem Validierungsprozess eines Dokuments im Web wie folgt verhalten:

Soweit nicht anderweitig vom Benutzer vorgegeben, wird der Validierungsprozess mit den Element-Informationseinheiten des spezifizierten Dokuments durchgeführt.
Soweit nicht anderweitig vom Benutzer vorgegeben, muss der Prozessor ein Schema konstruieren, das einem Schemadokument entspricht, dessen targetNamespace mit dem Namensraum-Namen, falls vorhanden, der Element-Informationseinheit, mit der der Validierungsprozess durchgeführt wird, identisch ist.

Die Komposition des kompletten Schemas für die Verwendung in einem Validierungsprozess wird in Schicht 2: Schemadokumente, Namensräume und Komposition (§4.2) beschrieben. Die für das Auffinden entsprechender Schemadokumente benutzten Mittel sind vom Prozessor und von der Anwendung abhängig, vorbehaltlich folgender Anforderungen:

Schemata werden im Web in der in Standards für die Darstellung von Schemata und Retrieval von Schemadokumenten im Web (§4.3.1) spezifizierten Form dargestellt.
Der Autor eines Dokuments benutzt Namensraum-Deklarationen, um die beabsichtigte Interpretation von darin erscheinenden Namen zu bezeichnen. Es kann ein Schema über den Namensraum-Namen abrufbar sein, muss aber nicht. Das heißt, ungeachtet dessen, ob das Default-Verhalten eines Prozessors ein solches Dereferenzieren versucht oder nicht, muss er immer in der Lage sein, Benutzerdefinitionen statt diesem Default den Vorrang zu geben.

Anmerkung:
Die Erfahrungen haben gezeigt, dass es aus Performance-Sicht nicht in allen Fällen sicher oder wünschenswert ist, das Dereferencing von Namensraum-Namen als Selbstverständlichkeit zu betrachten. Benutzergemeinschaften und/oder Verbraucher/Provider- Vereinbarungen geben möglicherweise Umstände vor, in denen ein solches Dereferenzieren eine sensible Default-Strategie ist: Diese Spezifikation erlaubt es bestimmten Gemeinschaften, solche Konventionen aufzustellen und zu implementieren, schreibt dies aber nicht vor. Benutzern steht es immer frei, Namensraum-Namen als schemaLocation-Information bereitzustellen, wenn Dereferencing gewünscht ist (siehe unten).
Wenn andererseits ein Dokument mit einem bestimmten Schema von einem (menschlichen oder nicht) Dokumentautor erstellt wurde und gewährleistet wird, dass das Dokument ganz oder teilweise mit diesem Schema konform ist, dann werden die schemaLocation- und noNamespaceSchemaLocation-[Attribute] (im Instanz-Namensraum von XML Schema, d.h. http://www.w3.org/2001/XMLSchema-instance) (nachfolgend xsi:schemaLocation und xsi:noNamespaceSchemaLocation) bereitgestellt. Das erste enthält die Gewährleistung des Autors mit Paaren von URI-Referenzen (eine für den Namensraum-Namen und eine für einen Hinweis auf den Standort eines Schemadokuments, das Namen für diesen Namensraum-Namen definiert). Das zweite bietet ebenfalls eine URI-Referenz als Hinweis auf den Standort eines Schemadokuments ohne targetNamespace-[Attribut].
Soweit keine anderslautenden Anweisungen vorliegen, beispielsweise durch die aufrufende Anwendung oder durch eine Befehlszeilenoption, sollten Prozessoren das Dereferencing jeder URI-Referenz auf Schemadokumentstandorte im tatsächlichen Wert solcher xsi:schemaLocation- und xsi:noNamespaceSchemaLocation-[Attribute] versuchen; siehe Einzelheiten weiter unten.
xsi:schemaLocation- und xsi:noNamespaceSchemaLocation-[Attribute] können in jedem Element vorkommen. Allerdings ist es ein Fehler, wenn ein solches Attribut nach dem ersten Erscheinen einer Element- oder Attribut-Informationseinheit innerhalb einer Element-Informationseinheit vorkommt, die anfangs validiert wurde und dessen [Namensraum-Namen] es adressiert. Entsprechend den Regeln Schicht 1: Übersicht über den Kern der Schemagültigkeitsprüfung (§4.1) kann das entsprechende Schema locker assembliert werden, ist andernfalls aber durch den Validierungsprozess hindurch stabil. Obwohl schemaLocation-Attribute für jedes Element vorkommen und inkrementell bei ihrer Entdeckung verarbeitet werden können, ist ihre Wirkung im Wesentlichen für den Validierungsprozess global. Definitionen und Deklarationen bleiben über den Bereich des Elements, in dem die Bindung deklariert wird, hinaus wirksam.

Beispiel

Mehrfache Schema-Bindungen können über ein einziges Attribut deklariert werden. Betrachten Sie zum Beispiel folgendes Stylesheet:

 <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                http://www.w3.org/1999/XSL/Transform.xsd
                                http://www.w3.org/1999/xhtml
                                http://www.w3.org/1999/xhtml.xsd">

Die in schemaLocation benutzten Namensraum-Namen können, müssen aber nicht, mit jenen identisch sein, die tatsächlich das Element qualifizieren, innerhalb dessen Start-Tag es sich befindet, oder mit einem seiner anderen Attribute. Beispielsweise können wie oben alle schemaLocation-Informationen auf Wunsch für das Dokumentelement eines Dokuments deklariert werden, ungeachtet dessen, wo die Namensräume wirklich benutzt werden.

Bedingung an Schema-Darstellung: Strategie für Schemadokument-Standorte

Für einen gegebenen Namensraum-Namen (oder keinen) und eine (optionale) URI-Referenz für xsi:schemaLocation oder xsi:noNamespaceSchemaLocation sollten schemabewusste Prozessoren jede Kombination der folgenden Strategien in beliebiger Reihenfolge implementieren:

1 Tue nichts, zum Beispiel weil ein Schema Komponenten für den gegebenen Namensraum-Namen enthält, von dem schon bekannt ist, dass er verfügbar ist, oder weil von vornherein bekannt ist, dass alle Bemühungen, Schemadokumente zu lokalisieren, nicht erfolgreich sein werden (zum Beispiel in eingebetteten Systemen).

2 Basierend auf dem schemaLocation-URI, identifiziere ein existierendes Schemadokument entweder als XML-Dokument-Ressource oder als <schema>-Element-Informationseinheit in irgendeinem lokalen Schema-Repository.

3 Basierend auf dem Namensraum-Namen identifiziere ein existierendes Schemadokument entweder als XML-Dokument-Ressource oder als <schema>-Element-Informationseinheit in irgendeinem lokalen Schema-Repository.

4 Versuche, den schemaLocation-URI aufzulösen, um eine Ressource im Web zu lokalisieren, die ein <schema>-Element ist, enthält oder darauf referenziert.

5 Versuche, den Namensraum-Namen aufzulösen, um eine solche Ressource zu lokalisieren.

Wann immer möglich sollten Konfigurations- oder Aufruf-Optionen für die Auswahl und/oder die Reihenfolge der implementierten Strategien angeboten werden.

Verbesserte oder alternative Konventionen für Web-Interoperabilität können in Zukunft standardisiert werden, ohne diese Spezifikation neu zu definieren. Beispielsweise erwägt das W3C derzeit Initiativen, um das Packaging von Ressourcen in Bezug auf bestimmte Dokumente und/oder Namensräume zu standardisieren: Dies wäre eine Ergänzung zu den hier in Schicht 3 beschriebenen Mechanismen. Diese Architektur vereinfacht auch Innovationen auf Schicht 2: So wäre es beispielsweise in Zukunft möglich, einen zusätzlichen Standard für die Darstellung von Schemakomponenten zu definieren, der z.B. erlaubt, Typdefinitionen stückweise zu spezifizieren statt alle auf einmal.

`[5]`	`token`	`::=`	`'.' \| '/' \| '//' \| '\|' \| '@' \| NameTest`
`[6]`	`whitespace`	`::=`	`S`

XML Schema Teil 1: Strukturen

Deutsche Übersetzung

XML Schema Teil 1: Strukturen

W3C Empfehlung 2. Mai 2001

Zusammenfassung

Dokumentstatus

Inhaltsverzeichnis

Anhang

1 Einleitung

1.1 Zweck

1.2 Abhängigkeiten von anderen Spezifikationen

1.3 Konventionen und Terminologie

2 Konzeptioneller Rahmen

2.1 Übersicht zu XML Schema

2.2 Abstraktes Datenmodell

2.2.1 Typdefinitions-Komponenten

2.2.1.1 Typhierarchie

2.2.1.2 Einfache Typdefinition

2.2.1.3 Komplexe Typdefinition

2.2.2 Deklarations-Komponenten

2.2.2.1 Element-Deklaration

2.2.2.2 Element-Ersetzungsgruppe

2.2.2.3 Attribut-Deklaration

2.2.2.4 Notations-Deklaration

2.2.3 Elementgruppen-Komponenten

2.2.3.1 Elementgruppe

2.2.3.2 Partikel

2.2.3.3 Attribut-Verwendung

2.2.3.4 Wildcard

2.2.4 Komponenten zur Definition von Identitätsbeschränkungen

2.2.5 Gruppen-Definitions-Komponenten

2.2.5.1 Elementgruppen-Definition

2.2.5.2 Attributgruppen-Definition

2.2.6 Anmerkungs-Komponenten

2.3 Bedingungen und Validierungsregeln

2.4 Konformität

2.5 Namen und Symbolbereiche

2.6 Schema-bezogene Auszeichnungen in Instanzdokumenten

2.6.1 xsi:type

2.6.2 xsi:nil

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

2.7 Schema-Darstellung im World Wide Web

3 Schemakomponenten im Detail

3.1 Einführung

3.1.1 Komponenten und ihre Eigenschaften

3.1.2 XML-Darstellung von Komponenten

3.1.3 Die Abbildung zwischen XML-Darstellungen und Komponenten

3.1.4 Leerraum-Normalisierung während der Validierung

3.2 Attribut-Deklarationen

3.2.1 Die Schemakomponente Attribut-Deklaration

3.2.2 XML-Darstellung der Schemakomponente Attribut-Deklaration

3.2.3 Bedingungen an die XML-Darstellung von Attribut-Deklarationen

3.2.4 Validierungsregeln für Attribut-Deklarationen

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

3.2.6 Bedingungen an die Schemakomponente Attribut-Deklaration

3.2.7 Vordefinierte Attribut-Deklarationen

3.3 Element-Deklarationen

3.3.1 Die Schemakomponente Element-Deklaration

3.3.2 XML-Darstellung der Schemakomponente Element-Deklaration

3.3.3 Bedingungen an die XML-Darstellung von Element-Deklarationen

3.3.4 Validierungsregeln für Element-Deklarationen

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

3.3.6 Bedingungen an die Schemakomponente Element-Deklaration

3.4 Definition komplexer Typen

3.4.1 Die Schemakomponente Definition eines komplexen Typs

3.4.2 XML-Darstellung der komplexen Typdefinition

3.4.3 Bedingungen an die XML-Darstellung von komplexen Typdefinitionen

3.4.4 Validierungsregeln für komplexe Typdefinitionen

3.4.5 Beiträge von komplexen Typdefinitionen zum XML-Information-Set

3.4.6 Bedingungen an die Schemakomponente komplexe Typdefinition

3.4.7 Vordefinierte komplexe Typdefinitionen

3.5 Attribut-Verwendungen

3.5.1 Die Schemakomponente Attribut-Verwendung

3.5.2 XML-Darstellung der Komponente Attribut-Verwendung

3.5.3 Bedingungen an die XML-Darstellung der Attribut-Verwendungs-Komponente

3.5.4 Validierungsregeln für Attribut-Verwendungen

3.5.5 Beiträge von Attribut-Verwendungen zum XML-Information-Set

3.5.6 Bedingungen an die Schemakomponente Attribut-Verwendung

3.6 Attributgruppen-Definitionen

3.6.1 Die Schemakomponente Attributgruppen-Definition