Es ist damit zu rechnen, dass diese Spezifikation weiterentwickelt
wird. In Planung ist - wenn hierfür
ein klarer Bedarf zu erkennen ist - für die Übermittlung von
Lieferscheinen und Rechnungen. Es ist also dafür Sorge zu tragen, dass
Server und Client, die unterschiedliche Versionen der veloconnect-Spezifikation
implementieren, 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
1.
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
werden alle nach dem Muster
urn:veloconnect:{name}-{version}.{revision} bezeichnet. Die
Versionsnummer stimmt mit der Versionsnummer der Spezifikation
überein. Eine Änderung der Revisionsnummer findet nur statt, wenn
die Schemadefinitionen für diesen Namensraum geändert
werden.
- Zu jedem Namensraum, der in einer
veloconnect-Spezifikation verwendet wird, gibt es in jeder neueren
Spezifikation mit gleicher Versionsnummer genau einen Namensraum,
dessen Bezeichnung bis auf die Revisionsnummer mit diesem
übereinstimmt.
- Die Modifikationen der Schemadefinitionen werden
wie folgt sein. Sei D ein nach der Spezifikation u.v gültiges
XML-Dokument und u.y eine neuere Spezifikation. 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.
Letzlich bedeutet diese Regel 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.