- From: Tim Ellison <tim@peir.com>
- Date: Fri, 22 Jun 2001 00:03:07 +0100
- To: <ietf-dav-versioning@w3.org>
> [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