\documentstyle[myzed,twocolumn]{myarticle}
\pagestyle{empty}

\setlength{\textheight}{8.75in}
\setlength{\columnsep}{2.0pc}
\setlength{\textwidth}{6.8in}
\setlength{\footheight}{0.0in}
\setlength{\topmargin}{0.25in}
\setlength{\headheight}{0.0in}
%\setlength{\headsep}{0.0in}
\setlength{\headsep}{-0.3in}
\setlength{\oddsidemargin}{-.19in}
\setlength{\parindent}{1pc}

\makeatletter

\def\@normalsize{\@setsize\normalsize{10pt}\xpt\@xpt
\abovedisplayskip 10pt plus2pt minus5pt\belowdisplayskip
\abovedisplayskip
\abovedisplayshortskip \z@ plus3pt\belowdisplayshortskip 6pt plus3pt
minus3pt\let\@listi\@listI}

\def\subsize{\@setsize\subsize{12pt}\xipt\@xipt}

\def\section{\@startsection {section}{1}{\z@}{1.0ex plus 1ex minus
.2ex}{.2ex plus .2ex}{\large\bf}}

\def\subsection{\@startsection {subsection}{2}{\z@}{.2ex plus 1ex}
{.2ex plus .2ex}{\subsize\bf}}
\makeatother

\bibliographystyle{alpha}

\begin{document}

\input{myhyphen}

%don't want date printed
\date{}

%make title bold and 14 pt font (Latex default is non-bold, 16 pt)
%\title{\Large\bf My Wonderful Article in IEEE Format}

\title{\Large\bf Using a Reference Model for Information System 
Compatibility: \newline an Experience\setcounter{footnote}{0}\thanks{This 
work has been
developed within the Progetto Finalizzato CNR ``Sistemi Informatici
e Calcolo Parallelo'', Subproject \#7 ``Sistemi di Supporto al
Lavoro Intellettuale'' and ESPRIT Project \#6763 ``Document 
Logistics''}}

\author{${\rm Cesare}$ ${\rm Maioli^{1}}$, ${\rm Wilma}$ ${\rm Penzo^{1}}$,
${\rm Stefano}$ ${\rm Sola^{2}}$, ${\rm Fabio}$ ${\rm Vitali^{2}}$ \\[.25in]
\noindent
1) Computer Science Dept., 
University of Bologna, ITALY
\\
\noindent
2) CIRFID, University of Bologna, ITALY \hspace{1.1in} \\
}


\maketitle

%I don't know why I have to reset thispagesyle, but otherwise get page
%numbers

\thispagestyle{empty}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% RISISTEMO IL BORDO

%\setlength{\headsep}{0.0in}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{sloppypar}

\subsection*{\centering Abstract}

\noindent
{\em
Because of the rapid pace of advances in the field of hypertext,
data interchange systems are becoming important for the
longevity of information systems based on hypertext or including
hypertext features. Reference models, identifying those traits
that are common to all systems of a certain kind, allow us to
create an intermediate data format useful for data interchange. 
The Dexter Hypertext Reference Model
appears the most apt to capture all the different aspects of hypertext
systems. 
In this paper we present some issues that are central in
developing the interchange procedure between a hypertext
information system and the Dexter model, examine some of the
difficulties we faced when dealing with Dexter, and sketch, as
an example, the formal model of our hypertext system RHYTHM
along the lines of the Dexter Model.
With a little elasticity and some minor modifications, we were able to
generate a satisfactory model of RHYTHM, and this shows
that Dexter has a very robust structure capable of
dealing with an unexpectedly large class of hypertext systems.
}

\section{Introduction} 

\vspace{1ex}
Information systems that are beginning to use hypertext systems for
central or secondary tasks are bound to depend on architectural
choices that may have drastic effects in the future. Hypertext
technology is still in its infancy, its core and boundaries have yet
to be unanimously defined: new systems are realised, new technologies
come into widespread use and new user requirements are presented that
make current decisions appear premature and inadequate for the future.
Whether
an information system uses highly promising hypertext
prototypes, commercial systems, or \mbox{in-house} approaches, the chances are
that in a few years they will all become obsolete because of the
speed of progress in this specific and in related fields.
The reuse of information in different applications (not necessarily
hypertexts), the possibility of showing the same hypertext on
different platforms and/or presenting it with different hypertext programs,
is essential for information managers \cite{Glushko}.
Reference models provide a general though indirect solution
to ensuring a long useful life to an information system; they
allow us to map functionals and data structures between
different applications, thereby smoothing the transition to
newer or more powerful ones.

Since reference models identify only those traits that are
common to all relevant systems, hypertext reference models
will concentrate on their key features: data
organisation (i.e., {\em nodes\/}) and data connection (i.e.,
{\em links\/}).
The Dexter Reference Model, deriving from of a series of workshops
attended by many important professionals in the hypertext
field, is the most widely accepted hypertext reference model.
The large
number of contributors (most of whom are architects of important
existing hypertext systems) and its generality and completeness of
vision helped the model assume an important role in the
hypertext community. The usefulness of the Dexter Model was stressed
by a panel at Hypertext '89 \cite{Akscyn} and was later used as a
paradigm for comparing systems (for instance in \cite{Schutt},
\cite{Bieber}, \cite{Garzotto91} and \cite{Frisse}).

In \cite{Gron} the realisation of a hypertext system following the
strict guidelines of the Dexter Model is described. Even though
some unforeseen pitfalls in the original Dexter Model were exposed,
an interesting hypertext system was created, clearly thanks
to the generality of the model itself. Interesting results were
obtained regarding the Dexter Model {\em per se\/}: the emphasis on
avoiding dangling links is considered excessive and the encapsulation of
components within composites is said to inhibit using external objects
within the hypertext environment.

In \cite{Killough}, Killough and Leggett used Dexter as the
intermediate format for a hypertext interchange procedure, 
at present limited to the interchange between Intermedia and KMS. Since
Dexter was the interchange format, two procedures were needed
to obtain the translation, {\em IIF2Dexter\/} (Intermedia Interchange
Format is the output format of the Transfer facility of Intermedia) and
{\em Dexter2KMS\/}. The whole interchange testbed
foreseen in \cite{Killough} comprises systems such as Intermedia, KMS,
Notecards, Hypercard and Guide. Many (if not all) of their main
architects took part in the committee that originally delivered the
Dexter
Model. It is therefore hardly surprising that the Dexter Model
is an adequate intermediate interchange format for those systems and
those that they closely resemble.

