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 Saturday, 19 December 1998 20:51:45 UTC