W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Re (3): collection version resources

From: Greg Stein <gstein@lyra.org>
Date: Thu, 4 Jan 2001 09:56:14 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010104095614.F17220@lyra.org>
On Thu, Jan 04, 2001 at 08:31:39AM -0500, Edgar@edgarschwarz.de wrote:
> >    workspace I think it makes sense to allow it. Just some months ago
> >    I had the pathological case that I needed two different versions of
> >    a file in a software release.
> > 
> > I believe that the term "pathological case" is key here.  There are
> > cases where exposing two versions in a release does arise, but in 
> > practice, these cases tend to be pathological, and the value of
> > supporting this is outweighed by the cost of ambiguous merging behavior.
> > 
> > For those (rare) cases when you need to do this, Greg's suggestion
> > should be fine (where you just initialize a new version history
> > with the version that you need to expose in the same workspace).
> Will be OK in practice but I still don't love it. Because it wouldn't be a
> problem in my model.

If you limit the scenarios that are supported, then sure... it wouldn't be a
problem. But DeltaV covers a lot of different ways of doing versioning, and
supports a number of different server models.

Yes, it would be great to have a workspace where two resources had the same
version history. But that monkeys up your MERGE case.

> >    Sorry I'm not sure I understand. What's a "version resource" ? A
> >    versioned resource, a version of a resource or a versionable
> >    resource ? Just to name some guesses.
> My problem was that in the draft 10.11 there is a definition for "version" but
> not for "version resource".

The definition for "version" /should/ read "version resource".

In general, the terms in S1.3 should be "Version Resource" and "Version
History Resource" for consistency.

> Also Greg (And you in Chapter 11) was talking
> about "collection versions" so I assumed that the equivalent term would be
> "resource version" and wondered about "version resource".

Version resource is the generic term. I was speaking about the specific case
where a version resource is for a collection. I guess you could use the term
"member version" but I've never seen that used/needed in discussions.
Collection versions are quite special (thus, section 11), and needed to be
distinguished in the coversation.

> > When we say "resource", we are always referring to collections AND member
> > resources.
> > Resource := Collection Resource | Member Resource
> Perhaps that is in RFC 2518 ?

Yes, it is.

> But I didn't find it at the start of DELTA-V.
> Perhaps this should be made clear (even if 2518 and 2616 are mentioned).
> Because the obvious interpretation of a resource I think is of a
> "member resource" (Aka file :-)

The first paragraph of S1.3 makes it clear that the draft uses terms from

I don't think that a person can reasonably make use of the DeltaV draft
without being familiar with RFC2518. Thus, using the terms freely is a
reasonable expectation.

> There is a definition of "working resource" in 4.1 but I would prefer it
> to be in 1.3 (Terms) to get a better overview what's going on.

I would agree. It would actually be useful to add simple definitions for the
other resources, too (activity, baseline, baseline selector, baseline
history, and workspace).

> Neverthess my question is whether it would be possible/useful to give a short
> formal definition of DELTA-V concepts somewhere as an EBNF grammer
> like I'm trying with my stuff.

This could certainly be produced, but it would probably be an associated
document rather than part of the RFC. There was one written a long time ago
(read: out of date) and is linked off the DeltaV home page (the "model"


Greg Stein, http://www.lyra.org/
Received on Thursday, 4 January 2001 12:56:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC