Detaillierte Erläuterung des Beispielcodes zum Erweitern der Aufzählungsliste im XML-Schema

Das Hinzufügen neuer Werte zu einer Liste ist eine häufige und notwendige Anforderung. Musterdesigner möchten häufig in einer System-Architektur eine Möglichkeit einbauen, einen Mehrwert zu schaffen, und dieser Mehrwert ist während der Entwurfsphase nicht bekannt. Wie kann ein Schema-Designer eine erweiterbare, einfach zu implementierende Liste aufgezählter Werte erstellen? In diesem Artikel werden verschiedene Möglichkeiten vorgestellt, um dieses Ziel zu erreichen. Musterdesigner und -implementierer benötigen eine Erweiterung Das Hinzufügen neuer Werte zu einer Liste ist eine häufige und notwendige Anforderung. Musterdesigner möchten häufig eine Möglichkeit in die Systemarchitektur einbauen, einen Mehrwert zu schaffen, und dieser Mehrwert ist während der Entwurfsphase nicht bekannt. Wie kann ein Schema-Designer eine erweiterbare, einfach zu implementierende Liste von Aufzählungswerten erstellen? In diesem Artikel werden verschiedene Möglichkeiten vorgestellt, um dieses Ziel zu erreichen.
Schemadesigner und -implementierer benötigen eine Möglichkeit, vorhandene Aufzählungslisten in XML-Schemas zu erweitern. Leider erlaubt die XML-Schema-Spezifikation keine Erweiterung während der Erstellung dieser Listen (siehe Verwandte Themen). Die während der Entwurfsphase ausgewählten Werte sind fest und verfügbar. Trotz dieser Einschränkung nutzen Menschen immer noch verschiedene Alternativen, um eine Listenerweiterung zu erreichen. Dies wird häufig von Kunden gewünscht, die vorhandene Schemata verwenden, die nicht geändert werden können. Sie möchten die Abwärtskompatibilität wahren und gleichzeitig neue Funktionen hinzufügen. In diesem Artikel erfahren Sie, wie Musterdesigner die Hindernisse überwunden haben, um diese Funktionalität zu erreichen.
Eine Aufzählungsliste ist ein spezifizierter Satz von Werten für einen bestimmten Datenpunkt. Beispielsweise können Sie Ländercodes über eine feste Werteliste anzeigen, darunter DE (Deutschland), US (Vereinigte Staaten) und JP (Japan). Was sollte angesichts gegebener Werte getan werden, wenn ein neues Land identifiziert wird, beispielsweise TL (Osttimor) oder BA (Bosnien und Herzegowina)? Clients, die die vorherige Namensliste verwenden, müssen ihre Implementierung ändern, um die neuen Werte zu berücksichtigen.
Bei Verwendung eines XML-Schemas zur Modellierung von Daten werden Aufzählungswerte explizit aufgelistet. Daher enthält die Liste der Ländercodes die einzelnen Aufzählungswerte der Reihe nach. Oftmals müssen neue Werte in einer Liste identifiziert und in die Liste aufgenommen werden, und Musterdesigner versuchen, einen Weg zu finden, die Liste zu erweitern und dies praktisch in den Entwurf einzubauen, um das Hinzufügen neuer Werte zu ermöglichen ​die zum Zeitpunkt der Wertschöpfung nicht bekannt sind.
Erstellen Sie eine erweiterbare Aufzählungsliste
Bei der Suche nach einer Lösung für dieses Problem wurden wir von vier Schlüsselkriterien beeinflusst:
Erweitern Sie zunächst die Liste nach der Entwurfsphase. Unabhängig davon, ob es darum geht, schnell einen neuen Handelspartner zu etablieren oder zeitkritische neue Datenfelder einzurichten, ist die Skalierung, wenn es darauf ankommt, ein echter Bedarf.
Zweitens ist die Fähigkeit, Werte im Parser zu validieren, entscheidend für die Vereinfachung der Implementierung.
Drittens ist es wichtig, die Analyse und Überprüfung in einem einzigen Zyklus abzuschließen. Dadurch wird vermieden, dass die Validierung in einem separaten Zyklus und Parser wie bei der Genericode-Lösung durchgeführt wird. Bei manchen Setups kann das Hinzufügen neuer Technologieanforderungen zu kostspielig oder zu zeitaufwändig sein.
Schließlich muss die Lösung abwärtskompatibel mit dem ursprünglichen Schema sein. Inkompatible Listenänderungen können nicht als Erweiterungen bezeichnet werden.
Manche Leute denken, dass Aufzählungslisten überhaupt nicht erweitert werden sollten. Datenmodellierer könnten denken, dass sie, wenn sie ein Modell dazu bringen möchten, mehr Daten einzubeziehen und das Modell zu erweitern, ein Schema basierend auf dem Produkt erstellen können – und so bei Bedarf ein größeres Modell mit weniger Einschränkungen erstellen können. Wenn Sie das ursprüngliche Schema und Datenmodell steuern können, ist dies möglich und dieser Ansatz möglicherweise ideal. Wenn Sie jedoch nach der Entwurfsphase tatsächlich skalieren müssen, wird ein solcher Ansatz nicht funktionieren.
Es wurde auch argumentiert, dass der Schlüssel zur Erweiterung der Aufzählungsliste darin besteht, keine XML-Schema-validierenden Parser zu verwenden. Genericode (siehe Verwandte Themen) empfiehlt die Validierung von Aufzählungslisten auf einer zweiten Ebene, getrennt vom anfänglichen XML-Schema-Parser-Validierungsprozess. Diese Theorie ist richtig und die Anwendung dieser Methode wird immer weiter verbreitet. Diese Lösung ist jedoch nicht möglich, wenn sie innerhalb eines Parsing-Zyklus abgeschlossen werden soll. In manchen Fällen ist es nicht möglich, einen zweiten Verifizierungszyklus durchzuführen.
Natürlich können Sie neue Elemente in einer neuen Liste erstellen. Es besteht jedoch keine Abwärtskompatibilität mit dem Raw-Modus. Unser Ziel ist es, eine erweiterbare Liste zu implementieren und gleichzeitig die Abwärtskompatibilität aufrechtzuerhalten (siehe Ressourcen).
Für die Zwecke dieses Artikels basieren die hier getroffenen Annahmen auf meiner Erfahrung in der Arbeit mit Kunden – nämlich der Notwendigkeit, eine bestehende Aufzählungsliste mit Mehrwert zu erweitern. Außerdem gehe ich davon aus, dass die Analyse und Validierung des XML-Schemas in einem Schritt erfolgt.
Notwendige Bedingungen für die Erweiterung der Aufzählungsliste
Das Erweiterungsbeispiel weist vier notwendige Bedingungen auf:
Ermöglicht die Erweiterung der Aufzählungsliste nach der Entwurfsphase.
Überprüfen Sie die Aufzählungsliste mit einem Parser.
Validieren Sie die Aufzählungsliste innerhalb eines Zyklus.
Aufrechterhaltung der Abwärtskompatibilität mit dem Originalmodus.
Zum Beispiel muss ein Team eine aufgezählte Liste regionaler Branchenverbände (oder eine beliebige vorhandene Liste) nehmen und die Schemakomponenten je nach Nutzung ändern. Das vorherige Schema stellte eine aufgezählte Liste von MaritalStatus-Komponenten und -Werten bereit, wie in Listing 1 gezeigt.
Liste 1. Liste zur Familienstandsaufzählung

