- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Thu, 9 Jul 1998 15:02:58 PDT
- To: w3c-dist-auth@w3.org
In the advanced collection design, a reference is a resource that is independent of its target, e.g. operations on either don't affect the other. They have distinct sets of properties, and (baring referential integrity) either can be deleted without affecting the other, and so on. This allows us to not deal with, e.g., the security problems of relaying requests from reference to a (possibly remote) target. Yet there have also been suggestions that this is a *policy* that should not and need not be built into the protocol. I can easily imagine that, at least in some limited cases, some users would prefer to sometimes be able to get a kind of reference that is not independent, so that e.g. a PROPFIND on the reference returns all and only the properties of the target, and so on. Let me call such a reference a 'direct' reference. Direct references (and their targets) do *not* have properties 3.1.2 and 3.1.3. Operations on one *do* affect the other. A collection listing *does* follow references. A GET on the reference just gets the target, a PROPFIND goes to the target, etc. This also means giving up on 3.1.8. This kind of reference would sometimes be useful, even if it could only be implemented typically when both the reference and the target were on the same server, and even though it would require care (e.g. to avoid cycles. But this is true for symbolic links in file systems, too.) If it's the case that this kind of reference would ever be desirable (and I think it is), then I think we should alter the requirements document to introduce this distinction (between direct and indirect references), and to state which properties apply to which kind of reference. I don't think we should try to define this in the protocol document. Direct references raise too many hard issues to define now. (Remember how much trouble we got into just trying to define the semantics of referential integrity?) But if we extend the requirements document, at least we won't be *preventing* someone from defining the semantics of direct references later on. It's fine if the protocol provides only indirect references. It isn't going to do referential integrity, either. We have to leave *something* for future generations to do, after all. I mentioned this to Judy and she said I ought to ask the list, which is what I am doing now. To be concrete: This change would require adding the adjective "indirect" to requirements 3.1.2, 3.1.3, 3.1.4, 3.1.5(?) 3.1.8, and modifying the language in 3.1.12 FWIW, in the protocol, to implement direct references, you'd need to revive DELREF, because DELETE on a direct reference deletes the target as well as the reference. But that's for the protocol, not the requirements.
Received on Thursday, 9 July 1998 18:03:15 UTC