On the other hand, there are hypertext systems that present
great differences from the systems described in the Dexter
Model, and information systems that are not primarily
hypertext-based but present some features that have a clear
hypertext flavour. We believe these systems to be the real
test for the generality of the Dexter Model, and an important
issue to be that of verifying whether Dexter can be used for
their formalisation.

\mbox{In ~this ~paper ~we ~will ~stress ~the importance of} 
\mbox{reference
~models ~for ~the ~integration ~of ~hypertext} 
\mbox{functionalities ~~within
~~information ~~systems, ~with} 
\mbox{particular ~~~regard ~~to ~~~compatibility
~~and ~~~data} interchange issues. 

Because of their generality,
reference models need to be adapted and completed. Systems
that differ widely from those that inspired Dexter need
particular care in doing so, since finding the correct way may
be somewhat tricky.

As an example, this paper would like to present our
successful attempts to adapt the model to RHYTHM, a hypertext system
that is currently being developed at the University of Bologna.
For various reasons RHYTHM differs widely from the aforementioned
hypertext systems, both in its features and basic structures. We feared
that Dexter could not be used to model RHYTHM, and that
interchange to and from RHYTHM should take other forms. However, this
work
proved that Dexter is robust and general enough for RHYTHM,
although a few corrections and secondary modifications were carried out.
Indeed,
our modifications neither change Dexter's basic philosophy
nor detract from its generality. On the contrary, we found it very
easy to implement our main modifications to the model: allowing
anchors to be stored externally (and therefore remotely) to
the node they refer to, just like often happens in distributed or
open hypertext systems.

To allow our system to be modelled along the lines of Dexter,
we first corrected and generalised Dexter to
include a larger class of hypertext systems (most notably, those
employing external anchors), while maintaining the generality and
incompleteness of a good reference model; then we specified RHYTHM
in Dexter terms, despite their apparent dissimilarities.


We hope that these efforts will convince information
system managers of the usefulness, soundness and robustness of the
Dexter Model, and that our modified model will be the basis for an
evolving and developing view of a complete reference model. Some new
hypertext features still have to be integrated (including
distribution support, multi-user creation and multi-authored
note taking), some others will have to be made possible by appropriate
spaces (we are particularly interested in versioning,
inclusion and innovative access mechanism such as browsers).

This paper will summarise the efforts needed to adapt Dexter
to largely different hypertext systems or information systems
employing hypertext features. In the next section we will
briefly introduce the basic steps that need to be taken when
applying hypertext features to information systems by means of
reference models. In section 3 we will briefly introduce the
Dexter Model. Section 4 is devoted to the modifications to
Dexter being in our opinion general enough to be
included in the Model itself. Section 5 and 6 use RHYTHM as
an example of this adaptation: we will first introduce
RHYTHM's basic features and then show the most prominent points
of our specific model.

\section{Information systems and reference models}

\vspace{1ex}
A reference model is a structured description of a domain used to
compare existing implementations, design new ones and map out possible
areas for standardisation \cite{Parunak}. Reference models come in handy
when defining and describing the boundaries and basic features of a
field and help to provide a more formal and structured approach in
designing new systems and in relating them to existing ones.
Finally, they may help to define a transition from an older
system to a newer one.

Reference models (RMs) are an aid towards standardisation,
but are not standards in themselves. Indeed, as \cite{Crane} notes,
long-lived standards can only emerge after we know much more about
how people use hypermedia. The field of hypertext is still young
and many major advances can be expected within the next few years.
A premature effort to standardise may inhibit innovation
(\cite{Hardt}, \cite{Oren90}), while hypertext RMs may lead in
the right direction, helping to integrate them into a general
understanding of what constitutes the hypertext field.
Furthermore, RMs are not full formal models: they aim to model
only common features of different systems, present and future, and do
not specify
any of them in full. Therefore an RM is by nature incomplete
and general, explicitly leaving provisions for the detailed
specification of each system.

RMs are an invaluable aid in defining standards for interoperability and
data interchange. They provide
a clear and simplified path for transferring data between systems:
they can be used either to modernise an information system by
moving all the data to a new hypertext system, or for the
regular exchange of data in both directions between two
different systems that are used for different purposes or in
different parts of the same enterprise.

In a certain sense, therefore, they provide some solutions for managing
information systems: whether a specific hypertext system is to be chosen
that will clearly be obsolete in a few years, or it is decided
that two different hypertext systems be used in different
parts of the information system, the existence of a hypertext RM may
guarantee that current efforts will not be wasted in subsequent
upgrades and reunifications.

The interchange between different systems can be approached as
an {\em ad hoc\/} procedure which involves the case by case
determination of those functions that can be maintained,
those that need to be remapped to similar ones, and those that
will be lost. Furthermore, this procedure needs to be repeated
for all systems involved, thus making interchange a
complex process.
Otherwise, interchange may involve the 
determination of an
intermediate format that provides a framework for all specific
procedures. The intermediate format helps to limit
the number of interchange procedures between many
different systems, which would otherwise be needed from every source
system to every destination system. The number of different
combinations that have to be examined is therefore {\em n\/}
instead of {\em n(n-1)/2\/}.

The intermediate format may easily result from a reference
model. The Dexter Model, for instance, was explicitly devised
to produce such an intermediate format for hypertext.


After finding a proper reference model, the complete model of
the system can be obtained by completing and specifying the
parts that were incomplete or too general in the reference
model. This can be tricky if the system widely differs from
those that inspired the original model, as our experience
shows. In our case, this required a certain amount of
elasticity and fantasy, but the results were satisfactory.


Nodes and links are the key characteristics of hypertext
systems and systems with hypertext features. A complete model
along the
lines of Dexter will therefore try to define nodes
and links in Dexter terms, by separating the parts concerned with content,
storage and display of nodes and links with the aid of the
three layers at the core of the Dexter Model. Modelling will 
continue by filling in the blanks in the model: the Dexter 
Model is concentrated on more general issues
than data types, file systems and other specific computer-
related concepts. It is therefore necessary to specify Dexter
schemata down to commonly understood computer terms (for
example, JPEG or RTF data types, the operating system's filename
conventions, etc.).


