On Wed, 30 Jul 2003, Matthew J. Dovey wrote:
> > How did OAI handle the 1.0, 1.1, 2.0 transitions?
> "Is version 2.0 of OAI-PMH compatible with earlier versions?
> OAI-PMH version 2.0 is not backward compatible. Results from the

Ralph:
> Maybe. But, as the service gets more mature, the changes should be
> smaller and maybe the choice will become easier. My hope is for rapid
> stability.

I don't think we'd be doing anyone a great disservice by simply
abandonning 1.0 so long as 1.1 clients can still talk to 1.0 servers with
simple requests. (By simple, I mean that they don't include any of the
1.1 changes)

So I think we don't increment the namespace at all and all of the new
fields go in to the existing namespace. We can increment it at major
versions if we feel the need.

That said, I think a version parameter might still be useful, especially
for SRU, but I'm in two minds about what it should default to. If we
abandon 1.0, then we can say that version defaults to the latest release,
then for the majority of clients and servers it's unneeded. If it
defaults to 1.0 then it's required on every transaction just to benefit
the people who aren't upgrading, which might be no one.

A 1.0 client can be pretty quickly retrofitted with the version parameter
to say 'I'm only 1.0 please be gentle' even though it wasn't a valid param
in 1.0 ... SRU 1.0 servers will simply put it in the unknown fields and
return a 1.0, but 1.0 SRW servers will fail the request with a SOAP fault.
The client can always catch that and take off the version parameter I
suppose. *ponder*

Rob

--
      ,'/:. Dr Robert Sanderson ([log in to unmask])
    ,'-/::::. http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I