- From: <jamsden@us.ibm.com>
- Date: Thu, 20 May 1999 14:05:05 -0400
- To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
Geoff makes a lot of good points below. I misunderstood his meaning of the term resource and took it to mean something we stored, not calculated. His solution is sounding better all the time. Geoffrey Clemm <geoffrey.clemm@rational.com> on 05/20/99 01:00:24 PM To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org cc: Subject: Re: use of attribute to qualify property value At 08:03 AM 5/20/99 -0400, jamsden@us.ibm.com wrote: > >The history of a versioned resource doesn't seem like a resource to me, it seems >more like information, meta-data, about another resource of set of related >resources. This is a generated report, not a resource. This is an unusually constrained notion of what a resource can be. All of the reports generated by cgi-bin scripts are legitimate resources. How is a history report any less so? And even if we accepted this very constrained notion of a resource (which I do not), most common "versioning" implementations are based on an an identifiable object (an RCS ",v" file, an SCCS "s." file, an object in a database) which contains the history of a versioned resource. So neither theory nor practice seems to support this contention. > Making it a resource > would likely result in redundant data in many server implementations, This again seems to presume that every resource must be mapped to a file or a directory. A key element of the power and generality of the web is that this is not the case. In particular, since the protocol requires that the server represent each revision of a versioned resource as a resource, and requires that each revision have a distinct revision-id, how does using the collection protocol to obtain information on the set of resources (revisions) that comprise the history of a versioned-resource result in redundant data? The alternative being proposed in the 01 spec is to model this history information as a property that is logically "merged" into the properties whatever revision or working-resource is being selected by the versioned-resource. A naive server implementation would be to replicate this report property on every revision. Now *that* would result in redundant data. If the server is smart enough not to do this naive implementation of properties, it is smart enough not to do a naive implementation of collections. > and interfer with the user's namespace. It only requires the allocation of a single URL for the "repository" of history information. All other history URL's can be members of this repository. Appealing to existing practice, every versioning system I know of either allocates (or has the user allocate) such a URL, or makes each history resource explicitly visible in user URL space. Cheers, Geoff >"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/19/99 05:03:35 AM > >I believe the problem that led to the use of property attributes was >the attempt to model the "history" of a versioned resource as a >property. If instead we model it as a resource (i.e. a "history resource" >that contains a collection of revisions), then we can just use >headers (like the Depth header) to modify the PROPFIND call that >is applied to this collection. > >Cheers, >Geoff > > From: Yaron Goland <yarong@microsoft.com> > > As explained in detail in > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html XML > attributes are a bad idea. > > The use of attributes invariably indicates an ill considered data structure. > > In this case they are used to avoid dealing with the issues of properties on > properties. Let us not avoid these hard problems but grabble them head on. > > Yaron > > > -----Original Message----- > > From: Jim Davis [mailto:jdavis@coursenet.com] > > > > In at least two places, the DeltaV draft protocol (Kaler et > > al, Jan 20, > > 1999) uses an attribute value to qualify the value of the > > property returned > > in a PROPFIND. (The two places I've noticed are 5.2 > > defaulthistory, which > > uses the limit attribute and 5.4 directlineage, which uses the scope > > attribute). > > > > This is a little funny, for two reasons > > > > 1. As far as I know, WebDAV has never settled whether XML > > attributes are > > part of a property value (with the exception of the xml:lang > > attribute). A > > client can certainly store a property whose value includes > > attributes, but > > it's not clear that the server MUST preserve the attributes. > > (Please don't > > argue with me about whether it should or should not, all I am > > saying is > > that, to the best of my knowledge, it's an unsettled controversy) > > > > 2. It seems weird to me that the value one gets back is > > affected by the > > attribute. It's not like I expect proxies to be caching the values of > > PROPFIND, but I would like some guidance as a client writer > > about when two > > properties can meaningfully be compared. Clearly, in this > > case, they can't > > if the attributes differ. Would you propose that, in > > general, a property > > can only be compared if all attributes are exactly the same? > > This isn't > > unreasonable, but I would like this settled for WebDAV in > > general, and not > > by accidental precedent in DeltaV > > > > best regards > > > > Jim > > > > ps I'm new to DeltaV, apologies if this has already come up > > >
Received on Thursday, 20 May 1999 14:05:37 UTC