- From: <Edgar@EdgarSchwarz.de>
- Date: Tue, 5 Jun 2001 17:29:08 -0400
- To: ietf-dav-versioning@w3.org
- Cc: Edgar@EdgarSchwarz.de
"Clemm, Geoff" <gclemm@rational.com> wrote: > 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. Hey, that's an impressive target. I won't pretend to solve this problem with my comments :-) > 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. I follow this thread already for a while and couldn't decide which way to go. But at the moment I think I agree with Geoff. It sure is easier to cope with a limited number of resource types. OTOH there is the problem to define them and their differences. Then some are similar but still different and you are in danger to define a (class) hierarchy sometime in the future. Then you always will have discussions about whether new resource types will be necessary if they just have one or two more methods or properties than another one. In the realm of programming languages there are ideas of avoiding compatibility problems between classes (which have their defined place in a class hierarchy) or components (Buzz word :-) by just defining interfaces in the form of messages/methods. As long as an object understands all of the messages (By name) of an interface it is treated as that (resource)type. If it has a different semantics for some methods ? Bad luck. I see that this is a risk, but OTOH it is more flexible. I acknowledge the drawbacks some of you have mentioned, but a design without (too much) redundencies also has it's advantages. So I guess removing resource type is okay with me (See my signature about Einstein) Cheers, Edgar -- edgar@edgarschwarz.de http://www.edgarschwarz.de * DOSenfreie Zone. Running Active Oberon. * Make it as simple as possible, but not simpler. Albert Einstein
Received on Tuesday, 5 June 2001 17:29:08 UTC