[tdwg-tapir] TAPIR namespace and versioning

Renato De Giovanni renato at cria.org.br
Mon Aug 14 21:17:29 CEST 2006


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:
> 
> http://rs.tdwg.org/tapir/1
> 
> 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




More information about the tdwg-tag mailing list