Hi Renato,
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.
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.
Finally a comment on your answer to why is useful to include the version number on the namespace:
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.
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. 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.
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. 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.
So... anybody supports the remove of the version number in the namespace? If not I shut up right now.
Javi.