variants and configurations

The point in this email is an orthogonal point, but is related to the
discussion of variants.

If an approach is being developed to deal with variants, then that
approach should consider configurations also.  As long as we allow a
collection (or a linked set of documents) as one conceptual entity,
then we could also use the same mechanism for identifying semantically
consistent versions (which is what a configuration is).

When I had asked this question previously, Jim had mentioned that
cookies can be used to implement such a mechanism.  This is certainly
plausible, although I would like to hear some scenarios.  In any case,
however, all the problems that are being visited here with respect to
authoring tools will also show up in configurations.  Cookies may
indeed give a mechanism on the client side to keep the state of active
configurations, but that does not say anything about how a server will
identify a configuration.

So the answer to Jim is: cookies might very well be sufficient, except
that to our knowledge there is no cookie standard that defines
versions and configurations, and cookies are useless for interoperable
versioning purposes if there is no standard way of identifying
versions and configurations.

This also relates to the naming of versions. Here's my take on naming
versions of objects.  When a new version is created, it has to be
given a specific version name, and that name has to be generated by
someone. This someone has to be either the client or the server.  If
there are no standards version naming, as the WebDAV draft says, then
the client can't invent names, since it can't know what names will be
permitted by the server (e.g. one server might require a number
following a period, while another might have alphabetic characters
following a percent sign or /).

If the name is assigned by the server, then the client has to find out
the name at the time the version is written, so that it can
consistently refer to the version that it just wrote.  Therefore
writing a version has to be atomic with finding out the version
written; otherwise an intermediate write could screw up the version
name discovery.

I agree with Jim that version ordering (predecessor/successor) is an
important question, but I don't think it's central.  They are only
needed when you want to do an "undo" or "replay" without knowing to
which version one wants to revert; you can do an awful lot without
storing sequence information in a systematic way.

Accessing multiple variants -- for an individual object, isn't that
done just by accessing the appropriate member of a container?  That
is, if /foo/bar names the containers holding all versions of document
bar, then /foo/bar/13 might be version 13.  On my quick read of the
WebDAV documents I've seen, this seems to be implicit; but I don't
remember seeing any particularly concrete descriptions of how the
protocol is intended to be used.

For configurations consisting of consistent versions of a set of objects,
perhaps we can create new containers with external links to the specific
versions of all of the objects of interest?  I don't know.  I don't think
configurations in the sense Jim defines (the configuration goes to a new
version any time any member object does) are going to be helpful, since
they don't scale.

Received on Friday, 29 August 1997 11:35:33 UTC