Idle remarks
Fabio Vitali (vitali@cis.njit.edu)
Fri, 7 Jun 1996 03:52:53 -0500
Hi.
Being really up to being torched alive by this group, I'll add some more
questions to my previous posting.
What does an undecorated URLs mean? Opaque and determined by the versioning
tool? Access to a "default version"? What about being able to access to the
whole tree (or whatever) of versions? VTML allows the access to the whole
block of data, and allow the client to parse and show individual versions.
This is also useful for differencing and comparison at the client side.
What about enquiring about the shape of the version tree (or whatever)? How
do I ask: How many branches are growing out of version x? Say I want to
merge diverging contributions, and need to know how many offsprings of a
specific version have been checked in at this moment.
Larry Masinter writes:
>Separate out the problem of
> a) construct a URL for a previous version of a resource
> given the current version of a resource and information
> about the server's versioning system
> b) determining from two URLs what their version relationship
> might be.
>
>I think it's reasonable to use URL-decoration for (a) and not for (b).
I really don't see the difference. They both depend on the specifics of the
versioning system, and therefore at the very least from the opaque
"versioning identifier" contained in the URL. Some naming systems will
contain no clue about the relations between versions. E.g. if version
"Madagascar" is derived from version "Bolivia", I bet you can't provide
(a). If the versioning system uses any of the naming schemata proposed in
the VTML paper, then you can have the exact relation existing between any
two versions. In both cases, anyway, the URL has nothing to do with this
determination, because it's everything in the versioning identifier, which
is opaque to the URL decoration (I think we agree on this, don't we?).
David Fiander writes:
>>Fetch the version previous to URL(x).
>
>if "URL(x)" is a versioned URL, this boils down to
>
> Fetch the version previous to the version "foo"
>
>which will clearly give the same answer all the time, since every
>version of the document will only have one immediate predecessor.
Uhm, will it? Diverging branches of versions are only one of the possible
options for the development of documents. VTML allows for re-joining
branches through the MERGE operation, and Palimpsest goes even further by
allowing versions to be composed of arbitrary collections of changes, so
that there can be no proper "previous version". This is something that is
specific of the versioning system. What I'm trying to say, is that Robert
Pettengi's question may have a unique answer (tree-shaped versioning
structure), a non-unique answer (DAG-structure as in VTML), or no
reasonable answer (sick graph structure as in Palimpsest), depending,
again, from the versioning system.
Ciao
Fabio Vitali