Further Modifications to the Dexter Hypertext Reference Model: a Proposal
Wilma Penzo
Stefano Sola
Fabio Vitali
Technical Report UBLCS-94-1 January 1994
Laboratory for Computer Science University of Bologna Piazza di Porta S. Donato, 5 40127 Bologna (Italy)
The University of Bologna Laboratory for Computer Science Research Technical Reports are available via anonymous FTP from the area ftp.cs.unibo.it:/pub/TR/UBLCS in compressed PostScript format. Abstracts are available from the same host in the directory /pub/TR/UBLCS/ABSTRACTS in plain text format. All local authors can be reached via e-mail at the address
[email protected].
UBLCS Technical Report Series
¨ Babaoglu, 93-4 A Formalization of Priority Inversion, by O. ˘ K. Marzullo and F. Schneider, March 1993. 93-5 Some Modifications to the Dexter Model for the Formal Description of Hypertexts, by S. Lamberti, C. Maioli and F. Vitali, April 1993. 93-6 Versioning Issues in a Collaborative Distributed Hypertext System, by C. Maioli, S. Sola and F. Vitali, April 1993. 93-7 Distributed Programming with Logic Tuple Spaces, by P. Ciancarini, April 1993. 93-8 Coordinating Rule-Based Software Processes with ESP, by P. Ciancarini, April 1993. 93-9 What is Logic Programming good for in Software Engineering?, by P. Ciancarini and G. Levi, April 1993. 93-10 Scheduling Real Time Tasks: A Performance Study, by F. Panzieri, L. Donatiello and L. Poretti, May 1993. ¨ Babaoglu 93-11 Specification and Detection of Behavioral Patterns in Distributed Computations, by O. ˘ and M. Raynal, May 1993. 93-12 Interaction Systems II: The Practice of Optimal Reductions, by A. Asperti and C. Laneve, May 1993. 93-13 Reliability Analysis of Tree-Based Structures and its Application to Fault-Tolerant VLSI Systems, by M. Roccetti, June 1993. 93-14 Guard Compilation in Logic Shared Dataspace Languages, by M. Gaspari, June 1993. 93-15 Data Algorithm: A Numerical Method to Extract Shape Information from Gray Scale Images, by R. Davoli and F. Tamburini, June 1993. 93-16 Towards Performance Evaluation in Process Algebras, by R. Gorrieri and M. Roccetti, July 1993. 93-17 Split and ST Bisimulation Semantics, by R. Gorrieri and C. Laneve, July 1993. 93-18 Multilanguage Interoperability, by G. Attardi and M. Gaspari, July 1993. 93-19 HERMES: an Expert System for the Prognosis of Hepatic Diseases, by I. Bonf`a, C. Maioli, F. Sarti, G.L. Milandri and P.R. Dal Monte, September 1993. 93-20 An Information Flow Security Property for CCS, by R. Focardi and R. Gorrieri, October 1993. 93-21 A Classification of Security Properties, by R. Focardi and R. Gorrieri, October 1993. 93-22 Real Time Systems: A Tutorial, by F. Panzieri and R. Davoli, October 1993. 93-23 A Scalable Architecture for Reliable Distributed Multimedia Applications, by F. Panzieri and M. Roccetti, October 1993. 93-24 Wide-Area Distribution Issues in Hypertext Systems, by C. Maioli, S. Sola and F. Vitali, October 1993. 93-25 On Relating Some Models for Concurrency, by P. Degano, R. Gorrieri and S. Vigna, October 1993. 93-26 Axiomatising ST Bisimulation Equivalence, by N. Busi, R. van Glabbeek and R. Gorrieri, December 1993. 93-27 A Theory of Processes with Durational Actions, by R. Gorrieri, M. Roccetti and E. Stancampiano, December 1993.
Further Modifications to the Dexter Hypertext Reference Model: a Proposal1 Wilma Penzo2
Stefano Sola3
Fabio Vitali3
Technical Report UBLCS-94-1 January 1994 Abstract The Dexter Hypertext Reference Model is considered the most general formal expression for the description of hypertext systems. Its purpose is to present a standard for the realization and the organization of this kind of system. The model gives a set of definitions, expressed in Z language, describing the nodes and links forming the domain network. Besides the relationship between components in the hypertext, the model presents a set of operations concerning their creation, modification and deletion. Furthermore, it shows the runtime behaviour a hypertext system should adhere to. Analysis of the Dexter Model revealed some syntactic and semantic errors in link management and the hypertext definition. Moreover, anchor management suffers from static definitions leading to possible inconsistencies in the system. In this paper we present some modifications to the Dexter Model with the aim of finding a solution to these inadequacies. An alternative definition of anchor representation is given through new Z specifications. Furthermore, link management is completely revised as regards component deletion policy. This paper belongs to a three-part study containing our analysis of the Dexter Model. The first and the second papers show some modifications and extensions to the said model, while the third part provides the formal description of RHYTHM, the hypertext system under development at the University of Bologna. In this first part we have modified the structure of the Dexter Model leading to a new view of the model.
1. This work has been done within subproject #7 “Sistemi per il supporto del lavoro intellettuale” of the Progetto Finalizzato CNR “Sistemi Informatici e Calcolo Parallelo”. 2. Universit`a di Bologna, Dipartimento di Matematica, Piazza di Porta San Donato, 5, I - 40127 Bologna, Italy 3. CIRFID, Universit`a di Bologna
1
1 Introduction
1
Introduction
Since its introduction, the Dexter Hypertext Reference Model has become the basic reference point for formal descriptions of systems in the hypertext field. Its definition is given in Z notation, a formal language based on set theory, first-order logic and schema calculus defining all the basic structures and the relationships between them. In the following, we introduce and justify our main modifications. A basic knowledge of the original Dexter Model and of elementary concepts of Z is assumed [Hal90], [Spi92]. The purpose of the Dexter Model is to represent a standard for modelling hypertext systems and providing some guidelines in their creation. The most important advantages of adopting a model as a systematic method for hypertext construction is the uniformity of realization allowing the model to achieve compatibility with all systems [Grø92], [HKo90], [VDP90]. The aim of the Dexter Model is therefore a complete and general formulation of the main features representing hypertext systems. Nevertheless, our approach to the model has revealed the presence of a few errors and inadequacies, creating a need for modifications to its structure. Our contribution has led to syntactic corrections and some considerations on semantic issues [Lam92]. This report represents the first part of a larger work made up of three papers analysing the structure of the Dexter Model and proposing modifications and extensions to its definition. Furthermore, the conclusion proposes the formal model of RHYTHM (Research on HYpertext THeory and Management), the hypertext system under development at the University of Bologna [Mai91], according to the rules set by the Dexter Model. In section 2 a general description of the Dexter Model is given, introducing the basic premises for subsequent considerations. Of the three layers into which each hypertext system may be divided, only the Storage Layer and the RunTime Layer are discussed in this report. In section 3 a first approach to our modifications of the model is given. Formal definition of hypertext is considered and its incorrectness is shown; a solution is provided in the reformulation of some Z schemas. In section 4 link management is considered by pointing out some inadequacies in the identification of links within composites. A complete solution is then given based on a recursive search inside composite components. In section 5 we present the behaviour of the hypertext after the modifications of a component. The ModifyComponent definition is revised placing particular emphasis on anchor management in the involved component. Furthermore, particular attention is given to the deletion of hypertext elements, providing the correct replacement or total elimination of updated links. In section 6 a new policy for anchor identification is presented taking into consideration the presence of a limitation in the model. We have introduced a suitable function, similar to the resolver search mechanism for hypertext components, enabling the dynamic mapping of anchors inside nodes. By describing the anchor requirements, called anchor specifications (ANCHOR SPEC), a search is made dynamically in the hypertext to identify those elements satisfying the necessary conditions at a given time. In section 7 we show a general way of handling both internal and external anchoring, pointing out how they influence the rest of the model. The modifications we introduced only regard some parts of the model and have little impact on the structure and elegance of the model as a whole. In our opinion, the great UBLCS-94-1
2
2 The Dexter Model
strength of the model is also shown in the ease with which our modifications fit into its general framework, taking advantage of most of its structure.
2
The Dexter Model
In 1990 Halasz and Schwartz proposed a landmark in the realization of hypertext systems. At the NIST Hypertext Standardization Workshop held in Gaithersburg they introduced the Dexter Hypertext Reference Model (in short Dexter Model) in order to provide a standard in hypertext design. This model arose from the need to give a general formalisation of modelling systems in this field [Gar91], [Grø92]. As a matter of fact the aim of this model is to provide the general guidelines for the description of hypertext systems and to point out the main characteristics every hypertext system should refer to. In detail it defines the basic structure this kind of framework is supposed to consist of. Furthermore, it gives a precise and well-defined presentation of the architectural features typically belonging to the above-mentioned systems [Kil90]. In this sense, the Dexter Model is considered the reference model to cling to in a correct formulation of definition specifications. It represents the most general and complete formal document to follow in planning hypertext systems. The model allows us to introduce a standard for data and information exchange even between systems with apparently different characteristics [Glu92], [Nel90]. The existence of systems differing in specific features makes the unification of their basic mechanisms essential to make compatibility possible [Aks89]. A description of the model is given in Z , a specification language based on set theory and first-order logic. This choice is justified by the need to provide formal expressions in a general form in order to avoid misunderstandings arising from a lack of precision in the descriptions. The model presents a layered organization as follows: The Within Component Layer: representation of aspects specific to several systems. It represents the internal state of a system through explicit reference to the details of implementation. In this layer all the technical choices (involving data management, memorization techniques and so on) are made according to system peculiarities. The Storage Layer: the logical structure of the system is specified through the description of nodes as components of the hypertext network and links as connections between them. It specifies the relationship between the domain elements and it defines possible operations on them. The RunTime Layer: represents the interactive aspect of the system and its behaviour at the time of execution. It describes the dynamic state of the hypertext through real interaction with the user and the specification of external representation. In order to maintain a general configuration within the Dexter Model, only the Storage Layer and partially the RunTime Layer have been fully developed. Moreover, several functions are intentionally left unspecified to allow for freedom during implementation. The above-mentioned layers communicate through two mechanisms allowing interaction to occur between modules: Anchoring: between WCL and SL. It allows for “mapping” from the logical structure of the database elements to the corresponding internal representations of the components. Presentation Specifications: between SL and RTL they express how the system is presented to the world, representing the interactive aspect of the hypertext and its impact UBLCS-94-1
3
2 The Dexter Model
RunTime Layer
Presentation of the hypertext; user interaction; dynamics
Presentation Speci cation
Storage Layer a \database" containing a network of nodes and links
Focus of the Dexter model
Anchoring
Within Component Layer the content/structure inside the nodes
Figure 1. Layers and Organization of the Dexter Model
on the user. Possible choices during the project are left unspecified. The anchor is a mechanism of permanent selection, identifying a particular area in the referred component and establishing a marked zone as a reference point for it. In this sense, anchors are used as end-points in relational connections realized by means of links [Mai92]. The structure of an anchor consists of an identifier unique to each component (ANCHOR ID) and a part pointing to the related value (ANCHOR VALUE).
ANCHOR == ANCHOR ID ANCHOR VALUE In the following sections we will introduce a brief description of the layers presented in the Dexter Model, leaving out the definition of the WCL, whose description cannot be specified in a general way. 2.1
Storage Layer
The fundamental entity in the Storage Layer is the component. In the given definition it could be a simple atom, a single link or a composite identifying other components.
BASE COMPONENT ::= atom hhATOM ii j link hhLINK ii j composite hhseq BASE COMPONENT ii UBLCS-94-1
4
2 The Dexter Model
COMP INFO attributes : ATTRIBUTE !7 VALUE anchors : seq ANCHOR presentSpec : PRESENT SPEC #anchors = #( rst (jran anchors j)) COMPONENT compBase : BASE COMPONENT compInfo : COMP INFO Each component is given a unique identifier (UID) so that each element of the domain can be found as the result of application of the appropriate function accessor described in the following schema. A further function is presented in the hypertext definition: the resolver function which applies to generic component specifications (COMPONENT SPEC) returning the UIDs of those elements satisfying the given requirements. Thereby, the hypertext framework is expressed in the following definition:
PROTO HYPERTEXT components : F COMPONENT resolver : COMPONENT SPEC !7 UID accessor : UID 7 COMPONENT HYPERTEXT PROTO HYPERTEXT 8 c : components c 2 ran accessor ran resolver = dom accessor 8 c : components (c ; c ) 2= ( subcomp ) 8 c : components 9 lids : F UID j lids = linksTo (PROTO HYPERTEXT ; accessor (c )) S rst (janchors (c )j) = ((anchorSpecs accessor )(jlids j)) The definition of LINK is based on a sequence of elements, called specifiers, determining the end-points involved in the relational connection.
COMPONENT SPEC ; PRESENT SPEC ]
[
DIRECTION ::= FROM j TO j BIDIRECT j NONE SPECIFIER componentSpec : COMPONENT SPEC anchorSpec : ANCHOR ID presentSpec : PRESENT SPEC direction : DIRECTION UBLCS-94-1
5
3 The Hypertext Definition
LINK speci ers : seq SPECIFIER #speci ers 2 9 s : ran speci ers s :direction = TO Furthermore, a specifier indicates the component it is referred to by means of the application of the resolver function to the componentSpec information contained in it. Indeed, the given set COMPONENT SPEC represents all the possible descriptions of components and allows for the identification of elements according to the characteristics they have in the hypertext. Therefore, the mapping of the resolver function to specific nodes satisfying the given requirements allows for the realization of virtual links at runtime. This is possible thanks to the said dynamic identification of components. 2.2
RunTime Layer
The fundamental concept in the RunTime layer is INSTANTIATION. It represents how a component of the hypertext is shown to the user. A component may have a large number of different instantiations which do not necessarily correspond to the real internal state of the hypertext. The instantiation of a component is modified at runtime and the changes are saved only through an explicit operation. In this sense, an instantiation can be considered a sort of runtime “cache” for the component. Each instantiation is given an Instantiation IDentifier (IID) and, besides the role of representing a component, it constitutes an instantiation for the anchors belonging to the Storage Layer and referring to it. It is defined as follows:
INSTANTIATION base : BASE INSTANTIATION links : seq LINK MARKER linkAnchor : LINK MARKER ! ANCHOR ID dom linkAnchor = ran links This layer also presents a set of operations applicable to the hypertext domain and defines the concept of session as a sequence of actions on the state of the system.
3
The Hypertext Definition
In this and the following sections, we demonstrate some inadequacies relating to hypertext definition, links and operations on components. As previously said in the description of the Storage Layer, a hypertext consists of a set of components, nodes of the network, and two functions for their determination. The hypertext definition states some properties of the above-mentioned functions and defines a restriction on the structure of the network: components can be represented in a direct acyclic graph (DAG) organization, avoiding the presence of self-containing composite components. Examining the third assertion of the definition we noticed an incorrect formulation of the final expression: UBLCS-94-1
6
3 The Hypertext Definition
rst (janchors (c )j) =
S((anchorSpecs accessor )(jlids j))
It may be useful to introduce the parts involved with a more detailed explanation:
lids represents the set of UIDs belonging to LINK components referring to a given component c. anchors(c) represents the set of anchors belonging to the COMP INFO of a given component c. These anchors are end-points of the links referring to c. anchorSpecs is a partial function returning the set of ANCHOR IDs corresponding to the anchors that appear the specifiers of a given link.
The left-hand side of the equality represents the set of ANCHOR IDs of the anchors used by links pointing to the component c. This set is determined by the information (the anchors sequence) contained in the COMP INFO of the given component. The right-hand side also represents a set of ANCHOR IDs of anchors that are end-points of links. In this definition the sequence of specifiers involved in the link is considered and the result of the application of anchorSpecs gives the elements of the set. We claim that this set is a superset of the previous one. We consider the case of a binary link with specifiers referring to two different components so that the link starts from component c1 and reaches component c2 (a very common case in hypertexts). In this case the expression
rst (janchors (c 1)j)
identifies the ANCHOR ID of the anchor belonging to the component c1,while the expression
S((anchorSpecs accessor )(jlids j)) determines ANCHOR IDs belonging to both specifiers. So, in this set, the ANCHOR ID related to component c2 is present, as well as the one related to component c1. Therefore, in this case the said equality does not hold. The solution given in this paper is based on the selection of specifiers composing links. Only particular ANCHOR IDs are considered: those belonging to specifiers having componentSpec related to the component in analysis. Formally this can be represented by a new hypertext definition as follows: UBLCS-94-1
7
4 Operations on Links
HYPERTEXT PROTO HYPERTEXT 8 c : components c 2 ran accessor ran resolver = dom accessor 8 c : components (c ; c ) 2= ( subcomp ) 8 c : components 9 lids : F UID j lids = linksTo (PROTO HYPERTEXT ; accessor (c )) (9 spec set : F SPECIFIER j spec set = f s : SPECIFIER j 9 l : LINK ; lid : lids j l = (link base accessor )(lid ) s 2 ran l :speci ers ^ s :componentSpec = (resolver accessor )(c ) g (9 aid set : F ANCHOR ID j aid set = f aid : ANCHOR ID j 9 s : spec set aid = s :anchorSpec g rst (janchors (c )j) = aid set )) Only a subset of the specifiers involved in the link is determined (the set called spec set). All its elements refer to the same component c. The consistency control, verifying the presence in each component of the proper information concerning related links, can now be executed.
4
Operations on Links
In the model links represent the dynamic navigational aspect since they allow non-sequential connections between the components contained in its structure. So when a link is created the source and destination components should be told of this operation through an appropriate recording of the associated information. In the same way, in a component deletion the identification of the links referring to it is essential in order to allow a coherent update of the hypertext so as not to create the so-called “dangling links”. Concerning this issue, the Dexter Model presents some functions in support of link modification. We will show some cases in which the application of these functions is not completely correct, since it applies generally to a reduced and limited range of possibilities. In the hypertext definition the function linksTo is called in order to determine the UIDs of the links referring to a given component: UBLCS-94-1
8
4 Operations on Links
linksTo : PROTO HYPERTEXT UID ! F UID linksTo = ( H : PROTO HYPERTEXT ; u : UID f uid : UID j (9 comp : LinkComp j comp 2 H :components uid = H :accessor (comp ) ^ (9 s : COMPONENT SPEC j s 2 componentSpecs (comp ) u = H :resolver (s ))) g) where: LinkComp is a LINK component (i.e. a component whose BASE COMPONENT is a single link) as we can observe from its definition:
LinkComp COMPONENT compBase 2 ran link
componentSpecs is a partial function returning the set of specifications of the components involved in the given link. By the linksTo definition only LinkComps are considered in the search. This means that only single links are taken in account, overlooking their presence inside composite components. On the other hand, the BASE COMPONENT definition provides the presence of recursive structures by means of the composite mapping, so that composite components could have links inside their structures. As previously said, each whole component is given a UID: links inside composites do not have UIDs on their own and so it is not possible for them to be found through the linksTo function. In this sense, the Dexter Model is lacking in an exhaustive mechanism for link identification, thereby affecting the correct management of the system. This creates consistency problems in the deletion of components, creating “dangling links” within composites, leaving therefore undefined end-points in link crossing. We found a solution to this incompleteness by means of a new definition of the linksTo function:
linksTo : PROTO HYPERTEXT UID ! F LINK linksTo = ( H : PROTO HYPERTEXT ; u : UID f l : LINK j (9 comp : COMPONENT j comp 2 H :components ^ l 2 LinksOf (comp ) (9 cs : COMPONENT SPEC j cs 2 componentSpecs (l ) u = H :resolver (cs ))) g)
where LinksOf is a function returning the set of links appearing in the basic structure of a given component:
LinksOf : COMPONENT !7 F LINK 8 c : COMPONENT LinksOf (c ) = LinksIn (base (c ))
UBLCS-94-1
9
5
Modifications to the Hypertext
and LinksIn recursively searches through the subparts of a composite component.
LinksIn : BASE COMPONENT !7 F LINK 8 bc : BASE COMPONENT (bc 2 ran atom ) ) LinksIn (bc ) = ? ^ (bc 2 ran link ) ) LinksIn (bc ) = f link bc g ^ (bc 2 ran composite ) ) LinksIn (bc ) = S(LinksIn (jran(composite bc )j)) The said modifications affect the rest of the model, leading to a rapid update of some changes in definitions like componentSpecs, anchorSpecs and the HYPERTEXT schema. Also the linkConsistent definition would be modified in order to manage the consistency of links inside the hypertext framework correctly:
linkConsistent : P HYPERTEXT 8 H : HYPERTEXT linkConsistent H , (8 l : LINK ; s : SPECIFIER j (9 comp : COMPONENT j comp 2 H :components l 2 LinksOf (comp )) ^ s 2 ran l :speci ers (9 c : COMPONENT j c 2 H :components (H :accessor H :resolver )(s :componentSpec ) = c )) The above-mentioned changes affect either the modification or the deletion of components. In the next section we will show how to update the Dexter Model in order to support them consistently.
5
Modifications to the Hypertext
Within the model the modification of components is allowed by the ModifyComponent definition. To store a modified component, the model replaces the old instance with the new one. UBLCS-94-1
10
5
Modifications to the Hypertext
ModifyComponent : HYPERTEXT UID COMPONENT ! HYPERTEXT 8 H : HYPERTEXT ; uid : UID ; c 0 : COMPONENT 9 c : COMPONENT ; H 0 : HYPERTEXT j c = H :accessor (uid ) ^ H 0 :components = H :components n f c g [ f c 0 g ^ H 0 :accessor = H :accessor f uid 7! c 0 g ^ H 0 :resolver = H :resolver ^ info (c 0) = info (c ) ^ c typeConsistent c 0 ^ linkConsistent H 0 ModifyComponent (H ; uid ; c 0) = H 0 In the original definition the new component is assigned the same COMP INFO as the one it replaces. The replacement operation cannot be considered correctly made since the old component may have been modified in the attributes and anchors. Just as in the linkConsistent operation, referring to the consistency of connections between nodes, the introduction of the new definition anchorConsistent deals with checking the correct presence of anchors inside components. This definition relies on a function, called Aaccessor, which allows access to an anchor given the ANCHOR ID of the anchor and the UID of the component it belongs to.
Aaccessor : UID ANCHOR ID 7 ANCHOR
anchorConsistent : P HYPERTEXT 8 H : HYPERTEXT anchorConsistent H , (8 c : COMPONENT ; a : ANCHOR ; uid : UID ; aid : ANCHOR ID j a = H :Aaccessor (uid ; aid ) ^ c = H :accessor (uid ) a 2 anchors (c ) ^ (9 l : LINK ; s : SPECIFIER j l 2 LinksOf (c ) ^ s 2 ran l :speci ers s :componentSpec = H :resolver (uid ) ^ s :anchorSpec = aid )) The above definition verifies each anchor belonging to a component as being an end-point of at least one link in the hypertext. Consequently, the ModifyComponent definition will be replaced by the following: UBLCS-94-1
11
5
Modifications to the Hypertext
ModifyComponent : HYPERTEXT UID COMPONENT ! HYPERTEXT 8 H : HYPERTEXT ; uid : UID ; c 0 : COMPONENT 9 H 0 : HYPERTEXT j (9 c : COMPONENT ; di Anchors : F ANCHOR j c = H :accessor (uid ) di Anchors = ran(info (c )):anchors n ran(info (c 0)):anchors ^ 0 H :components = H :components n f c g [ f c 0 g ^ H 0:accessor = H :accessor f uid 7! c 0 g ^ H 0:resolver = H :resolver ^ H 0:Aaccessor = H :Aaccessor ? B di Anchors ^ 0 c typeConsistent c ^ anchorConsistent H 0 ^ linkConsistent H 0 ) ModifyComponent (H ; uid ; c 0) = H 0 Concerning the deletion of components, the Dexter Model presents the operation DeleteComponent. According to the previously introduced modifications about link and anchor management, a new policy will be kept regarding elimination operations. The following definition represents the new formulation of DeleteComponent:
DeleteComponent : HYPERTEXT UID ! HYPERTEXT DeleteComponent = ( H : HYPERTEXT ; uid : UID ( H 0 : HYPERTEXT j 9 H1 : HYPERTEXT ; links : F LINK j links = linksTo (H ; uid ) ^ H1 = deleteLinks (H ; links ; uid ) H 0 :components = H1 :components n f H :accessor (uid ) g ^ 0 H :accessor = f uid g C ? H1 :accessor ^ H 0 :resolver = H1:resolver ? B f uid g ^ H 0 :Aaccessor = H1:Aaccessor ^ anchorConsistent H 0 ^ linkConsistent H 0 )) When a component leaves out the hypertext domain, the updating of its navigational connections is necessary. Besides the deletion of the related links, the components involved should be updated regarding the anchors representing their end-points. Since the Dexter Model provides multi-directional links by means of sequences of specifiers, when eliminating a connection between two components only the deletion of the specifiers involved with the above-mentioned elements is appropriate. In this way the remaining structure of the link would be kept unchanged, leaving the other connections possible. This operation will be realized by means of the deleteSpecifiers and deleteLinks definitions. UBLCS-94-1
12
5
Modifications to the Hypertext
deleteSpeci ers : HYPERTEXT LINK UID ! seq SPECIFIER 8 H : HYPERTEXT ; l : LINK ; uid : UID 9 new spec seq : seq SPECIFIER j (9 spec set ; new spec set : F SPECIFIER j spec set = f s : SPECIFIER j s 2 ran l :speci ers ^ s :componentSpec = H :resolver (uid ) g new spec set = ran l :speci ers n spec set ^ new spec seq = l :speci ers new spec set ) deleteSpeci ers (H ; l ; uid ) = new spec seq
deleteLinks : HYPERTEXT F LINK UID ! HYPERTEXT 8 H : HYPERTEXT ; l set : F LINK ; uid : UID (l set = ? ) deleteLinks (H ; l set ; uid ) = H ) ^ (l set 6= ? ) (9 H 0 : HYPERTEXT ; new l set : F LINK j (8 l : LINK j l 2 l set (9 c : COMPONENT ; new spec seq : seq SPECIFIER j c 2 H :components ^ l 2 LinksOf (c ) new spec seq = deleteSpeci ers (H ; l ; uid ) ^ (#new spec seq 2 ^ (9 s : ran new spec seq s :direction = TO )) ) H 0 = replaceLink (H ; l ; new spec seq ; c ) ^ (#new spec seq < 2 _ (8 s : ran new spec seq s :direction 6= TO )) ) H 0 = removeLink (H ; l ; c ) ^ new l set = l set n f l g)) deleteLinks (H ; l set ; uid ) = deleteLinks (H 0; new l set ; uid ))) Furthermore, if the deletion of specifiers leads to a sequence which no longer corresponds to a LINK then the complete link has to be removed or replaced by the updated one (functions removeLink and replaceLink). UBLCS-94-1
13
5
Modifications to the Hypertext
removeLink : HYPERTEXT LINK COMPONENT ! HYPERTEXT 8 H : HYPERTEXT ; l : LINK ; c : COMPONENT 9 H 0 : HYPERTEXT j (9 H1 : HYPERTEXT j (isLink c ) H1 :components = H :components n f c g ^ H1 :accessor = f H :accessor (c ) g C ? H :accessor ^ H1 :resolver = H :resolver ? B f H :accessor (c ) g ^ H1 :Aaccessor = H :Aaccessor ) ^ (isComposite c ) (9 new base : F BASE COMPONENT ; new base seq : seq BASE COMPONENT ; c 0 : COMPONENT j new base = ran(composite (base (c ))) n f link (l ) g ^ new base seq = (composite (base (c ))) new base ^ (#new base seq = 1 ) (9 bc : BASE COMPONENT j bc = new base seq (1) c 0 = component (bc ; info (c )))) ^ (#new base seq > 1 ) c 0 = component (composite (new base seq ); info (c ))) H1 :components = H :components n f c g [ f c 0 g ^ H1 :accessor = H :accessor f H :accessor (c ) 7! c 0 g ^ H1 :resolver = H :resolver ^ H1 :Aaccessor = H :Aaccessor )) H 0 = deleteLinkAnchors (H1; ran l :speci ers )) removeLink (H ; l ; c ) = H 0 replaceLink : HYPERTEXT LINK seq SPECIFIER COMPONENT ! HYPERTEXT 8 H : HYPERTEXT ; l : LINK ; new spec seq : seq SPECIFIER ; c : COMPONENT 9 H 0 : HYPERTEXT j (9 H1 : HYPERTEXT ; c 0 : COMPONENT ; old spec set : F SPECIFIER ; l 0 : LINK j l 0:speci ers = new spec seq ^ (isLink c ) c 0 = component (link (l 0); info (c ))) ^ (isComposite c ) (9 new base : F BASE COMPONENT ; new base seq : seq BASE COMPONENT j new base = ran(composite (base (c ))) n f link (l ) g ^ new base seq = ((composite (base (c ))) new base ) a hlink (l 0)i c 0 = component (composite (new base seq ); info (c )))) H1:components = H :components n f c g [ f c 0 g ^ H1:accessor = H :accessor f H :accessor (c ) 7! c 0 g ^ H1:resolver = H :resolver ^ H1:Aaccessor = H :Aaccessor ^ old spec set = ran l :speci ers n ran new spec seq ^ H 0 = deleteLinkAnchors (H1; old spec set )) replaceLink (H ; l ; new spec seq ; c ) = H 0 Within their structure removeLink and replaceLink use the deleteLinkAnchors function in order to permit, in the anchors sequence, the deletion of those anchors belonging to components UBLCS-94-1
14
6 Anchoring in Dexter
involved in the eliminated link. Each of these components is replaced by an analogous one merely differing in the informative part.
deleteLinkAnchors : HYPERTEXT F SPECIFIER ! HYPERTEXT 8 H : HYPERTEXT ; spec set : F SPECIFIER (spec set = ? ) deleteLinkAnchors (H ; spec set ) = H ) ^ (spec set 6= ? ) (9 H 0 : HYPERTEXT ; new spec set : F SPECIFIER j (8 s : SPECIFIER j s 2 spec set (9 c ; c 0 : COMPONENT ; a : ANCHOR ; new anchors : F ANCHOR ; new seq : seq ANCHOR j c = (H :accessor H :resolver )(s :componentSpec ) ^ a = H :Aaccessor (H :resolver (s :componentSpec ); s :anchorSpec ) ^ new anchors = ran(info (c )):anchors n f a g ^ new seq = (info (c )):anchors new anchors ^ base (c 0) = base (c ) ^ (info (c 0)):attributes = (info (c )):attributes ^ (info (c 0)):anchors = new seq ^ (info (c 0)):presentSpec = (info (c )):presentSpec H 0 :components = H :components n f c g [ f c 0 g ^ H 0 :accessor = H :accessor f H :accessor (c ) 7! c 0 g ^ H 0 :resolver = H :resolver ^ H 0 :Aaccessor = H :Aaccessor ? Bfa g^ new spec set = spec set n f s g)) deleteLinkAnchors (H ; spec set ) = deleteLinkAnchors (H 0; new spec set ))) After the above introduced modifications, the new version of the Dexter Model allows for the correct management of any kind of operations on the hypertext framework.
6
Anchoring in Dexter
As we have previously explained, an anchor is a persistent data selection inside a component. It allows for steady references to worthwhile parts of a document even when closing a session [Mai92]. Each element of the hypertext is provided with the sequence of its related anchors (in the COMP INFO part), representing possible end-points of links or interesting pieces of data. In the Dexter Model, all structures dealing with anchors only deal with ANCHOR IDs. The COMP INFO schema stores full ANCHORs, i.e. pairs of ANCHOR IDs and ANCHOR VALUEs, being therefore responsible for storing the table with which ANCHOR IDs are mapped to ANCHOR VALUEs. Another structure particularly related to anchors is the SPECIFIER. A sequence composed of a variable number (greater than 2) of specifiers allows for multiple end-point links. Commendably, the Dexter Model does not store the UID of the end-point component in the specifier, but a COMPONENT SPEC, which is mapped to the corresponding UID via UBLCS-94-1
15
6 Anchoring in Dexter
the resolver function. This indirect addressing, among other things, allows for the creation of computed links, i.e. links for which one or more end-points need to be computed at runtime [Bie91]. Therefore, links can connect different components depending on the context, since in different moments the resolver function may provide different UIDs for the same COMPONENT SPEC. On the other hand, anchors are stored statically in the specifiers, i.e. a specific ANCHOR ID is stored in the SPECIFIER structure. This somewhat voids the usefulness of the dynamic resolution of the COMPONENT SPEC. In order to determine the ANCHOR VALUE associated to the corresponding ANCHOR ID of the specifier, it is necessary to examine the anchors sequence in the COMP INFO of the indicated component, finding a match among the other ANCHOR IDs. This technique assumes a strong consistency in the anchor management, mantaining the same ANCHOR IDs for all the anchors associated with each component [Ore87]. This imposes a heavy constraint of unicity over ANCHOR ID, even though it is said that the scope of unicity for ANCHOR IDs is the node: whenever a COMPONENT SPEC needs to be dynamically evaluated, an ANCHOR ID must be issued that has never been used in all interested nodes (possibly all the nodes of the hypertext) and will never be used again in the future for different links. This is clearly excessive. Furthermore, in an anchor search operation the presence of the corresponding ANCHOR ID (provided by the anchorSpec field of the SPECIFIER) is supposed to be absolutely certain. This assumption might be wrong in two possible cases: in the anchors sequence the anchor corresponding to the given ANCHOR ID does not exist. the anchor is present in the sequence but the related value (ANCHOR VALUE) does not fit the requirements. These situations might lead to the presence of “dangling links” besides incorrect search and finding of anchors in the hypertext. Therefore, we propose to proceed with anchors as well as components, i.e. have the ANCHOR ID obtained dynamically by a runtime evaluation of a specification. This means not storing an ANCHOR ID, but an anchor specification in the specifier, which can then be mapped to the corresponding ANCHOR ID at runtime along with the component UID. For this purpose we can introduce a new function, AIresolver, which, given an ANCHOR SPEC and the UID yielded by the resolver, returns the corresponding ANCHOR ID.
SPECIFIER componentSpec : COMPONENT SPEC anchorSpec : ANCHOR SPEC presentSpec : PRESENT SPEC direction : DIRECTION AIresolver : UID ANCHOR SPEC !7 ANCHOR ID This new function needs to be stored in the PROTO HYPERTEXT definition. This alternative choice for anchor identification is based on the concept followed for the resolver function. This method allows for yielding and dynamic queries in the hypertext domain. Indeed, in different moments different results may occur. UBLCS-94-1
16
7
7
External Anchoring
External Anchoring
The Dexter Model explicitly supports hypertext systems where the link end-points storage is local to the nodes the links refer to. For instance, in an external table stored along with the node, or as tags directly within the node. This last method is also suggested by the fact that the update of ANCHOR VALUEs is never considered, but it is thought of as being automatic; i.e. happening during the editing of the node. In the considered model ANCHOR IDs are used in all possible cases leaving ANCHOR VALUEs only stored by the owning component in the anchors sequence of COMP INFO. These ANCHOR VALUEs are easily obtained, however, when the corresponding ANCHOR IDs are known. Anyway, not all real life hypertext systems implement span-to-span links as stored in local tables or directly within the nodes themselves. Their policy of storing ANCHOR VALUEs differs largely from that of the nodes. Anchor management represents an independent operation also providing various techniques for updating. In particular, these systems allow links to store the ANCHOR VALUEs directly, so that direct access to the correct position of the node can take place. It is our opinion that a standard formal model, as the Dexter Model intends to be, should be general enough to comprise even this kind of system. Therefore, a description of these mechanisms should be provided in order to handle both systems supporting traditional issues and systems storing ANCHOR VALUEs within links and requiring explicit update policies. For this purpose, a very small modification to the model is needed. Systems enforcing an external anchoring mechanism must directly access the ANCHOR VALUE part of the anchor, since the component does not contain any reference to the anchor (it is, indeed, external); it is simply necessary to map the anchor specification, given by the anchorSpec field of the considered link, directly to the ANCHOR VALUE. This could be realised by the introduction of an appropriate function:
AVresolver : UID ANCHOR SPEC !7 ANCHOR VALUE The above definition is directly related to the introduction of the AIresolver function, both allowing differentiated specifications depending on different anchoring policies adopted by hypertext systems. With external anchoring, anchor updating is no longer a vague task, but must be explicitly issued: it must be done when “saving” the component, i.e. in the realizeEdits function, in systems such as Intermedia or Sun’s Link Service or Microcosm; it belongs to the AVresolver function itself in systems such as Xanadu or RHYTHM. Three different anchor updating policies can be found: Anchors are kept within the component and are automatically updated while the instantiation is edited. This is the system to which the Dexter Model implicitly refers. No explicit anchor update function is required, because it is assumed that the trasformation from the original instantiation to the modified one handles the problem automatically. This may happen, for instance, because the anchor end-points are inserted within the data. The data format is tailored for hypertext use and anchor update is just a by-product of data editing. Anchors are kept outside the component and are updated when the edited instantiation is saved. An explicit anchor update function is required in the realizeEdits step, so that UBLCS-94-1
17
8
Conclusions
the table is committed. This function can only be issued by the RunTime Layer to the instantiation, so that it can track the movements of anchors during edits. Open hypertext systems, which do not have control over the data format of the components, use this mechanism. The actual editors can still use their own data format, but they should “behave well” in order for the link system to update the data of the end-points correctly. Anchors are kept outside the component and are updated only when the document is accessed again. An explicit anchor update function is required when the document is accessed again. This may be done through versioning, as Xanadu or RHYTHM do, because the system has to know how to track anchors to the latest version. This is particularly useful when a distributed system is implemented, in which a centralised link base is impractical and remote components should be linked even though a write access right is not available. In the RunTime Layer, editing consists in substituting a component INSTANTIATION with another one. In this operation, however, there are no consistency requirements. Unfortunately, this is an unacceptable simplification: anchors have to be correctly updated within the instantiation step. This may be a task which is intrinsically carried over during the editing phase, or an explicit task to be carried over at the end of the editing phase. Indeed, this may even happen only when the anchor is actually accessed, such as in RHYTHM or in Xanadu. Nonetheless, it is a task which cannot be forgotten.
8
Conclusions
After the introduction of the Dexter Model many hypertext systems have come out that do not completely fit within its framework. Therefore, some small amendments are needed for the sake of generality and completeness. The main reason for these modifications is due to our difficulties in relating our hypertext system, RHYTHM, to the said model. RHYTHM (Research on HYpertext THeory and Management) is a prototypical hypertext system under development at the University of Bologna. RHYTHM implements external anchors both for navigational links and for inclusion. Because of external links, it was very difficult to relate RHYTHM to Dexter. External anchoring contrasts with Dexter’s current attitude towards anchoring, yet it is commonly implemented in many hypertext systems (for instance Microcosm [Dav92]), and it is essential when dealing with free linking in read-only data (es. CD-ROM, cfr. [Ore87]), with open hypertext systems (cfr. [Dav92]) or widely distributed systems (cfr. [Mai93], [Ore90]). Our contribution to a complete definition of the anchoring mechanism has led to the introduction of new Z schemata and axiomatic definitions in the Dexter Model. Furthermore, several definitions have been revised through modifications regarding misconceptions and inadequacies found in the model. These changes have involved deletion and modification operations as well as link and anchor management. It is our opinion that a formal hypertext model should allow for the representation of all the different policies adopted by the various existing systems. This is especially important for the Dexter Model, which is considered to be the general basis for an interchange mechanism. UBLCS-94-1
18
REFERENCES
References [Aks89] R. Akscyn, F. Halasz, T. Oren, V. Riley, L. Welch: Interchanging Hypertexts. Panel of the Hypertext ’89 Conference, ACM, Pittsburgh (PE), 1989 [Bie91] M. Bieber: Issues in Modelling a “Dynamic” Hypertext Interface. Proc. of the Hypertext ’91 Conference, ACM, San Antonio (TX), 1991 [Dav92] H. Davis, W. Hall, I. Heath, G. Hill, R. Wilkins: Towards an Integrated Information Environment with Open Hypermedia Systems. Proc. of the ACM Conference on Hypertext ECHT ’92, Milano (I), 1992. [Gar91] F. Garzotto, P. Paolini, D. Schwabe: HDM: A Model for the Design of Hypertext Applications. Proc. of the Hypertext ’91 Conference, ACM, San Antonio (TX), 1991 [Glu92] R.J. Glushko: Hypertext and Multimedia for Managers. ECHT ’92 Tutorial, Milano (I), 1992 [Grø92] K. Grønbæk, R.H. Trigg: Design Issues for a Dexter-based Hypermedia System. Proc. of the ACM Conference on Hypertext ECHT ’92, Milano (I), 1992 [Hal90] F. Halasz, M. Schwartz: The Dexter Hypertext Reference Model. Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990 [HKo90] S.L. Hardt-Kornacki, L.M Gomez, J.F Patterson: Standardization of Hypermedia: What’s the Point? Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990 [Kil90] R. L. Killough, J. J. Leggett: Hypertext Interchange with the Dexter Model: Intermedia to KMS. Technical Report TAMU-HRL 90-002, Texas A&M University, 1990 [Lam92] S. Lamberti, C. Maioli, F. Vitali: Some Modifications to the Dexter Hypertext Reference Model. T.R. n. 7/115, P.F. Sistemi Informatici, CNR (Italy), 11/92 [Mai91] C. Maioli, F. Vitali: Authoring tool development with the RHYTHM hypertext system. AICA 91, Siena, 9/91 [Mai92] C. Maioli, F. Vitali: Anchors and Paths in a Hypertext Publishing System. AICAText’92 Proceedings, AICA, Milano, 3/92 [Mai93] C. Maioli, S. Sola, F. Vitali: Wide-Area Distribution Issues in Hypertext Systems. ACM SigDoc ’93 Conference Proceedings, ACM, Kitchener (Canada), 1993 [Nel90] T.H. Nelson: Literary machines. 90.1, Mindful Press, Sausalito (CA) 1990 [Ore87] T. Oren: The Architecture of Static Hypertexts. Proc. of the Hypertext’87 Conference, ACM, Chapel Hill (NC, USA) [Ore90] T. Oren: Towards Open Hypertext: Requirements for Distributed Hypermedia Standards. Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990 [Spi92] M. Spivey: The Z Notation. A Reference Manual. Second Edition. Prentice-Hall, 1992 [VDP90] H. Van Dyke Parunak: Reference and data Model group (RDMG): Work Plan Status. Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
UBLCS-94-1
19
