RE: Use of DAV properties for structural protocol elements

I take it that this note is part of the discussion of backpointers.  So it
is meant primarily as an argument in favor of standardizing backpointers,
just as we should standardize the collection-related properties Lisa
proposed.  Because as structural (I would call them "operational")
properties, failure to use them consistently across clients can cause
interoperability problems.

I see two other implications as well:

1. The DAV spec actually contains some mistakes because it does not
distinguish between operational and descriptive live properties.

I agree that the spec's directives about how to treat live properties on
COPY are broken, but not that the operational / descriptive could completely
solve the problems.  The spec says that servers SHOULD copy live properties
as live, identically behaving properties (that is, they wouldn't necessarily
have the same value at the destination); if they cannot keep the properties
live at the destination, they MUST copy them as dead properties or else fail
the request.

There are problems with both clauses.

Where the presence or absence of the property tells something about the
state or capabilities of the resource, we can't dictate that the property
must be copied with the resource at all.  The DAV:lockdiscovery property
should not be copied with a resource, since the copy is not locked.  Other
operational properties, whose presence indicates support for some optional
WebDAV functionality, cannot be copied if the destination is on a part of
the server (or on another server) that does not support the related
functionality (DAV:supportedlock, DAV:reftype, etc.).  

For some properties, where the value could be seriously misleading, it is
better not to copy them at all than to copy them as dead properties.

2.  Because clients will want to display for users only descriptive
properties, maybe we need an attribute of properties: IsDescriptive
(boolean).  And a new element for use with PROPFIND -- descriptiveprop --
which retrieves all descriptive properties, in contrast to allprop, which
retrieves all properties, both descriptive and operational.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Saturday, December 19, 1998 8:51 PM
> To: Jim Davis; w3c-dist-auth@w3.org
> Subject: Use of DAV properties for structural protocol elements
> 
> 
> I'm wondering if we're getting into trouble because the DAV
> spec conflates elements of real metadata -- elements that
> describe the actual documents -- with properties that are actually
> just structural elements of the repository in which the
> data is being held.
> 
> The 'backpointer' property, and many of the properties that
> were on the Microsoft slides at the end of the 
> meeting, aren't really properties of the resources or
> documents at all -- they're artifacts of the repository.
> 
> One could easily imagine non-standard metadata properties
> being used effectively by an interoperable client, because
> of the existence of 'propfind'. But mixing in structural
> properties such as 'has-child-subcollections' and
> 'backpointer' into the set of properties will actually
> confuse such clients, since these properties will need
> to be listed, but the clients cannot treat them as if they
> were some kind of metadata or resource description at all.
> 
> The WebDAV specification in section 4 tries to define the
> nature of properties, and does make some reference to
> 'live' properties as having semantics maintained by the
> server, but the implication throughout the section is
> that properties are attributes of the 'data', and not
> that they're somehow attributes of how the particular
> repository stores the data.
> 
> The goal of allowing flexible repository attributes is to
> allow for different repositories to create different schema
> of metadata, whether or not those properties fit into
> 'Dublin core' or any other framework for asserting extrinsic
> properties of documents.
> 
> I would like to suggest that insofar as WebDAV clients
> use semantics of non-standard structural properties, there
> will be severe interoperability problems, and should be
> discouraged, or even made to be non-compliant. I acknowledge
> that there is can be a fuzzy boundary between structural
> and non-structural live properties; however, I'd suggest
> that we be suspicious of properties that, for example,
> change for one resource when another resource is MOVEd.
> 
>    Live Property - A property whose semantics and syntax are enforced
>    by the server.  For example, the live "getcontentlength" property
>    has its value, the length of the entity returned by a GET request,
>    automatically calculated by the server.
> 
> So I think we may need some other mechanism than 'live'
> properties for structural elements such as backpointers.
> 
> For example, COPY says:
> 
>    Live properties SHOULD be duplicated as identically behaving live
>    properties at the destination resource. 
> 
> Now, this clearly doesn't apply to 'backpointer'. If you
> were to have a server with a 'backpointer' live property,
> and were to supply (reasonably) a 'propertybehavior' element
> that suggested that all live properties should be copied,
> then no resource would copy.
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter
> 
>

Received on Wednesday, 23 December 1998 11:07:38 UTC