Augment links are special visible text embedded in a document and recognized by the viewer software. The link holds navigation instructions that leads the viewer to another point in another document. This was before Internet and it was presumed that the local file system could access the new document. These navigation instructions are otherwise much richer than html links. Augment documents have structures via which to navigate. The navigation instructions can include searching forward for text given within the link.
Viewing an Augment or html document does not reveal that someone has produced a link to the text that you are viewing.
It might be suggested that the commentator edit a copy of the document upon which he comments and then publish the copy with relevant anchors. This does not provide notification of comments nor provide indications of comments by multiple commentators. It is also tempting for the commentator to change the text which would likely go undetected.
When someone wants to comment on some document, called the subject here, and register the comment, he first runs an applet from the xa server.
He provides to the applet, the URL of the subject and enough text from the subject to identify the text that he wants to comment on.
The applet returns an html anchor that might look like:
<a href=http://xxa.com?3S34ff#3S34ff name=03S34ff> The value “3S34ff” is called the link ID. At this point the data base has no idea where, if anywhere, this link has been installed. The table entry will last for days at least.
What has happened is that the xa server has fetched the subject, found the text, computed a secure hash of the subject, and built a table entry consisting of
Alternatively the commentator could view the subject thru the xa server (see below) where he might find appropriate pointers that others have already established.
If a standard browser follows the link at this point then the xa server will be notified with a message containing the link ID. The data base is used to locate the original subject in which the interesting text is decorated such as: <a name=3S34ff> <font color=#ff0000> Interesting text </font></a> which yields “Interesting text” in its context.
This is cute but not the real purpose. The commentator may register his comments by submitting its URL to the xa server. He identifies himself, perhaps with a password. The server then passes over the commentary looking for special links that it might have handed out. It records such instances in a second table in the data base. The table entry would then hold:
There are advantages to this scheme beyond the desiderata given above. The xa function can be either centralized or distributed. Any machine running a browser can host an xa server. This cuts down on the cost of traffic between the server and browser. Casual users can use a centralized xa and not pay to install an xa server.
A further advantage is that, not being integrated with a browser, this functionality can be upgraded to new browser and server technologies with little or no effort. The rapid pace of html and browser evolution makes this attractive.
Suppose that we use standard browsers, standard html and standard httpd servers, but that we have a special proxy, xa, that is html savvy. This proxy might have caching function. A caching proxy already intervenes in some of the right places. It is also OK if the proxy role is already filled for our new proxy can itself refer to the “real” proxy.
The commentator uses a standard browser to view the subject document that he wants to comment on. The subject is on a standard server machine. When the commentator wants to comment on the object he starts an applet in another window by invoking an URL to xa. He informs the applet of the subject (if necessary). Sometimes the commentator will be viewing the subject via xa as proxy and xa will probably be able to take advantage of this but I think there is no conceptual difference.
To indicate a target in the subject the commentator moves text with copy & paste from the subject window to the applet window. The text arrives to xa which finds the text and warns if the text is not unique. Xa returns to the applet window a legal html pointer to be included in the commentary.
There is magic in that link. It points to xa and delivers to xa information to locate the subject document and locate the interesting text within the subject. This might be because xa remembers the tagging or because the memory is in the link. (long link—many characters) In either case xa serves up the document and dynamically modifies it to include an anchor so that the reader’s browser can find the anchor. xa may also decorate the text so that the reader knows what text is referred to.
There are several alternatives for the nature of this “xa pointer”.
Xa is in a position to be aware of version of the documents that it indexes. It might warn that a document has been changed since a comment about it was made. With the second alternative xa is in a position to follow pointers even to updated documents.
The reader advises xa which which commentators the reader is interested in. Commentary is merely a newer document with xa pointers to the subject document being displayed. A relational data base connects the two documents. The references are to portions of text in the older document.
I think that the only impediments to scaling are the data base. I think that data base practice solves this.
I think that this scheme can be made more rational and easier to explain.