Hi Renato,
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 have to say that I am also not that sure about it ejem, but still I also feel a little bit better because I see this mechanism being used in OGC and the standards there are working with a lot of implementations, different versions of the standards, etc.
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.
But wait, what you are saying here is two things. You are saying that namespaces are used for: 1) provide a scope mechanism so that tag names from different schemas dont crash. 2) denote the concept behind an element
I fully agree with the first but not with the second.
<a_little_bit_of_guessing> XML schema is just a way of defining XML documents, not the concepts behind the elements. I think we have had this discussion several times. XML schema does not define the semantics of the XML and therefore the namespace is not intended to be used to solve crashes among semantics. </a_little_bit_of_guessing>
In any case I am not sure that we will change the semantics of a concept without actually changing its name. Even for us would be nasty, outputModel in the sense of TAPIR 1.2?
Regarding the XML format, well, just by using the namespace you can not validate a document, you need the schemaLocation for it and there is where the person producing the XML should include the version that is valid for the document. In the client side the software must take care of the version attribute or take the risk to try to understand whatever it comes with his code.
On the other hand, I do see the advantages of keeping the same namespace if changes are not significant.
Fine, I think nothing prevent us for doing this. And because we dont feel comfortable with none of the solutions we can go both ways, the same as in ABCD. So, do you like keeping the 1.0 in the namespace? We use 1?
Maybe we could use 1.0 in the namespace and in the version we use 1.0.0 and we keep them consistent, so that you have namespace 1.0 and version 1.0.3
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 only within the document they are parsing, they dont make use of namespaces to solve version issues.
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...
Fine, version negotiation will be included once we need it, that's when next version is released.
So, summarizing, because I think we already agree. -Namespaces only change when there is a backwards compatibility problem. -We add the version attribute to the schema so that we can keep track of different versions.
And I would include (I dont know if you agree on this) -Use 2 numbers in the namespace and 3 in the version and keep them consistent.
JAvi.