Hi Markus,
Ok, I understand that if you think that we should not take care of version negotiating at this moment then we have to include the major version in the namespace.
In any case I still tend to thing that there is not such a big advantage of using the protocol version in the namespace. Maybe we will have TAPIR 2.0 which will modify completely most operations but leave intact the inventory. Why clients only using inventories have to break?
I rather prefer to see an exception on the client when he does not understand the server than a crash only because of namespaces...
What are the advantages of including the version on the namespace? Briefly (just to revate :D )
Cheers.
On 7/31/06, "Döring, Markus" m.doering@bgbm.org wrote:
Well, I hope that TAPIR is not changing really. It should be much more stable than our content schemas. So if we include the major version in the namespace I think this is OK.
Including the full version number as an attribute into the schema I think is always a good idea. This way we could add minor things to the schema keeping backwards compatability and still discover the exact schema version.
I dont think our community currently could handle different major and incompatible versions of a protocol. So negotiating for a version of the protocol seems to me too much too soon. by the way a great album title: http://en.wikipedia.org/wiki/Too_Much_Too_Soon_%28album%29
-- Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Montag, 31. Juli 2006 01:56 An: tdwg-tapir@lists.tdwg.org Betreff: [tdwg-tapir] TAPIR namespace and versioning
Hi all,
After discussion in Tervuren about ABCD and versioning issues I thought that we should maybe consider the same strategy for TAPIR. That is:
-Do not include the protocol version in the namespace but rather use always something like http://rs.tdwg.org/tapir -Use the version attribute in the schema. -Include a version attribute in the request top element to specify the TAPIR version of the message. -A new mandatory version parameter for GET operations called version.
I even think that we should not change the namespace when doing non backwards compatible changes to the protocol. Clients should take care themselves of looking at the version attribute always.
This is the way all OGC standards work and I think is a good strategy.
But this can probably be consider a pretty dramatic change in the protocol right now... what do you think? I think it would be great to include this strategy from the beginning so we are not so worry about breaking clients with possible small changes in future versions.
Best regards,
Javier.
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir