| Table of Contents | ||
|---|---|---|
|
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
...
During further development of this specification, not all involved implementations are expected to incorporate the specification's latest version. It is therefore necessary to ensure that servers and clients implementing different versions of the Veloconnect specification can interact as smoothly as possible. Further development of the specification must accordingly abide by the following rules:
Rule: Version guideline
Each Veloconnect specification is numbered according to the scheme {version}.{revision} numeriert. Hierbei ist , with {version} die Versionsnummer und representing the version number, and {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:{modulrepresenting the revision number. This specification therefore has version number 1 and revision number 3. A specification is newer than another if its version number is higher, or if the version numbers match and the revision number is higher.
Changing at most within a period of 12 months is the version number.
The namespaces of modules defined in the specification are all designated according to the scheme urn:Veloconnect:{module-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 . The version number matches the specification's version number. The revision number corresponds to the last revision in which this module was added or modified.
A module used in a Veloconnect specification {version}.{r1} verwendet wird, wird auch in allen Spezifikationen is also used in all specifications {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 Requests in der URL(-S)-Bindung fehlen die Informationen über die Namensräume. Daher wurde mit veloconnect 1.3 für diese Bindung der Parameter version eingeführt, damit der Client die von ihm unterstütze Version mitteilen kann.
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ückgeliefertif r2 is larger than or equal to r2.
A module's schematic definitions are modified as follows: Suppose D is an XML document valid according to specification u.v, and u.y is a more recent specification of the same version. We can transform D into an XML document E so as to replace the identifiers of namespaces with the associated identifiers of the newer specification assigned in the previous section. The transformed document E will then also be a valid document according to the specification u.y.
Suppose D is an XML document valid according to specification u.v, and x.y a newer specification where x and u are different. If transformation of namespaces for document E can be performed similarly to the previous case, and the root element of E is declared in the newer scheme, then document E is also valid according to specification x.y.
This rule implies extensive downward compatibility. It also demonstrates that implementations essentially use namespaces as a signal to identify the version of the specification according to which the involved parties are operating, and that a use of unqualified names does not lead to any misunderstandings.
Requests in the URL(-S) binding lack information about namespaces. Introduced therefore for this binding with Veloconnect 1.3 was a parameter version allowing the client to communicate the version it supports.
This can have various consequences for the client and server, if they communicate with a counterparty which implements a different version of the specification. Some recommendations are made for implementation of clients, some related rules are formulated for servers.
Recommendations for client implementations
Implementation should not make assumptions about an absence of elements or attributes. It is thoroughly possible for a newer specification, for example, to insert another optional element between two child elements.
Similarly, additional values may be allowed for types defined as enumeration. Implementation should be prepared for this case and, if necessary, generate a notice for the user.
Because a server is not expected to implement the latest specification, it might be necessary to support outdated operations, i.e. those no longer provided for in the current specification.
Rule: Downward compatibility (server)
When dealing with clients which implement an earlier specification version, a Veloconnect compliant server must observe the following rules:
If a request from the client can be converted into a valid request via transformation of the namespaces described above, this transformed request must be answered in accordance with the specification.
Otherwise the server can choose whether the request is answered according to an earlier specification, or whether error code 406 is returned.
Rule: Upward compatibility (server)
When dealing with clients which implement a later specification version, a Veloconnect-compliant server must follow the following rules
If a request from the client can be converted into a valid request via transformation of the namespaces, this transformed request must be answered in accordance with the specification.
Otherwise error code 405 is returned.
...