W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: PROPFIND instead of REPORT

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 21 Dec 2000 11:14:57 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569BC.003DCCEF.00@d06mta07.portsmouth.uk.ibm.com>


I shalln't pretend to be a core-centric observer, but ...

Discussing the 'number of URLs' isn't going to work for a couple of
reasons.

(1) In the face of BIND there can be any number of URLs to a resource --
but let's dismiss this one.

(2) Using VERSION-CONTROL, as defined in core, clients can create any
number of version-controlled resources (VCRs) based upon a given version
(using <DAV:version> in the body).  Each VCR would have its own URL, so the
number of valid URLs in 'the system' even for a single version will be n+m!

I think we _do_ have to talk about the number of resources created.
Assume a single versionable resource.  After the initial VERSION-CONTROL
method is applied, three resources are created:
  - a version, containing a copy of the content and dead properties of the
versionable resource,
 - a VCR, containing a copy of the content and dead properties of the
version/versionable resource,
 - a version history, containing properties that refer to the version. (not
presently in core).

From here clients can create new versions (CHECKOUT & CHECKIN) and create
new VCRs (VERSION-CONTROL) independently.

However, version histories seem to provide little functionality.  They can
answer all the version URLs (which may be difficult for a distributed
server to compute anyway), the initial version (which could be deduced as
the version with no predecessor*), and the latest version (just the
chronologically latest checkin-time, also difficult when distributed).
Beyond that, histories provide a 'handle' to the versions when all the VCRs
have been deleted -- I suggest that this role could equally be played by
any version (by following predecessor-successor references).

*-presently the DAV:predecessor set is unprotected and so multiple versions
could have no predecessor.  I suggest that we do not allow clients to
PROPPATCH an empty predecessor set on a checked out VCR/working resource.

Depending upon how popular 'latest' proves to be, that can be provided by a
different mechanism.


Tim


From: Greg Stein <gstein@lyra.org>

To:   Lisa Dusseault <lisa@xythos.com>
cc:   ietf-dav-versioning@w3.org
Subject:  Re: PROPFIND instead of REPORT

I've always seen version history resources as separate beasts from the
version selector. So yes... N+2.

And for that reasons, I've also expressed by reluctance to put them into
Core without an example case from a "Core server" mindset person.

Cheers,
-g

On Wed, Dec 20, 2000 at 05:57:13PM -0800, Lisa Dusseault wrote:
> This is likely to clear up some confusion:  I was just discussing this
stuff
> with Barry Lind today, and we were unclear on the concept of what
resources
> or valid URLs must exist.
>
> Our question was, for a document that has n revisions, how many valid
URLs
> (I'm avoiding the word resource) exist?
>  n version resources, e.g.
http://dav.example.org/foo/document.htm?version=n
>  +1 version-controlled resource, e.g.
> http://dav.example.org/foo/document.htm
>  +1 version-history resource, e.g.
> http://dav.example.org/foo/document.htm?version-history
>
> So we're talking about a model with n+2 valid URLs?  Like Boris may have
> done, I previously interpreted the versioning spec to require n+1 valid
> URLs:  one for each version, plus one for the resource/history thing,
which
> I thought was one beast, rather than two.  Now it seems you're saying the
> resource URL and the version-history-resource URL are two different
things,
> so the entire count is n+2.
>
> If that's the case, then I'm dead against requiring a version-history
> resource for servers implementing CORE.  Make the list of versions be a
> property on the version-controlled resource, or let versions be
discoverable
> by adding an <allversions> tag to PROPFIND.  It doesn't matter much, just
> keep it simple!
>
> Lisa
>
>
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> > Clemm
> > Sent: Wednesday, December 20, 2000 11:44 AM
> > To: ietf-dav-versioning@w3.org
> > Subject: Re: PROPFIND instead of REPORT
> >
> >
> >    From: Greg Stein <gstein@lyra.org>
> >
> >    On Tue, Dec 19, 2000 at 01:25:22PM -0500, Boris Bokowski/OTT/OTI
wrote:
> >
> >    > Then what about putting version history resources into core
> >    > versioning? In document management systems, the history resource
> >    > for a version like:
> >    >  http://dav.example.org/foo/document.htm?version=7
> >    > could be just:
> >    >  http://dav.example.org/foo/document.htm
> >
> >    I'd expect the second URL to refer to the "latest" version
> > rather than the
> >    version history.
> >
> > I'm sure Boris meant something like:
> >
> > http://dav.example.org/foo/document.htm?version-history
> >
> > as the URL for the version history resource, since
> >
> > /http://dav.example.org/foo/document.htm
> >
> > is the URL for the version-controlled resource.
> >
> > Note that we need to be a bit careful with the terms "refer" and
> > "latest" in this context.  When a version-controlled resource is
> > checked-in, its content and dead properties are the same as those of
> > the version resource identified by the DAV:target of the
> > version-controlled resource, but the URL refers to the
> > version-controlled resource, not to that version resource, and the
> > DAV:target is not necessarily the "latest" version (new versions can
> > be created in the version history without changing the DAV:target of
> > the versin controlled resource).
> >
> > Cheers,
> > Geoff

--
Greg Stein, http://www.lyra.org/
Received on Thursday, 21 December 2000 06:16:17 GMT

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