Re: Version issues
Dylan Barrell (dbarrell@opentext.com)
Mon, 10 May 1999 00:27:34 +0200
Message-ID: <01BE9B1B.5FDCA2F0.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'Sankar Virdhagriswaran'" <sv@hunchuen.crystaliz.com>,
Cc: "Falkenhainer, Brian" <Brian.Falkenhainer@usa.xerox.com>,
Date: Mon, 10 May 1999 00:27:34 +0200
Subject: RE: Version issues
> > > can work in the context of DAV. First, there is the question of
'linked
> > > object consistency management'.
> >
> > Is totally orthogonal to what level of versioning (even none) is
supported
> > by the server.
> >
>
> Not in the context of parallel development or in the context of
> embedded/linked resources. If I edit an HTML page as part of a set of
pages
> I am working on and you edit one of the pages linked by that HTML page as
> part of another set of pages, what should happen when I submit my changes
> and you submit your changes? I am *not* talking about *link management*
that
> is used to detect dead links. I am talking about maintaing consistency.
One
> (IMHO, horrible) solution is to lock all the pages linked to a page when
I
> check out the source of the links. In a pathalogical case, this will
> essentially lock the Web site out such that only I can work on it.
I see the problem - I haven't seen any proposed solution to it in the
current spec. Should this be client or server side functionality and should
it even be exposed in the protocol? I would argue that it doesn't matter
where you put it and it should therefore not be explicity included in the
protocol.
>
> In addition, given that HTML pages embed and link include files, code
> segments, style sheets, images, objects, etc., maintained in separate
files,
> I don't see how the simple versioning scenario can work except to lock
all
> the embedded/linked files such that they don't evolve while I am editing
an
> HTML page. IMHO, this will essentially ground site development to a halt
in
> any web site where more than 3 authors are working on that web site.
What about XML structures? Here you could theoretically lock entire
sub-structures or a single sentence! Why should the protocol care how the
server solves this problem? I check-out a resource, the server figures-out
what it has to lock in order to ensure that any changes which are
subsequently made are consistent and decides what to inform me about if it
identifies a conflict. We simply have to put a protocol and structures in
place which allow the server and client to communicate about these types of
issues.
>
> > Can you give an explicit example? I cannot imagine why not!
> >
>
> See above. Does this make sense to you?
>
> > We must be careful not to argue on terms which haven't been properly
> > defined. Before I get into this argument about "simple versioning" and
> > "proper configuration management", I would like to understand what we
are
> > actually discussing.
> >
>
> Fair enough. Simple versioning to me implies a system like SCCS (from a
user
> interaction model). When I want to evolve a file, I check it out. The
system
> locks the file such that nobody else can edit it at the same time. When I
> check-in my changes, a new version (revision ?) is created.
Simple versioning in my mind also excludes multiple trees and parallel
development.
>
> Configuration management allows me to identify a group of files
(resources
> in the HTTP context) as being a consistent unit. I think of each HTML
page
> (i.e., the most popular HTTP resource) as a configuration for the reasons
> given above (embedding and linking, and the need for parallel
development).
In my mind simple configurations do not include parallel development.
>
> > This is totally orthogonal. A variant is simply a translation of a
> revision
> > to some other format (be it language, document format or character set
> > encoding etc. etc.). If you view the resources as a tree with the
> > "variantable" (whew!!!) nodes as leaves which can sprout at various
points
> > on the stem, then variants can be viewed as blossoms which sprout from
the
> > base of a leaf. Some leaves have no blossoms, some have multiple.
Variants
> > are never versioned. The base variant is versioned (master).
> >
>
> But, from an authoring perspective how will the user scenario work.
> Typically, (at least in the US of A) while some body is editing a english
> page, some body else is editing a french variant of the same page.
> Typically, the person editing the english page coordinates their work
with
> the person editing the french page. Unless these two pages are considered
to
> be part of a set whose consistency has to be maintained (i.e., a
> configuration), the system cannot help resolve potential conflicts that
> might arise when one of the authors looks (i.e., reads) the page being
> edited by the other author in order to edit their page (and vise versa).
No problem - one of the two is still the master. It does not seem to make
sense (at least in my experience) for two "authors" to have to perform the
same "creative" effort of defining what each chapter, paragraph and section
is going to communicate. The content is authored in one language and then
simply translated into the other languages. For each version of the master
there may be a translation and this translation may even be incomplete (it
represents the work in progress at that particular point in time). At some
point the master version is released and the translators working on the
other variants will continue to update the most recent version of the
variant until complete and then mark it "published". The translations
changes do not necessarily need to be "versioned" in the usual sense of the
word as their origin is always the master which is versioned.
> This in my mind results in a requirement for configurations. And,
read-write
> based conflicts - which I have been pushing for without much success.
Even
> if we don't do read-write conflicts, at least configurations help me deal
> with multi-lingual authroing situations.
Yes but configurations are indpependent of variants. Either a configuration
contains "the English variants of the user documentation for product X.Y"
or they contain "all language variants for the quick start manual for
product X.Y" or possibly "all language variants of all the documentation
for product X.Y". Depending on how you view configurations, these will
either be created once all the items are complete (for example when used
for production of box contents) or they will be created at the beginning of
the development/authoring process and be "frozen" once all items are
complete. In the latter case if the master is English and the variant
French, then the English content will be versioned and "snapshots" of the
French translation will be created intermittently along the way. In the
former case it doesn't matter.
> Maybe there are simpler solutions,
> but given the fact that we are dealing with embedded and linked resources
> and given that some of these resources have variants that are edited by
> multiple people in parallel, I really can't see how simple versioning
will
> work. My prediction is that with tools that support simple versioning
(i.e.,
> level 1), the authoring organization will build procedures to implement
> 'configuration management' suffering through human imposed errors or
> serializing the development process losing productivity. But, hey, that
is
> the market choice!!
In my opinion its all a matter of interpretation of the meaning of the
variant - if it is a true variant and not a related resource, then it is
simply a translation.