Scenarios (contd.)

Here is a text version of the Distributed Authoring Scenarios document.

	- Ora Lassila
	  Visiting Scientist, W3C

----------
Distributed Authoring Scenarios

Editor: Ora Lassila, Nokia Research Center (Boston) & W3C
Version: 0.2
Date: 9/26/1996

Table of Contents

  1. Introduction
  2. Scenarios of Distributed Editing
  3. Scenarios of Distributed Document Management
  4. Scenarios Involving Document Locking
  5. Scenarios Involving Versioning
  6. Miscellaneous Scenarios
  7. References

1. Introduction

The purpose of this document is to catalog scenarios of distributed editing
and authoring as well as versioning, as related to the Interned Draft
document "Requirements on HTTP for Distributed Content Editing" [1]. These
scenarios can serve as examples of distributed authoring HTTP extensions'
usage, and can be used as basis for discussion of various requirements and
protocol features.

The scenarios in this document have been divided into sections addressing
different aspects of the distributed authoring area: the first section
focuses on the manipulation of the contents of resources (documents), the
second section focuses on the management of the documents themselves and
their relationships to other documents and the URL space. Sections have also
been included for scenarios involving locking and versioning, although these
may overlap with the aforementioned two sections.

[Comments are requested regarding new or existing scenarios and document
format. Please send them to the author.]

2. Scenarios of Distributed Editing

This section contains scenarios where contents of resources are changed
through the use of HTTP (as opposed to through local file system
operations).

2.1. Editing HTML

Jane, the maintainer of a web page, needs to update its HTML source. There
are no other variants to this page, such as translations into other
languages. She is working with a distributed authoring tool, DistEdit. She
loads the HTML source into DistEdit via HTTP. She then performs some edits
to the HTML source. The HTML source is then written back to its original URL
using HTTP. The distributed editing session is ended.

Relevant requirements (see [1]) and/or protocol features: 1 (Source
Retrieval), HTTP PUT, 10 (Partial Write).

2.2. Editing a Particular Language Version of an HTML Resource

Jane, who is fluent in French, needs to update the HTML source of the French
language variant of a web page which has English, French, and German
language variants. She is working with a distributed authoring tool,
DistEdit. She loads the French language HTML source into DistEdit using
HTTP, and makes some corrections and modifications. She then writes the HTML
source back to the original URL using HTTP. The distributed editing session
is ended.

Relevant requirements and/or protocol features: 1 (Source Retrieval),
HTTP PUT, 10 (Partial Write).

2.3. Editing HTML with Server Side Includes

Jane needs to update the HTML source of a web page. The HTML source includes
a server side include (SSI) directive which instructs the HTTP server to
insert the current date into the document, and is written in English. There
are no other variants to this page, such as translations into other
languages. Jane is working with a distributed authoring tool, DistEdit. She
loads the HTML source (including the source of the server side include
directive) into DistEdit via HTTP. She then performs some edits to the HTML
source. The HTML source is then written back to its original URL using HTTP.
The distributed editing session is ended.

Relevant requirements and/or protocol features: 1 (Source Retrieval),
HTTP PUT, 10 (Partial Write).

2.4. Editing Word Processor Source which Gets Converted to HTML

Jane needs to update the source of a web page, stored in the native format
of the HTTP-aware word processor DistProc. The HTTP server containing this
resource has extensions provided by the vendor of DistProc which
automatically convert the DistProc native files into HTML which is served
whenever the web page is accessed from its URL, U. The web page does not
include any graphic content, and is written in English. She loads the web
page source into DistProc from URL U using HTTP, and begins to edit this
DistProc native format source file. After making some modifications, she
saves the source file back to the original URL, U, using HTTP. She then
checks the HTML source by retrieving URL U using their favorite web browser.
Since it looks fine, she ends the distributed editing session.

Relevant requirements and/or protocol features: 1 (Source Retrieval),
HTTP PUT.

3. Scenarios of Distributed Document Management

Scenarios in this section describe remote management of the properties of
resources, remote management of URL hierarchies (aka "directories"), as well
as visualization of the relationships among graphs.

3.1. Creating a New Resource

Jane is working with distributed authoring tool DistEdit on a new HTML page
which does not contain any embedded graphical content. She has finished her
edits, and saves the HTML resource to a web server using the HTTP protocol.
She is prompted for a URL for the new document; the page is then written to
this URL using the HTTP "PUT" method.

Relevant requirements and/or protocol features: HTTP PUT.

3.2. Creating a New Resource through a "Save As" Dialog Box"

Jane is working with distributed authoring tool DistEdit on a new HTML page
which does not contain any embedded graphical content. She has finished her
edits, and wishes to save the HTML resource to a web server using the HTTP
protocol, but does not know the exact name of the level of the URL hierarchy
where she wants the document to be stored. She invokes the "Save As..."
feature of DistEdit, which includes a hierarchy level viewer, a list of all
the entities and their MIME types at a specific level of the hierarchy,
along with the ability to go up or down a level of the hierarchy by clicking
on either ".." to go up, or the name of a hierarchy level to go down. She
moves up and down within the URL hierarchy using the facilities of the
hierarchy level viewer, finally finding a good hierarchy level for the
resource. She then enters a name for the HTML resource, and hits the "Save"
button. The DistEdit tool now writes the HTML page to the URL created by
combining the hierarchy level selected using the hierarchy level viewer, and
the name just entered by her. The web page is written to the URL using the
HTTP "PUT" method.