An important step is then identifying where the system falls
short of the model: for instance, while the Dexter Model
allows \mbox{n-ary} links, many systems (including RHYTHM) only
allows two end-points for each link. All restrictions with respect to the
generality of the model should be carefully noted and pointed
out. This is important if the system being modelled is a
source of the interchange procedure, and becomes fundamental
when modelling the destination system. In this case, it is also
necessary to establish a policy for dealing with 
cases not covered by the system. For instance, since RHYTHM
allows link end-points to partially or totally intersect, the
policy would provide for an n-ary link to be transformed in as
many coinciding binary links as necessary.


\section{The Dexter Model}

\vspace{1ex}
In this section, we briefly introduce some concepts of the
Dexter Model, which we will amend and then apply in sections 4
and 6. The Dexter Hypertext Reference Model has been developed taking
many different hypertext systems into account, among which Augment,
Concordia, IGD, FRESS, Intermedia, Hypercard, Hyperties, KMS, HAM,
Notecards, Sun Link Service and Textnet. It is written using Z,
a set-based specification language \cite{Spivey92}. A small introduction
to some basic concepts of Z can be found in the appendix at the end of this paper.

Hypertext systems are divided into three layers, called {\em
within-component layer\/} (WCL), {\em storage layer\/} (SL) and 
{\em run-time layer\/} (RTL). The focus of the
model is the SL, where the basic node-link structure is represented
through the concept of {\em component\/}, generic containers of data,
collected in a database (the {\em hypertext\/}) and connected by
relational
{\em links\/}. The WCL concerns the internal representation of
application data
within the application components, while the RTL concerns the way these
components are shown on the screen and how the user interacts with
them. To obtain a relevant degree of generality, the WCL and the RTL
are only modelled superficially, since they are application-
dependent and are different in each system.

The SL is based on the concept of
components, which can either be atoms, links or arbitrary sequences
of other components, called {\em composites\/}.
Thanks to composites, a certain freedom
in composition is obtained and it is possible to create new first class
structures
in the hypertext database as collections of simpler ones. While the
content is contained in the schema BASE\_COMPONENT, a schema is
devoted to handling properties of the components, COMP\_INFO, and an
identifier, UID, is uniquely associated with the components via the
accessor function:

\begin{zed}
BASE\_COMPONENT ::= atom \ldata ATOM \rdata \\
\t1              |  link \ldata LINK \rdata \\
\t1              |  composite \ldata \seq BASE\_COMPONENT \rdata
\end{zed}

\vspace{-.5ex}

\begin{schema}{COMPONENT}
compBase : BASE\_COMPONENT \\
compInfo : COMP\_INFO
\end{schema}

\vspace{-.5ex}

\begin{zed}
accessor : UID \pinj COMPONENT
\end{zed}

\noindent
A link is a sequence of specifiers, which are structures used to refer
to the whole or some specific parts of an existing component.
For our purposes, the Dexter specifier is a key concept: it captures
the essence of link end-points. Each specifier refers to a component,
and within it to an anchor, i.e., a specific point (some words, a
place, some objects) within the component to which the link is
attached. The direction field is used to model the
direction of links, which are directed arcs in some systems, two-way
connections in others and can be simple bookmarks in others.

Presentation specifications provide a generic way of
handling different policies in showing link markers (signs for the user
of the existence of a link).

\begin{syntax}
DIRECTION & ::= & FROM | TO \\
	  &  |  & BIDIRECT | NONE
\end{syntax}

\begin{schema}{SPECIFIER}
componentSpec : COMPONENT\_SPEC \\
anchorSpec : ANCHOR\_ID \\
presentSpec : PRESENT\_SPEC \\
direction : DIRECTION
\end{schema}

\vspace{-.5ex}

\begin{schema}{LINK}
specifiers : \seq SPECIFIER
\where
\# specifiers \geq 2 \\
\exists s : \ran specifiers @ s.direction = TO
\end{schema}

\vspace{-.5ex}

\begin{zed}
resolver : COMPONENT\_SPEC \pfun UID
\end{zed}

\noindent
A component is usually referred to by the UID, an unique identifier
that allows direct access to it. Specifiers store a component
specifier, which is mapped onto the relevant UID through the resolver
function. 

This is very important because it allows links to store virtual
references, which can change over time and act as dynamic queries. In
many systems (Hypercard is the
clearest example) a link is not stored as a connection between two
fixed nodes, but is computed at run-time executing a script (e.g. in
Hypercard: ``Goto card number a+b+c'', where values a, b, and c
may change over time).


Anchors represent a way of modelling span-to-span links, i.e., those that
connect a specific part of a node (a word, an object, a place)
to a different specific part of the destination node. The
anchors are used to represent the said part of the nodes.
Specifiers only store the identifier, while in the component a table of anchors
helps to map the identifier to the corresponding value.

\begin{zed}
ANCHOR == ANCHOR\_ID \cross ANCHOR\_VALUE
\end{zed}

\vspace{-.5ex}

\begin{schema}{COMP\_INFO}
attributes : ATTRIBUTE \pfun VALUE \\
anchors : \seq ANCHOR \\
presentSpec : PRESENT\_SPEC
\where
\# anchors = \# (first \limg anchors \rimg)
\end{schema}

\noindent
It is to be noted that specifiers use a very general mechanism
to refer to components, which can change dynamically over time,
but permanently store the identifier of the specific anchor: different
components that at different times become end-points of the same
link must share the same anchor identifier.
A critical piece of the Model is the interface between SL and WCL:
ATOMs and ANCHOR\_VALUEs are important in the Storage Layer but are not
modelled because they are specific to each hypertext system, since
they depend on the internal characteristics of the components.

The main Run-Time Layer concept is that of the
instantiation of a component, which is shown on the screen and interacts
directly with the user. Anchors are instantiated in link markers,
but there is no strict relation between the anchor defined in a
component and the marker shown in the instantiation: this means that
we are free to use the concept of anchor for more things than just
navigational links: for instance, to define bookmarks, notes,
script activators, etc.

\begin{schema}{INSTANTIATION}
base : BASE\_INSTANTIATION \\
links : \seq LINK\_MARKER \\
linkAnchor : LINK\_MARKER \fun ANCHOR\_ID
\where
\dom linkAnchor = \ran links
\end{schema}

\section{Modifications, adaptations and additions to Dexter concepts}

