1) a document is moved; the forward document has the old UDI and contains the new UDI.
2) a document is generic, eg. "This month's report"; the forward document has a published UDI and contains the UDI of the currently relevant document.
Document D is moved to location (c). A forward document F replaces it at (b). F contains "(c).D" and itself must have UDI "(b).D"
(a UDI has the form x.y.z... where some of the dots could actually be slashes, but this is not relevant here).
When the browser at (a) follows the link from X, it references "(b).D" The server at (b) will now have to return the response "forward to (c).D", and it must do so from knowledge stored at (b). It could keep a list or any other record that D has moved, but in our model we will use the file system, by adding an extension: document F is in the file "D.html.f", the server looks for "D.html" first, then tries "D.html.f" and thereby knows that D does exist after all. The browser gets the information about D's true location, and automatically gets it. Although the server could get D, this should not be done because there could be a chain of forwards and the server would have to pass the browser's profile along it, maybe finding out-of-date servers on the way. The browser should follow the chain (at no extra cost in number of exchanges).
At (a) the user has D represented, and makes a link to it from N. The anchor will contain "(c).D" viz. the UDI of the real D.
If there is a long chain of forwards, then UDIs get substituted until the end of the chain is reached.
The mechanism of getting at (c).MA and displaying it can be the same as for case 1, but document T is not like F of case 1: if the user wants to put a link to this month's report in N, (s)he would be very surprised if this link always referred to (c).MA. Instead, this link should continue to refer to T, so that it really is "this month's report" and not "March". Therefore, a different extension should be used for T, for example "g" instead of "f", and the server's response is different.
There may be a chain of forward documents with a generic in the middle, and as soon as the browser finds such a response, it sticks to that UDI rather than continuing to substitute UDIs.
[Note:can anyone think of a useful case of a chain of generics?]
In general, the algorithm makes sense only at the server's site, and the server will have to (a) recognise that the requested document is to be constructed by elaboration of the algorithm and (b) start and possibly control the software doing the construction.
There are two issues:
1) how to construct and edit the algorithm using WWW,
2) how to make external software execute the algorithm.
Editing can only be done by using an option in the browser whereby the author of the elaborated document addresses it with a specific request to return the algorithm, not the result. This is a special request to the server