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

On Wed, Jun 06, 2001 at 10:16:33AM +0100, Tim_Ellison@uk.ibm.com wrote:
> Greg Stein <gstein@lyra.org> wrote:
>...
> > *) howthehell do I describe a Working Resource? I can't see that it has a
> >    unique property.
> 
> (You're going to like this :-)

[ Greg puts on his safety harness... ]

> A working resource has <DAV:checked-out/> and does not have
> <DAV:auto-checkout/>
> (appears and does not appear, respectively, in
> DAV:supported-live-property-set)

Oh, bleck.

I can't possibly imagine a client developer figuring stuff like that out.
Geez...

> > *) is DAV:checkout-set actually unique to a Version resource? Some of those
> >    properties are reflected in VCRs. Which Version Resource properties *do*
> >    get copied to a VCR, and which do not? The ones that don't will therefore
> >    signal whether a resource is a Version resource or not.
> 
> 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.

This is why I'm leery of this approach. If I looked for a version-name
property, then I'd be screwed because it would be on all my VCRs, too.

> For the full list of defining properties, plus Geoff's corrections, see
> http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001AprJun/0115.html

Reading that, it would appear that creating a classification of the
resources is order dependent. I better have my checks in the proper 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.

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

>...
> > Oh: and Tim argued, "well, for somebody to implement DeltaV, we're going to
> > ask a lot more than simple Set computations." Oh. Great. Just because some
> > part is difficult, that means we can make *everything* difficult? That's
> > bogus.
> >
> > "Hey, John. You can do DeltaV if you can jump over this 6 foot bar. Oh.
> > Wait. The DeltaV designers said that if you can do that, then you can also
> > jump over this 10 foot bar. Cool. Go, man! Jump!"
> >
> > pthtpth. Non-starter.
> 
> (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 :-)

> Flame on.
> 
> Come on Greg -- you can't be serious.
> [ ... Tim berating me ... ]

:-) Okay. I probably deserved that.

Partly serious. I disagree with the notion of saying that something has an
acceptable difficulty just because something else is even more difficult.
I'd prefer to see a simple "this is <this> type" in the resourcetype field.

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

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 7 June 2001 02:14:11 UTC