Bei der Weiterentwicklung dieser Spezifikation ist damit zu rechnen, dass nicht alle beteiligten Implementierungen jeweils den aktuellsten Stand der Spezifikaiton 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:
Regel: Versions-Richtlinie
Jede veloconnect-Spezifikation wird nach dem Schema {version}.{revision} numeriert. Hierbei ist {version} die Versionsnummer und {revision} die Revisionsnummer. Die vorliegende Spezifikation hat also die Versionsnummer 1 und die Revisionsnummer 3. 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. 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.
Empfehlung für Client-Implementierungen
Die Implementierung sollte keine Annahmen über das Nichtvorhandensein von Elementen oder Attributen machen. Es kann durchaus sein, dass eine neuere Spezifikation z.B. zwischen zwei Kindelementen ein weiteres optionales Element einfügt.
Ebenso kann es sein, dass für Typen, die als Aufzählung definiert sind, weitere Werte erlaubt werden. Die Implementierung sollte auf diesen Fall gefasst sein und gegebenenfalls einen Hinweis an den Benutzer generieren.
Da nicht davon auszugehen ist, dass die Server jeweils den neuesten Stand der Spezifikation implementieren, müssen gegebenenfalls auch veraltete Operationen, d.h. Operationen, die in der aktuellen Spezifikation nicht mehr vorgesehen sind, unterstützt werden.
Regel: Abwärtskompatibilität (Server)
Im Umgang mit Clients, die einen älteren Stand der Spezifikation implementieren, muss ein veloconnect-konformer Server folgende Regeln beachten:
Sofern eine Anfrage des Client mit der oben beschriebenen Transformation der Namensräume in eine gültige Anfrage umgesetzt werden kann, ist diese transformierte Anfrage gemäß der Spezifikation zu beantworten
Andernfalls hat der Server die Wahl, ob die Anfrage gemäß einer früheren Sepzifikation beantwortet wird oder ob der Fehlercode 406 zurückgeliefert wird.
Regel: Aufwärtskompatibilität (Server)
Im Umgang mit Clients, die einen neueren Stand der Spezifikation implementieren, muss ein veloconnect-konformer Server folgende Regeln beachten:
Sofern eine Anfrage des Client durch eine entsprechende Transformation der Namensräume in eine gültige Anfrage umgesetzt werden kann, ist diese transformierte Anfrage gemäß der Spezifikation zu beantworten
Andernfalls wird der Fehlercode 405 zurückgeliefert.