scenarios for version-aware web authoring

Jim asked me to put together a few scenarios for distributed authoring.
Below are a few offerings, with a bit of emphasis on the problems I've
seen managing our web site and a few pot shots from the SCM world.  This
certainly doesn't cover all the vagaries of the problems we need to
address, but it is a stab at real world versioning of web content.

The scenarios are:

1) Two people trying to change the same document.

2) Revising a set of documents and publishing them when complete.

3) Reverting the revised document set.

On we go:

1) Two people trying to change the same document.

    A certain Web site is maintained by two people, both of whom make
    changes on an ad hoc basis.  As is frequently the case, there are a
    few documents that are hot points of congestion, even between these
    two people.  Both people have a fancy, version-aware Web authoring
    tool that interacts with their Web server.

    "Joe" downloads a document from the Web site, and decides that it
    needs work.  He clicks on the "edit" button from his browser/authoring
    tool, and the tool reports two things: first, that the Web server
    has acknowledged his edit operation (giving him assurance that a
    subsequent PUT will not be a complete surprise to the server);
    second, that the document he will edit is identical to that which
    he viewed.  This may not always be the case: sometimes the document
    viewed by users is not the true, editable source of the document.
    But in this case it is.  Joe proceeds to revamp the document.

    "Jane" meanwhile is viewing the same document and realizes that in
    the document the word "fuchsia" has a typo.  Jane also clicks the
    "edit" button, but the authoring tool has a lengthier report for
    her:  in additing to what Joe was told, Jane is told that Joe is
    also working on the same document.  Jane calls Joe and they reach
    an agreement:  Jane will make her fix now (because the error is
    embarrassing) and Joe will make sure this alteration makes it into
    his revision.

    Jane makes her changes and clicks the "save" button.  Her authoring
    tool prompts her for a brief description of her changes, and then
    the server informs Jane that her change has resulted in a new,
    named revision of the document, and that name is displayed.

    Joe forgets what he was doing, and weeks later (while working on
    something else) clicks the "what am I working on" button.  In the
    long list of documents that Joe has started to change is the document
    we've been discussing, and Joe decides it is time to finish it off.
    He makes his final edits, and clicks the "save" button.  Joe,
    however, gets a message indicating that what he edited is no longer
    the latest version of the document, and Joe clicks the "merge"
    button.  The authoring tool has the latest and greatest merge
    mechanisms, and in the process of resolving Jane's work with his
    he realizes that Jane did more than just fix the misspelling she
    said she would.  That doesn't matter, because the merge mechanism
    uses actual differences, not verbally stated intentions.

    Joe again clicks the "save" button, and this time he is prompted for
    a description and his new version of the document is saved.

2) Revising a set of documents and publishing them when complete.

    Jane and Joe's version-aware web server is fairly simple: normally,
    it serves up the latest revision of each document, but if instructed
    it will instead serve up the revisions of documents as listed in a
    named configuration.  In this way, they can make their trivial
    changes and have them show up immediately, but if they plan to make
    a heavy-duty overhaul they can save the current set as a working
    configuration and tell the server to use those until the work is
    complete.  (This can all be carried out without the explicit knowledge
    of Jane and Joe's authoring tool, because the Web server makes itself
    configurable via Web pages with forms on them.)

    Joe is about to make a set of minor changes, and to be on the safe
    side tells the server to save the current configuration as "stable",
    a name he uses for these occasions.  He goes through the various
    documents, clicking "edit" on any that he thinks are in need of
    updating.

    Once again Joe forgets what he is doing, but a few days later the
    "what am I working on" button again comes in handy.  He realizes that
    his work is about complete, and makes his final edits.

    Joe's changes really are a coherent set that should appear
    simultaneously, and he doesn't want to find out halfway through
    saving that Jane has made changes that need merging, so he clicks
    the "Save All" button.  Fortunately, Jane has been busy viewing
    _other_ parts of the web and hasn't made any changes to their local
    Web pages, and so Joe is prompted for a description of the changes
    he has made.  Since Joe is saving all the documents at once, a single
    description applies to all the changes.  One by one the new documents
    are saved, and in the end Joe gets confirmation that all documents
    are in place.  Joe browses the result and is satisfied that their
    customers are seeing what he has just finished.

    Joe goes on vacation.

3) Reverting the revised document set.

    Jane gets back to real work and realizes that every document that
    Joe edited has the same old spelling problem.  In a panic she calls
    Joe but realizes that he is on vacation.  Knowing that the errors
    would harm their image, she decides to undo what Joe has done until
    he returns and can correct his mistakes.

    Jane begins by browsing the revision history of each document, and
    notes that all the erroneous documents came about at the same time
    when Joe saved his changes just before vacation.

    Jane browses the configuration lists in the version-aware web server
    and sees that Joe had made a "stable" configuration before his
    latest work.  Jane instructs the server to serve up only documents
    from the "stable" configuration.  As this doesn't involve changing
    any of Joe's work, it is a quick fix to the pages on their public
    web server.  Jane now browses the documents on their server and is
    satisfied that they are the precursors to Joe's latest change.

    When Joe returns, he fixes his spelling mistakes and then tells
    the server to resume using the latest documents.

---

Christopher
----
Christopher Seiwald     Perforce Software	www.perforce.com       
seiwald@perforce.com    f-f-f-fast SCM		1-510-865-8720

Received on Wednesday, 28 August 1996 13:39:21 UTC