Re: Use of DAV properties for structural protocol elements

At 05:50 PM 12/19/98 PST, Larry Masinter wrote:

Summary: Larry raises two objections to "structural" properties.  I believe
both are faulty.

>One could easily imagine non-standard metadata properties
>being used effectively by an interoperable client... but structural
>properties such as ...'backpointer' ... 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.

Without addressing the epistemological issues you raise (between
"structural" and "real" metadata) it's not clear to me that the
DAV:resources (backpointer) property would be any more confusing to a
generic client than any other non-standard metadata property.  Suppose, for
example, one constructed a hypertext system of arguments, refutations, and
justifications, where resources stored the text and the argument structure
was represented as (link) properties.  While I am unsure whether a
(hypothetical) "RHET:refutes" property is 'real' or 'structural' metadata,
it seems reasonable to use WebDAV in this way.

But to a client ignorant of the RHET properties there is no important
differences between RHET:refutes and DAV:references.  Both contain a set of
DAV:href elements.

So please explain how DAV:references will confuse clients.

>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.

I believe you are mistaken.  The spec says "identicially behaving". 

Suppose resource R is a references to target T.  If you copy T to (new)
resource S, then there are no references whose target is S, so the
DAV:references property will be empty on S.  It's the same behavior as before.
So the COPY of T will succeed fine.

Or suppose you COPY resource R. This is just the same as if you had done a
second MKREF, and hence the DAV:resources property of S will now have a new
item.

It seems to me that either resource may copied without a problem.

Please explain how you think this is paradoxical, confusing, or impossible.

best regards

Jim



------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301

Received on Monday, 28 December 1998 18:54:02 UTC