Re: DAV.Versioning.DefaultPublished

At 1:07 PM 1/30/97, Stephen Martin wrote:
>The DAV.Versioning.DefaultPublished link should only be an attribute
>of the document tree not of each of the individual versions.

I agree.  My recollection of the rationale for this design choice is
somewhat hazy, although I do remember pushing for this feature.  My
reasoning was based on the need to discover the Default Published Version
(DPV) in situations where there wasn't a version tree root.  However, we
subsequently made the versioning tree root madatory, removing the need to
discover the DPV from members of the version tree.

At the Irvine meeting two drawbacks to having a predefined link like
DAV.Versioning.DefaultPublished were uncovered.  First, if the entire
version tree is not managed by a single server (as could be the case for a
server with a replicated data store) then it is difficult to maintain all
of these predefined links.  The design team was assuming that a version
tree would be managed by a single server, which makes this update much
easier.

Second, having any predefined links makes it more difficult to have the
same resource in multiple version trees, a capability of document
management systems.  This is due to the logical storage of links on a
resource.  If a resource is a member of one version tree, it currently
would have predefined links stored on it.  If that resource were made part
of another version tree, it would need to have predefined links for that
new version tree as well.  How does the server define these links, and how
does the client get access to the right set of links for the current
version tree.

Also, there is a related issue that there might be more than one Default
Published Version.

These issues will need to be considered as the versioning model is
redesigned to handle the version tree being on potentially many servers.

- Jim

Received on Monday, 3 February 1997 15:11:59 UTC