Colloquium at Stanford
The Unfinished Revolution

Memorandum


Date: Fri, 18 Feb 2000 14:11:33 -0800

From: Eric Armstrong Reply-To: unrev-II@onelist.com

To: unrev-II@onelist.com

Subject:   DKR/OHS requirement: "invisible links"

vaneyken@sympatico.ca wrote:

I believe that we need a secondary form of hyperlink pertaining to abbreviations and specialized terms. Those would not be underlined. A reader would simply expect that clicking on them would immediately generate the appropriate definition, preferably in a separate window so as not to interrupt the primary document being read.

Yes, yes, YES!

I've been wanting this since working with help systems in the last millennium. That is a major reason for being happy with XML -- typed links, so you can mark a link as a "normal" or "invisible" link. Such words would appear as normal text so the links don't interfere with normal reading, but the cursor would change shape when over them to indicate that a link exists.

When you converting the XML document for display in HTML, the type can control the transformation so that the link displays with no underlining, with the same color as everything else, and in a separate window. (That makes the most sense, as you say.)

Expanding on the concept, it is worth remembering that English is a second language for a large part of the world's population (including much of our population!). Much like spell checkers have a standard language word list and topic-specific word lists, the authoring system's glossary could have standard-english terms as well as topic-specific terms.

To keep transmission times down, the work of recognizing language terms and creating links should probably take place on the receiver's system. The system can check whatever glossaries happen to be present, and do the dynamic linking accordingly. To minimize processing times, one can imagine several levels of operation:

The glossaries themselves have all the characteristics of a DKR, or least of a HyperDocument. They need to be authored, edited, improved, and transmitted. When new revisions are created, the differences need to be transmitted.

The receiver then needs options to:

  1. Accept transmitted differences (& merge into existing copy)

  2. Make a "back issue" request to retrieve the difference-base

    • If the original document does not already exist, that means a message is sent back to the "document origin" that says "send the original". The original is then automatically sent.

    • If the original document exists, but is out of date, that means a message is sent back to the "document origin" that says "send all differences between and . The original is then updated.

    • In each case, the "document origin" should be the central server from which the document was "published". If the document cannot be found on that site, then a message is sent to the system that sent the message originally.

      Example:

      • A document is sent from eric@myHome, to be "published" at bootstrap.org

      • The document is archived at bootstrap.org at the same time it is sent to everyone on the bootstrap list. (How and when that happens TBD.)

      • The "document origin" is myDocment@bootstrap.org

      • The bootstrap server will then reply to most requests for back issues.

      • If that is not available for some reason, then then clientApp@myHome will be contacted. (Messages will be sent to eric@myHome and bootstrap.org to inform the owners.)

      • If both requests fail, then one message goes to the receiver of the document, and another goes to eric@myHome to spotlight the difficulty.



Sincerely,



Eric Armstrong