RE: Relative URLs, Multiple bindings

[freed from spam trap -rrs]

Date: Fri, 5 Apr 2002 16:08:03 -0500 (EST)
Message-ID: <FDEHJMOEIDFPFLBKEICGGEEHCGAA.tim@ellison.name>
From: "Tim Ellison" <tim@ellison.name>
To: <ietf-dav-versioning@w3.org>

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of B H, Girish
> Sent: 04 April 2002 16:48
> To: 'ietf-dav-versioning@w3.org'
> Subject: Relative URLs, Multiple bindings
>
>
> Hi,
> Some queries regarding the URLs returned by a PROPFIND.
>
> Assume that we have a collection A/B/ and two members A/B/x and A/B/y.
>
> 1. When a PROPFIND is issued for A/B/, is it a MUST that the
> return URLs are
> A/B/x and A/B/y (that is always relative to the parent), or is it possible
> that completely different URLs are returned.
> For example, if we maintain some unique identifiers for the resources in a
> global path, say VCRs/, then we could probably want to return VCRs/1234
> (representing x) and VCRs/5678 (representing y). Is this allowed?

Although you may be within the letter of RFC2518 by doing so, it is unclear.
Section 8.1 PROPFIND says:
"...the multistatus XML element for a collection resource with member URIs
MUST include a response XML element for each member URI of the collection,
to whatever depth was requested. Each response XML element MUST contain an
href XML element that gives the URI of the resource on which the properties
in the prop XML element are defined."

Here I would interpret the "member URI of the collection" to mean the URI
segment known as the internal member of the collection.

Even if you could argue that the spec does not disallow the unique
identifiers, I strongly suspect that would break versioning unaware clients.

> 2. Is it possible that two bindings are pointing to the same Resource?

This is the purpose of the bindings spec. that is in progress.

> To illustrate, assume that we had the resource A/B/x and another
collection
> P/Q. Now both A/B and P/Q is checked-out. x is moved from A/B to
> P/Q.

If the collections A/B and P/Q are checked out then they will be working
collections, and will have bindings to history resources (i.e. the history
of 'x').

> After this, we do an UNCHECKOUT on A/B and a CHECKIN on P/Q. Now both
> A/B and P/Q have bindings pointing to x.

If A/B and P/Q are in the same workspace, then the CHECKIN must fail to
preserve workspace semantics; otherwise, I think it would be implementation
sepecific behavior as to whether the move created a link to the same
resource or a copy (that is, the spec does not state what happens, and you
should not rely on either case).

Regards,
Tim

Received on Saturday, 6 April 2002 07:33:54 UTC