Re: Reading version of draft Functional requirements for basic versioning
I would like to see 'browser' changed to 'client' everywhere in the
document. This is because 'versioning' is useful for authors who are
interacting with remote repositories even if they're not using a
I think also that most (if not all) of the instances of 'user agent'
could also be 'client'. While all 'user agents' are clients, the
converse is not true: some clients, and clients of version-enabled
repositories in particular, might not be 'user agents' but other
There are places where you say 'versioning-aware', but I think that
'aware' is not strong enough. For interoperability to be useful, the
participants need to actually support versioning, and not just be
'aware' of it.
I think the word 'Style' in 'Style-free Versioning' is confusing;
we're not talking about style sheets. And in some ways, it is
impossible to be 'free' of style. Mainly what you want is 'Support for
many different versioning paradigms'. It would be useful to elaborate
more fully on what those different paradigms might be, or at least
In 'Legacy Resource Support', it is misleading to call
'non-versioning' servers 'legacy', since we might expect many future
repositories to not support versioning. It's not 'legacy' in that you
don't expect them to be obsolete. Perhaps you mean 'Interoperability
with non-versioning systems' or some such.
When you talk about 'named versions', it would be useful to explain
that a version 'name' is often a number.
What does 'Some versions of a resource are special.' mean?
I would suggest _not_ prejudicing the design choice by avoiding
capitalizing LOCK, UNLOCK, NOPS, RESERVE, UNRESERVE, etc. etc.
which makes it seem like you want a new HTTP operation for each