Re: Re (3): collection version resources

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

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"
document).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 4 January 2001 12:56:56 UTC