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