Home
Über mich
Blog
Veröffentlichungen
IT-Trainings
Impressum


XML: Versionierung und Namespaces

Daß Datenstrukturen sich ändern können, ist normal. Normal ist auch, daß die Folgeprogrammierung der geänderten Sachlage anzupassen ist. Änderungen zu blockieren, um sich die aufwändige Anpassung der Folgeprogrammierung zu ersparen, ist auf Dauer kaum durchzuhalten.

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

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

Das bedeutet, daß sich bei jeder neuen Version auch die Namespaces des XML Inputdokuments ändern. In der Folge muß eiligst die gesamte Programmierung angepaßt 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.

Weit sinnvoller ist der Ansatz, den Namespace konstant zu halten und ein zusätzliches Attribut für die Versionierung vorzusehen. Beispiel:

<XSLSchulung 
   version="2017" 
   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>

Unterschiedliche Versionen ohne Namespaces

Es gibt Systeme, die (scheinbar) auf Namespaces verzichten (und vielleicht auch damit noch werben, daß sie ohne diesen "überflüssigen Ballast" auskommen) und sich auf die Versionsnummer konzentrieren. Die könnten wir notfalls ignorieren, ist bestimmt nicht soooo wichtig. Ist das nun die Lösung?

Leider nein. Der (scheinbare) Verzicht auf einen Namespace bedeutet nur, daß wir uns bei einer evtl. notwendigen Datenkonvertierung nicht mehr mit Namespaces herumschlagen müssen. Versionierungskonflikte sind damit keineswegs aus der Welt.

So kann es auch bei Tools desselben Herstellers passieren, daß 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, daß 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 Informationsverlustes bleibt hoch.

qrpic/namespaces3.jpg

wg / 14. Oktober 2017




Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf (info10@wilfried-grupe.de).



Vielen Dank für Ihr Interesse an meiner Arbeit.


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

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