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

RE: FW: DeltaV Passthrough issues

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 5 Feb 2001 14:58:32 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <CNEEJCPIOLHKIOFNFJDPAEBMCDAA.lisa@xythos.com>
> Note: Lisa asks a bunch of great questions here.  They are all
> good candidates for FAQ entries.  For the moment, I'll just
> do the easy thing and answer them in email.  I'll try to get
> this info transcribed to the FAQ.  If anyone else has a chance
> to enter this information in the FAQ, that would be greatly
> appreciated!

Two of the questions I asked so far seemed to be answered with simple
clarifications.  I've added those to the FAQ.

Many of the questions are NOT suitable for being answered in the FAQ.
They clearly ask for normative declarations (rather than unstated
assumptions), which belong in the spec, or rewording of text in the
spec.

> But there is no "implicit" pass through by a version-controlled
> resource.  This is explicitly stated in section 2.1.
>
>    To recap:  When new kinds of resources that have targets,
>    like "Direct Reference Resources" or "Version controlled Resources"
>    (DRR/VCR), are exposed to clients that are not familiar
> with the new
>    kinds of resources, it's often beneficial to allow some of
> the methods
>    the client may send to "pass through" to the target of DRR/VCR.
>
> A version-controlled resource does not have a "target".  We
> explicitly got rid of this term because it was misleading people
> into thinking just what you describe above.  Pass through behavior
> only occurs when explicitly requested by a header, or when
> explicitly defined in the semantics of a new method.

I'd like to believe you ;) but the draft states:

"A PUT or PROPPATCH to a version-controlled resource with the
DAV:auto-version property set will automatically check out that resource
prior to executing the PUT or PROPPATCH.  If that resource is
write-locked, the resource remains checked-out until the resource is
unlocked, at which time the resource is checked in and a new version is
created in the version history of that resource."

That to me is "passthrough", even without the label target, because it
bypasses the content or properties of the VCR in order to create a new
version.  How am I supposed to change the properties of the VCR itself?
The previous paragraph states:

"In order to use methods like PUT and PROPPATCH to directly modify the
content or dead properties of a version-controlled resource, the
version-controlled resource must first be checked out.  When the
checked-out resource is checked in, a new version is created in the
version history of that version-controlled resource.  The version that
was checked out is remembered as the predecessor of the new version."

That is unacceptable.  It's completely unacceptable to create a new
version of a resource, just in order to be able to modify a property
like 'Last-published-version' on the VCR.  For the sake of conciseness,
let's call this a "global" property: it applies to all versions, and
can't have different values on different versions.

In order to modify a global property, does a new version have to be
created? Even though nothing changed on the old version? (the only
change, conceptually, is a dead property on the VCR).  If I understand
the model correctly, that won't work because the properties of a
checked-in VCR are the same as the properties of the checked-in version.
So global properties can't be placed on VCRs at all.

Where do global properties go, then? You state that rather than put
global properties on the VCR, the client ought to put them on the VH:

> It sounds like you're talking about properties on the version history
> resource.  Your server of course must then support the version history
> option, but then you PROPPATCH the version history resource
> just as you
> would PROPPATCH any other resource.

That's unacceptable.  First, as you point out, the server must support
an extra resource, the VHR.  Then, in order to present a directory
listing with the value of a global property like
"Last-published-version" for each of n VCRs in a directory, the client
would have to issue a depth:1 PROPFIND request to find all the URLs to
the VHRs, then issue n PROPFIND requests, one to each VHR independently,
to get the values of "Last-published-version".

However, the real showstopper is the lack of resource transparency.
Global properties, like "author" from Dublin Core, or "Editor-in-Chief",
are hidden away in VHRs.  That means that versioning-unaware clients
cannot interoperate with versioning clients on the same set of
documents.  They can't even PROPFIND a set of VCRs to get properties
which ought to exist.

lisa
Received on Monday, 5 February 2001 17:59:47 GMT

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