Notes:

  1. The AOLpress distributed authoring tool currently provides this
     capability, which they term "Network saving of HTML pages" using the
     "AOLpress file dialog."
  2. For file-based servers, there is typically a mapping between URL
     hierarchy levels and directories in the filesystem.

Relevant requirements and/or protocol features: 12 (List URL Hierarchy
Level), HTTP PUT.

3.3. Creating a New Resource in a New Hierarchy Level

Jane is working with distributed authoring tool DistEdit on a new HTML page
which contains some associated embedded graphical content. She finishes her
edits, and wishes to save the HTML resource to a web server using the HTTP
protocol, as well as save the graphical images (collectively we will call
this publishing). She invokes the publishing feature of DistEdit, which
includes the hierarchy level viewer (as described in the previous scenario).
She finds a level of the hierarchy using the hierarchy viewer, but since
this is a new web, she decides to create a new level of the hierarchy just
to contain this web. Pressing the "Create New Hierarchy" button causes the
author to be queried for the name of the new hierarchy level. Once entered,
DistEdit informs the HTTP server that a new hierarchy level should be added
below the level currently displayed in the hierarchy level viewer. If the
author has the correct access permissions to create a new hierarchy, the new
hierarchy level is created. The web author then presses the "Publish"
button, and his web of HTML and graphic entities are written to the HTTP
server.

Notes:

  1. The AOLpress distributed authoring tool currently provides the
     capability to make new hierarchy levels, supported by their "MKDIR"
     HTTP method.

Relevant requirements and/or protocol features: 12 (List URL Hierarchy
Level), 13 (Make URL Hierachy Level), HTTP PUT.

3.4. Visualizing Webs as Graphs

In order to understand the link structure and resource inclusion
relationships at a hierarchy level, a web maintainer chooses the "Graph
View" option of their distributed editing tool DistEdit. DistEdit queries
the web maintainer for which level of the hierarchy to display using a graph
visualization, and then uses the HTTP protocol to read information about
that level of the hierarchy. DistEdit uses this information to display a
graphical visualization of the hierarchy level, including an icon for each
resource, solid lines between the icons representing links, and dashed lines
representing inclusion (for example, images loaded using the IMG tag).
Entities the web maintainer has read and write access to are displayed in
green, those which they have read access to are in white, and those which
they have no access to are in red. To create the graph visualization,
DistEdit must, using HTTP, get a listing of all the entities at a level of
the hierarchy, and their access control permissions.

Notes:

  1. The AOLpress distributed authoring tool currently provides a similar
     capability, which they term the "MiniWeb," a "bird's-eye" graphical
     view of web site documents and how they are linked together.
  2. The FrontPage distributed authoring tool provides equivalent
     capability, which they call a "Link View," and also supports the
     related "Outline View" and "Summary View."

Relevant requirements and/or protocol features: 12 (List URL Hierarchy
Level).

3.5. Modifying Access Rights

Realistic. A sales manager at a company which contains an organization-wide
intranet is working with an intranet-enabled spreadsheet program, DistCalc.
After entering the sales figures for the previous month (which are below
projections), a graph of the sales figures is generated as a JPEG image, and
then saved to the departmental HTTP server using the HTTP "PUT" method.
Realizing that it might be best to limit access to this information, in
their web browser they bring up the graph image. After selecting the menu
option, "Modify Access Permissions," the browser displays the access control
page for the graph image resource. The sales manager uses the
(server-specific) facilities on this page to modify the sales chart's access
control rights so it is password protected.

Ideal. In the ideal case, the DistCalc program would display a dialog box
asking the user for what access rights the graph resource should have before
the graph is saved to the departmental HTTP server.

Notes:

  1. The "realistic" case assumes that reaching consensus on an access
     control standard for HTTP resources is not achievable in the near term,
     and hence access control will vary with server type. It also assumes a
     continuation of the current trend of having an access control URL for
     each resource. The "ideal" case shows what could be achieved if an HTTP
     access control standard is created.

No matching requirements or protocol features.

3.6. Copying Documents

Jane is looking at the list of monthly reports available on the server. She
selects one from the list that she wants to use as the basis for a new
monthly report. She asks for a copy of this monthly report to be made in the
same directory but with a different name. Since she is not intending to work
on it now, there is no reason to pull the content to the client.

Relevant requirements and/or protocol features: 14 (Copy).

3.8. Modifying/Setting Document Attributes

Jane is creating a new document on the Web. She sends it to the server, but
also wants to set a bunch of attributes that can be used later in searches
(author, title, document type, subject, organization, etc.). Sometimes she
may also want to create catalog entries for documents that are not available
in electronic form. There will be no content for these documents, just
attributes.

