Hi Javier,
I wish I had the same conviction as you on this matter... As I said, every time I do some research about this topic I find different opinions and no consensus. Some comments below...
I still think we should remove totally the version number from the namespace and fix it to just tapir. I prefer that than asking people to ignore the namespace when parsing documents. If clients want to try with newer versions of the protocol then I prefer they ignore the version attribute than the namespace. I like to know from the namespace that something is TAPIR at least.
You know that namespace is an abstraction whose main purpose is to avoid the ambiguity of "items" that have the same "identifier". Following this definition, the first realease of TAPIR will have, for instance, the precise notion of an outputModel. Now suppose that in the next release for some reason we significantly change that notion (both the meaning and the XML format). Then even in these situations what you suggest is to keep the same namespace for the same element identification? Is this also what OGC would do with WFS if they change the meaning and the basic format of features? I may be wrong here, but I think this would not the expected usage of of all technologies behind the protocol.
On the other hand, I do see the advantages of keeping the same namespace if changes are not significant.
I dont really see the advantage of including the version number on the namespace, but still... if you prefer so I would suggest then that we have the namespace like:
And not 1.0. For me 1.0 looks like a real version number and therefore we could have 1.1 that looks like a minor revision of the protocol.
But in the other hand the 1 alone does not look very pretty.
There's also the W3C date pattern.
I dont really understand your answer. I dont think implementation of the TAPIR protocol will make use of our targetNamespace, the same way that for creating a WFS service I dont use the official XML schema, I just worry that I validate against it.
Namespaces can be widely used by parsers, XSLT transformations, XQuery statements, etc.
But if you are worry is that we might make a change in the protocol that makes it not backward compatible... then we are in the same discussion as in ABCD, only change the namespace if the changes break backwards compatibility.
Agreed (so maybe in the first part of the message you were only considering "small" changes?).
But even on the namespace or in the version attribute whenever we start making changes to TAPIR protocol implementations will have to start worrying about versions.
We can conceive our own way of encoding version, but if we don't change the namespace for major versions, then other generic tools may have problems. I can't give you a concrete example now. Maybe some XML validator could be free to cache XML Schemas and associate them with namespaces. In this case it could report that new protocol messages are invalid just because it's still using the original (cached) version of the XML Schema.
If we go including version number in the namespace and in the version attribute then it is going to be two places where implementations will have to start taking care. At some point I think there is not going to be any way we will avoid having to consider version negotiation, but still maybe the first version of TAPIR doesnt need to declared it. It could be in the next revision where we include this. And frankly the kind of version negotiation through the capabilities document as described in OGC standards is pretty simple to implement at least in the server side.
Right. It's the frequent dilemma: try to implement now and be prepared for a possible future, or leave it to the next version...
Best wishes, -- Renato