Common Graph for Versions and Variants (was: RE: File attributes (RE: The 7 Deadly Sins of Versioning))

Marcus Jager writes:
> I am asking if we can find a way of merging the variants with
> versioning so that we get a solution to both.

I firmly believe that an elegant solution exists which handles both variants
and versions using the same operations.

When there is a sequence of versions of a resource, these versions are
related by a "is-revision-of" relationship.  Similarly, variants of a
resource are related by a "is-variant-of" relationship.  Both relationships
can easily co-exist in the same version-and-variant history graph. The nodes
of the graph are (pointers to) resources.  The arcs are either
"is-revision-of" or "is-variant-of" relationships.

This accomodates both versions and variants of a resource in the same graph
structure.

Fabio Vitali writes:
> Versions differ from language alternates at least for one major issue:
they
> are machine-processable. And usually machine-generated. This means that
> with versions it is possible to provide more sophisticated services than
> simply prompting the user: "I have 23 alternatives of this resources. Here
> is the list. Which one do you want?"

HTTP defines a mechanism for content negotiation using the "Accept" headers,
and hence there is already a well-defined mechanism for requesting a
particular variant if the user has established the preferences of their
user-agent.

Also, many variants are machine-generated: different renderings of the same
document (e.g., PDF, Postscript, HTML) are often machine-generated, although
the term "rendering" is often used instead of "variant". But this is moot.

In what way do you feel machine-processing of versions is important for our
protocol design?

>>So far WebDAV has avoided forcing any structure or format on the contents
of
>>the resources that it accesses and stores. I think it would be dangerous
to
>>give this up.
>
>Indeed. Especially if the structures and formats eventually come out
>limited in scope and flexibility by implementation haste, good-enough
>attitude and lack of temporal perspective.

A protocol which limits remote authoring (and versioning) to a small subset
of media types would be short-sighted indeed.  There are many media types in
existence, and more are likely to be defined in the future.  The only
constant in this area is change.  A remote authoring and versioning solution
which accomodates all media types provides the maximum flexibility for
accomodating this change.

- Jim

Received on Thursday, 28 May 1998 21:06:11 UTC