XML / XML: Die Sache mit den Namespaces / Versionierung

Versionierung

Versionierung

➪ Dass Datenstrukturen sich ändern können, ist normal. Normal ist auch, dass die Folgeprogrammierung der geänderten Sachlage anzupassen ist. Änderungen zu blockieren, um sich die aufwendige Anpassung der Folgeprogrammierung zu ersparen, ist auf Dauer kaum durchzuhalten. Daher ist eine klare Versionierung geänderter XML-Datenstrukturen von zentraler Bedeutung.

Auf dieser Seite:

Grundsätzlich gibt es drei Möglichkeiten der Versionierung:

Versionierung über Namespaces

Häufiger Anlass für Ärger und Stress ist, wenn die Versionierung der XML-Inputdokumente direkt in die eingearbeitet ist. Beispiel:


<XSLSchulung xmlns="www.wilfried-grupe.de/XSLSchulung/2018" />

Das bedeutet, dass sich bei jeder neuen Version auch die Namespaces des XML-Inputdokuments ändern. In der Folge muss eiligst die gesamte Programmierung angepasst und erneut getestet werden, um Datenverlust zu vermeiden. Fatal, weil oft überflüssig, ist das bei minor changes, bei denen sich lediglich die versionsbedingten Namespaces ändern, die Datenstrukturen selber aber unverändert erhalten bleiben.

Versionierung über Namen der Elemente bzw. Attribute

Ein ähnliches Problem erkennen Sie, wenn die Versionierung in den abgebildet wird, zum Beispiel im Root-Element. Ändert sich mit der Versionierung auch der Elementname, so sind die hier hinterlegten Informationen verloren, wenn nicht zeitnah die Konvertierungslogik angepasst wird.

Um sich die lästigen Anpassungen zu ersparen, ist es ein beliebter Trick, diese Versionsinformationen (hinter denen sich vermutlich unterschiedliche Datenstrukturen verbergen) durch (, , etc.) auszublenden. Auch hier ist die Gefahr des Informationsverlustes hoch.

Versionierung über Attribut "@version"

Weit sinnvoller als die vorgenannten Möglichkeiten ist der Ansatz, den Namespace konstant zu halten und ein zusätzliches Attribut @version für die Versionierung vorzusehen.

Solange die Datenstrukturen sich nicht von Grund auf ändern, sondern die Elemente lediglich zusätzliche Childnodes oder Attribute erhalten, ohne die bisherigen Strukturen von Grund auf zu verändern, müssen die auswertenden Programme nicht bei jeder Änderung aktualisiert werden.

Beispiel:


<XSLSchulung 
   version="2018" 
   xmlns="www.wilfried-grupe.de/XSLSchulung" />

Auf diese Weise ist zumindest bei den erwähnten minor changes nicht mit einem Datenverlust zu rechnen.

Die Deklaration von XSLT ist hier beispielhaft: Der Namespace


<xsl:stylesheet 
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/>

ist für XSLT 1.0, 1.1, 2.0 und 3.0 immer gleich, lediglich das Attribut "version" ändert sich.

Auch in XML-Schema wird der Namespace selbst beibehalten:


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

Für die Versionierung wird in XSD 1.1 noch ein zusätzlicher Namespace deklariert:


<xs:schema 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
   vc:minVersion="1.1">
</xs:schema>

Das Konzept beruht also auf Erweiterung, aber nicht grundsätzlicher Änderung, um die Kompatibilität der auswertenden Programme abzusichern. In diesem Fall müssen Sie sich bei einer evtl. notwendigen Datenkonvertierung nicht mehr mit Namespaces herumschlagen.

Ist dagegen eine grundsätzliche Änderung der Datenstruktur unumgänglich, so kann der Namespace ggf. beibehalten werden; das "@version"-Attribut oder eine alternative Konstruktion ist dann aber unverzichtbar. Unvermeidlich ist dann auch die Anpassung der Folgeprogrammierung.

So weit, so gut. Kontraproduktiv wird es jedoch, bei einer grundsätzlichen Änderung der Datenstruktur zwar die Namespaces beizubehalten, aber auch die Versionierung zu ignorieren.

So kann es auch bei Tools desselben Herstellers passieren, dass der Datensender in einer höheren Version arbeitet als der Datenempfänger. Dann kann der Empfänger die Daten nicht verarbeiten, sondern erhält (hoffentlich!) eine Fehlermeldung z.B. einer "Unsupported Version Exception" oder "Unsupported data format Version".

Solche Fehlermeldungen mögen ärgerlich und nervtötend sein. Ihre Behandlung kann aber nicht darin bestehen, die Versionsnummern zu überschreiben oder zu löschen. Es kann ja sein, dass die Datenstruktur der höheren Version (Datensender) ganz anders aussieht als diejenige, mit der der Datenempfänger arbeitet. Dann verarbeitet das (empfangende) Tool nur jene Elemente/Attribute, die zufällig in beiden Versionen identisch adressiert sind. Die Gefahr des Informationsverlusts bleibt hoch.

wg / 12. April 2018



Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf.






Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

☎ 0151. 750 360 61 * eMail: info10@wilfried-grupe.de

www.wilfried-grupe.de/namespaces3.html