[tdwg-tapir] TAPIR namespace and versioning

[Javier de la Torre]

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.