\vspace{1ex}
Many obstacles can be found in using Dexter to create the complete
model of a hypertext system. Some of these problems are apparent,
and can be resolved by the careful use of existing Dexter structures
(e.g. in our case, Dexter's node-link structure is very different from
RHYTHM's virtual
reference list); others are due to specific features of the system
not considered by Dexter (e.g. users and group handling) because of
generality. Others involve further
specifications of existing structures (e.g. inclusion links or
distribution support). In the next section we will describe our own
experience in facing these kinds of problems for our system,
RHYTHM. Whereas, in this section we would like to describe 
some problems that in our opinion have some kind of generality,
so that our solutions should be considered modifications to
the Dexter Model {\em per se\/}, rather than adaptations of it to a
specific purpose. However, this is not the place for a lengthy
discussion, so we will only hint at some problems and our
proposed solutions.

For instance, Dexter allows links to be part of composites, but then
avoids checking link properties on these: only LinkComps (i.e.,
components, the BASE\_COMPONENT of which is only one LINK) are checked
in various functions like linksTo, linkConsistent, etc. Indeed,
LinksToAnchor returns the UID of the links associated with a given
anchor, but links belonging to a composite may not have a UID of
their own, since they have been used as an element within its
BASE\_COMPONENTs, and a UID is only associated with the whole
composite. We have reformulated all these functions to take into
account links belonging to composites. The full schemata are
somewhat longer than the originals and cannot be presented in
this paper\footnote{A couple more oversights regard the definition of
HYPERTEXT and the definition of
ModifyComponent, where the COMP\_INFO part of the new component is
exactly the old one, so that it is impossible to modify
(attribute,value)
pairs or update local anchors when the underlying content has been
modified. For a complete exposition of these points, refer to
\cite{Penzo}.}.
Another example regards the definition of specifiers.
By rigidly storing the ANCHOR\_ID of the end-point component, yet
still allowing components to change over time thanks to a query
mechanism based on COMP\_SPEC, the system is forced to use a
consistent numbering scheme of anchors within components: if a
link points to different components at different times, the
list of anchors of each must use the same identifier for the
corresponding anchor, which in our opinion entails a heavy consistency
burden. Therefore we suggest storing a specifier for anchors as
well, so that the end-point anchor identifier is computed at
run-time along with the component identifier:

\begin{schema}{SPECIFIER}
componentSpec : COMPONENT\_SPEC \\
anchorSpec : ANCHOR\_SPEC \\
presentSpec : PRESENT\_SPEC \\
direction : DIRECTION
\end{schema}

\begin{zed}
resolver : COMPONENT\_SPEC \cross \\
\t1	ANCHOR\_SPEC \pfun UID \cross ANCHOR\_ID
\end{zed}

\noindent
or, equivalently, if we do not like to modify the existing
resolver function,

\begin{zed}
resolver : COMPONENT\_SPEC \pfun UID
\end{zed}

\begin{zed}
AIresolver : UID \cross ANCHOR\_SPEC \\ 
\t3			\pfun ANCHOR\_ID
\end{zed}

\noindent
Computing the end-point of a link therefore becomes a run-time
query both for identifying the component and for identifying
the exact anchor.

A final remark must be made regarding {\em external anchoring\/}
and the associated problem of {\em anchor updating\/}. Some systems do
not store the reference to the end-point of the anchor within
the data container, but in an external repository so that creating
a new anchor requires no modification to the data
or the data container. Such systems require an explicit update
mechanism for anchors since the data editor does not know of the
anchor, which is useful in open hypertext systems \cite{Davis},
distributed systems \cite{Maioli93} or when dealing
with ROM and WORM devices \cite{Oren87} and \cite{Oren90}.
In Dexter terms, an external anchoring mechanism is one that allows
Anchor Values to be stored externally to the Component they refer to.

The Dexter Model clearly supports only internal anchors:
specifiers store the Anchor ID, which is mapped to the
appropriate Anchor Value thanks to the anchor table that is
stored in the CompInfo of the component.