<xsd:simpleType name="MaritalStatusEnumType"> 
<xsd:restriction base="xsd:normalizedString"> 
<xsd:enumeration value="porced"/> 
<xsd:enumeration value="Married"/> 
<xsd:enumeration value="NeverMarried"/> 
<xsd:enumeration value="Separated"/> 
<xsd:enumeration value="SignificantOther"/> 
<xsd:enumeration value="Widowed"/> 
<xsd:enumeration value="Unknown"/> 
</xsd:restriction> 
</xsd:simpleType> 
<xsd:element name="MaritalStatus" type="MaritalStatusEnumType"/>

Angenommen, ein Unternehmen möchte diese Werte nutzen und unterstützt darüber hinaus seine wichtigen Handelspartner bei der Nutzung eines anderen Wertes. CivilUnion ist ein erweiterter Wert, von dem das Unternehmen erkennt, dass er nicht Teil des ursprünglichen Schemas ist. Aber semantisch gesehen ist es auch in Ordnung, ein vorhandenes Element – ​​MaritalStatus – zu verwenden. Wie erreicht das Unternehmen dies?
Zurück zum Anfang
Lösung 1: Bearbeiten Sie das ursprüngliche Schema, um den neuen Aufzählungswert einzuschließen.
Natürlich ist das Bearbeiten des ursprünglichen Schemas, um den neuen Aufzählungswert einzuschließen, der einfachste Ansatz. Bewahren Sie lokale Kopien der Schemata auf und bearbeiten Sie die Schemata dann, um die von Ihrem Unternehmen verwendeten Aufzählungswerte zu unterstützen.
Vorteile: Einfach zu implementieren
Nachteile:
Erfordert die Bearbeitung von Originalmustern, die sich nach und nach außer Kontrolle geraten. Bei der Erweiterung einer bereits bestehenden Liste möchte der Ersteller (Handelspartner, Verband usw.) möglicherweise eine neue Version der Liste veröffentlichen. Sie müssen Ihre Änderungen auf jede neue Version übertragen. Der
ManuelleBearbeitungsmodus kann zu unerwarteten Bearbeitungsfehlern führen.
Wenn Sie das Originalmuster nicht bearbeiten können (oder wollen), benötigen Sie eine Alternative.
Zurück zum Anfang
Lösung 2: Erstellen Sie eine neue Aufzählungsliste und fügen Sie sie zur ursprünglichen Liste hinzu.
Die zweite Option besteht darin, eine neue Aufzählungsliste zu erstellen und diese zur ursprünglichen Aufzählungsliste hinzuzufügen. Listing 1 zeigt die ursprüngliche Familienstandsliste. Listing 2 zeigt die neu erstellte Aufzählungsliste.
Listing 2. Neue Familienstandsaufzählungsliste

