Re: AW: Removing the DAV:activity and DAV:version-history and DAV :baseline resource type values

"Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
>
> What is your rationale for checked-in/out in the type?
> I think I have missed something in the spec, since it
> feels like a property to me.

I agree that, for most of us, the checked-in status of a resource would be
considered part of its 'state' rather than its 'type'.  However, these
terms are ambiguous at best, and in previous posts I had tried to avoid
using 'type'.

The only DAV:resourcetype that we have right now is DAV:collection which is
useful to clients since it tells them that the namespace can be / is
extended 'through' this resource.  It is also redundant since clients could
simply try an operation on the extended namespace and react to its success
or failure (e.g. PROPFIND depth 1 on something, or PUT to a URL
one-segment-longer) to determine if the resource has collection semantics.
So I would suggest that the rationale for providing DAV:collection is that
it is a convenient way to give clients a hint that these 'extended
namespace' operations have a chance of succeeding, and to given them a
reasonable assumption that they should display the [+] twisty progressively
as the namespace is explored, etc.

[Footnote: Of course after discovering a DAV:collection resource there is
nothing to stop another client deleting the DAV:collection and replacing it
with a non-DAV:collection thereby foiling the client's assumptions, which
means all clients must have some way to deal with the world as though there
was no DAV:collection anyway. (lock everything yeh)]

So, if we are to continue this use of DAV:resourcetype it would be to give
clients a useful classification of a resource at a particular point in time
that would give them a reasonable set of data for displaying an icon,
greying menu items and so on.  It should convey both versioning 'type' and
'state' that is within the mandate of WebDAV.  The specification has
already called out a number of useful resource classifications and they are
the ones that I proposed (DAV:checked-in _and_ DAV:checked-out may be
redundant).

Tim
p.s.  Just in case anyone missed an earlier post, I'll reiterate that the
spec is not broken, it works just fine as it is written today, and I
continue to support it fully in its present form.  I'm just exploring this
idea and enjoying the thoughtful observations that it produces re: spec
complexity, clarity of presentation, etc.

Received on Wednesday, 6 June 2001 10:21:56 UTC