New DAV Scenarios

I have edited the DAV Scenario document to include recent scenarios from
Del Jensen. The document is available at

http://www.w3.org/pub/WWW/Authoring/draft-lassila-dist-auth-scenarios.html

A text-only version is included with this message.

	Ora Lassila
	Nokia Research Center / Boston

Distributed Authoring Scenarios

Editor: Ora Lassila, Nokia Research Center (Boston) & W3C
Version: 0.3
Date: 11/7/1996

Table of Contents

  1. Introduction
  2. Scenarios of Distributed Editing
  3. Scenarios of Distributed Document Management
  4. Scenarios Directly Related to Forthcoming DAV RFC
  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. A section has
also been included for scenarios involving versioning, although these may
overlap with the aforementioned two sections.

In version 0.3 the section on locking (which was empty) has been
eliminated, and a section has been included containing scenarios directly
related to the forthcoming RFC on distributed authoring and versioning.

[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 Directly Related to Forthcoming DAV RFC

[ This section contains scenarios directly related to the current draft of
the forthcoming RFC on distributed authoring and versioning. Eventually,
these scenarios will become the entire scenario document and will replace
scenarios in the other sections. For now, they have been included
separately. Most of this section is taken directly from Del Jensen's
(Novell) message to the DAV mailing list; scenario notes are his. OL ]

4.1. Scenarios for Transactions to OPEN a Document Container.

Scenario A: A person, agent or thing, PAT, requests that repository R (a
web, a DMS store, etc.) be opened. The server response to PAT establishes
context for R; for example, a list of R attributes and corresponding
attribute values, followed by a list cataloging the objects immediately
subordinate to R (folders, files, pages, whatever). Variation 1: PAT
requests by location (URL). Variation 2: PAT requests by identity (URI).

Scenario B: PAT requests that file F (containing document D) be opened. The
server response to PAT establishes context for F; for example a "reference
handle" for accessing the attributes and content of F.

Scenario C: PAT opens folder S. In response, PAT receives context for S.
Just after PAT's OPEN request PAT2 initiates a MOVE of S.

Notes:

  1. A semantic problem: how does PAT understand the object-context
     response of the OPEN well enough to make use of it?
  2. The need to support URI's as well as URL's. We should keep a close eye
     on the URI/URC work groups (see URI specification RFC1630, and see
     also http://www.acl.lanl.gov/URI/uri.html).
  3. The issue of locking resources. In scenario C, suppose PAT opens S in
     something like a "share deny none" mode. What might happen? a) The
     server might reject PAT2's MOVE request. b) The server might honor
     PAT2's MOVE request and "shadow" the old URL for S until there is no
     pending operation or unresolved state with respect to S via the shadow
     URL. c) The server might honor PAT2's MOVE request and do nothing
     about pending operations or unresolved states with respect to S via
     the orphaned URL.

4.2. Scenarios for Transactions to CLOSE a Document Container

Scenario A: PAT, having examined the list of container attributes for
folder S, uses an editing tool in order to change the value V1 of the
attribute A to V2. The new attribute value has local instantiation at the
remote host(s) which are providing an environment for PAT's editing tool.
The (server side) object S itself does not yet reflect V2 at A. Through
some action, either explicitly (such as requesting a "close" transaction
with S) or implicitly (such as ending the edit session) PAT asks for
closure with S. Variation 1: A second party PAT2 has meanwhile requested to
PUT a value to A. Variation 2: At the time of PATs CLOSE request, PAT is
disconnected from the network.

Scenario B: PAT has opened folder S and requested that all objects in S not
accessed within the last six months be deleted. Before the deletion is
complete, PAT requests closure with the repository R containing S.

Notes:

  1. The problem of encountering a race condition is the explicit issue
     raised by Scenario A. But there is also the implicit issue of
     providing a common sematic space for PAT's editing environment and the
     server-side DMS. In this case it would be nice if PAT's environment
     had lexicological connection with A, i.e., could ascertain how the
     value of A is represented (data type, range, etc.). Semantic problems
     such as these are often resolved by promoting standard formats for the

     transport container. Will the work group get involved with format
     issues?
  2. Scenario B illustrates an obvious closure issue, to wit: all ongoing
     processes and unresolved state conditions that are artifacts of the
     interaction between PAT, S and R must be "cleanly" terminated and
     resolved before closure. Usually.

4.3. Scenarios for Transactions to DELETE a Document Container

Scenario A: PAT opens folder S and examines its content. PAT decides to
delete all non-folder objects in S, but is unsure if existing folders
subordinate to S have valuable content. PAT directs that all non-folder
objects in S be deleted.

Scenario B: PAT directs that folder S and all subordinate folders and
content be deleted. A document subordinate to S is currently open to PAT2.

Scenario C: PAT directs that file F containing document D be deleted. A
copy process of D to some other repository is in progress.

Scenario D: PAT directs that all containers and related content subordinate
to folder S with content that has not been modified since a given date
(supplied by PAT or otherwise provided) be deleted. One or more active
documents in the repository reference a common header that is in a file F
subordinate to S. F meets the delete criterion.

Notes:

  1. The delete might need to act within the context of query results on
     container/content attributes as well as scope conditions on the store
     hierarchy.
  2. B and C show how "locking" might be a good thing.
  3. D illustrates how someone might wish to incorporate a "reference
     count" attribute on linked objects, and desire that reference count
     values be appropriately factored into the query/scope constraints for
     certain kinds of transactions.

4.4. Scenarios for Transactions to UNDELETE a Document Container