<xsd:simpleType name="MyExtMaritalStatusEnumType"> 
<xsd:restriction base="xsd:normalizedString"> 
<xsd:enumeration value="CivilUnion"/> 
</xsd:restriction> 
</xsd:simpleType>

Verknüpfen Sie sie mit der Originalliste mithilfe des -Tags, wie in Listing 3 gezeigt.
Listing 3. Kombinieren von zwei Listengruppen

<xsd:simpleType name="MaritalStatusType_Union"> 
<xsd:union memberTypes="MyExtMaritalStatusEnumType MaritalStatusEnumType"/> 
</xsd:simpleType> 
<xsd:element name="MaritalStatus" type="MaritalStatusType_Union"/>

Diese Lösung erfordert noch die Bearbeitung des Schemas – das heißt, das Element MaritalStatus wird durch MaritalStatusType < dargestellt 🎜>Typkonvertierung in den Typ MaritalStatusType_Union. Keine große Änderung, aber dennoch einige manuelle Bearbeitungsarbeit. Vorteile: Die ursprüngliche Aufzählungsliste wird nicht geändert.
Nachteile:
Alle Werte müssen während der Entwurfsphase bekannt sein, was späte Bindungslösungen verhindert.
Erfordert Unterstützung für das Tag , aber manchmal kann dieses Tag nicht mit Tools implementiert werden.
Zurück zum Anfang
Lösung 3: Erstellen Sie ein Schema und kombinieren Sie es mit dem primitiven Enum-Typ
Sehen Sie sich nun den Anwendungsfall für Bevölkerungsdaten zur Augenfarbe an. Listing 4 zeigt diese Liste.
Listing 4. Aufzählungsliste für die Augenfarbe einer Person

