Re: Versioning goals doc

Chris Kaler wrote:

> - Under "Definitions" : I don't think it is necessary that abstracted
> versioned resources do not exist.  In fact, I don't really see the point of
> this term.  It really assumes you have some Vgraph like implementation.

Well, yes.  Isn't that where we are? The "CM must be an optional feature"
requirement, which came out of the Chicago meeting, takes the "versioning is
the degenerate case of CM" approach out of the running.  Given that, the only
proposals on the table are Vgraph-based.

> - Under "Definitions" : The Vgraph is defined as an artifact of a proposed
> implementation.  We need to keep this document focused on the scenarios
> being addressed and the problems it must solve (the requirements).  I can
> see the point of an abstraction called a "version graph", but you seem to be
> defining the Vgraph.
>
> - Under "Goals" : I disagree with #1.  We are trying to define a standard
> that meets the requirements of the Internet community.

And, for some people, one of those needs is to be able to use their existing
repositories, so they can apply DAV to content they've already developed.

> - Under "Goals" : #5 is tied to an implementation.  Why doesn't #2 cover
> this?

Because all that #2 says is that there exists a URI for each revision; you may
have to issue a request to find out what it is.  Being able to build a URI
directly makes it possible to publish links to revisions.

Note, also, that we're talking about two different URIs here.  I expressed it
poorly, but my view is that the one in #5 is a URI to a resource inside the
Vgraph, which is a reference to the real revision; that reference can then have
versioning properties (e.g., log entry) distinct from the properties on the
revision itself.

> - under "Goals" : #6 is also tied to an implementation.  What is the
> scenario?  A requirement that says something like, "You must be able to
> search version history" is valid.  Is that what you meant?

I don't know; what do you mean by "search version history"? Is it equivalent,
in a Vgraph-based case, to "search the Vgraph"?

> - Under "Goals" : There are some aspects of a revision that must be mutable.
> For example, changing the security.

Mmm, true.  Anything else? I don't think so.

> I think this is what you meant by your
> explanation paragraph, yes?

No.

> - I didn't see anything about automatic versioning for HTTP/1.1 clients.
> Did I miss it?  (which is entirely possible).

No, I forgot about it.  (Not having minutes from Raleigh has been making this
work harder; my own notes weren't complete.)

> - Personally, I'd like to see a goal that we make it easy for clients to
> interact with DAV servers that support versioning.

Motherhood & apple pie, isn't it? We certainly aren't going to go out of our
way to make things harder; otherwise we'd be expressing the protocol elements
in ASN.1, layering on top of three other complex protocols (of which two would
be copyrighted and one would be incompletely specified), and demanding
interoperability with the Dewey Decimal System.  But this isn't the ITU.  :-)

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |Nondeterminism may or may not mean never |
|francis@netscape.com      | having to say you're wrong.             |
\====================================================================/
New area code for work number: 650

Received on Thursday, 24 September 1998 16:48:31 UTC