1 - Introduction
Currently, we refer to anchors within an infostructure by the full URL for the anchor, for example:
http://www.agri.org/pub/documents/Farming/animals.html#PIGSObviously, if the infostructure changes, this URL may no longer point to the correct place. WebLinker solves this problem by presenting each infostructure as a logical entity.
We define a Local Resource Name (LRN) as a method to access an infostructure. An example of a LRN for the above anchor infostructure is:
http://www.agri.org/lrn/FARMING/PigsThe last part of the LRN, in this case Pigs, is a fragment identifier (Frag-Id) within the infostructure, i.e. it denotes a specific point within the infostructure. Figure 2 shows examples of fragment identifiers for the infostructure FARMING. When a link to the infostructure is traversed, the fragment identifier is resolved, and the correct node of the infostructure is returned. The advantage of this is that a fragment identifier will always point to the correct point in the infostructure.
Figure 2: All references to the infostructure are through the fragment identifiers for that infostructure.
In order to use this scheme, an infostructure maintainer must decide upon a set of fragment identifiers within the infostructure that an external document can link to. All access to the infostructure is through these fragment identifiers. The server on which the infostructure resides dynamically resolves the fragment identifier whenever the infostructure is accessed, returning the appropriate document.
This solves the two problems for the remote infostructure maintainer mentioned in Section 1.1:
This has the advantage that running WebLinker will take less time than rebuilding the entire set of HTML files. Also, if we consider two closely coupled infostructures, with many links between them, we now only have to change one thing, the mapping rule in the table, instead of changing many links in the source document.
Generated with WebMaker