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

Greg wrote:

> > A version is identified by its support for the
> > <DAV:version-name> property.
>
> But also the absence of some other properties. VCRs have the version-name
> property on them, too.

Nope.  A version-controlled resource does not have a DAV:version-name
property.

> Reading that, it would appear that creating a classification
> of the resources is order dependent. I better have my checks
> in the proper order.

Nope again, the checks can be performed in any order.

> If we aren't going to use resourcetype, then the contents of
> that post must be reflected somewhere. Or people just aren't
> going to get it right. If it doesn't go into the spec "because
> it duplicates information", then where are we supposed to put
> it, such that people will find it?
>
> The spec seems the appropriate place for algorithms like that.

I hereby volunteer to write an appendix describing that if people consider
it a good thing.

> But using a resourcetype can avoid algorithms in the first place :-)

> > (I don't know what 'pthtpth' means, but you probably just swore at me in
> > acronym-speak:^)
>
> Nah. Just a typed out "raspberry". :-)  (and you probably don't
> know that term either, over there in the UK :-)

Oh yes, I'm please to say that some parts of our `culture` are compatible
:-)

> ...
> >...
> > (2) If we _do_ go for extending DAV:resourcetype the likely outcome is
> > something like a *Set* of orthogonal characteristics, such as
> > <version-controlled-resource>, <collection>, <checked-in> -- guess what,
> > you'll have to do that "difficult" Set thing again anyway.
>
> This is probably the sticking point here. We'd probably end up with
several
> tokens in there to avoid combinatorial explosion :-(

Absolutely.

Tim

Received on Thursday, 7 June 2001 07:04:35 UTC