...
Bei der Weiterentwicklung dieser Spezifikation ist damit zu rechnen, dass nicht alle beteiligten Implementierungen jeweils den aktuellsten Stand der Spezifikaiton Spezifikation umsetzen. Es ist also dafür zu sorgen, dass Server und Client, die unterschiedliche Versionen der veloconnect-Spezifikation implementieren, weitgehend reibungslos zusammenarbeiten können. Die Weiterentwicklung der Spezifikation wird daher folgenden Regeln unterworfen:
...
Jede veloconnect-Spezifikation wird nach dem Schema {version}.{revision} numeriertnummeriert. Hierbei ist {version} die Versionsnummer und {revision} die Revisionsnummer. Die vorliegende Spezifikation hat also die Versionsnummer 1 und die Revisionsnummer 35. Eine Spezifikation ist neuer als eine andere, wenn ihre Versionsnummer größer ist, oder wenn die Versionsnummern übereinstimmen und die Revisionsnummer größer ist.
Innerhalb eines Zeitraums von 12 Monaten findet höchstens ein Wechsel der Versionsnummer statt.
Die in der Spezifikation definierten Namensräume von Modulen werden alle nach dem Muster urn:veloconnect:{modul-name}-{version}.{revision} bezeichnet. Die Versionsnummer stimmt mit der Versionsnummer der Spezifikation überein. Die Revisionsnummer entspricht der letzten Revision, in der dieses Modul hinzugefügt oder geändert wurde.
Ein Modul, das in einer veloconnect Spezifikation {version}.{r1} verwendet wird, wird auch in allen Spezifikationen {version}.{r2} verwendet, wenn r2 größer oder gleich r2 ist.
Die Modifikationen der Schemadefinitionen eines Moduls werden wie folgt sein: Sei D ein nach der Spezifikation u.v gültiges XML-Dokument und u.y eine neuere Spezifikation zur gleichen Version. Wir können D derart zu einem XML-Dokument E transformieren, dass wir die Bezeichner von Namensräumen durch ihre im vorherigen Abschnitt zugeordneten Bezeichner der neueren Spezifikation ersetzen. Das transformierte Dokument E wird dann auch wieder ein nach der Spezifikation u.y gültiges Dokument sein.
Sei D ein nach der Spezifikation u.v gültiges XML-Dokument und x.y eine neuere Spezifikation, wobei x und u verschieden sind. Falls eine zum vorherigen Fall analoge Transformation der Namensräume zum Dokument E möglich ist und das Wurzelelement von E im neueren Schema deklariert ist, dann ist das Dokument E auch wieder ein nach der Spezifikation x.y gültiges Dokument.
Diese Regel bedeutet eine weitgehende Abwärtskompatibiltät. Ebenso zeigt dies, dass Implementierungen Namensräume im wesentlichen als Signal verwenden, um zu erkennen nach welchem Stand der Spezifikation die beteiligten Parteien arbeiten, und die Verwendung der unqualifizierten Namen zu keinen Missverständnissen führt.
...
Bei Änderungen an der Spezifikation die eine Abwärtskompatibilität verhindern würden (breaking-change), dürfen diese nur unter einer höheren Versionsnummer veröffentlich werden. Bei Aktualisierung der Revisionsnummer muss die Änderung immer abwärtskompatibel sein.
Für Client und Server hat es unterschiedliche Konsequenzen, wenn sie mit einer Gegenseite kommunizieren, die einen anderen Stand der Spezifikation implementiert. Für die Implementierung von Clients werden einige Empfehlungen ausgesprochen, für Server einige diesbezügliche Regeln formuliert.
Für beide gilt jedoch, dass die XSD-Schemas nicht zur Input-Validierung genutzt werden sollten. Weder Client noch Server wissen die exakte Version der Gegenseite und können daher nicht die korrekte Version des Schemas zur Validierung wählen. D.h. die Schemas sollten nur als Dokumentation betrachtet werden bzw. für interne Tests bei der Umsetzung genutzt werden um die eigene Implementierung zu verifizieren. Zur Laufzeit sollte der Input über eine eigenen Implementierung validiert werden. Dabei kann nicht davon ausgegangen werden, dass der Input 100% der eigenen, gerade genutzten, Schema-Version entspricht.
Empfehlung für Client-Implementierungen
...
Sofern eine Anfrage des Client mit der oben beschriebenen Transformation der Namensräume in eine als gültige Anfrage umgesetzt werden kann, ist diese transformierte Anfrage gemäß der aktuellen Spezifikation des Servers zu beantworten
Andernfalls hat der Server die Wahl, ob die Anfrage gemäß einer früheren Sepzifikation Spezifikation beantwortet wird oder ob der Fehlercode 406 zurückgeliefert wird.
...
Sofern eine Anfrage des Client durch eine entsprechende Transformation der Namensräume in eine als gültige Anfrage umgesetzt werden kann, ist diese transformierte Anfrage gemäß der aktuellen Spezifikation des Servers zu beantworten
Andernfalls wird der Fehlercode 405 zurückgeliefert.
...