Subject: Re: Optional Backpointers from Targets to References

From: Jim Amsden <[email-masked]>
Date: Tue, 15 Sep 1998 19:18:06 -0400

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.

[email-masked] on 09/15/98 05:39:40 PM
Please respond to [email-masked]
To: Jim Amsden/Raleigh/IBM@ibmus
cc: [email-masked]
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.
>
> [email-masked] on 09/15/98 04:02:41 PM
> Please respond to [email-masked]
> To: [email-masked]
> 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
> [email-masked]
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580

--
Greg Stein ([email-masked])

---

From: Jim Amsden <[email-masked]>
Date: Fri, 18 Sep 1998 11:03:24 -0400

The client applications using backpointers know what the property is and that
it is a live property supported by the particular server. Clients that don't
use backpointers would ignore or just not use the property even though that
particular server was maintaining them. This is typical of any client
application that uses some specific meta-data of its own. The only thing unique
is that the server is maintaining it as a live property.

[email-masked] on 09/17/98 04:29:50 PM
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: Re: Optional Backpointers from Targets to References

Jim Amsden wrote:

> But client applications relying on the option won't interoperate with servers
> that don't support it, so there isn't interoperability across WebDAV servers.
I
> suggest a better solution is for those servers built on repository managers
> that can or need to support backpointers likely have specific client
> applications that choose to use them.

Choke.  And what happens when one of these clients tries to coexist with a
client
that doesn't support backpointers?

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |There are footprints on the moon.  No    |
[email-masked]      | feet, just footprints.                  |
\====================================================================/
New area code for work number: 650

---

From: "Slein, Judith A" <[email-masked]>
Date: Mon, 21 Sep 1998 15:48:46 -0400

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Friday, September 18, 1998 9:32 PM
> To: Slein, Judith A
> Cc: 'WebDAV'
> I doubt that unrestricted backpointers to collection parents will be
> implementable on general web servers, but I have no objection 
> to defining
> an optional backpointer property provided that it is also 
> mentioned that
> such a property is not a very good way to implement scalable systems.

Could you be more specific about the kinds of scalability problems you
envision?

> The same functionality can be accomplished via a DASL query, 
> regardless
> of how the server backend works, which has the advantage of specifying
> the scope of the query.  So, I don't think directly specifying
> a property to hold that information should imply that the property is
> maintained live.  OTOH, I'm not sure how the response to such a DASL
> query would look like (i.e., if it would need DAV:references itself).
> 

You are thinking the query would be:

Find the resources on server S that have DAV:reftarget = T?

This is certainly possible in cases where the client has a certain list of
servers that it cares about.  This includes the case that motivated the
suggestion about backpointers in the first place -- DMSs. It's less useful
for more open-ended cases like the client just trying to find out who would
be affected if it deletes a resource. 

It does seem to me that the property should be live if it exists at all.
Otherwise the property value will just be unreliable, since some clients
that create references may maintain it while others do not.

--Judy

---

From: "Bruce Cragun" <[email-masked]>
Date: Wed, 23 Sep 1998 09:36:20 -0600

These points are valid and represent well what our experience has been here at Novell with our GroupWise document management.  We allow users to create references to documents.  The documents exist in the library database, while the references exist in a user's folders.  A given document can have an unlimited number of references pointing to it and there are valid reasons for wanting those backpointers (yes, we do use backpointers in a real-world solution).

Generally we have seen no business need for Jim's second statement, the ability to discover all folders containing a reference to a given document.  In reality, we don't care what folders contain the references.  More important for us the ability to discover those references (via the backlinks) regardless of where they exist.  We use the discovery to "update" the references, which for us contain key data that gets displayed when a user sees a list of the document references.  So, for example, we store the subject as part of the reference.  That way, when the reference is displayed we don't have to hit the database to get the subject but have it already as part the reference's data.  When a user changes the document's subject, we follow all of that document's backpointers and inform each of the new subject.

In a URI-based system (as with WebDAV), Jim's case #1 also represents a completely valid use for backpointers.

>>> Jim Davis <[email-masked]> 09/22 12:44 PM >>>
Jim Amsden and other have asked me to explain the usefulness of the
backpointer.

Before I do, I want to emphasize that I am well aware that there are many
reasons why a server couldn't or shouldn't provide backpointers from *all*
targets  to *all* references.  I hope here only to show that there are
*some* applications for which this is useful, and then to argue that it's
worthwhile standardizing the protocol so that  applications that *do* use
this feature will have a standard way to access it on those servers that
happen to provide it.

Reasons it is useful:

1) Referential integrity.  Some applications desire references that are
guarenteed to remain valid, even when the target moves.  The easiest way to
do accomplish this is by storing back pointers from the target to the
reference.
While there is no requirement that the backpointer be exposed in the
interface, there is no harm in doing so.

2) Multiple containment.  Some document management systems have an abstract
notion of a 'document' that can be in many 'folders'.  For any such
document, it is sometimes necessary to obtain the set of folders in which
it appears.  The most direct mapping of these abstractions to WebDAV
(assuming Advanced Collection Resources) is:
 folder ::  WebDAV collection
 document ::  WebDAV resource
 containment :: WebDAV reference

That is, if document D is in folder F, there is a reference resource in F
whose target is D. Then, to find the set of all folders {F, G, H...} that
contain
document D, one first obtains the set of backpointers on D, then
(trivially) obtains the set of collections that contain those references.

3) Generality/Extensibility:  Backpointers are used in countless data
structures (consult any textbook on data structured or algorithms).  There
will certainly be uses we can't anticipate now.  The 'multiple containment'
example above is just the first one.

I hope to have demonstrated the usefulness of the dav:references property.
It will be optional, and hence cost-free, but useful to those applications
and servers who need it.