RE: DAV:resourcetype

[Tim's logic process mostly deleted]

> Ok, now we bring the workspace under version control.  By the
> same argument
> you wouldn't use <DAV:version-controlled-workspace-collection/>, but
> rather:
>
>   <DAV:resourcetype>
>     <DAV:workspace/>
>     <DAV:collection/>
>     <DAV:version-controlled/>
>   </DAV:resourcetype>
>

Tim, at this point, you're taking the argument rather father than I, for
one, would wish you to.  Rather than criticize the argument taken to an
extreme, realize that we can stop before then.

It's been pointed out by many that there is a fuzzy line between type and
state.  Fine.  We're humans designing this protocol, and we can handle a
little fuzziness.  There's no need for our implementations to worry about
telling the difference between a type change and a state change, as long as
our implementations can tell both the type and the state reliably.  So let's
attack the problem of most clearly delineating the type and the state.

I've always prefered to have type defined as something which changes rather
unfrequently, perhaps never.  So we could stop before version-controlled is
added to the resourcetype.  Both version-controlled and
non-version-controlled workspaces could be represented as
  <DAV:resourcetype><DAV:workspace/><DAV:collection/></DAV:resourcetype>

As you point out, this allows clients to easily recognize that the workspace
can be treated as a collection for depth requests and other purposes.  They
don't need to know if it's version-controlled to be able to deal with it;
that's a major feature of the DeltaV specification.

If there's a version of a baseline, I'd represent it as

<DAV:resourcetype><DAV:workspace/><DAV:collection/><DAV:version/></DAV:resou
rcetype>

Tim said:
> The only workable solution is to make DAV:resourcetype a *set*
> of types and/or states.

That's incorrect.  There are other workable solutions.  State can be
indicated in other ways.  We don't put <DAV:locked/> into the resourcetype
in the base DAV specification -- we have <DAV:lockdiscovery> to do a much
better job of this.  Similarly, we don't need to put checkin/checkout state,
or even version-controlled state into the resourcetype.  Although, as you
point out, we could.

> Now, tell me how is this different to DAV:supported-*-set?

It is different.
 - It's less variable.  Supported-*-set can contain a whole mess of things
depending on what the server chooses to implement.
 - It's more directly purposed.  Supported-*-set is not intended to show the
type of things.  As JimA points out, just because two things support method
FOO, doesn't mean they have the same behaviour when you tell them to FOO.
 - It more closely maps to what the client needs to know first of all --
that is, what *kind* of thing is this so that I can display a correct icon
when the user browses.  Afterward, the client may need to know the
supported-*-set for other purposes.

Lisa

Received on Thursday, 21 June 2001 13:21:37 UTC