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

Issues/questions regarding sections 3, 4 and 5...

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Tue, 07 Aug 2001 12:44:29 +0100
Message-ID: <3B6FD49D.1092BE77@merant.com>
To: ietf-dav-versioning@w3.org

After reading through sections 3 & 4 & 5 (with a group of other MERANT
staff) here is a list
of issues/questions  (some of these issues are editorial and simply need
in the spec, others are real issues/questions).


In the specification some of the sections eg, 10.1,10.2 have no white
space after the
section number, others (eg section 9.7,1.6 do have a single space). Some
sections, eg 13.10
are followed by multiple whitespace characters.  I think this is caused
by conversion from
Microsoft Word to ASCII.  We should correct this before submitting the


Section 3.1.4, the last sentence does not seem to make sense, it reads:

"A live property is supported by a resource if that property has the
semantics defined for
that property"

The property always has the semantics defined for that property.  Now we
have the
property-o-rama we could replace that definition with something like:

"A live property is supported by a resource as specified in Appendix A
(section 23)."


Section 3.9 the specification says that when a resource is automatically
checked out:

"the DAV:checked-in property MUST be empty"

Should it be empty or should it be removed, I read this statement as
meaning that
DAV:supported-live-property-set would still contain DAV:checked-in and
on DAV:checked-in would return an empty value. I thought we were going
to remove the
DAV:checked-in property from the supported-property list when the
resource is checked-out.
The specification should be consistent with respect to which properties
are removed and which
are empty in the various states of the resource since it is crucial for
the whole "check the
properties to find out what type of resource this is" system to work.

This also applies to section 4.4 where it talks about properties being
"no longer set".


Section 4.4 starts to talk about the UNCHECKOUT on a Working Resource.
I think this text
would make more sense if it was in "Working Resource Feature" section 8.


Section 4.3 states for CHECKIN that :

"The response for a successful request MUST include a Location header".

The only time deltav talks about the location header is for CHECKIN of a
of a working resource (section 9.3).  Why is this only on those methods?
What is the use case for it
(does it simply save the client from having to PROPFIND the
DAV:checked-in?).  I ask this because
the Location header is not returned by other methods that create
resources,  eg UNLOCK etc for
auto-versioning clients (eg when automatically checking in).

I suggest we either remove the feature or use it consistently eg
whenever a new resource
is created return the Location header.


Section 5.4.1 since this report is on a collection I would like a Depth
header defined.
Again I think we should be consistent (to avoid speical-case coding).
Any method that gets properties
of a collection should take a Depth header.


Section 5.5 defines this mechanism where OPTIONS can be used to find a
possible location
in the namespace that is to be used for version histories.  I assume
this is so a client can indicate
in a GUI if a collection is a collection of version histories or a
client could choose not to display
that part of the namespace.

It seems odd that this is only available for version histories, these
are not the only resource that have
"server-defined" URLs.  For example would the clients want a OPTIONS
request to indicate where
in the namespace will be used to reference versions as opposed to
version controlled resources?
The same arguments as in section 5.5 applies to versions, they may not
be stored on the same server etc.

I also think an example of the OPTIONS method being used for this would
be good as it is quite different
from other uses of OPTIONS.


Reading section 5.6 it took us quite a while to decide how to delete the
last version from a version history.
I think the answer is "you don't" you must delete the version history
itself in order to delete the last version.
Did we interpret this correctly?  Do you think we should clarify this in
the spec?

I look forward to seeing some of you at the deltav sessions in London

Peter Raymond - MERANT
Received on Thursday, 9 August 2001 07:26:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC