RE: Use of DAV properties for structural protocol elements

> I take it that this note is part of the discussion of backpointers.

My note was motivated not only by the discussion of backpointers,
but also by the concern about the "infinite levels of implementation
complexity" that might arise and prevent _effective_ interoperability.

I used the word 'structural', but I think 'operational' is closer.

Yes, I think we should distinguish between descriptive properties
and operational ones. I wasn't even entirely sure that operational
properties should be 'properties'; mainly the issue is whether
clients that want to be unaware of the distinction should even
SEE the operational properties.

> 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 think it might be necessary to do something strong: The proper
and efficient functioning of a compliant client MUST NOT depend
on the presence or proper functioning of non-standard server
operational properties. Otherwise, a client could be 'compliant'
and not properly interoperate with a compliant server. This would
destroy the primary value of having a standard in the first place.

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

Another way to look at this is that the current DAV spec isn't
consistent with operational properties; a quick revision at
Proposed Standard would be to disallow them completely.


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

To adequately support simple clients interoperability, it may
be necessary to set the default the other way: operational
properties are not returned by PROPFIND, and some other
method is needed to obtain them, if they're being represented
as properties at all.

Larry

Received on Wednesday, 23 December 1998 14:15:01 UTC