  %preambul
  %
  %  $Description: Author guidelines and sample document in LaTeX 2.09$ 
  %
  %  $Author: ienne $
  %  $Date: 1995/09/15 15:20:59 $
  %  $Revision: 1.4 $
  %
   
  \documentclass[times, 10pt,twocolumn]{article} 
  \usepackage{latex8}
  \usepackage{times}
   
  %\documentstyle[times,art10,twocolumn,latex8]{article}
   
  %------------------------------------------------------------------------- 
  % take the % away on next line to produce the final camera-ready version 
  \pagestyle{empty}
   
  %------------------------------------------------------------------------- 
  \begin{document}
   
   %tiitel ja autor
   \title{Grammar-Based Visual Modeling of Computer Texts}
    
   \author{J\"uri Kiho\\
   University of Tartu\\ Institute of Computer Science \\ 
   J. Liivi 2, 50409 Tartu, Estonia\\ Jyri.Kiho@ut.ee\\
   }
    
   \maketitle
   \thispagestyle{empty}
    
  %===========================================.
   
  \def\hs{\hspace*{5pt}}
  \def\fred{Amadeus-\-f\hspace{1pt}RED}
   
  \input amadeusLatex
  %===========================================.
   \begin{abstract}
   The problem of computer texts conversion are investigated. 
   It is pointed out that conversion procedures involve     
     some kind of modeling: any  
   particular set  of conversion rules constitute a conversion model.  
   The suggested  idea of automation of converter building is to separate the 
   conversion model from source languages structures 
   (grammars).  If for each source language its grammar is  defined and  
   a parser (automatically) generated, then the  conversion of parse trees 
 (instead of source texts)  to 
   target texts can be described by the model.   
    It allows to specify 
   a general convert procedure which yields the result target text 
    given a uniform parse tree (generated by the source text parser) and a model.   
   A visual (sketchy) modeling implementation of  
   the converters building process   are   
   explained. 
   \end{abstract}
   %sections
   \Section
   {Introduction} %not numbered
   In this paper the problem of textual data conversion is considered. 
   Conversion of a source text means giving it another form in accord 
   with a set of conversion rules. The conversion rules define how and where 
   the source primitives will be placed in target texts.
   It would be reasonable to consider any 
   particular set  of conversion rules as a (conversion) model.
    
   Any particular conversion method addresses (1) a source language, 
   (2) a target language and (3) a conversion model. Since conversion
   means just format transformation, both the source and the target 
   language have the same set of primitives. \\  
   Often (but not always) the model defines the {\em two-way conversion}: 
   from source  to target and {\em vice verse}.\\ 
   One of the important conversion types is  Some-to-XML, for instance, 
   Flat-to-XML \cite{XFlat}. Effective converters may impose rather strict  
   constraints on source languages, some of them accepting, for instance, only 
    so-called comma separated values (CVS). \\  
   Conversion of type Some-to-XML combined with 
   the conversions of type XML-to-Some  provides the conversion 
   Some-to-Some. \\
   It should be noticed that using XML as an intermediate target language in    
   some $SL$-to-$TL$ converter 
   is not always reasonable.  
   Generally speaking, it  involves  
   the need to build two converters, $SL$-to-XML and XML-to-$TL$. \\
   Some real examples where the straight converter would be preferred:\\ 
   1. $SL$ is the LinkGrammar language \cite{LNKGR}, where a text is a 
    sentence in English with assigned to it  
   a syntactic structure, which consists of a set of labeled links connecting pairs 
   of words. $TL$ is a 
   linkage diagram language expressing  explicitly  
   the structures assigned to source sentences. \\
   2. $SL$ is the language in which annotated dialogues in Estonian are 
   written down \cite{DLG}. $TL$ is a visual language for source annotation 
   schemes. \\
   The need for converters of many different types,   
   each performing conversion from one specific language to another one,  
    raises the problem how to automate the process of  
   converter building. Some of the options for automated  
   content conversion into XML format are addressed in  \cite{RVirk}.\\
   It is desirable, indeed, to build converters as general as possible. 
   The ideal aim would be a converter for Any-to-Any. At a first glance this aim 
   seems practically unreachable, but after certain reformulation of the 
   problem, real steps in this direction can be made. The problem can be posed      
   as follows.\\
   Given a source language, a target language and a conversion model, 
   automatically generate the corresponding converter.
   Some attempts to solve this problem have been made 
   for conversions of type Any-to-XML, e. g. \cite{SPY}. In fact, the problem 
   has been further reduced: instead of the converter generator the 
   model-dependent converters are developed which perform conversions  
   according to given conversion models. \\
   In the following,  a realistic process of constructing such converters  
   is outlined.  This approach assumes that a parser for any particular 
   source language can be easily generated on the basis of the 
   source language grammar.  First,  a general schema of building 
   grammar-based converters is given.  Further,  
   a particular  implementation of the process as     
   sketchy modeling  in the system \fred \ cite{RR} is described.   
    
    
    
    
   \Section
   {General process of building grammar-based converters}
   Let $SL$ be a source language, $SG$ its grammar and $TL$ a target 
   language.  
   Suppose that a conversion model $M$ has already been  
   defined. \\
   To build the $SL$-to-$TL$ converter according to $M$ the following 
   steps are to be performed. 
    \begin{enumerate}
    \item
    Build the $SG$-based parser ($SP$) for $SL$ which constructs 
    parse trees for texts in $SL$. 
    \item
    Develop the method $convert$ which takes two arguments, a
    parse tree (of a concrete source text)  and a conversion model, 
    and yields the target text (the converted source text). 
    \item
    Specify the converter:
    
    \hs\hs- - - Let $SLtext$ be an arbitrary text in $SL$
     
    \hs\hs$parseTree = SP(SLtext);$
     
    \hs\hs$TLtext = convert(parseTree, \ M);$
     
    \hs\hs- - - Result: $TLtext \in TL$
    \end{enumerate}
   Obviously, the third step is trivial and the  first step can be quite 
   easily automated using some parser generator. The most critical    
   one is the second step: if dependent on $SL$ and/or $TL$, 
   a lot of programming work would be needed to  develop 
   the convert method anew for each next converter.
    
   So it would be extremely desirable to have a universal 
   convert method independent of 
    source and target languages, i.\ e. which  
   accepts models $M$ for any $SL$ and $TL$. In turn, 
   it leads to the need for making the model structure independent of 
   $SL$ and $TL$. 
    
   One solution to this problem is to introduce a special model 
   description language (yet another new language together with its 
   GUI), such as the data extraction language DEL \cite{DEL}. 
   However, the sketchy modeling technique described in the following 
   sections offers an alternative solution which is more uniform and 
   user-friendly.  Namely, the same visual diagram representation
   views are  
   used for target languages as well as for conversion models. So, the  
   conversion models become independent of source languages, though 
   staying dependent on the (single) target sketchy language.
   \Section
   {Sketchy modeling}
    
       The sketchy 
      modeling method \cite{SZ} \cite{RR} implemented in \fred \  offers 
   a uniform and, at the same time, highly
       flexible framework for graphical representing, processing and editing 
      computer texts' structures. It also serves as a basis for 
   rapid development of specialized and structure-driven {\em ad hoc} editors
   for computer texts of various kinds. 
   Because of the multi-language nature of \fred \  the conversions between various 
   text formats are inherent to the system. All texts processed are represented 
   in an inner format (as linked Java objects) called the sketchy text language.  
   Sketchy texts are assigned WYSIWYG display views (view attributes) from a list of available 
   ones. Below, only one particular view (the sketchy view) is used for sample  
   sketchy texts.\\
   In figure  \ref{Stext} the sketchy text structure is acquainted. 
   The {\em sketchy text} is a {\em sketch} 
   (denoted by prolonged left bracket in the sketchy view). 
   A sketch may have {\em primitive heads} and 
   consists of one or more {\em branches}. A branch may have primitive heads and 
   contains  {\em  primitive members} and/or sketches (the sub-sketches).\\   
   A sketch with just one branch  is called the {\em mono-sketch}. In the following 
   examples, 
   mainly the mono-sketches are in use. Any sketchy text element (except comments) 
   may have a comment. \\   
   Every sketchy text is assigned a {\em base language} 
   (the base language attribute) -- the source 
   language the sketchy text (as conversion target) has been converted from.\\
    \begin{figure}%Skethcy text elements Stext}
     [h]
    {\scheme 
    \simplesketchB{
    sketch comment }{
    \simpleheadc{
    primitive head text}{
    text comment}
    }{
    \simplebranch{
    branch 1 comment}{
    \simpleheadc{
    branch 1 primitive head text}{
    text comment}
    }{
    \primitivec{
    primitive member text}{
    text comment}
    \simplesketch{
    inner sketch comment}{
    \primitive{
    (sketch and branch heads are missing)}
    }
    \primitive{
    . . . }
    }
    \simplebranch{
    branch 2 comment}{
    \simpleheadc{
    branch 2 primitive head text}{
    text comment}
    }{
    \primitivec{
    primitive member text}{
    text comment}
    \primitive{
    . . . }
    }
    }
    }
    \caption{
      Sketchy text elements.}\label{Stext}
    \end{figure}%Skethcy text elements Stext}
   In the following, a simple source language $SL$ is introduced for 
   illustration purposes. Any text 
   in $SL$  describes a descending family tree (see example in figure  \ref{FT}). \\
   The following description of converter development  process will be based on    
   the sample case of  
      converting family trees to 
   sketchy text. Corresponding trial version of \fred \  is available \cite{FAMoo}. \\
   Some approximate time estimations for converter 
   building steps are included in square brackets [te: \dots ]. The estimations 
   are derived from  author's personal experience while developing a converter for 
   annotated dialogues \cite{DLG}. \\
   To give the reader some flavor of the GUI used  some menu commands 
    in square brackets [mc: \dots ] are pointed out too.\\
    \SubSection
    {Grammar and parse trees}
    First of all, the grammar for $SL$ should be 
    specified, rewritten in JJTree/JavaCC \cite{JavaCC} and debugged.
    At this stage cooperation between domain and grammar experts is  
    necessary. 
    It may take a considerable amount of time [te: up to 3 man-days]
    to specify the grammar. The grammar specification could be 
    in EBNF or XBNF etc. and not necessarily describe all minor 
    details. In figure \ref{GfFT} a sample grammar is presented. \\
     \begin{figure}%Grammar for family trees. GfFT}
      [h]
     {\scheme %\figurefont
     \simplesketch{
     \hskip 400pt }{
     \primitive{

     }
     \primitive{
     s ::$=$ person }
     \primitive{
     person ::$=$ "$\{$" name (data)* (partnership)* "$\}$" }
     \primitive{
     name ::$=$ ($<$IDENTIFIER$>$)+}
     \primitive{
     data ::$=$ "("  (\~{}[")"])  ")"}
     \primitive{
     partnership ::$=$ "[" name (data)*  (child)* "]"}
     \primitive{
     child ::$=$  person}
     }
     }
     \caption{
       Grammar for family trees.}\label{GfFT}
     \end{figure}%Grammar for family trees. GfFT}
    Next, the grammar is detailed and given the JJTree/JavaCC form and 
     syntactically debugged [te: up to 1 man-day] until the sequential 
    application   
    JJTree-JavaCC-javac runs correctly and produces the first 
    version of the parser (e.g. $Family00Parser.class$ in our sample 
    case).\\
    Independent of the last activity, the new base language 
    is installed into \fred \ [te: up to 1 hour  (if manually)]. 
    Basically it involves making a new Java class 
     ($BaseLanguageFamily00.java$ in our sample case) 
    according to a pattern and including the new base language name and few 
    related actions into the parent class. \\ 
    At this point, \fred \ is ready to support further debugging 
    the grammar. One can open [mc: {\em File+Read \ text}] a concrete source text (e.g. 
    family tree in figure \ref{FT}) and get [mc: {\em Tools+Parse} and 
    {\em Tools+Reduce}] its 
     \begin{figure}%Sample family tree (FT) as plain text. FT}
      [h]
     {\scheme %\figurefont 
     \simplesketch{
     }{
     \primitive{
     }
     \primitive{
     $\{$Jaan King (1743 $-$ 1817)}
     \primitive{  
     \hs\hs(Was born in Tartu. Moved to Edinburgh in 1780. ) }
     \primitive{
      \hs\hs  [ Mari Kass (1750 $-$ 1777) $\{$Kai King (1770 $-$ ? )$\}$ ]}
     \primitive{
     \hs\hs   [ Mary McQueen (1760 $-$ 1835)  }
     \primitive{
     \hs\hs\hs(Church wedding in June 1783.)}
     \primitive{
       \hs\hs ]}
     \primitive{
     $\}$}
     }
     }
     \caption{
       Sample family tree (FT) as plain text.}\label{FT}
     \end{figure}%Sample family tree (FT) as plain text. FT}
    reduced parse tree (figure \ref{PT}) or an error message. In the case of 
    error, the grammar (or, perhaps, the source text) needs to be 
     corrected. Developing the grammar ends, when a 
    sufficient number of sample source texts have been accepted by the 
    parser.\\
    JJTree \cite{JavaCCGR} enables to suppress generation of some nodes in parse trees.
     In the sample grammar the node "IDENTIFIER" is suppressed 
    as meaningless from the family tree point of view.  
     So, for instance, in the parse tree (figure \ref{PT}) the terminal symbols "Jaan" and "King" both 
    become successors for the non-terminal node "name".\\ 
    Parse trees are also displayed in the visual sketchy form: each 
    non-terminal node, say $nt$,   
    is represented by a sketch containing all descendant nodes of 
     $nt$ as its sub-sketches (figure  \ref{PT}). The 
    name of the non-terminal is prefixed by $^0$ and shown as the 
    sketch comment. \\ 
    Non-terminal nodes which do not have
    non-terminal successors, i.e. have only terminal successor(s), 
    are called the {\em primitive non-terminals}. \\ 
     The primitive non-terminals in the sketchy parse tree 
    are reduced to sketch primitive members. In such case the 
    terminal values (e.g. "Jaan" and "King") are listed in the 
    primitive text and separated by $^1$ (e.g. "Jaan$^1$King"); the 
    name of the primitive non-terminal is prefixed by $^0$ and shown as the 
    text comment (e.g. "- - - $^0$name").    
     \begin{figure}%Parse tree for FT as sketchy text. PT}
      [h]
     {\scheme %\figurefont
      
     %\simplesketch{
     %\hskip 400pt }{
     \simplesketch{
     $^0$person}{
     \primitivec{
     Jaan$^1$King}{
     $^0$name}
     \primitivec{
     1743 $-$ 1817}{
     $^0$data}
     \primitivec{
     \footnotesize \sffamily 
     Was born in Tartu. Moved to Edinburgh in 1780. }{
     \normalsize $^0$data}
     \simplesketch{
     $^0$partnership}{
     \primitivec{
     Mari$^1$Kass}{
     $^0$name}
     \primitivec{
     1750 $-$ 1777}{
     $^0$data}
     \simplesketch{
     $^0$person}{
     \primitivec{
     Kai$^1$King}{
     $^0$name}
     \primitivec{
     1770 $-$ ?}{
     $^0$data}
     }
     }
     \simplesketch{
     $^0$partnership}{
     \primitivec{
     Mary$^1$McQueen}{
     $^0$name}
     \primitivec{
     1760 $-$ 1835}{
     $^0$data}
     \primitivec{
     Church wedding in June 1783.}{
     $^0$data}
     }
     }
     }
     %}
     \caption{
      Parse tree for FT as sketchy text.}\label{PT}
     \end{figure}%Parse tree for FT as sketchy text. PT}
    \SubSection
    {Primary model}
    \fred \ supports conversions of type Any-to-Sketches. 
    Therefore it is natural to represent conversion models also 
    in the sketchy form. \\ 
    In \fred, the {\em sketchy model} is a sketchy text 
    which serves as a template for target  
    sketchy texts. It also includes $^0$-prefixed non-terminal names
    (see figure \ref{Mnull}) to establish the connections to parse 
    trees of source texts.\\    
     \begin{figure}%Primary model (M0) for family trees.}
      [h]
     {\scheme %\figurefont
     \simplesketch{
     PERSON $^0$person}{
     \primitive{
     $^0$name}
     \primitive{
     $^0$data$*$}
     \simplesketch{
     PARTNERSHIP $^0$partnership*}{
     \primitive{
     $^0$name}
     \primitive{
     $^0$data$*$}
     \simplesketch{
     PERSON $^0$person*}{
     \primitive{
     }
     }
     }
     }
     }
     \caption{
       Primary model (M0) for family trees.}\label{Mnull}
     \end{figure}%Primary model (M0) for family trees.}
    In particular, if a non-terminal $nt$ occurs in a comment of 
    a sketch $s$ in the 
    sketchy model, every sub-tree  
    with root $nt$ in the parse tree will be converted to a  
    sketch, having the same attributes as the sketch $s$.  
    Likewise, if a primitive non-terminal $pnt$ occurs as a primitive 
    member $p$ in the sketchy model, every sub-tree 
    with root $pnt$ in the parse tree will be converted to the primitive $p$. 
    The primitive text is composed from the terminal successors of the 
    node $pnt$. \\
    In the model, the possible repetition of a construct in the target text is shown 
    by an asterisk at the end of corresponding non-terminal name.\\
    A primary model (figure  \ref{Mnull}) can be quickly obtained 
     from a particular parse tree in which  all (or most) 
    of the non-terminals occur. For that, the parse tree should be 
    simply modified (changed into the model)  and saved like any other sketchy text in \fred. \\
    When the sketchy model is complete, \fred \  is ready to 
     perform conversions. One can input a source text 
    [mc: {\em File+Read \ text}] and get [mc: {\em Tools+Sketchify}] 
    the target sketchy text (like in figure  \ref{FTnull}) 
     converted according to the model. \\
    Usually, the primary model is not adequate and satisfactory 
    for the domain. Nevertheless, it serves as a good starting point for 
    further conversion model design. 
     \begin{figure}%FT as sketchy text modeled according to  M0 FTnull}
      [h]
     {\scheme %\figurefont
     \simplesketch{
     PERSON }{
     \primitive{
     Jaan King}
     \primitive{
     1743 $-$ 1817}
     \primitive{
     Was born in Tartu. Moved to Edinburgh in 1780. }
     \simplesketch{
     PARTNERSHIP }{
     \primitive{
     Mari Kass}
     \primitive{
     1750 $-$ 1777}
     \simplesketch{
     PERSON }{
     \primitive{
     Kai King}
     \primitive{
     1770 $-$ ?}
     }
     }
     \simplesketch{
     PARTNERSHIP }{
     \primitive{
     Mary McQueen}
     \primitive{
     1760 $-$ 1835}
     \primitive{
     Church wedding in June 1783.}
     }
     }
     }
     \caption{
     FT as sketchy text modeled according to  M0 (in figure \ref{Mnull}).}\label{FTnull}
     \end{figure}%FT as sketchy text modeled according to  M0 FTnull}
    \SubSection
    {Meaningful model}
    As an example,  a more meaningful model for conversion of family 
    tree texts is presented  in this section (with some minor technical 
    details omitted). 
    First of all, it should demonstrate the ease of experimenting with  
    different models in the \fred \ environment.\\
    The model in figure  \ref{Myks} defines the following conversion. 
    Each "person" in a given source text is converted to a sketch. The latter 
    has several primitive heads commented by the person's "data"; 
    in addition,  the person's "name" takes the place of the 
    first primitive's text.
     The sketch for a person contains  
    several branches each corresponding to a "partnership". The head of the branch is similar to 
    the head of sketch. Each branch, in turn, contains several sketches. 
    Actually, the inner sketch in the model is optional and included 
    only for clarity and may be considered a model comment. 
    It does not affect the conversion, because the  
    nesting of persons into partnership is determined already by the grammar 
    and is present in every parse tree.
     \begin{figure}%Another model (M1) for family trees.}
      [h]
     {\scheme %\figurefont
      
     \simplesketchB{
     $^0$person}{
     \simpleheadc{
     $^0$name}{
     $^0$data}
     \simpleheadc{
     }{
     $^0$data*}
     }{
     \simplebranch{
     $^0$partnership*}{
     \simpleheadc{
     $^0$name}{
     $^0$data}
     }{
     \primitive{
     $^0$data$*$}
     \simplesketch{
     $^0$person*}{
     \primitive{
     }
     }
     }
     }
     }
     \caption{
     Another model (M1) for family trees.}\label{Myks}
     \end{figure}%Another model (M1) for family trees.}
    In figure  \ref{FTMyks} an example of a newly modeled family tree is 
    depicted. 
     \begin{figure}%FT as sketchy text modeled according to  M1  FTMyks}
      [h]
     {\scheme %%\figurefont
     \simplesketchB{
     }{
     \simpleheadc{
     Jaan King}{
     1743 - 1817}
     \simpleheadc{
     }{
     Was born in Tartu. Moved to Edinburgh in 1780. }
     }{
     \simplebranch{
     }{
     \simpleheadc{
     Mari Kass}{
     1750 - 1777}
     }{
     \simplesketchB{
     }{
     \simpleheadc{
     Kai King}{
     1770 - ?}
     }{
     \simplebranch{
     }{
     }{
     \primitive{
     }
     }
     }
     }
     \simplebranch{
     }{
     \simpleheadc{
     Mary McQueen}{
     1760 - 1835}
     }{
     \primitive{
     Church wedding in June 1783.}
     }
     }
     }
     \caption{
     FT as sketchy text modeled according to  M1 (in figure \ref{Myks}). }\label{FTMyks}
     \end{figure}%FT as sketchy text modeled according to  M1  FTMyks}
    When the modeling process is accomplished, i.e. a satisfactory 
    conversion model is elaborated, the backward conversion method 
    ({\em textualize}) may be written and included into the corresponding 
    base language class [te: 2 man-hours]. It enables to convert  
    target sketchy texts back into source language texts 
    [mc: {\em Tools + Textualize}].\\
    If the  choice of views currently offered by \fred \ does not include a 
    convenient one, a new WYSIWYG view can be programmed and included into 
    the system [te: 2-3 man-days]. 
     
    \SubSection
    {XML-oriented models}
    \fred \ supports the two-way conversion XML-to-SketchyXML, i.e. the base language 
    XML has already been installed. The  
    conversion model 
    is rather straightforward: any XML element (say, $e$)   
    converts to a mono-sketch ($se$) which contains all sub-elements of  
    $e$ as sub-skethces. The tag of $e$ becomes the comment of $se$ and the 
    attributes of $e$ are placed in the head of $se$.\\
    By the way, it means that any sketchy text $t$ which contains 
    only mono-sketches without heads (like in figure  \ref{FTnull}) can be 
    interpreted as an 
    sketchy XML text as well. Consequently, $t$ can be assigned the 
    base language XML [mc: {\em Base+Set}] and thereafter converted to 
    XML [mc: {\em Tools+Textualize}]. Applying these operations for 
    the sketchy text in figure \ref{FTnull} yields the XML text in figure  
    \ref{FTXnull}.\\
     \begin{figure}%FT from figure \ref{FTnull} textualized to XML FTXnull}
      [h]
     {\scheme %\figurefont
      
     \simplesketch{
     \hskip 400pt }{
     \primitive{
      $<$PERSON $>$}
     \primitive{
      \hs Jaan King}
     \primitive{
      \hs 1743 $-$ 1817}
     \primitive{
      \hs Was born in Tartu. Moved to Edinburgh in 1780. }
     \primitive{
       \hs $<$PARTNERSHIP $>$}
     \primitive{
       \hs \hs Mari Kass}
     \primitive{
       \hs \hs 1750 $-$ 1777}
     \primitive{
        \hs \hs $<$PERSON $>$}
     \primitive{
        \hs \hs \hs Juhan King}
     \primitive{
        \hs \hs \hs 1770 $-$ ?}
     \primitive{
        \hs \hs $<$$/$PERSON$>$}
     \primitive{
       \hs  $<$$/$PARTNERSHIP$>$}
     \primitive{
       \hs $<$PARTNERSHIP $>$}
     \primitive{
       \hs \hs Mary McQueen}
     \primitive{
      \hs \hs  1760 $-$ 1835}
     \primitive{
       \hs \hs Church wedding in June 1783.} 
     \primitive{
       \hs $<$$/$PARTNERSHIP$>$}
     \primitive{
      $<$$/$PERSON$>$}
     }
     }
     \caption{
     FT from figure \ref{FTnull} textualized to XML.}\label{FTXnull}
     \end{figure}%FT from figure \ref{FTnull} textualized to XML FTXnull}
    To get perhaps more meaningful sketchy XML for family trees, 
    a more appropriate conversion model should be used. For instance, 
    the model 
    in figure  \ref{Mkaks} reflects the wish to use attributes for 
    person/partner names and for the first portions of their data. \\
     Indeed, it is quite natural to assign all sketches in the 
     XML-oriented model to base language 
    XML.\\
    The sample result of such conversion is depicted in figure  \ref{FTkaks}. 
    Since the model's base language is XML, the result sketchy text also 
    has the same base language. So the corresponding plain XML text 
    (in  figure  \ref{FTxml}) can be   
    obtained immediately [mc: {\em Tools+Textualize}]. 
     
     \begin{figure}%XML-oriented model (M2) for family trees.}
      [h]
     {\scheme %%\figurefont
      
      \simplesketchB{
      ps $^0$person}{
      \simplehead{
      names $=$ " $^0$name "}
      \simplehead{
      dates $=$ " $^0$data "  }
      }{
      \simplebranch{
      }{
      }{
      \primitive{
      $^0$data$*$}
      \simplesketchB{
      conjugal $^0$partnership*}{
      \simplehead{
      partner $=$ " $^0$name "}
      \simplehead{
      partner-dates $=$ " $^0$data "  }
      }{
      \simplebranch{
      }{
      }{
      \primitive{
      $^0$data$*$}
      \simplesketch{
      ps$^0$person*}{
      \primitive{
      }
      }
      }
      }
      }
     }
     }
     \caption{
     XML-oriented model (M2) for family trees.}\label{Mkaks}
     \end{figure}%XML-oriented model (M2) for family trees.}
     
     \begin{figure}%FT as sketchy XML text modeled according to  M2}
      [h]
     {\scheme %%\figurefont
      
     \simplesketchB{
     ps }{
     \simplehead{
     names $=$ " Jaan King "}
     \simplehead{
     dates $=$ " 1743 $-$ 1817 "  }
     }{
     \simplebranch{
     }{
     }{
     \primitive{
     Was born in Tartu. Moved to Edinburgh in 1780. }
     \simplesketchB{
     conjugal }{
     \simplehead{
     partner $=$ " Mari Kass "}
     \simplehead{
     partner-dates $=$ " 1750 $-$ 1777 "  }
     }{
     \simplebranch{
     }{
     }{
     \simplesketchB{
     ps }{
     \simplehead{
     names $=$ " Kai King "}
     \simplehead{
     dates $=$ " 1770 $-$ ? "  }
     }{
     \simplebranch{
     }{
     }{
     \primitive{
     }
     }
     }
     }
     }
     \simplesketchB{
     conjugal }{
     \simplehead{
     partner $=$ " Mary McQueen "}
     \simplehead{
     partner-dates $=$ " 1760 $-$ 1835 "  }
     }{
     \simplebranch{
     }{
     }{
     \primitive{
     Church wedding in June 1783.}
     }
     }
     }
     }
     }
      
     \caption{
     FT as sketchy XML text modeled according to  M2 (in figure \ref{Mkaks}).}\label{FTkaks}
     \end{figure}%FT as sketchy XML text modeled according to  M2}
     
     \begin{figure}%FT from figure \ref{FTkaks} textualized to XML. FTxml}
      [h]
     {\scheme %%\figurefont
      
     \simplesketch{
     \hskip 400pt }{
     \primitive{
      $<$ps names $=$ " Jaan King "}
     \primitive{
      \hs dates $=$ " 1743 $-$ 1817 "  $>$}
     \primitive{
      \hs \hs Was born in Tartu. Moved to Edinburgh in 1780 }
     \primitive{
       \hs \hs $<$conjugal partner $=$ " Mari Kass "}
     \primitive{
       \hs \hs \hs partner-dates $=$ " 1750 $-$ 1777 "  $>$}
     \primitive{
        \hs \hs \hs $<$ps names $=$ " Kai King "}
     \primitive{
        \hs \hs \hs \hs \hs dates $=$ " 1770 $-$ ? "  $>$}
     \primitive{
        \hs \hs \hs $<$$/$ps$>$}
     \primitive{
       \hs \hs $<$$/$conjugal$>$}
     \primitive{
       \hs\hs  $<$conjugal partner $=$ " Mary McQueen "}
     \primitive{
       \hs \hs \hs partner-dates $=$ " 1760 $-$ 1835 "  $>$}
     \primitive{
       \hs \hs \hs\hs  Church wedding in June 1783.}
     \primitive{
       \hs \hs $<$$/$conjugal$>$}
     \primitive{
      $<$$/$ps$>$}
     }
     }
     \caption{
     FT from figure \ref{FTkaks} textualized to XML.}\label{FTxml}
     \end{figure}%FT from figure \ref{FTkaks} textualized to XML. FTxml}
     
   \Section
   {Conclusion}
   The problem of computer texts conversion has been investigated. 
   It has been pointed out that the conversion procedures involve     
   certain kind of modeling. It would be reasonable to consider any 
   particular set  of conversion rules as a (conversion) model. \\ 
   There exists a real need for converters of many different types,   
   each performing conversion from one specific language to another one. 
    In turn, it leads to the problem how to automate the process of  
   converter building.\\
   In this paper, an effective process of converter building is  
   outlined. It is restricted to the conversions of type 
   Any-to-Skt, where Skt stands for "sketchy text language".  
   However, the sketchy text language is rather general mean for 
   expressing structured computer texts of different kind. 
   In many cases Skt may serve as the target language for  
   conversions from  less structured source languages. Visual handling of 
   sketchy texts is fully supported by the system \fred. 
   The latter already offers (two-way) conversions of type Java-to-Skt,   
   XML-to-Skt et al.\\
   The basic idea of automation of converter building is to separate the 
   conversion model from source languages structures 
   (grammars). Instead of determining how particular source language  
   syntactic constructs should be converted, the model defines 
   the mapping of parse trees onto the target language Skt.  
    The format of parse trees does not depend on source languages: 
   any parse tree itself is represented in Skt. It allows to specify 
   a general convert procedure which yields the result target text 
    given a parse tree (of a source text) and a model. The convert 
   procedure has been implemented and integrated into \fred. 
   The needed parse trees are provided by corresponding parsers which are  
   separately generated using JavaCC/JJTree. \\
   If one wishes to build a converter from a source language $SL$ to   
   the sketchy language, the following steps are to be performed:
    \begin{enumerate}
    \item
    Specify a grammar ($SG$) for $SL$.
    \item
    Build a $SG$-based parser (a parse tree constructor) using JJTree-JavaCC-javac. 
    \item
    Install  $SL$ as a new base language for  \fred.
    \item
    In \fred, debug the grammar $SG$ using the visual parse facility. 
    \item
    In \fred, develop the conversion model using standard visual 
    editing mode and the conversion facility (sketchifier) to test the model.
    \end{enumerate}
   Due to the embedded general-purpose converter, supplementing 
   \fred \  with a new 
   convertible base language takes only numbered work-hours. 
   Inevitably, the work 
   with grammar (steps 1-2) remains the most time-consuming 
   activity. Often the source language appears to be not well-defined, 
   especially in the case of some legacy or manually prepared data.
    \vspace*{8cm}
   
   
  %------------------------------------------------------------------------- 
  \nocite{RR, SZ, JavaCC, JavaCCGR, XFlat, DLG, DEL,RVirk,FAMoo,LNKGR, SPY}
  \bibliographystyle{latex8}
  \bibliography{References}
  \end{document}
