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

Re (2): Removing the DAV:activity and DAV:version-history and DAV:baseline resource type values

From: <Edgar@EdgarSchwarz.de>
Date: Tue, 5 Jun 2001 17:29:08 -0400
Message-Id: <200106052129.RAA18118@tux.w3.org>
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

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