- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 5 Jun 2001 10:47:41 -0400
- To: ietf-dav-versioning@w3.org
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Von: Clemm, Geoff > This I believe remains the key argument. Is future > interoperability improved, unaffected, or harmed through the > addition of these new resourcetype values? My argument is the > "like a duck" argument (i.e. if it looks like a duck and acts > like a duck, even if it is some refinement of a duck, if your > client does not know about that "duck refinement", it is better > for your client to treat it as a duck than to treat it as an > "unknown resource"). I think it's not only future interoperability, but also interoperability as such which can be improved by explicitly stating the type of a resource. Rumour has it that code can have bugs. Sticking to the analogies in this thread, if your mother-in-law does not report a property properly, the alligator might look like a duck and eat your client alive. So the reason for adding values to DAV:resourcetype is that it is more likely for a server to be able to return the correct DAV:resourcetype value than it is for it to return the correct DAV:supported-method-set or DAV:supported-live-property-set value? I find that rather hard to understand (much less, believe :-). The reason I'm applying so much time/energy to this thread, is that it is really a general DAV question that shows up (and will continue to show up) in every DAV extension. I'd like to develop some guiding principle for "what goes in DAV:resourcetype", so that we don't end up having these same (often metaphysical :-) arguments every time the topic comes up. For some historical background, I orginally proposed DAV:supported-method-set and DAV:supported-live-property-set because DAV:resourcetype wasn't giving me the detail I needed to populate my GUI's. Certainly, before I had these two properties, DAV:resourcetype was essential. This may therefore be one of those times where a protocol feature that was required has become redundant through the addition of later features. Cheers, Geoff
Received on Tuesday, 5 June 2001 10:42:57 UTC