RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   "Clemm, Geoff" <gclemm@rational.com> wrote:

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

   (Sorry about that -- but I can't talk about bytes on the wire for
   too long without getting a bit silly.)

Please, no apologies!  That was my favorite part of this whole
thread (:-).  I was just forcing myself to stop (:-).   From:
Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   "Clemm, Geoff" <gclemm@rational.com> wrote:

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

   (Sorry about that -- but I can't talk about bytes on the wire for
   too long without getting a bit silly.)

Please, no apologies!  That was my favorite part of this whole
thread (:-).  I was just forcing myself to stop (:-).

   One suggestion is to annotate DAV:resourcetype with those types and
   categorizations adopted by the Delta-V specification (version,
   working resource, baseline, etc.)  Those types were obviously
   considered important when writing the specification to aid in its
   understanding, so it seems reasonable to reflect them in the
   resources themselves.

I believe it is important to distinguish things that are needed to
understand the protocol definition from things that are needed in
the protocol itself.  To use an extreme example, although examples of
how to use the methods are very important parts of the protocol
definition, we will not be supporting a "get-example" method that at
runtime retrieves for you a standard example of how each method is
used.  I believe that the "resource type", like the "examples",
are needed to understand the protocol definition but are not needed
at runtime by the protocol.

   It will also remove the possibility of ambiguity being
   inadvertantly introduced by some later addition to the
   specification (though due diligence would dictate that the future
   designers avoid such pitfalls).

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.e. what specifically
   > can clients do with that new value that they couldn't already do
   > without it).

   I agree that giving resource type a new value will not give clients
   any further capabilities.  I never intended to portray this as a
   failing of the specification, and it certainly should not hold up
   its progress through the process.  It is a matter of style, and I
   think that is why there is a protracted debate about it.

I think it's actually a good sign for the stability of the spec that
all we have to debate about is this kind of "angels on the head of a
pin" issue (:-).

   The problem has already been solved, and I have had the opportunity
   to express my viewpoint.  I have no objection if the authors
   'pull-rank' and proceed.

Well, we have to do something while our area directors are looking the
spec over (:-).  There is ample precedence for the author's opinions
being superceded (the label feature and the update feature come to
mind :-), and this is an interesting (by some extremely geekish
definition of interesting :-) topic, so please don't let it drop if
you feel there are still any interesting points to be made.

Cheers,
Geoff


   One suggestion is to annotate DAV:resourcetype with those types and
   categorizations adopted by the Delta-V specification (version,
   working resource, baseline, etc.)  Those types were obviously
   considered important when writing the specification to aid in its
   understanding, so it seems reasonable to reflect them in the
   resources themselves.

I believe it is important to distinguish things that are needed to
understand the protocol definition from things that are needed in
the protocol itself.  To use an extreme example, although examples of
how to use the methods are very important parts of the protocol
definition, we will not be supporting a "get-example" method that at
runtime retrieves for you a standard example of how each method is
used.  I believe that the "resource type", like the "examples",
are needed to understand the protocol definition but are not needed
at runtime by the protocol.

   It will also remove the possibility of ambiguity being
   inadvertantly introduced by some later addition to the
   specification (though due diligence would dictate that the future
   designers avoid such pitfalls).

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.e. what specifically
   > can clients do with that new value that they couldn't already do
   > without it).

   I agree that giving resource type a new value will not give clients
   any further capabilities.  I never intended to portray this as a
   failing of the specification, and it certainly should not hold up
   its progress through the process.  It is a matter of style, and I
   think that is why there is a protracted debate about it.

I think it's actually a good sign for the stability of the spec that
all we have to debate about is this kind of "angels on the head of a
pin" issue (:-).

   The problem has already been solved, and I have had the opportunity
   to express my viewpoint.  I have no objection if the authors
   'pull-rank' and proceed.

Well, we have to do something while our area directors are looking the
spec over (:-).  There is ample precedence for the author's opinions
being superceded (the label feature and the update feature come to
mind :-), and this is an interesting (by some extremely geekish
definition of interesting :-) topic, so please don't let it drop if
you feel there are still any interesting points to be made.

Cheers,
Geoff

Received on Monday, 4 June 2001 13:52:22 UTC