FW: [Moderator Action] Re: use of attribute to qualify property value

Caught by the spam filter -- I've put in a request for this email address to
be added to the accept2 list.

- Jim

-----Original Message-----
From: Geoffrey Clemm [mailto:geoffrey.clemm@rational.com]
Sent: Thursday, May 20, 1999 10:46 AM
To: jamsden@us.ibm.com; ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org
Subject: [Moderator Action] 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 Friday, 21 May 1999 18:06:36 UTC