RE: DAV:resourcetype

> [Tim's logic process mostly deleted]

Probably best place for it <g>.

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

[snip]

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

I'm surprised that you think a resource may be brought under version
control, then taken out of version control, very often -- but it is a
judgement call, so whatever.

> Both version-controlled and non-version-controlled workspaces
> could be represented as
>   <DAV:resourcetype><DAV:workspace/><DAV:collection/></DAV:resourcetype>

Ok, and to detect if the resource is version-controlled you would presumably
... look at the DAV:supported-*-set(s) properties? or fish (PROPFIND) for
specific properties.

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

Agreed.  We should retain the RFC2518-way of denoting a collection so that
we do not disturb the existing clients (or require a change to RFC2518).

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

"deal with it [as a collection]".  Agreed.  Clients can deal with it as a
collection using the RFC2518 procedure for detecting collection-type.

Versioning clients that are interested whether a resource is, say,
version-controlled or checked-in would use some other mechanism for
determining the resource state.

Hopefully you agree that we have to say in the DeltaV spec. what that
mechanism is, and I'm cool with that.

> If there's a version of a baseline, I'd represent it as
>
> <DAV:resourcetype><DAV:workspace/><DAV:collection/><DAV:version/><
> /DAV:resourcetype>

Not so, since a baseline is neither a workspace nor a collection.  It does
not behave like a collection (i.e., support collection-type methods such as
MKCOL and Depth: operations); and it does not act like a workspace (i.e.,
have DAV:workspace-checkout-set property).

My point is only that we need to specify what it means for a resource to
have those elements in the resource type.

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

I _really_ don't want to go round the state vs. type argument again, so
would you like that original statement better if I said:
  "The only workable solution is to make DAV:resourcetype a *set* of
classifiers."
(You can choose your favourite word here, but the point is that the value
will be a _set_.)

Each element in the DAV:resourcetype value names what you can expect the
resource to support in terms of methods and/or properties.

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

This is true.

>  - It's more directly purposed.  Supported-*-set is not intended
> to show the type of things.

I thought we were debating that <g>.

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

I agree.  (I don't think anyone suggested that would happen.)

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

Maybe, depending upon the values we choose for DAV:resourcetype.  I can
imagine clients wanting to know if a resource is mutable or not in order to
determine the correct icon, menu options to offer, etc.


I've said it before, but I'll say it again, I don't believe that this is a
fundamental problem in the specification that should cause any hold up.  I
have no problem with defining elements to add in to DAV:resourcetype that
represent a classification/type/category of behavior for a resource.
However, such elements MUST have a well-defined meaning in terms of the
properties they imply are supported and the methods it imply are supported.
Obviously we cannot have an element meaning one thing for one server and
another thing for another server.

I would like to put on record that I believe that such an element is
redundant, since if it is well-defined in terms of the properties and
methods it implies, that information WILL also be available in the
DAV:supported-*-set properties (yes, most likely as a sub-set of the entire
supported-*-set values).

I will further point out, merely as an observation, that the process for
detecting the defined subset of properties and methods in the
DAV:supported-*-set values is going to be no more difficult than detecting
the subset of elements in the DAV:resourcetype value.  And, clients that
retrieve the DAV:supported-*-set values can determine state and other
information without subsequent interaction with the server (the client gets
it all in one gulp).

We will be interoperable.  It will work for both of us.  Let's wrap this up
and move on.

Tim

Received on Thursday, 21 June 2001 19:03:14 UTC