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 a8a63e71ccce8bcd0a2f59429578398f-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 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 a8a63e71ccce8bcd0a2f59429578398f, 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>

Als nächstes erstellen Sie ein Muster (einen

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>

Kombinieren Sie abschließend die Liste mit dem Muster mithilfe des a8a63e71ccce8bcd0a2f59429578398f-Tags, wie in Listing 6 gezeigt.

Listing 6. Kombination aus Aufzählungsliste und erweitertem Modus

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

Derselbe Knoten hat Standard- und erweiterte Werte. Die beiden Werte sind leicht trennbar und können beide mit dem Parser überprüft werden, wie in Listing 7 gezeigt.

Listing 7. Beispiel-XML-Instanz

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

Vorteile:

Das gleiche Element kann für alle Daten verwendet werden.
Validieren Sie grundlegende Aufzählungslisten mit Parsern.
Erweiterungswerte klar trennen.
Diese Lösung ermöglicht die spätere Bindung neuer Werte.
Nachteile:
Der Inhalt des Elements muss analysiert werden, um festzustellen, ob es erweitert wurde.
Musterparser müssen reguläre Ausdrücke unterstützen.
Erfordert Unterstützung für das Tag a8a63e71ccce8bcd0a2f59429578398f
Zurück zum Anfang
Lösung 4: Separate Felder für Erweiterungen verwenden
Bei dieser Lösung ändern sich die Aufzählungsfelder nicht. Sie müssen jedoch im Schema ein Erweiterungsfeld entwerfen, um den zusätzlichen Wert aufzunehmen. In diesem Fall handelt es sich bei der Ausgangsliste um eine abhängige Person (Beziehung zwischen Arbeitsberechtigtem und abhängigem Arbeitnehmer), wie in Listing 8 dargestellt.
Listing 8. Abhängigkeitsaufzählungsliste

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

erfordert ein zusätzliches

Attribut – Erweiterung – das neue Werte aufnehmen kann. Listing 9 zeigt diese Eigenschaft. Listing 9. Das Erweiterungsattribut für Abhängigkeiten

<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"/>

Listing 10 zeigt einige XML-Beispiele, die Erweiterung widerspiegeln.

Listing 10. Beispiel-XML-Instanz

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

优点：
不需要编辑原始模式。
该解决方案允许在以后绑定新值。
在原始模式中显式设计 extension 方法。
缺点：
在设计阶段，必须在每个枚举列表中设计 extension 方法。
必须在元素中而不是在属性中设置枚举值。
回页首
解决方案 5： 基于文档的方法 —— 与字符串结合
注意：解决方案 5 和解决方案 6 违反了在一个周期内进行验证 这一要求。但是，我之所以在这里介绍它们，是因为在很多实际环境中可以使用这些方法。
在第 5 个解决方案中，使用 a8a63e71ccce8bcd0a2f59429578398f 标记将枚举列表与字符串结合。实际上，该解决方案提示接收系统哪些值是标准的（包括包装和拼写）。但实际上字符串字段可以存放任何值。因此，解析器并不验证值。相反，这些值在第二个周期或者在接收数据的应用程序中验证。有些 XML 组织就使用这样的方案。
清单 11 显示通过 a8a63e71ccce8bcd0a2f59429578398f 将一个枚举列表和 75eb557cfb45ea1d8dae02dc93b76dca 结合。因为任意值都可以是一个字符串，所以不用验证枚举列表。这些值建议使用标准值。
清单 11. 与字符串结合的 DayOfWeek 枚举列表

<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"/>

优点：可以添加任意的扩展值，即使在后期绑定时也可以添加。
缺点：
解析器不验证枚举值，在第二个步骤中才进行验证。
需要 a8a63e71ccce8bcd0a2f59429578398f 标记支持。
回页首
解决方案 6： 基于文档的方法 —— 使用 fca1af215fef1d5c1bced9a59797830f
要使用该方法，将实际的枚举值放到 21dba8562c1ffae18c64c17dc18f6cb0 标记内，同时将数据字段保留为一个简单字符串。清单 12 显示枚举值。
清单 12. 在 ae418a134aca541d60939a34685157c2 标记内的枚举值

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

优点：
可以添加任意的扩展值，即使在后期绑定时也可以添加。
只需要最简单的 XML 模式特性。
缺点：解析器不验证枚举值。
回页首
未讨论的方法
我省略了其他几种扩展枚举列表的解决方案。下面简单介绍了两种没有使用的方法：
使用 0f2bc009383268386b5007a40602d2a3 标记： 通常不使用 XML 模式的这一特性，而且一般无法用工具实现它。该方法经常被认为是避免重新定义的最佳实践。
使用 substitutionGroup 元素替换包含所有值的联合列表： 另外一种出色的解决方案，使用了替换组和联合。将原始列表与新列表联合以创建一个完整的枚举列表，然后使用 substitutionGroups 标记（或 44403ce233a2c37c854bc989d9695611 标记）替换一个全局作用域元素。该方法的缺点是替换不能派生有效的联合，替换需要两个组件来自相同的基类型。扩展和限制是替换的两个有效方法。但是，根据 XML 模式规范，联合并不是有效的派生技术（参阅 参考资料）。
回页首
结束语
XML 模式设计者和实现人员需要一种方法来扩展现有的枚举列表。因为一旦原始列表创建后，规范不允许进行扩展，因此需要找到一种方法实际实现扩展。实现人员可以使用本文的示例来设计和扩展枚举列表。每种方法都有优缺点，没有一种方法在所有用例中都是最佳方法。那么，应该使用哪种方法呢？
请考虑这些经验法则：
如果您习惯编辑原始枚举列表或模式，而且在设计阶段就知道所有要扩展的枚举值，最好使用 解决方案 1（手动编辑原始列表）或 解决方案 2（创建新列表并加入到原始列表中）。
如果想使用相同的语义元素来包含基本枚举列表和扩展枚举列表，可以考虑 解决方案 3（与模式联合）。
如果允许原始列表与扩展列表有不同的字段，可以使用 解决方案 4（独立的字段）。
如果不想在解析器中解析枚举值，可以考虑 Genericode 方法或使用 解决方案 5 或 解决方案 6。
这些指导原则可以使模式设计者找到实用的最佳实践，而且可以帮助他们创建易于实现、可扩展的枚举列表。
XML 模式和 XML 实例示例 ExtendEnumeratedListsCode.zip 2KB

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Beispielcodes zum Erweitern der Aufzählungsliste im XML-Schema. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!