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

Edgar@EdgarSchwarz.de wrote:
> "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 :-)

Geoff: hey, you've been rumbled! From your ACL list posting:
    "For DAV:resourcetype in the versioning protocol, I
    really don't care much what we do with DAV:resourcetype
    there either, but figured we might as well argue about
    something in the versioning list while we're waiting
    for the area directors to review the versioning protocol."

Which is it? You want to "develop some guiding principle" for future
generations, or "don't much care ... but figured we might as well argue
about something"<g>
(You don't have to answer that question:-)

> > 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)

I agree with your observation, and note that the "interfaces" are usually
_named_.  Since the specification has already named these interfaces
("types") I think it makes sense to use those names rather than constantly
refer to resource types by the set of "messages/methods" they define.

Tim

Received on Wednesday, 6 June 2001 06:00:52 UTC