W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

More Scenarios in preparation for writing the RFC

From: Steve Carter <SRCarter@gw.novell.com>
Date: Fri, 25 Oct 1996 16:29:19 -0600
Message-Id: <s270eaf7.086@gw.novell.com>
To: w3c-dist-auth@w3.org
Del is not in today and asked that I get this posted for him. So, for your reading enjoyment  here's Del.
-------------------------------------------
To: W3C Distributed Authoring Working Group
From: Del Jensen (youll remember me as the silent one from Novell, Steve was the loud one)
Re: RFC and Scenarios

I have volunteered to act as RFC editor, and Jim has provisionally accepted my offer.

Accordingly, I=ve been reviewing the draft documents, scenarios and discussions in order to pull 
together what might be called an emerging consensus within the work group, preparatory to 
editing a formal requirements document for review and release.

With respect to the substantive issues herein, I have borrowed extensively from the scenarios 
provided by others in the group, as well as from forum discussions and preliminary drafts of 
requirements.  Mistakes and omissions should be attributed to my lack of as opposed to an active 
intent to willfully misunderstand or promote mischief (Im not a trouble maker). With that 
introduction let me begin.

-------------------------------------------------------------------------------------------

We begin with a statement of the "global" requirements, followed by a statement of the functional
requirements for "an extension to http for distributed authoring and version control" (herein 
called "Extension").

As each functional requirement is stated, it is followed by:
>  scenarios illustrating what might happen in the course of a client/server transaction in the 
context of the functional requirement,
>  a brief discussion of the implementation issues raised by the scenarios.
The (brief) discussion of implementation issues is intended as an aid to ensure that the
requirements do not inject implementation elements into the protocol design; this would be
contrary to the spirit of application level interoperability which is so fundamentally an objective 
of the overall http initiative.  Take note that this material is preliminary and incomplete.


Global Requirements:

Ia. (weak)   The Extension shall be endorsed by the W3C.
 
Ib. (strong) The Extension shall be endorsed by both the W3C and the IETF.

II.  The Extension shall provide a foundation of core functionality to support the basic
activities of "distributed authoring" and "version control" across the Web, and shall
promote interoperability among and between components involved in such activity. 


Functional Requirements:

The functional requirements provide a contextual framework for defining the Extension.  These
requirements can be roughly grouped as follows: 
>  Changing/Observing the state of a document or document container or category
(Category/Container/Content Transactions), 
>  Locating a document (Search/Retrieval Transactions), 
>  Administrative transactions. 


Category/Container/Document Transactions:

Unless stated otherwise, container denotes an object/entity of the document store (as opposed to a 
transport container), whether the store is a file system or a document management system 
(DMS).  One can imagine many kinds of hierarchical container models. A file system comes 
readily to mind. Some container models, such as a web, may not be strictly hierarchical.  A 
category/container/document object that has the attribute of location on the Web might be 
referenced with a URL; were the location volatile or not known, such an object might be 
referenced with a URI. In fact, the issue of abstracting container/document identity is so 
important that we make it the subject of our first functional requirement.


1.  The Extension shall support reference to document and container objects by URL, and 
the Extension shall at least not be incompatible with the emerging URI standard.

2.  The Extension shall support transactions to OPEN a document container. 

Scenario 2a: 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 2b: PAT requests that file F(containing document D) be opened.  The server response to 
PAT establishes context for F; for example a Areference handle" for accessing the attributes and 
content of F. 

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

Issues: The scenarios illustrate:
<  First, a semantic problem: how does PAT understand the object-context response of the OPEN 
well enough to make use of it?
<Second, 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. See also 
http://www.acl.lanl.gov/URI/uri.html.)
<  Third, the issue of locking resources. In scenario 2c, suppose PAT opens S in something like a 
Ashare 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 Ashadow@ 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.  At the risk of 
violating the Aoath of neutrality@ we took as RFC editor, we suggest that c) would not 
yield satisfactory results.


3.  The Extension shall support transactions to CLOSE a document container. 

Scenario 3a: 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 3b: 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.

Issues: The problem of encountering a race condition is the explicit issue raised by Scenario 3a. 
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?

The second scenario (3b) 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.	The Extension shall support transactions to DELETE a document container. 

Scenario 4a: 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 4b: PAT directs that folder S and all subordinate folders and content be deleted. A 
document subordinate to S is currently open to PAT2.

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

Scenario 4d: 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.
Issues: 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. 4b and 4c show how "locking" 
might be a good thing. Scenario 4d 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.


5.  The Extension shall support transactions to UNDELETE a document container. 

Scenario 5: 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 Aplex@, so that S3 was also subordinate to Sk which 
was not subordinate to S1.


6.  The Extension shall support transactions to COPY a document container. 

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

Scenario 6b: 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. 

Issues: 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 6b 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?


7.	The Extension shall support transactions to MOVE a document container. 

Scenario 7a: PAT directs that folder S1 be moved to folder S2. In the container hierarchy, S2 is 
subordinate to S1.
 
Scenario 7b: 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.

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


8.	The Extension shall support transactions to GET container attributes and values. 

Scenario/Issues: See 3.


9.	The Extension shall support transactions to PUT document container attribute 
values. 

Scenario/Issues: See 3.


10.	The Extension shall support transactions to ADD and DELETE container 
attributes.

Scenario/Issues: See 3.


11.	The Extension shall support transactions to OPEN a document. 

Scenario 11a: 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 11b: 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.

Issues: 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.  The second scenario 
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.

12.	The Extension shall support transactions to CLOSE a document. 

Issues:


13.	The Extension shall support document CHECK IN and CHECK OUT transactions 
to a repository. 

Scenario 13: 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 Das 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.


14.	The Extension shall support transactions to COPY and MOVE documents. 


15.	The Extension shall support transactions to DELETE and UNDELETE documents 
from a repository. 

Scenario 15: 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.

Issues: The principal lesson of scenario 15 is twofold:
             <	Document deletions (like container deletions) can be subject to qualifying 
conditions such as meeting query and scope criteria.
             <	Developers must be wary of deadlocks.

Notes to myself:
Don't forget version control stuff.
Don't forget BEGIN/END TRANSACTION for roll-back to a logically consistent state.
Don't forget locking.
Don't forget to allow for request to override caching. Can a document stipulate
"don't cache me"? Can part of a document?
Don't forget 'purge' file/container. 

Document edit transactions:
 
16.	The Extension shall support transactions to GET document attributes and values. 

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


17.	The Extension shall support transactions to PUT the value of a document attribute. 

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


18.	The Extension shall support transactions to ADD and DELETE document 
attributes. 


19.	The Extension shall support transactions to GET document content. 


20.	The Extension shall support transactions to PUT document content. 


21.	The Extension shall support transactions to UNDO and REDO puts to document 
content or document attribute values. 


Search/Retrieval Transactions:

this section incomplete.


Administrative Transactions:

this section incomplete.
Received on Friday, 25 October 1996 18:31:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:41 GMT