Memorandum

Date: Mon, 05 Jun 2000 20:32:54 -0700

From:	Eric Armstrong
	eric.armstrong@eng.sun.com Reply-To: unrev-II@egroups.com

To:	unrev2 unrev-II@egroups.com

Subject:

Requirements v.0.8 (chgs)

This minor addition to the requirements doc merely states the obvious, on the theory that stating the obvious is a good thing in a specification. (On the other hand, an interesting design implication came out of thinking through the obvious. That note is also captured here.)

Note: With this "change-model" of specification-revisions, *you* (the recipient) are playing the role of the DKR/OHS system, as currently envisioned. (Or Joe is, at least, if he is updating his online HTML document.) Given the kind of DDOM that Lee Iverson proposes, the original version of the document would already be on your system. What comes over the network is the changes to the document (as well as comments added to it, etc.) The DKR/OHS will automatically merge those changes into the existing version of the document, highlighting them as "new" until you have cleared those markings.

Make the following changes to version 0.7 of the document to produce 0.8:

1. Under "Change History" add "0.8 - Added "Quotable" section

2. In the General Characteristics section, insert "Quotable" before "Accelerative".

3. Append the following text to the end of the "Categorizable" section:

   To summarize, then, the requirements for the proper handling of categories, are:

   • Creatable (add new categories)
   • Hierarchical (catA:catB)
   • Assignable (node <--> catA)
   • Removable (node <-/-> catA)
   • Changeable (catA --> catB, selected subset of nodes changes)
   • Auditable (audit trail)
   • Searchable (to find all nodes of given type(s))

4. Add the following text before the "Accelerative" section:

   Quotable

   In addition to being able to add commentary to existing documents, the user must be able to easily quote from existing documents when creating new ones.

   Internally, the quotations will appear as a link (for example, using the w3c XInclude specification). But the quoted material will appear "inline" in the new document. The link, in this case, will be a "hard link". That is, when newer versions of the text are created, the link will not point to them, but will instead point to the original version. The fact that newer versions exist, however, will be reflected in the display (explained next).

   When displayed, quoted material will be automatically attributed, and followed by a link to the original source node, in its original context. If that material has changed, that link will be flagged as "older", and a link to the newer version will also be presented. (The document's author(s) will then have the option of using the newer version in place of the original.)

   Design Note:

   If the system is truly a network (a node can exist in multiple contexts), then the pointer must point not only to the node, but also to it's parent context, so that the link goes to the document the node was quoted from. On the other hand, if the system is not really a network (but only appears to be one through the action of inclusion operations like quoting, then the system must be prepared to handle "pointers to pointers". In other words, if the node appeared in document A, and it was quoted in document B, then when constructing Document C, quoting the same text from document B will construct a link (pointer) in C to the pointer (virtual node?) in B that points to A. The "context" of the node, in that case, must be B, and not A.