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

RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 3 Jun 2001 00:05:06 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1032D9559@SUS-MA1IT01>
To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
   From: Tim Ellison [mailto:tim@peir.com]

   It would appear that there are two camps represented on the list.

   Those that want more info in DAV:resourcetype, even if that means
   duplicating information that can be deduced by
   DAV:supported-live-properties et al.

   Those that want the opposite, i.e. downplay DAV:resourcetype and
   rely on the capabilities of a resource to determine it's 'type'.

   Pistols at dawn?  A democratic vote?  Reasoned debate?

I'll go for what's behind door number three (reasoned debate).

As tempting as it is to continue the alligator and mother-in-law
analogies (:-), it's probably more productive to focus on a concrete
benefit these new DAV:resourcetype values provide to a client.

So to start off, let's look at the only DAV:resourcetype value defined
by RFC-2518: DAV:collection.  The utility of this resourcetype value
is clear: if you have done a PROPFIND's with Depth:1, this tells you
whether to put a "+" next to a member resource, telling the
user that they can ask for nested members of that member.

As an aside, what RFC-2518 *should* have done is provide some live
property such as DAV:internal-member-count.  This would have given
the client the same information (i.e. this resource can have internal
members), but also given it something useful (like how many members
it has).  But this thread is not to correct the mistakes of RFC-2518
(but that doesn't mean we shouldn't learn from those mistakes :-).

The floor is now open for proposed additions to DAV:resourcetype,
and a specific reason for that addition (i.e. what specifically
can clients do with that new value that they couldn't already do
without it).  

Received on Sunday, 3 June 2001 00:05:45 UTC

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