- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Wed, 23 Dec 1998 11:14:36 PST
- To: <w3c-dist-auth@w3.org>
> 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