Re: Optional Backpointers from Targets to References

There are capabilities that can be optional, and others that if optional
compromise the notion of a standard and render the protocol effectively server
dependent. Providing optional back pointers (among many others in WebDAV) I
think is going too far. This is too low-level and fundamental to be optional.
Client applications will be impossible to write if not only do they have to
deal with low-level protocols, methods with semantics hidden in control couples
(headers), XML documents that must be parsed for results, etc., but they'll
also have to adjust themselves to a myriad of server peculiarities. Too much of
this will limit WebDAV's appeal due to the complexity of building servers to
support it and clients to use it let alone a user's ability to understand those
that are built. WebDAV should keep it simple and leave the complexity to the
user's problem domain. My rule of thumb is when in doubt, leave it out. Another
rule of thumb: if you have to describe the semantics of something in a series
of special cases, there's something wrong with your abstraction. WebDAV is
starting to reach this boundary.






w3c-dist-auth-request@w3.org on 09/15/98 05:39:40 PM
Please respond to w3c-dist-auth-request@w3.org
To: Jim Amsden/Raleigh/IBM@ibmus
cc: w3c-dist-auth@w3.org
Subject: Re: Optional Backpointers from Targets to References

However:

1) the property is optional. If it is tough for a particular
implementation, then they can choose to not implement it

2) if the perf is too much, then a server can avoid it

3) if the property is implicit, then an real update may not be required.

Given that some implementions can handle back-references without much
problem, then it would be quite nice to be able to extract them.
Especially if the server keeps telling you that you can't delete it
because of other references. Without this, it would be quite a bear to
find those other refs.

-g

Jim Amsden wrote:
>
> This property may be impossible to support for a number of reasons. First its
> the same problem that makes maintaining referential integrity difficult and
> that has been deferred. Second, there may be significan performance
> consequences of trying to maintain the references. And third, creating a
> reference to a resource will require modification of the target resource to
> update its properties while that resource may not be updatable by the
> requesting principal. This is not a good reason for prohibiting a reference. I
> recommend that we keep things simple and not add the requirement.
>
> w3c-dist-auth-request@w3.org on 09/15/98 04:02:41 PM
> Please respond to w3c-dist-auth-request@w3.org
> To: w3c-dist-auth@w3.org
> cc:
> Subject: Optional Backpointers from Targets to References
>
> There has been no discussion following Jim Davis's mailnote "Proposal:
> optional backpointers for ACR" of August 19.  Unless there are
> objections, this proposal will be incorporated in the Advanced
> Collections protocol specification, and a corresponding requirement will
> be added to the Advanced Collections requirements.
>
> The requirement will state:
>
> There is an interoperable means of navigating from a resource that is
> the target of multiple references up the collection hierarchies from
> which it is referenced.
>
> The protocol specification will include:
>
> The definition of a new, optional property DAV:references, which
> provides backpointers from a target to all resources that refer to it.
>
> This property is live on servers that choose to support it.  It may be
> present on resources on other servers, but in that case will be dead.
>
> Clients can use this property to discover which resources reference the
> target resource, and by parsing the URLs of the references, can discover
> the collections where those references reside and navigate up the
> collection hierarchy.
>
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580

--
Greg Stein (gstein@lyra.org)

Received on Tuesday, 15 September 1998 19:14:09 UTC