Relevant requirements and/or protocol features: 11 (Attributes).

4. Scenarios Involving Document Locking

This section [yet to be written] will contain scenarios involving the
various locking requirements outlined in [1].

5. Scenarios Involving Versioning

This section contains scenarios involving document versioning. Please note
that the three scenarios here actually form one long scenario.

[some of the versioning functionality could also be incorporated into the
scenarios in the previous sections; OL]

5.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
(we'll call them "Jane" and "Joe") 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 addition 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.

5.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.

5.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.

6. Miscellanous Scenarios

This section contains scenarios relevant to distributed authoring which do
not fit in any of the preceding sections.

6.1. Printing a Multi-Resource Document

Browsing. A net surfer browsing the web loads the introductory page for a
book which has been written in HTML and subdivided so that there is a
separate resource for each chapter, and many side links to clarifying text
and standalone figures. Since the book is of interest, the net surfer would
like to print the entire document. Clicking on the "Print" button of their
web browser brings up the Print dialog box, which contains an option, "Print
multi-resource document," which they select, before pressing the "Start
Printing" button.

The browser now begins, in the background, to load all of the chapters of
the book along with their explanatory sidebars, sending them one by one, in
order, to the printer. When complete, the browser pops-up a dialog box
stating that the document has been completely printed.

Distributed Authoring. This scenario applies equally well to a distributed
authoring situation. If the author of a multi-resource document is using a
distributed authoring tool to write the document, it is desirable for them
to be able to print the document as a whole, rather than by loading and
printing each resource in turn.

Notes:

  1. This type of printing capability is supported by the KMS hypertext
     system, an early monolithic (but very feature-rich) hypertext
     environment.
  2. Another common example of a multi-resource document which would be
     desirable to print as a whole is a slide presentation which has been
     converted into HTML.

6.2. Quick Browsing of Related Resources

A professor is working on a new textbook using their favorite
intranet-enabled word processor, DistProc. Once the initial draft of this
book is complete, they use the "Publish" feature of DistProc to save their
book as multiple resources, one per chapter, on a web server. Since the
author intends for their students to read the text using web browsers
employing a DistProc reader plug-in, the professor has the book on the HTTP
server in DistProc native format, preserving layout information.

In order to provide additional browsing structure to the students, the
professor uses the feature of DistProc to automatically create links to the
table of contents, index, and glossary for the book. To make generating
feedback easier, all book chapters automatically have a link to a
corrections and feedback page. As the students are reading the text, these
automatic links are displayed as special toolbar icons in their browser.

Notes:

  1. The AOLpress distributed authoring tool currently "allows pages to add
     toolbar buttons on the fly using the HTML 3.2 "<link rel ...>" tag. For
     example, your page can add toolbar buttons that link to a home page,
     table of contents, index, glossary, copyright page, next page, previous
     page, help page, higher level page, or a bookmark in the document."
  2. The scenario above is currently unachievable because LINK tags are only
     supported in HTML.

6.3. Others

[These scenarios are interesting, but I'm not sure where they belong; OL]

Jane's department keeps its documents organized in hierarchical collections.
There is a collection called "Monthly Reports" with subcollections for each
month. There is also a collection called "Monthly Business Letters" with
subcollections for each month. The monthly reports are used to derive the
monthly business letters, so the monthly reports appear in the appropriate
"Monthly Business Letters" subcollections as well. When Jane writes her
monthly report, she puts it into Monthly Reports/199608 and into Monthly
Business Letters/199608. Only one copy of the report should exist on the
server, but it appears in both places when users browse or search the
collections.

The first time Jane's monthly report gets printed, it gets converted to
PostScript, which she wants to store on the server. Now there will be two
renditions of the same (version of the same) document from which she can
choose when she retrieves the document in the future. She also saves the
printing instructions (duplex, landscape, stapled, etc.) for the document,
which she may want to retrieve with the PostScript later.

7. References

[1] Jim Whitehead, 1996. "Requirements on HTTP for Distributed Content
Editing", Internet Draft, available as
http://ds.internic.net/internet-drafts/draft-whitehead-http-distreq-00.txt

Acknowledgements

The following people have contributed to this document by sending sample
scenarios and/or by commenting:

   * Dave Long, dave@sb.aol.com
   * Christopher Seiwald, Perforce Software, seiwald@perforce.com
   * Judith A. Slein, Xerox, slein@wrc.xerox.com
   * Jim Whitehead, UC Irvine, ejw@ics.uci.edu

Author's Address

 Ora Lassila

 Nokia Research Center / Boston       or World Wide Web Consortium, MIT/LCS
 3 Burlington Woods Drive, Suite #250    545 Technology Square
 Burlington, MA 01803                    Cambridge, MA 02139

 Phone: +1 (617) 238-4908
 Fax: +1 (617) 238-4949
 E-Mail: lassila@w3.org

Received on Thursday, 26 September 1996 17:20:45 UTC