Re: use of attribute to qualify property value

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. Making it a resource
would likely result in redundant data in many server implementations, and
interfer with the user's namespace.

I don't share Yaron's view on the use of XML properties. They have some
advantages and disadvantages over content model, and DAV should not prescribe
any particular policy. It should be up to the client and data modeler to decide.
See xml-dev for lots of discussion on using attributes vs. content.




"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/19/99 05:03:35 AM

To:   ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
cc:    (bcc: Jim Amsden/Raleigh/IBM)

Subject:  Re: use of attribute to qualify property value





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>
   Cc: w3c-dist-auth@w3.org
   Date: Mon, 17 May 1999 17:46:57 -0700
   X-Mailer: Internet Mail Service (5.5.2524.0)
   Resent-From: ietf-dav-versioning@w3.org
   X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/187
   X-Loop: ietf-dav-versioning@w3.org
   Sender: ietf-dav-versioning-request@w3.org
   Resent-Sender: ietf-dav-versioning-request@w3.org
   Precedence: list
   Content-Type: text
   Content-Length: 2121

   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]
   > Sent: Mon, May 17, 1999 4:35 PM
   > To: ietf-dav-versioning@w3.org
   > Cc: w3c-dist-auth@w3.org
   > Subject: use of attribute to qualify property value
   >
   >
   > 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 08:06:45 UTC