113
string that identifies that change with respect to its version. Change IDs are appended to the
version number following a “#” character. Version specifications can also be added to the
header, and can explicitly exclude or include particular changes into their particular version.
This differs somewhat from Palimpsest because operations are always specified with respect
to a base version, directly supporting the common tree-structured versioning style (and
making other styles somewhat harder to implement).
It is possible to simulate Palimpsest semantics for insertion and deletion by using VTML
in a way that does not take advantage of the built-in versioning facilities of VTML. Each
Palimpsest insertion into a particular context (another insertion) is added as a successor of
the version of that context. This creates a version graph whose inheritance relationships du-
plicate the causal ordering of insertion changes. Successive insertions into the same context
create multiple alternative successors to the version of that context (with one change in
each successor version). Nested insertions create chains of related versions. Palimpsest move
and copy cannot properly be represented in VTML, because insertion and deletion operations
can implement only frozen operations, not dynamic ones.
6.1.3 External and Internal changes
The first portion of a VTML file consists of external changes, which are stored separately
from the data representing all versions. The external change format is useful in the design of
protocols and support for disconnected work for the same reason that Palimpsest changes are
useful. They wrap up all the information needed to describe the updates in a version in one
place. External changes need to locate the points on which operations should act, and for
this reason they need to be location and time invariant, like Palimpsest addresses. VTML ad-
dresses are a combination of a version number and character offset. Versions must be immu-
table, and VTML semantics require some external protocol or server to secure agreement as to
which version numbers are actually selected for any version. VTML is designed, like much of
the WWW, to work with a document server that is capable of handling all operations per-
string that identifies that change with respect to its version. Change IDs are appended to the
version number following a “#” character. Version specifications can also be added to the
header, and can explicitly exclude or include particular changes into their particular version.
This differs somewhat from Palimpsest because operations are always specified with respect
to a base version, directly supporting the common tree-structured versioning style (and
making other styles somewhat harder to implement).
It is possible to simulate Palimpsest semantics for insertion and deletion by using VTML
in a way that does not take advantage of the built-in versioning facilities of VTML. Each
Palimpsest insertion into a particular context (another insertion) is added as a successor of
the version of that context. This creates a version graph whose inheritance relationships du-
plicate the causal ordering of insertion changes. Successive insertions into the same context
create multiple alternative successors to the version of that context (with one change in
each successor version). Nested insertions create chains of related versions. Palimpsest move
and copy cannot properly be represented in VTML, because insertion and deletion operations
can implement only frozen operations, not dynamic ones.
6.1.3 External and Internal changes
The first portion of a VTML file consists of external changes, which are stored separately
from the data representing all versions. The external change format is useful in the design of
protocols and support for disconnected work for the same reason that Palimpsest changes are
useful. They wrap up all the information needed to describe the updates in a version in one
place. External changes need to locate the points on which operations should act, and for
this reason they need to be location and time invariant, like Palimpsest addresses. VTML ad-
dresses are a combination of a version number and character offset. Versions must be immu-
table, and VTML semantics require some external protocol or server to secure agreement as to
which version numbers are actually selected for any version. VTML is designed, like much of
the WWW, to work with a document server that is capable of handling all operations per-
