Re: use of attribute to qualify property value
jamsden@us.ibm.com
Thu, 20 May 1999 14:05:05 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
Message-ID: <85256777.00635CFD.00@d54mta03.raleigh.ibm.com>
Date: Thu, 20 May 1999 14:05:05 -0400
Subject: Re: use of attribute to qualify property value
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
> >
>