[tdwg-tapir] TAPIR namespace and versioning

[Renato De Giovanni]

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 at 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 at lists.tdwg.org
> > > [mailto:tdwg-tapir-bounces at lists.tdwg.org] Im Auftrag von
> > > Javier privat
> > > Gesendet: Montag, 31. Juli 2006 01:56
> > > An: tdwg-tapir at 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.