RE: Versioning goals doc

Chris Kaler writes:
> - Under "Definitions" : I don't think it is necessary that abstracted
> versioned resources do not exist.

This is a good point. I feel the last sentence in the definition of
"abstract versioned resource" can safely be omitted without losing the
essence of the concept.

> In fact, I don't really see  the point of this term.  It really assumes
> you have some Vgraph like implementation.

An abstract versioned resource does not assume the existence of a version
graph.

In this working group we have agreed many times that each revision of a
"chunk of state" is its own resource.  So, if you start with a resource with
URL "example.html", and make a revision of it with version control active,
that new revision will be a separate resource, with a separate URL, from the
resource with URL "example.html".  One potential convention that an
individual server might adopt (out of many possible conventions) is to tack
on a version identifier to the end of the original URL.  So, the URL of the
first revision of "example.html" might be "example.html?ver=2.0".

OK, since each revision of a resource is itself a resource ("example.html"
and "example.html?ver=2.0" are two separate resources, with two different
URLs), what term do you use to describe all of the revisions over time of
the resource with URL "example.html"?  The goals document is proposing the
term "abstract versioned resource".

The term "versioned resource" doesn't work, because that implies just a
single resource, when, in fact, there are multiple resources, one for each
revision.

Chris Kaler writes:
> - 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.

While I agree that using a Vgraph places some restrictions on the solution
space, I doubt they're as restrictive as you're making them out to be.  A
version graph approach does rule out sums of changes approaches similar to
those used in the PIE system.  In these systems, a user constructs the state
of each object by adding together various changes (e.g., start with
baseline, add bug fix #43, add bug fix #56, add operating system upgrade
patch).

But, I don't think this is what you're proposing WebDAV adopt.

I guess I don't see your objection to a version graph.  If someone is making
changes to resources, and these changes are tracked, then a revision of a
resource has an "is-derived-from" relationship between it an the resource it
is derived from.  Once you accept that this relationship exists (and it
seems to me that it must if the system supports reverting to a previous
revision), then it is reasonable to discuss the topology of the
relationships, and to give a name to the set of resources and relationships
between them.  Hence version graph.

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

I'm not very fond of this goal either.  It's a standardized URL munge.

John Stracke writes:
> 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.

But, once you have discovered the URI for a prior revision, then you can
always link to that revision.  The URL string manipulation convention you're
proposing is merely a shortcut for avoiding this first step of discovering
the URI of the revision.

Chris Kaler writes:
> - 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 agree that this is still too implementation-specific, since I can imagine
potential implementations where a version graph is not a collection, but whe
re I would still want to perform searches across a version graph.  I agree
with Chris that the real requirement is something along the lines of "It
must be possible to perform content and property searches across the members
of a version graph."   It might also be a nice goal to be able to search
across the members of a configuration as well.

Chris Kaler writes:
> - Under "Goals" : There are some aspects of a revision that must
> be mutable. For example, changing the security.  I think this is what you
> meant by your explanation paragraph, yes?

Live properties in general are tricky here.  I think it makes sense to limit
freezing of properties to dead properties only.

Chris Kaler writes:
> - Under "Goals" : #11, again this is tied to a proposed protocol.  What is
> the scenario you are trying to address?  "It must be possible to determine
> the predecessor and successor versions" ?

I think the goal is to support finding the predecessor and successor of a
particular revision.  However, I think this requirement is already covered
in RFC 2291.

- Jim

Received on Friday, 25 September 1998 15:41:37 UTC