Re: Reading version of draft Functional requirements for basic versioning

At 12:15 AM 9/12/96, Larry Masinter wrote:
>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
>'browser'.

   Thanks. I _meant_ to be consistent. Will global search to make sure I am.

>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
>applications.
  This seems correct to me.

>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 thought that some level of support should be possible for completely
dumb clients (at least). This might involve extra server work to perform
automatic merges or some other workaround for client non-versioning.
>
>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
>give references.
The term versioning style comes from a recent Hypertext paper. I will add
references to a few of the significant methods, and call them "versioning
policies."

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

Interoperability with non-versioning systems it is.


>When you talk about 'named versions', it would be useful to explain
>that a version 'name' is often a number.
Sure. I tried to use version identifier consistently not to imply either
user-assigned strings, ro automatically-defined version numbers.

>What does 'Some versions of a resource are special.' mean?
I will change this to read "these versions of a resource are special" so
that the reference to the preceding bulleted list is more clear.

>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
>conceptual operation.
   True, my predjudices are showing there. I will try quoting them and see
if that's clear enough.

   Thanks for the comments, especially given how late this is...

   -- David

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/

Received on Thursday, 12 September 1996 14:58:27 UTC