Next message: Clemm, Geoff: "RE: Workspaces as versionable resources"
To: ietf-dav-versioning@w3.org
cc: reuterj@ira.uka.de, jjh@ira.uka.de
Date: Sat, 20 May 2000 18:09:32 +0200
From: Juergen Reuter <reuterj@ira.uka.de>
Message-ID: <"iraun1.ira.0076801:000520.160946"@ira.uka.de>
Subject: Re: draft-ietf-deltav04.5 now available
Geoffrey wrote:
> Table of Contents
> -----------------
>
> Many headlines end with a period where it probably should not occur
> (at least, the "." do not occur consistently).
> I didn't see any headlines that end with a period. I assume you are
> not referring to the "..." in the table of contents?
I am referring to:
http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-04.5.htm
This contains single and double "." at the end of some, but not all
headlines, e.g.:
> 7 Advanced Versioning.. 20
>
> 7.1 Advanced Versioning Terms 20
>
> 8 Advanced Versioning Semantics. 21
>
> 8.1 Target Selection and Workspaces. 21
>
> 8.2 Baselines 22
>
> 8.3 Parallel Development and Merging. 22
>
> 8.4 Activities. 22
>
> 8.5 Versioned Collections. 23
Note that the indention is also broken. From a short look at the html
code (arrgh! sgml/html was originally designed to be human-readable!)
I guess your software has some problems with converting the original
document into html. In fact, the resulting html is buggy: in section
2.1, it produces a "<big>...</big>" tag that is visible to the user:
> <span
>
> class=HTMLMarkup><span style='color:red'><big></span></span><span
>
> style="mso-spacerun: yes"> </span>The revision that was checked out is the
> predecessor of the new revision.<span class=HTMLMarkup><span
style='color:red'></big></span></span></p>
Btw, the diagrams in sections 1.2 and 2.1 do not show properly (there
probably should be a "<pre>...</pre>" tag surrounding the diagrams).
> What about the
> redirection resources protocol which was mentioned in early versions
> of this protocol? It seems to have disappeared.
>
> Hmmm. I'm not sure what this is referring to. Do you have a particular
> protocol draft version you can point me at? (I of course keep the protocol
> drafts under version control :-).
For example, draft-ietf-deltav-versioning-04.txt mentions it in the
open issues section. I thought I once even read it somewhere in the
introduction, but I can not find it anymore; maybe I was wrong.
> > Predecessor, Successor
> > ...
>
> Ancestor and descendant are defined in terms of predecessor and
> successor. Bearing object inheritence in mind, it would be nice to
> notice that a predecessor can be viewed as an immediate ancestor and a
> successor as an immediate descendent.
>
> That would require us to introduce a term like "immediate", which I
> think should be avoided if we already have terms (i.e. predecessor and
> successor) that capture that concept.
I was just thinking of an informal note to the reader rather than
formally defining something new.
> What is the difference between a "protected" property and a
> "read-only" property? Yes, I know, a "protected" property may change
> e.g. as a side effect of a CHECKIN, but not via a PROPPATCH.
>
> Yes, that is why I decided to not use the term "read-only".
>
> Section 4.1 of [WebDAV] says:
>
> > Live properties include cases where a) the value of a property is
> > read-only, maintained by the server, and b) the value of the
> > property is maintained by the client, but the server performs syntax
> > checking on submitted values.
>
> So, a read-only property may also change. Hence I do not see any
> difference between "protected" and "read-only".
>
> Yes, but a protected property can be changed by the client, just not
> with a PROPPATCH. I'm concerned that people will interpret "readonly"
> as "only can be changed by the server".
Yes, but your argumentation is also applicable on WebDAV's "read-only"
properties. Hence, the term "read-only" seems to be flaw of WebDAV;
it should be renamed, and deltav should use the new term. So, I would
like to vote for renaming WebDAV's "read-only" into "protected".
Should this be put onto WebDAV's issues list?
> > ... all revision properties except ... are immutable.
>
> "immutable" should be defined somewhere and compared with "read-only"
> and "protected". "immutable" implies "protected", but not vice-versa,
> right? "immutable" implies "read-only", but not vice-versa, right?
>
> Immutable is not being used in a technical sense ... it just means
> "cannot be changed". Protected properties can be changed, but not
> with PROPPATCH.
I think it does not get clear that immutable is not being used in a
technical sense; for me, it sounded as if "immutable" were a synonym
for "read-only", which it is definitely not. But, once again, this
is probably a flaw of WebDAV rather than DeltaV.
> It should be mentioned that all versioning headers obey the message
> header format as specified in section 4.2 of [HTTP/1.1]. Otherwise,
> the field-name, for example, does not need to be a token, but could be
> regarded as a literal string. But that would mean that there is no
> implied LWS between the field-name and the ":" (just as, for example,
> there is no implied LWS in the HTTP-Version production in section 3.1
> of [HTTP/1.1]). Section 4.2 of [HTTP/1.1] also explicitly allows LWS
> between the ":" and the field-value.
>
> I would like to propose the following introduction in section 4: "This
> section defines some header fields additional to those defined in
> [WebDAV] and [HTTP/1.1]. They follow the format and conventions
> defined in section 4.2 of [HTTP/1.1]."
>
> I think it is better to just put the LWS explicitly in these productions.
> So I'll just add LWS? after the ":" and add LWS before the id.
HTTP/1.1 talks about "any amount of LWS" before the field value; hence
*LWS should be fine. Similarly, it is implied *LWS.
> ...
> Ok, but what happens, for example, when you try to DELETE a stable
> URL? Does that mean that the associated revision is to be deleted?
> ...
> The same questions arise when you apply DELETE or
> MOVE on a versioned resource whose target is a revision.
>
> No, in that case, the paragraph you quoted applies, and the DELETE or
> MOVE is applied to the binding to that versioned resource, not to the
> revision.
But, once again, given a server that does *not* support the bindings
protocol, what happens, when you try to DELETE a versioned resource
whose target is a revision? Delete the revision? Delete the versioned
resource? Return an error?
> When you say it is a misunderstanding, did you mean that it wasn't
> clear what was being said, or that you thought it meant something
> else?
I think it is the wording "target of a versioned resource" itself that
was confusing me. Ok, the definition in section 1.2 explicitly says
that the target is controlled with the Target-Header-Selector. Still,
I personally would prefer a term like "target of a request to a
versioned resource" or "request target of a versioned resource".
Bye,
Juergen