- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 3 Jun 2001 00:05:06 -0400
- 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). Cheers, Geoff
Received on Sunday, 3 June 2001 00:05:45 UTC