In internal anchoring
{\em \'a la\/} Dexter the update of Anchor Values is the duty
of the same entity entrusted with modifying the component
itself (in practical terms, if
the anchor is stored as a tag within the data, the anchor moves
automatically when the data is modified). This is not always
possible for all systems: for instance open hypertext systems
leave the editing to the original application, which is unaware
of links and anchors, and updates all anchors when saving the
document. Others (particularly Xanadu or RHYTHM) refer to
versioning to obtain the current value of the anchor.

Internal or external anchoring is a basic decision that different
hypertext systems take in different ways. We did not find a
common solution that models both ways and leaves the choice
of specifying one to each system model.
On the other hand, we have previously proposed a change in the way
anchors
were handled by the specifier, so that their identifier was the
result of a run-time query, by having the specifier schema store
an Anchor Spec in place of the Anchor ID, and by adding a
function that maps Anchor Specs to Anchor IDs when traversing links.
This
change is sufficient
for our proposed solution: the basic difference between internal
and external anchoring is that with internal anchoring the
identifier is translated into the appropriate value by means of a
table in the component, while with external anchoring the specifier
contains or maps directly to the anchor value without querying
the component.

Therefore an internal anchoring mechanism will
depend on the AIresolver function previously shown:

\begin{zed}
AIresolver : UID \cross ANCHOR\_SPEC \\
\t3			\pfun ANCHOR\_ID
\end{zed}

while an external anchor mechanism is simply characterised by a
different AVresolver function, which directly returns the Anchor
Value:

\begin{zed}
AVresolver: UID \cross ANCHOR\_SPEC \\
\t3			\pfun ANCHOR\_VALUE
\end{zed}

\noindent
Different hypertext systems will use one of the two functions in their
HYPERTEXT definition.

Anchor updating then becomes an autonomous
choice for system implementers: they either have it automatically
when editing the component, or deduce it when saving (e.g.
during the RTL function {\em realizeEdits\/}) or else, thanks
to versioning, deduce it when traversing the link (i.e., in the
AVresolver function itself).

In this section we have briefly mentioned some modifications
that we would make to the Dexter model {\em per se\/} in order to make
it more general and adaptable to a larger number of hypertext
systems. We tried to maintain the original philosophy and found
that we had to modify only marginal aspects of the model.
Better and more elegant solutions to the problems stated
are surely possible. In particular, since
Dexter specifies neither Anchor IDs nor Anchor Values, one could
argue that
the external anchoring problem could be solved by using Anchor
Values as Anchor IDs, so that there would be no need to add the
AVresolver function. However, we believe that this answer would
have meant merely playing with words, and that it was more important
to find a general and open solution.

In our opinion, the most important function that a hypertext RM should
perform is to give a clear and unambiguous aid to understanding
similarities and differences between different systems, so that
data interchange and interoperability are obtained with limited
effort. The force of Dexter lies in the fact that it is
largely general and unspecified: it is then possible, by
twisting the underlying semantics, that all its schemata mean
completely different things, but that, at the same time, none of its
constraints is violated. However, doing so would eliminate any hope for
Dexter to be used as a satisfactory means of facilitating hypertext
interchange.

\section{An example: The RHYTHM hypertext system}

\vspace{1ex}
We now introduce our own experience with checking the
generality of the Dexter Reference Model. We used as an
example the RHYTHM (Research
on HYpertext THeory and Management) Hypertext System, which is
being developed at the University of Bologna (for a complete
description of RHYTHM, see \cite{Lamberti}, \cite{Maioli91},
\cite{Maioli92} and \cite{Maioli93}). In this section we emphasize
the most prominent characteristics of RHYTHM, emphasizing
where it mostly differs from those systems that inspired
Dexter. In the next section, the main schemata of our model
are presented.

RHYTHM is a distributed hypertext system that, besides free
linking capabilities among distributed servers, offers inclusion,
versioning and authoring control. RHYTHM features a document system
to store, retrieve and show documents in a distributed manner.
Documents are versioned, i.e., for each document the system can
retrieve and show any intermediate state of its development. In the
same way, they are authored: the system can retrieve and show the
contributions of each author of a collaborative document. A document
is therefore a complex entity developing asynchronously over time 
many different users.

Each version of a document is a virtual entity, i.e., a list of
references (called anchors) either to other documents or to hidden
data containers; all anchors to documents are recursively resolved
in other references until an anchor to the actual data containers
is obtained. Distribution is due to the fact that each anchor may
refer to an arbitrary server on the network, and inclusion is
obtained by adding a reference pointing to a specific part of
another document.

A new version of a document is automatically activated when it is shown
to the user: at the start it will contain just a single
reference to the previous version of the document, but during the
editing many new anchors are added to account for the insertion of
new data, the deletion of old data and the inclusion of data from other
documents. Editing is completed on saving the new version
of the document: only the new data and the new list of anchors
need to be stored, since the old data already exists and can be
obtained by querying the previous version of the document.

Each document is associated with a group of authors, who are the
only ones allowed to create a new ``official'' version of the document.
But a new anchor list is created whenever anybody opens a document:
if the user belongs to the group, the system creates a new version
(we call this {\em versioning\/}), otherwise it creates a new document
containing all or part of the said document (we call this
{\em authoring\/}). In this way everybody is allowed to access and
modify
each readable document as if owning it and can freely add or
delete, because all modifications are automatically stored in a
personal copy of the document (without duplication of the common data).
Furthermore, every version of a document is still susceptible
to being modified, so that independent branches of subsequent
versions can be created and parallel versions can be
maintained.

As documents are divided into versions, links and inclusion end-points
can either refer to a specific version or be requested to transform
themselves into the corresponding end-points of the current version of
the receiving document. They can therefore contain either {\em static
anchors\/} or {\em dynamic anchors\/}. The system automatically checks
consistency and existence and avoids circularity.

The server, which is responsible for storing data, is independent from
the data format: it just handles blocks of bytes. The server builds the
document from the list of anchors, creating a list of blocks, called
{\em
handlers\/}, which store different kinds of data. The client receives
these blocks and connects an appropriate data manager and a part of the
screen to each handler. Only the data managers understand the data
format. The client thus appears to the user as a generic multimedia
editor with which it is possible to create zones containing different
types of data.

\section{Basic concepts of the RHYTHM-Dexter Model}

\vspace{1ex}
As we have said in section 2, creating a model of a system along the
lines of a reference model requires the mapping of the system's capabilities in
terms of the model, and the detailed specification of all features that fall in 
the model's spaces, to obtain a complete model.

There are three different tasks that have to be undertaken to
obtain the complete specification of a real hypertext system:
the given sets (i.e., unspecified entities) of the model must
be specified according to the real system (e.g. ATOMs and ANCHOR
VALUEs); the schemata that are too general for the real
system have to be restricted (e.g. Dexter allows n-ary links,
while RHYTHM allows only binary links), and specific features
must be added by modelling and appropriately inserting
them into the existing model. The last task has
two aspects: on the one hand, completely new concepts have
their own new schemata (e.g. users and group handling), on
the other, limited schemata are to be expanded (e.g.
specifiers' DIRECTION only refers to navigation links, while we
need to use links for inclusion as well).

What follows is therefore a brief account of our experience in
building the model of a hypertext information system with the
aid of the Dexter Reference Model.
The entire Dexter Model revolves around the definition of
Base Components. RHYTHM components are {\em files\/}, {\em documents\/}
and {\em versions\/}. None of them were easily mapped to Dexter
components,
unless a sort of creative approach was taken. In RHYTHM there is
a complete distinction between the entities storing the actual
data (files) and entities shown to the user (versions of
documents). Since a version is a list of references, we decided
to exploit links by introducing the concept of
inclusion links: versions are composites made exclusively of links:
some of them are navigational links, and the others, i.e., inclusion
links, represent the actual data. Data is actually stored in other
components, called {\em docuverses\/}, composed entirely of data
containers,
ATOMS, which are then directly mapped to files. Different
docuverses correspond to different RHYTHM servers, thus
obtaining distribution. While RHYTHM WCL and SL only deal
with data in their simplest form, {\em bytes\/}, the system then
transforms them into meaningful structures, {\em handlers\/}, when
transferring them
to the RTL, corresponding to RHYTHM clients.
The Presentation Specifier thus helps to determine the handler structure
that maps
the blocks of data in meaningful multimedia blocks.
The following briefly explains these points in greater detail.

\subsection{The Within Component Layer}

\vspace{1ex}
The Within-Component Layer refers to the parts of the model
which are internal to the component. There are two important
contact points between the SL and the WCL: the atoms, which
model the actual containers of data, and the anchor values,
which model a referencing schema to internal parts of the
component, independently of data type, data
format or modifications over time.

We thought that our main task was to specify the model down to very
simple computer concepts: file and bytes. Therefore an ATOM was thought
to be a sequence of data elements made of bytes which could easily be
mapped to files. The choice of a very general data type
for atoms is due to the fact that in practice the RHYTHM
system does not resolve blocks of data to their specific data
type until the block is delivered to the client: the server only
knows one data type, which is the array of bytes. This was easily
represented in the Dexter Model by considering the Presentation
Specifiers as the descriptions of data types that allow
the client to consider a generic block of data as an array of a
specific data type.

\begin{zed}
ATOM == seq BYTE
\end{zed}

\noindent
It is not clear whether the FILE schema should be put in the
Storage Layer, where it belongs by name, or in the
WCL, where all low level concepts should probably be placed.
Files are nonetheless the places where data collected in atoms
is permanently stored. Files can be accessed through filenames.

\begin{schema}{FILE}
fileName : FILENAME \\
data : ATOM
\end{schema}

\noindent
Anchor values are a means of referencing internal subparts of
components. In RHYTHM an anchor
value refers to an interval within the sequence of data-elements of
the component. This interval is specified by its starting point
and its length:

\begin{zed}
ANCHOR\_VALUE == POSITION \cross LENGTH
\end{zed}

\subsection{The Storage Layer}

\vspace{1ex}
The Storage Layer of the RHYTHM model is inevitably more complex
than Dexter's. However it is to be noted that, with the exception
of the modifications expounded in section 4, all further
modifications to the Storage Layer schemata are just additions to
handle specific RHYTHM features: whenever the RHYTHM Model derives
directly from Dexter, no further modification is necessary.
In the next subsection we will briefly account for the most
prominent features of the RHYTHM Hypertext System: we will
first introduce the two main kinds of link: navigation and
inclusion. In the following subsection Dexter components as
handled in the RHYTHM schemata are shown: docuverses and
versions. Next, documents are introduced as a superstructure
that connects versions in useful aggregates. Finally, the
basic concepts of authorship and ownership are introduced, 
and the difference between versioning and authoring is explained.

\subsubsection{Navigation links and inclusion links}

\vspace{1ex}
RHYTHM heavily depends on inclusion links: all new versions are
created including previous ones, and it is always possible to
include an arbitrary chunk of data from a version of another
document. Therefore we add a new specifier type, INCLUDE, and
divide links into two disjointed classes: navigation links and
inclusion links. In RHYTHM links have only two specifiers and it not
possible to have mixed kinds of link: they are either FROM-TO links
(navigation links) or INCLUDE-TO links (inclusion links).

\begin{syntax}
LINK\_TYPE & ::= & FROM | TO | BIDIRECT \\
           &  |  &  NONE | INCLUDE
\end{syntax}

\begin{schema}{INCLUSION\_LINK}
LINK
\where
\exists s : \ran specifiers @ \\
\t1   s.direction = INCLUDE
\end{schema}

\begin{schema}{NAVIGATIONAL\_LINK}
LINK
\where
\exists s : \ran specifiers @ \\
\t1   s.direction = FROM
\end{schema}

\noindent
Though the difference between navigation and inclusion links
is shown as part of a specific model, we believe
that it can be thought to contain some generality of
its own. Indeed, our modifications can be applied also to other
information system using similar kinds of references: hot and
warm links, the ``publish and subscribe'' mechanism in Macintosh
System 7, etc.

\subsubsection{Docuverse and versions}

\vspace{1ex}
We needed to differentiate between components as well: in RHYTHM, data
is never stored in components that can be accessed by the user,
and components accessible by users do not contain any kind of
data, only references. Through the use of inclusion links,
on the other hand, it is possible to regain all the advantages
obtained by the complete definition of composites. Therefore
there are two kinds of components, ATOM\_SEQ\_COMPONENT and
LINK\_SEQ\_COMPONENT, which are then aliased to the corresponding
RHYTHM terms, {\em DOCUMENTs\/} and {\em VERSIONs\/}:

\begin{schema}{ATOM\_SEQ\_COMPONENT}
COMPONENT
\where
compBase \in \ran composite \land \\
\t1   (\forall bc : BASE\_COMPONENT | \\
\t1   bc \in \ran (composite\inv(compBase)) @ \\
\t2     bc \in \ran atom)
\end{schema}

\begin{schema}{LINK\_SEQ\_COMPONENT}
COMPONENT
\where
compBase \in \ran composite \land \\
\t1   (\forall bc : BASE\_COMPONENT | \\
\t1   bc \in \ran (composite\inv(compBase)) @ \\
\t2     bc \in \ran link)
\end{schema}

\noindent
The docuverse (the name obviously comes from \mbox{Nelson's} Xanadu
\cite{Nelson})
is therefore the container of all the actual data (which will never
be shown to the user) and is used by the system to create the actual
content of versions. The docuverse does not contain links and
cannot be referenced by a navigation link. Versions, on the
other hand, are made exclusively of links, which are either
inclusion links (the actual data content of the component) or
navigation links. All navigation links necessarily point to another
version. To show a version, it is necessary to recursively explode
all inclusion links to other versions until they all become
inclusions of atoms of the docuverse, which contain the data to be
shown.

\subsubsection{Documents}

\vspace{1ex}
Versions are collected in larger entities, documents, that
establish relations between them. From the user's point of view,
the document is the foremost entity of the system. A document
is usually accessed in its most recent form, the {\em latest version\/},
but it is possible to show or refer to any previously saved state,
which is stored in an autonomous version. In its
more general form, a document is a tree of versions, as its
development may diverge into two or more different current versions.
All documents therefore share a common root, and for each version
there exists one, and only one, sequence of versions starting from the
root and leading to it. A numbering schema has been devised to
uniquely identify the position of a version within the version tree.

\begin{schema}{DOCUMENT}
name : NAME \\
group : GROUP\_ID \\
root : VERSION\_UID \\
latestVersion : VERSION\_UID
\end{schema}


\subsubsection{Users and groups}

Ownership relates to documents, and is the root of the
distinction between authoring and versioning. As in many
multi-user systems, users can be collected in GROUPs, which can
freely be created, mixed and modified.

Documents are owned by GROUPs, so that it is possible to have
multi-authoring of the same document. Each version is due to a
single user, so that it is necessary that every user who creates
a version belongs to the group owning the document.
If he does not, then a new document has to be created.
Information regarding the author and the position of a
component within a version tree is stored in the COMP\_INFO, as
pairs (attribute, value). It has therefore been necessary to make
the given sets ATTRIBUTE and VALUE partially explicit. For example,

\begin{syntax}
ATTRIBUTE & ::= & root | author | num\_version \\
          &  |  & sys\_admin | OTHER\_ATTRBS
\end{syntax}

\noindent
A docuverse component only needs the system administrator value,
while a version component stores its author, its position number
within the version tree of the document it belongs to and the
root version of the document it belongs to.

\subsection{The Run-Time Layer}

\vspace{1ex}
The Run-Time Layer is responsible for presenting the component to
the user as an instantiation. In RHYTHM the version is built
by the server and sent over the network to the client, which is
responsible for showing it. While for the server the version is
instantiated as a block of bytes, the client is able to
apply a meaningful structure to it by means of the Presentation
Specifiers and divide it into many smaller blocks of known structure,
called {\em handlers\/}.

\begin{schema}{INSTANTIATION}
handlers : \seq HANDLER \\
links : \seq LINK\_MARKER \\
linkAnchor : LINK\_MARKER \\
\t3			\fun ANCHOR\_SPEC
\where
\dom linkAnchor = \ran links
\end{schema}

\noindent
A handler is a complex structure. As mentioned above, a new
list of inclusions (called ``anchor list'' even if they are actually
inclusion links) is built every time a document is opened, and the
system only needs to save the new anchor list and the new data added
in the current session. The mechanism is too complex to be shown
here, but it is reflected in the inner structure of the handler:
The data\_block sequence contains the current state of the handler
to be shown to the user. The new\_data sequence contains just the
new data added during the current session and the anchor\_list
contains all inclusion links making up the new version of the
document. The data\_block sequence will be discarded when the version
is saved.

\begin{schema}{HANDLER}
anchor\_list : \seq BIN\_INCL\_LINK \\
data\_block : \seq DATA\_ELEMENT \\
new\_data : \seq DATA\_ELEMENT
\end{schema}

\noindent
For a complete explanation of the inner mechanisms of handlers,
we refer to \cite{Penzo}.

\section{Conclusions and future work}

\vspace{1ex}
In this paper we have shown some issues in developing the data
interchange procedures between different hypertext information
systems with the aid of a reference model providing an
intermediate data format.
This procedure focuses on completing the Dexter
Hypertext Reference Model to create the specification of a real
hypertext system. This specification can then be used to
implement an interchange mechanism for hypertext data between
the system and any other hypertext systems for which an
analogous model is created.

Our curiosity was aroused by the idea of
using Dexter to model a system, RHYTHM, which is very
different from those Dexter was originally designed from.
This demonstrates that, with an elastic approach,
Dexter can model a very large set of different hypertext systems and
can be a valid support establishing {\em una
tantum\/} or regular interchange procedures even between 
widely different systems.
We therefore found Dexter a robust and trustworthy model for the
specification of hypertext systems. Due to the rapid advances and
changes
in the hypertext
field, these procedures will result indispensable in guaranteeing a
lasting and useful life to information systems based on hypertext.

Furthermore, this paper has presented two principal results:
in the first place, that few modifications are needed to enable
Dexter to be a model for a larger class of hypertext systems.
In the second place, that modelling a real system with Dexter
does not require any further key modification, even if the
real system is apparently quite different from the system implied
by Dexter. All further modifications are mere additions regarding
specific features not covered by the original model.

\begin{sloppypar}

A lot of work still remains to be done in this field. We would like to
create {\em RHYTHM2Dexter\/}, an interchange procedure between RHYTHM
and
Dexter, and use it with {\em IIF2Dexter\/} and {\em KMS2Dexter\/}
created
by Killough and Leggett \cite{Killough}, so that our efforts are checked
against some existing results. Using this procedure, we wish to prove
that the interchange between RHYTHM and KMS or
Intermedia is easy and possibly automatic. Any system that,
designed to import data coming from already existing
hypertext systems, establishes the interchange format
with Dexter, will certainly simplify any transition.

\end{sloppypar}

% APPENDIX

\appendix

\section*{APPENDIX: The Z Language}

\vspace{1ex}
Z is a formal specification language whose notation has been widely
accepted for the specification of several software systems in the 
industrial environment. The Z language is based on elements of 
set theory and first order logic.

Here we give an essential view on the notational elements used
in this paper. The description of the evolution of a system state is 
specified through a box called {\em schema\/}. A schema is formed by a 
{\em declaration\/} part, in which elements of the state and
relationships among them are included, and a {\em description\/} 
part in which state invariants, preconditions and sequences of 
actions are specified. These actions lead to a modification of the
state of the system. Briefly:

\begin{schema}{SchemaName}
declarations...
\where
descriptions...
\end{schema}

\noindent
You can define operations or functions using the so-called
{\em axiomatic definition\/} whose form is the following:

\begin{axdef}
Declaration
\where
Predicate
\end{axdef}

\noindent
where the Predicate represents the body of the function.
Moreover, the Z user is allowed to define recursive structures.
An example used in this paper is the following:

\begin{zed}
BASE\_COMPONENT ::= atom \ldata ATOM \rdata \\
\t1		 |  link \ldata LINK \rdata \\
\t1		 |  composite \ldata \seq BASE\_COMPONENT \rdata
\end{zed} 

\noindent
which can be read as follows: a BASE\_COMPONENT is either an ATOM, or a
LINK, or a composite, i.e., a sequence of other BASE\_COMPONENTs.
More detailed references about specific notational aspects
may be found in \cite{Spivey92}. 

In order to facilitate the reading comprehension of this paper
we introduce a brief list of the Z symbols used most.

\noindent
$\power$ \t1	as power set ~~~~~~~~$\fun$ ~~~~~as function \\
$\finset$ \t1	as finite set ~~~~~~~~~$\pfun$ ~~~~~as partial function \\ 
$\seq$ ~~~~as sequence ~~~~~~~~~$\pinj$ ~~~~~as partial injection 

\noindent
Some of the advantages due to the use of the Z language are
the production of precise, unambiguous specifications and
the easy understanding of its notation.

Furthermore, Z is noteworthy also for capturing the dynamical
aspects of the evolution of the system thanks to the use of schemata
where the transformations of the system are specified.


\begin{thebibliography}{Garzotto91}
%
\bibitem[Aks89]{Akscyn} 
R. Akscyn, F. Halasz, T. Oren, V. Riley, L. Welch: 
{\em Interchanging Hypertexts\/}. 
Panel of the Hypertext '89 Conference, ACM, Pittsburgh (PE), 1989
%
\bibitem[Bie91]{Bieber} 
M. Bieber:
{\em Issues in Modeling a ``Dynamic'' Hypertext  Interface\/}.
Proc. of the Hypertext '91 Conference, ACM, San Antonio (TX), 1991
%
\bibitem[Cra90]{Crane} 
G. Crane: 
{\em Standards for a Hypermedia Database: Diachronic vs.
Synchronic Concerns\/}.
Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
%
\bibitem[Dav92]{Davis} 
\mbox{H. ~Davis, ~~W. ~Hall, ~~I. ~Heath, ~~G. ~Hill,} 
\mbox{R. ~~Wilkins: 
{\em ~~~Towards ~~~an
~~~Integrated\/}} 
\mbox{{\em Information 
~~~Environment ~~~with ~~~Open\/}} 
\mbox{{\em Hypermedia 
~Systems.}
~~Proc. ~of the ~ACM} 
\mbox{Conference ~~~on 
~~~Hypertext ~~~ECHT '92,} 
\mbox{Milano (I), 1992}
%
\bibitem[Fri91]{Frisse} 
M.E. Frisse, S.B. Cousins, S. Hassan, WALT: 
{\em A Research Environment for Medical Hypertext\/}.
Technical Briefing of the Hypertext '91 Conference, ACM, 
San Antonio (TX), 1991
%
\bibitem[Gar91]{Garzotto91} 
F. Garzotto, P. Paolini, D. Schwabe:
{\em HDM: A Model for the Design of Hypertext Applications\/}.
Proc. of the Hypertext '91 Conference, ACM, San Antonio (TX), 1991
%
\bibitem[Glu92]{Glushko} 
R.J. Glushko: 
{\em Hypertext and Multimedia for Managers\/}. 
ECHT '92 Tutorial, Milano (I), 1992
%
\bibitem[Gr\mbox{\o}92]{Gron}
K. Gr\mbox{\o}nb\mbox{\ae}k, R.H. Trigg: 
{\em Design Issues for a Dexter-based Hypermedia System\/}.
Proc. of the ACM Conference on Hypertext ECHT '92, Milano (I), 1992
%
\bibitem[Hal90]{dexter} 
F. Halasz, M. Schwartz: 
{\em The Dexter Hypertext Reference Model\/}.
Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
%
\bibitem[HKo90]{Hardt} 
S.L. Hardt-Kornacki, L.M Gomez, J.F Patterson:
{\em Standardization of Hypermedia: What's the Point?\/}
Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
%
\bibitem[Kil90]{Killough} 
\mbox{R.~L. ~~Killough, J.~J. ~~Leggett: 
{\em ~Hypertext\/}} 
\mbox{{\em Interchange ~~~with ~~the ~~~Dexter ~~Model:\/}} 
\mbox{{\em Intermedia ~~to ~KMS\/}.
~~Technical ~~Report} 
\mbox{TAMU-HRL ~~~~90-002, ~~~~~Texas ~~~~~A\&M} 
\mbox{University, 1990}
%
\bibitem[Lam92]{Lamberti} 
S. Lamberti, C. Maioli, F. Vitali:
{\em Some Modifications to the Dexter Hypertext Reference Model\/}.
T.R. n. 7/115, P.F. Sistemi Informatici, CNR (Italy), 11/92
%
\bibitem[Mai91]{Maioli91} 
C. Maioli, F. Vitali: 
{\em Authoring tool development with the RHYTHM hypertext system\/}.
AICA 91, Siena, 9/91
%
\bibitem[Mai92]{Maioli92} 
C. Maioli, F. Vitali:
{\em Anchors and Paths in a Hypertext Publishing System\/}. 
AICAText'92 Proceedings, AICA, Milano, 3/92
%
\bibitem[Mai93]{Maioli93} 
C. Maioli, S. Sola, F. Vitali:
{\em Wide-Area Distribution Issues in Hypertext Systems\/}. ACM SigDoc '93 
Conference Proceedings, ACM, Kitchener (Canada), 1993
%
\bibitem[Nel90]{Nelson} 
T.H. Nelson:
{\em Literary machines\/}. 
90.1, Mindful Press, Sausalito (CA) 1990
%
\bibitem[Ore87]{Oren87} 
T. Oren:
{\em The Architecture of Static Hypertexts\/}.
Proc. of the Hypertext'87 Conference, ACM, Chapel Hill (NC, USA)
%
\bibitem[Ore90]{Oren90} 
T. Oren:
{\em Towards Open Hypertext: Requirements for Distributed Hypermedia 
Standards\/}.
Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
%
\bibitem[Pen93]{Penzo}
\mbox{W. ~Penzo, ~S. ~Sola, ~F. ~Vitali:
{\em ~~~Further\/}} 
\mbox{{\em Modifications ~~to ~the ~~Dexter ~~Hypertext\/}}
\mbox{{\em Reference ~Model: ~a ~Proposal\/}. 
~~Technical} 
\mbox{Report, ~Laboratory of ~Computer ~Science,} 
\mbox{University of Bologna, 
Italy, 1993}
%
\bibitem[Sch90]{Schutt} 
H.A. Schutt, N.A. Streitz:
{\em HyperBase:  A Hypermedia Engine Based on a Relational Database 
Management System\/}.
ECHT'90 Conference Proceedings, Cambridge Press, Versailles (F), 1990
%
\bibitem[Spi92]{Spivey92}
M. Spivey:
{\em The Z Notation. A Reference Manual. Second Edition\/}.
Prentice-Hall, 1992
%
\bibitem[VDP90]{Parunak} 
H. Van Dyke Parunak:
{\em Reference and data Model group (RDMG): Work Plan Status\/}.
Proc. of the NIST Hypertext Standardization Workshop, Gaithersburg (Md), 1990
%
\end{thebibliography}

%\input{appendix}

\end{sloppypar}

\end{document}
