Hi Javi and others,

Sorry about taking so long to answer this one. Protocol and schema versioning seems to be a very complicated issue, with big discussions and doubtful recommendations.

I'm also not sure about the best way to proceed, but I tend to agree with Markus: change the namespace only for new major versions, but always indicate the full version as an attribute of the schema.

Instance messages could also indicate the full protocol version in the root element if the namespace will really be "reused" by different versions over the time.

I just feel that version negotiation is probably too much at this point. When time comes to make a major protocol change, providers could probably set up different provider instances in separate access points if they want to support more than one version. Having multi- version provider software using the same access point is also an alternative, but I fear we could be complicating the protocol for things that we're not sure if they are going to be used or implemented soon. Anyway, clients are always free to try parsing future versions of protocol messages - they don't necessarily need to break, as you said.

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.

Regards, -- Renato

On 31 Jul 2006 at 14:41, Javier de la Torre wrote:

Hi Markus,

Ok, I understand that if you think that we should not take care of version negotiating at this moment then we have to include the major version in the namespace.

In any case I still tend to thing that there is not such a big advantage of using the protocol version in the namespace. Maybe we will have TAPIR 2.0 which will modify completely most operations but leave intact the inventory. Why clients only using inventories have to break?

I rather prefer to see an exception on the client when he does not understand the server than a crash only because of namespaces...

What are the advantages of including the version on the namespace? Briefly (just to revate :D )

Cheers.

On 7/31/06, "Döring, Markus" m.doering@bgbm.org wrote:

...

Well, I hope that TAPIR is not changing really. It should be much more stable than our content schemas. So if we include the major version in the namespace I think this is OK.

Including the full version number as an attribute into the schema I think is always a good idea. This way we could add minor things to the schema keeping backwards compatability and still discover the exact schema version.

I dont think our community currently could handle different major and incompatible versions of a protocol. So negotiating for a version of the protocol seems to me too much too soon. by the way a great album title: http://en.wikipedia.org/wiki/Too_Much_Too_Soon_%28album%29

-- Markus

...

-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Montag, 31. Juli 2006 01:56 An: tdwg-tapir@lists.tdwg.org Betreff: [tdwg-tapir] TAPIR namespace and versioning

Hi all,

After discussion in Tervuren about ABCD and versioning issues I thought that we should maybe consider the same strategy for TAPIR. That is:

-Do not include the protocol version in the namespace but rather use always something like http://rs.tdwg.org/tapir -Use the version attribute in the schema. -Include a version attribute in the request top element to specify the TAPIR version of the message. -A new mandatory version parameter for GET operations called version.

I even think that we should not change the namespace when doing non backwards compatible changes to the protocol. Clients should take care themselves of looking at the version attribute always.

This is the way all OGC standards work and I think is a good strategy.

But this can probably be consider a pretty dramatic change in the protocol right now... what do you think? I think it would be great to include this strategy from the beginning so we are not so worry about breaking clients with possible small changes in future versions.

Best regards,

Javier.

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

Javi,

It's always good to know what OGC is doing and try to learn from their experience. However, they are not the only ones working with XML Schemas. And if you look at other groups you'll see that almost everyone uses either version numbers or dates in the namespace (just look at the namespaces declared in the <schema> element of tapir.xsd).

I know that "namespaces are not intended to solve crashes among semantics", but they do provide a way to say that ns1:myelement is fundamentally different than ns2:myelement, that was my point. I'm not sure if the example I gave was a good one - of course I wouldn't like to see this kind of difference between two TAPIR versions. It was just an example.

Yes, you can't validate a document without having the schema. But you could have the schema for some other reason without needing to read it from the schemaLocation. Actually I don't think it's safe to always trust the schemaLocation of documents (it should be possible to try to feed an application with an "alien" document that has a known namespace pointing to a fake schemaLocation... not sure how far this could go).

-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.

Agreed. But when time comes, we just need to clearly define what kind of changes would mean breaking backwards compatibility.

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.

Could be one or more numbers, or dates... it's just an identifier. I'll be happy with any of the available options, even the current one.

Regards, -- Renato