Eugene Eric Kim <eekim@eekim.com>, February 8, 2001, v1.1
This is a set of Use Cases for the Hyperscope and the OHS Editing Component, proposed and compiled over the past year. Ivar Jacboson has said that a very large system should have no more than 80 use cases, suggesting that small systems should have less than 20. So far, there are less than 20 Use Cases below, and I think it's reasonable to keep it that small. (Kulak, Guiney 37) 1A (02)
I've included links to requirements and some scenarios that use these Use Cases. 1B (03)
Remember that this is a very rough, early attempt at putting together a comprehensive list of Use Cases for the system. Feedback is encouraged. Please try to use the purple numbers! 1C (04)
Change the way a document is displayed. 2B1 (010)
View specifications are documents in and of themselves, and can be shared just as any other documents. A view applied to a document can be considered a different document, although it's not clear to me yet whether this abstraction is useful or confusing. 2B3 (012)
Create a link from one part of a document to another part of a document. 2C1 (014)
[Requirements 08, 09, 011, 020] 2C2 (015)
Who defines addressability on a document-by-document basis? In the OHS, if you use an intermediate XML file, then you can address any document using XPath. However, this may not be ideal. Also, what about a document's address? Different document types have different standards -- for example, URLs (eventually URNs) for web pages, and message IDs for e-mail. What about Microsoft Word documents on your local hard disk? 2C3 (016)
Should all links be stored externally, whether or not they are embedded in a document? 2C4 (017)
Edit the document, recording the new changes while retaining a copy of the old version. 3B1 (029)
The internal structure of revisions could be thought of as two nodes -- one containing the original data, one containing the revised data -- connected to each other via a link with the type "revision". This raises an interesting problem. One of our challenges will be conceptually differentiating concepts that the user-level concepts versus low-level concepts. For example, links at the implementation level will not necessarily be the same as the links that the user can see, use, and manipulate. 3B3 (031)
Reuse passages found in other documents. In some cases, you may want reused passages must stay in sync with changes to the passage in its original location, or in any of its locations. In other cases, you may only be interested in a copy of the passage (in other words, forking the node). 3C1 (033)
There are two types of reuse that we need to support: cloning and linking. (Again, that "linking" word!) 3C2 (034)
Make the document available to other users. 3D1 (036)
There should be some system of access control for documents. 3D2 (037)
Annotate a document or a particular passage in a document. 3E1 (039)
This could be implemented as links, allowing annotations without editing the original document. One option that is probably a necessity is the ability to embed annotations within a document. Although view control could include the ability to include excerpts from external documents, sometimes, those external documents may not be easily available, so it's desirable to make a document and its annotations a single atomic unit. For example, see the scenario on responding to e-mail. 3E3 (041)
Removes the document from the current repository. 3F1 (043)
Whether or not a document is actually removed, or whether it is simply categorized as "deleted" is a decision we need to make at some point. 3F2 (044)
Categorize a document using any number of customizable categories from any number of customizable taxonomies. 3G1 (046)
Categorize a passage within a document. 3H1 (049)
Typed links could potentially be used for categorizing passages. 3H2 (050)
For document formats that use rich XML vocabularies, element names are a form of categorization. For example, a <usecase> element would indicate that the nodes contained within fall under the category of a "Use Case." 3H3 (051)
Kulak, Daryl and Eamonn Guiney. Use Cases: Requirements in Context. (New York: ACM Press, 2000). 4A (053)
Document developed using Purple