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

Re: Re (2): collection version resources

From: Greg Stein <gstein@lyra.org>
Date: Tue, 2 Jan 2001 14:52:58 -0800
To: Edgar@edgarschwarz.de
Cc: ietf-dav-versioning@w3.org
Message-ID: <20010102145257.E17220@lyra.org>
On Tue, Jan 02, 2001 at 05:08:45PM -0500, Edgar@edgarschwarz.de wrote:
> Hi all,
> there are interesting discussions at the moment. I'm not sure I understand all the
> terms you are using.

These terms are all defined/explained in the DeltaV draft.

>...
> > If so, then how do I create two resources with a shared history which exist
> > within the same URL namespace? Are we intending to say "not allowed"?
>
> I'm not sure what you mean by "the same URL namespace" but for a 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. BTW it wasn't a
> problem with the model I will describe later.

By "same URL namespace" I meant that the two resources share a common parent
in the URL namespace. e.g. /A/B/foo and /A/C/bar are in the /A namespace.

Not sure where the term came from, but I believe "URL namespace" is from the
DAV spec (RFC 2518).

[ btw, I do agree that two instances of the same version (history) should be
  allowed within a workspace / namespace. note that not all namespaces are
  workspaces -- "workspace" has a specific meaning in DeltaV. ]

> > >    My ideal solution would be to allow collection versions, and thusly working
> > >    collections, to contain version resources *instead* of version histories.
>
> 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.

Defined in the draft. From your list, it would be "a version of a resource."

> > > No need for this change.  Activities contain versions, and baselines
> > > contain versions, which should be all the version containment that
> > > you need.
> > I can go with that.
> I'm not sure I agree. Just imagine what happened a while ago:
> Somebody came and told me: I want the OSI-Stack of MS14 4.0 for our new project !
> So I had a look: MS14 4.0 is version 2.61 (just an example number) which is composed
> of a couple of thousand of C, include, assembler and other files. And it contains
> OSI-Stack 5.55 (Still a couple of hundred files divided in dozens of directories).
> So all which is necessary is to merge OSI-Stack 5.55 to the workspace where you
> are developing your new project. You don't have to search for all includes you
> need because the release baseline contains containers which structure the whole stuff.
> So I want a collection version to contain recource versions and collection versions.

When we say "resource", we are always referring to collections AND member
resources.

Resource := Collection Resource | Member Resource

> > > You are about to get lost in a maze of twisty passages, all of which
> > > look alike ... don't go there (:-).
> As long as you are able to kill the thief you can find your way out :-)
> Just drop some of the stuff in your inventory once in a while.

hehe... that depends. Was Geoff worried about grues or whether the magic word
is xyzzy? 

> Now just a short description what I would like to be able to do with DELTA-V:
> Because I model my software for many years in what I called software units.
> A software unit was mapped to a directory below a base directory which again
> could contain other software units or individual files. So this would be my trial
> translation to WebDAV speak:

I think that you'll find DeltaV can already model what you're speaking of.
Please read through the draft to verify.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Tuesday, 2 January 2001 17:48:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT