Hi Javi and others,
Sorry about taking so long to answer this one. Protocol and schema versioning seems to be a very complicated issue, with big discussions and doubtful recommendations.
I'm also not sure about the best way to proceed, but I tend to agree with Markus: change the namespace only for new major versions, but always indicate the full version as an attribute of the schema.
Instance messages could also indicate the full protocol version in the root element if the namespace will really be "reused" by different versions over the time.
I just feel that version negotiation is probably too much at this point. When time comes to make a major protocol change, providers could probably set up different provider instances in separate access points if they want to support more than one version. Having multi- version provider software using the same access point is also an alternative, but I fear we could be complicating the protocol for things that we're not sure if they are going to be used or implemented soon. Anyway, clients are always free to try parsing future versions of protocol messages - they don't necessarily need to break, as you said.
About your last question, versioning the schema targetNamespace potentially affects each DOM node, SAX event and XPath node defined in existing applications. This can be good or bad, depending on the set of changes that were made in the protocol.
Regards, -- Renato
On 31 Jul 2006 at 14:41, Javier de la Torre wrote:
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.