<xsd:simpleType name="PersonEyeColorType"> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Black"/> 
<xsd:enumeration value="Hazel"/> 
<xsd:enumeration value="Gray"/> 
<xsd:enumeration value="Brown"/> 
<xsd:enumeration value="Violet"/> 
<xsd:enumeration value="Green"/> 
<xsd:enumeration value="Blue"/> 
<xsd:enumeration value="Maroon"/> 
<xsd:enumeration value="Pink"/> 
<xsd:enumeration value="Dichromatic"/> 
<xsd:enumeration value="Unknown"/> 
</xsd:restriction> 
</xsd:simpleType>

regulären Ausdruck), der den neuen Wert annimmt. Das Muster ist eine beliebige Zeichenfolge mit dem Präfix x: . x: ist ein Trennzeichen zwischen Standard-Aufzählungslisten und erweiterten Listen. Listing 5 zeigt dieses Muster. Listing 5. Regulärer Ausdruck für die Erweiterung

<xsd:simpleType name="StringPatternType"> 
<xsd:restriction base="xsd:string"> 
<xsd:pattern value="x:\S.*"/> 
</xsd:restriction> 
</xsd:simpleType>

<xsd:simpleType name="MyExtPersonEyeColorType"> 
<xsd:union memberTypes="PersonEyeColorType StringPatternType"/> 
</xsd:simpleType> 
<xsd:element name="PersonEyeColor" type="MyExtPersonEyeColorType"/>

<PersonEyeColor>Black</PersonEyeColor> 
<PersonEyeColor>x:Teal</PersonEyeColor>

<xsd:simpleType name="DependentRelationshipEnumType"> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="AdoptedChild"/> 
<xsd:enumeration value="Brother"/> 
<xsd:enumeration value="Child"/> 
<xsd:enumeration value="ExSpouse"/> 
<xsd:enumeration value="Father"/> 
<xsd:enumeration value="Granddaughter"/> 
<xsd:enumeration value="Grandson"/> 
<xsd:enumeration value="Grandfather"/> 
<xsd:enumeration value="Grandmother"/> 
<xsd:enumeration value="LifePartner"/> 
<xsd:enumeration value="Mother"/> 
<xsd:enumeration value="Sister"/> 
<xsd:enumeration value="Spouse"/> 
<xsd:enumeration value="Extension"/> 
</xsd:restriction> 
</xsd:simpleType>

<xsd:complexType name="DependentRelationshipType"> 
<xsd:simpleContent> 
<xsd:extension base="DependentRelationshipEnumType"> 
<xsd:attribute name="extension" type="xsd:string"/> 
</xsd:extension> 
</xsd:simpleContent> 
</xsd:complexType> 
<xsd:element name="DependentRelationship" type="DependentRelationshipType"/>

<DependentRelationship>Child</DependentRelationship> 
<DependentRelationship extension="MyNewRelationship">Extension</DependentRelationship>

<xsd:simpleType name="DayOfWeekEnumType"> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Sunday"/> 
<xsd:enumeration value="Monday"/> 
<xsd:enumeration value="Tuesday"/> 
<xsd:enumeration value="Wednesday"/> 
<xsd:enumeration value="Thursday"/> 
<xsd:enumeration value="Friday"/> 
<xsd:enumeration value="Saturday"/> 
</xsd:restriction> 
</xsd:simpleType> 
<xsd:element name="DayOfWeek" type="DayOfWeekEnumType"/> 
<xsd:simpleType name="ExtendedDayOfWeekType"> 
<xsd:union memberTypes="DayOfWeekEnumType xsd:string"/> 
</xsd:simpleType> 
<xsd:element name="DayOfWeek_solution5" type="ExtendedDayOfWeekType"/>

<xsd:element name="DayOfWeek" type="xsd:string"> 
<xsd:annotation> 
<xsd:documentation> 
<!-- suggested enumerations --> 
<xsd:enumeration value="Sunday"/> 
<xsd:enumeration value="Monday"/> 
<xsd:enumeration value="Tuesday"/> 
<xsd:enumeration value="Wednesday"/> 
<xsd:enumeration value="Thursday"/> 
<xsd:enumeration value="Friday"/> 
<xsd:enumeration value="Saturday"/> 
</xsd:documentation> 
</xsd:annotation> 
</xsd:element>