AW: Resource class

> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von
> Tim_Ellison@uk.ibm.com
> > "Clemm, Geoff" <gclemm@rational.com> wrote:
> > [...]
> The '(in other contexts)' that I was referring to was the ACL list.  I
> understood that the proposal was to extend <DAV:resourcetype> there with
> principal and other distinguishers.  I now wonder why there would be two
> different mechanisms adopted to solve the same problem.  What am
> I missing?
>
> Naturally, I'm not in favour of introducing 'a bunch of redundant
> information' anywhere in the spec.  I agree that the
> <DAV:supported-live-property-set> has all the information needed.
>
> <<snip>>
>
> > Note that whether or not a resource is checked-in or checked-out
> > is normally considered part of its "state" rather than part of
> > its "type" (which just illustrates the vague boundary between
> > "state" and "type" :-).  If you wanted to know whether or not
> > a resource was checked-in or checked-out, then you would have
> > to PROPFIND for checked-in and checked-out.
>
> I agree that the distinction is vague, which is why I said
> 'classification'.  When making high-level UI decisions (menu options
> greyed-out, choice of icons, etc.) the information required is usually
> 'type' _and_ 'state'.  Providing an efficient means of getting the full
> classification will be important for responsive UIs.

One example I can contribute to this discussion is that in our code
we have frequently to check if a resource is version controlled, and
only then we start to worry about the state, checked-in or -out,
of a version controlled resource.
But since I have to rely on checked-in/-out according to current
draft, I did some performance tests with a
propfind/allprop+supported-live-property-set instead of just allprop
and noticed a 5% performance hit with our test suite. Obviously I'm
doing a lot of propfinds, and likely our code can be improved, but
it surely indicates that supported-live-property-set does not
come for free. And keep in mind that every future extension of WebDAV
will have to show up in that set as well...

> Since <DAV:checked-in> and <DAV:checked-out> will appear in the
> <DAV:supported-live-properties> set I believe that it will be
> sufficient to
> PROPFIND on <DAV:supported-live-properties> and <DAV:resourcetype> (for
> <DAV:collection/> or a MIME-type etc.) to get an accurate classification.
>
> [...]
> >    (ii) It would seem that activities should have a <DAV:resourcetype>
> >    of <DAV:activity>, but I didn't see that in the -15 spec.
> >
> > It appears in the postcondition of MKACTIVITY, but I'm happy to
> > mention it in section 13.1 as well.
>
> I think that would be more consistent with other declarations of
> resourcetype.
>
> <<snip>>
>
> > Or (as I'm sure you can predict I will say ... :-) how about just
> > using DAV:supported-live-property-set?
>
> Ok, I get the point<g>
>
> However...
> It feels strange (in a woolly, hand-waving way) to characterise a resource
> based soley upon its observed/stated behavior -- especially given the
> existance of a <DAV:resourcetype> property that is being used intuatively
> in some cases (e.g. an activity), and not in others (e.g. a
> version-controlled configuration).

So, using Java terminology, we are talking about classes and interfaces.
Different classes are reflected in the resourcetype and the implemented
interfaces are currently deduced from the set of live properties.

So, maybe the designers of Java had also Tim's strange, wooly feeling
about just relying on class properties and required that a Java class
has to declare that it implements a certain interface. Therefore
a) compilers/runtime can easily see what an object supports
b) compilers can warn/fail if a class does not fully implement an interface
c) class designers can say what they mean. They avoid implementing
   an interface by accident. (What Tim talks about in the next paragraph).

> The danger that I see is that clients must base their characterisations of
> resources on the existance of specific live properties, and that future
> extensions to DeltaV will have to bear this in mind when defining new
> resource 'types'.  Spec writers will have to deliberately *undefine* a
> property just so that clients don't mistake them for the DeltaV types.
> For example, if I had an idea for a resource that was not a Baseline, but
> had a legitimate use for the <DAV:baseline-collection> property,
> all legacy
> (to-be:-) clients would spot the <DAV:baseline-collection> property and
> incorrectly assume it was a Baseline.

That is an argument to be more generous with new DAV: XML namespaces.

> How much more verbose English would be if we had to describe the
> characteristics of a crocodile and an alligator in order to
> distingush them
> rather than rely on their names.
>
> Tim
>

I should probably read more and propose less, but I would like a DAV
property

<implements xmlns="DAV:" xmlns:DV="DAV:versioning" xmlns:DX="DAV:feature-X">
  <DV:versionable-resource/>
  <DV:versioned-resource/>
  <DX:x-type/>
</implements>

which is part of a standard propfind/allprop response.

Stefan

Received on Tuesday, 15 May 2001 03:58:16 UTC