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.
========================================================
------------------------------------------------------------------------
Take your development to new heights. Work with clients like Dell and
pcOrder. Submit your resume to jobs@liaison.com. Visit us at
http://click.egroups.com/1/4358/4/_/444287/_/960262391/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Jun 05 2000 - 20:41:21 PDT