Container S1 (subordinate to S) and all subordinate containers have been
deleted. PAT requests that container S3 and all subordinate objects be
undeleted, where S3 was subordinate to S2 which in turn was subordinate to
S1. Variation 1: The container structure is "plex", so that S3 was also
subordinate to Sk which was not subordinate to S1.

4.5. Scenarios for Transactions to COPY a Document Container.

Scenario A: PAT directs that folder S1 be copied to folder S2. While the
copy is in progress, PAT2 directs that S1 be moved to folder S3.

Scenario B: PAT directs that a container Fbe copied to a location outside
the repository R. Although F contains only a simple text document, the
structure of F both as a logical and a physical entity is highly
idiosyncratic, being intimately bound to R. Consequently, F cannot be
expressed in the external domain. Variation 1: The DMS has export
capability (to the external file system) with a granularity that can
resolve F. Variation 2: The document contained by F has a native format
corresponding to the tool used to generate the document (HTML , WPD, etc.).
In this case one could interpret the copy as a transform from Fin the DMS
domain to the native document format D in the external domain. Variation 3:
The container to be copied is folder-like, i.e. a proper container, and the
container hierarchy in R is compatible with the external domain container
hierarchy. In this case, some kind of copy/transform could be implemented,
with the understanding that container attributes might be largely distorted
or lost.

Notes:

  1. Copying within R should be no big deal, though scenario 6a does
     illustrate why one might desire some kind of "read-lock" mechanism. As
     scenario B illustrates, copying container structure and content from
     one repository to another can be problematical. For example: how does
     one, in general, map a plex container model to a hierarchical model?

4.6. Scenarios for Transactions to MOVE a Document Container

Scenario A: PAT directs that folder S1 be moved to folder S2. In the
container hierarchy, S2 is subordinate to S1.

Scenario B: PAT directs that container S1 be moved to container S2. There
exists in web W a page P that is external to S which makes (forward)
reference (via URI) to one or more objects in S.

Notes:

  1. Again we see in the second scenario why it might be desirable to
     support the URI initiative.

4.7. Scenarios for Transactions to OPEN a Document

Scenario A: PAT requests that document D be opened. D is available in
English, German and Swedish, each using different word processors and each
with different revision histories.

Scenario B: PAT requests that document D be opened. D contains links to
headers, footers and graphical material. Variation 1: PAT's client side
environment is a browser. Variation 2: PAT's client side environment is an
editor.

Notes:

  1. In both scenarios it is important that source entities have meta-data
     identifying both the native (or "source") format (MS Word, Corel WP,
     etc.) and format revision.
  2. Scenario B also illustrates the possible desirability of server-side
     support for conversion of document source to a normal (canonical) form
     (such as HTML/MIME) for viewer/browser support. A typical DMS might,
     upon receipt of the OPEN request, retrieve the document meta-data and
     content from the store and create a temporary file containing the
     document content in its native format (such as Microsoft Word) on the
     system(s) hosting the store. The DMS would then respond (via the
     server) with status, the URL of the temporary file and the document
     meta-data (establishing context for the document object). The
     client-side process might then issue a GET request for either the
     source document (for editing), or the normal form document (for
     viewing). Though one might expect that editing source implies GETting
     source, one must not rule out the possibility of editing the
     (temporary) source file in-situ (server side); editing server side
     in-situ is one plausible approach to collaborative editing. While the
     Extension may not initially support collaborative editing of a single
     document, the Extension architecture should neither proscribe such
     functionality nor should it favor the adoption of any one particular
     implementation architecture.

4.8. Scenarios for Document CHECK IN and CHECK OUT Transactions to a
Repository

PAT "checks out" a document D with an "intent to edit" (i.e., a high
probability that PAT will delete, add-to or change document content or
document meta-data). Variation 1: PAT wants exclusive editing rights
("write lock") to D. PAT has no objection to letting others view as it is
edited. Variation 2: PAT wants exclusive editing rights D and PATobjects to
others viewing D as it is edited ("read/write lock"). Variation 3: PAT
wants to edit a local copy of D with the intent to merge and resolve
conflicts later at "check in". Note that this case accomodates editing
"off-line" (disconnected mode). Variation 4: PAT is willing to engage in
"free-for-all" editing, but wishes to make it known to other potential
editors that PATis entering/leaving the melee.

4.9. Scenarios for Transactions to DELETE and UNDELETE Documents from a
Repository

PAT directs that page P and all subordinate objects be deleted from web W.
Pn is subordinate to Pk is subordinate to P, and both Pk and Pn are in
scope (i.e., in W). It so happens that Pn forward links to Pk. The delete
process DEL recursively chains down from P, eventually encountering Pk, and
asserts a "read lock" on Pk preparatory to deleting Pk. Since Pk has
subordinate links, DEL continues down the chain until it encounters Pn,
where it asserts a "read lock" and recursively chains forward to Pk. DEL
requests a "read lock" on Pk.

Notes:

  1. Document deletions (like container deletions) can be subject to
     qualifying conditions such as meeting query and scope criteria.
  2. Developers must be wary of deadlocks.

4.10. Scenarios for Transactions to GET Document Attributes and Values

PAT submits a list of document URIs with the request that the
"subject/summary" attribute value be returned for each document.

4.11. Scenarios for Transactions to PUT the Value of a Document Attribute

PAT requests that the value of attribute "subject/summary" for document D
be modified to correct an error.

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:

   * Eui-Suk Chung, Ericsson, euisuk@w3.org
   * Del Jensen, Novell
   * 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,
 3 Burlington Woods Drive, Suite #250    MIT/LCS
 Burlington, MA 01803                    545 Technology Square
                                         Cambridge, MA 02139
 Phone: +1 (617) 238-4908
 Fax: +1 (617) 238-4949
 E-Mail: lassila@w3.org