Next message: Boris Bokowski/OTT/OTI: "conference call?"
Date: Fri, 25 Aug 2000 18:30:21 -0400 (EDT)
Message-Id: <200008252230.SAA05292@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Where have DAV:revision-set and DAV:working-resource-id/URL-set gone?
From: Juergen Reuter <reuterj@ira.uka.de>
Section 3.4.3:
==============
What is a "reasonable approximation"? A maximal difference of one
second? A millisecond? Please explain the reason for this
requirement so that the reader gets an idea of what is reasonable.
Actually, this was left deliberately vague because different servers
have different ideas about what is reasonable. We just wanted to
make sure implementors thought about what would be "reasonable" for
their expected use cases.
Section 3.5.1:
==============
Mmh, the former DAV:predecessor-set had the advantage that I could use
the same code for revisions and working resources when traversing through
the revision tree including working resources as special leaves of the
tree. But DAV:checked-out probably better reflects the concept of
working resources. So I am not really sure what is better.
DAV:checked-out and DAV:predecessor-set are different. DAV:checked-out
is a modifiable property that accurately reflects what version initialized
your working resource. DAV:predecessor-set is a modifiable property
that indicates what you want your predecessor-set to be. For "unreserved"
checkouts, you can encounter the situation where the predecessor-set
will not include the dav:checked-out version (but will contain some
descendant of the checked-out version, selected by the client).
Section 4.1:
============
replace "label" -> "label name" to be consistent with 3.4.4.
Yes, I was inconsistent. The problem is that we have both XML
elements and syntax. I was using "label" as the syntax class,
to distinguish it from "label-name" which is an XML element.
But now that we also have a "lable" XML element, it becomes ambiguous
again (drat). I guess I'll use "label-string" for the syntax class,
to make sure it isn't confused with the "label" XML element type
or the "label-name" XML element type.
<nitpicking>
Change wording: "A Target-Selector header has no effect if the
request-URL does not identify a version selector." Because a target
selector does not affect the request-URL, but its interpretation.
</nitpicking>
I'll see if I can think of something that doesn't obscure the point
being made.
Section 6.1:
============
Replace "version controlled resource" with "version selector resource"
for consistency with other sections.
Do others agree? I used the term "version controlled resource" in a
few places where it seemed to read better.
Section 6.6:
============
Is it really <!ELEMENT set (label-name)>
or rather <!ELEMENT set (label-name-set)> ?
Yes, you can only set one name at a time with a LABEL request.
"If DAV:add or DAV:replace is specified, the specified label selects ..."
DAV:replace is undefined.
Good catch! ("replace" was replaced with "set", but I missed a couple).
The difference between set and add is unclear.
"add" fails if the label is already applied to a version.
Section 21:
===========
For consistency, replace DeltaV -> Delta-V (2x)
Will make it consistent (but go the other way :-).
Reminder:
=========
* still conversion problems with Word->HTML:
- ".." in table of contents
- formatting of ascii art: missing <PRE>...</PRE>
I clean up the ascii form, but until last call, the HTML form
will just be whatever Word spits out (:-).
* write section for IANA editor to assign status code numbers 4xx
Will do.
And thanks for the review!!
Cheers,
Geoff