<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-1504">
  <Title>Hypertextual Grammar Development *</Title>
  <Section position="5" start_page="24" end_page="25" type="metho">
    <SectionTitle>
3 HyperGram
</SectionTitle>
    <Paragraph position="0"> HyperGram (Hypertextual Grammars) is a model for grammar development and documentation inspired to the idea of literate programming, which was first proposed by Knuth (1974) (cf. Knuth (1992), for an overview). Actually, the main source of inspiration is the hyper-literate programming approach (Steinman ~; Yates 1995, 1996), a revision of literate programming stressing the importance of hypertextual connections between pieces of code, in order to increase both the quality of the documentation and the productivity of the programmer. Therefore HyperGram is meant to serve as a tool both for documenting grammars and for facilitating the work of the grammar engineer. 2 1The similarity with the literate programming approach immediately comes to mind. Such a similarity will be emphasized in section 3 where the HyperGram model will be presented.</Paragraph>
    <Paragraph position="1"> 2In a sense, documentation tools need to be tailored with respect to the kind of linguistic organization (or linguistic theory) which is chosen as the basis for the implementation. In the case we are considering in this paper, we have in mind a typed, unification-based user language, which fits very well the hypertextual organization of the lingware. Indeed values of attributes are  The main goals that the model is intended to reach, which, we think, constitute possible answers to real needs of a typical user of systems like ALEP or PAGE in the context of a grammar development project, are the following:  1. It allows to produce an updated printed documentation at any stage of the process of grammar development, avoiding inconsistencies between the real grammar code and the code exemplified in the report; inconsistencies of this sort are frequent in standard reports.</Paragraph>
    <Paragraph position="2"> 2. It produces an hypertextual version of the documented resources, which can be directly made available for public consultation, e.g. via the Internet; 3. It provides the grammar writer with the possi null bility of accessing the lingware during the development or debugging work, by means of a unique hypertextual interface, which emphasizes user-friedliness and efficiency. This interface allows the direct interaction with the real grammar modules which can be edited, modified, compiled and so on.</Paragraph>
  </Section>
  <Section position="6" start_page="25" end_page="27" type="metho">
    <SectionTitle>
4 HyperGram's Modules
</SectionTitle>
    <Paragraph position="0"> The general organization of the HyperGram system 3 is shown in fig. 1, where the relations between the various modules and the linguistic resources are made explicit. The basic idea is that during the process of grammar production an integrated HTML text containing both the documentation and the links to the lingware is maintained. Such a report will be available at any time either for browsing (using a standard http compliant program) or printing. The coherence between the HTML version of the lingware and the one which is actually compiled is preserved through a set of automatic compilation steps completely transparent to the grammar engineer. Also the distinction between &amp;quot;reporting&amp;quot; and &amp;quot;implementing&amp;quot; looses much of its importance, as relevant pieces of documentation can be accessed and modified in a hypertextual fashion directly during grammar editing. The single conversion steps are described in details in the remaining sections.</Paragraph>
    <Paragraph position="1"> easily understandable as links to piece of information contained in the type system. These pieces of information, the types, refer, in turn, to other sets linguistic constraints which can be analougously interpreted in a hypertextual fashion.</Paragraph>
    <Paragraph position="2">  in the following is centered on documentation of ALEP lingware. Analogous considerations hold for the PAGE version.</Paragraph>
    <Section position="1" start_page="25" end_page="25" type="sub_section">
      <SectionTitle>
4.1 HG-conversion
</SectionTitle>
      <Paragraph position="0"> The module labeled as HG-conversion in fig. 1 is a program written in emacs-l+-sp aimed at assigning an hypertextual structure to the lingware files used by the system. The various conversion steps are the following: * The lingware files (written in plain ASCII) are assigned a basic HTML tagging, in such a way that the original indentation of the code (for instance the one automatically produced by emacs modes for grammar editing) is maintained (using the &lt;PRE&gt; tag). The original lingware files are of course left unchanged, while the HTML files (HTML lingware, in the figure) are saved in a directory specified by the user  when the HyperGram system is configured.</Paragraph>
      <Paragraph position="1"> * Some hypertextual links among linguistic descriptions used in the lingware are expressed by means of the standard anchor mechanism of  HTML, by interpreting the grammar formalism.</Paragraph>
      <Paragraph position="2"> The main idea is to use hypertextual links to express the logical relations holding among the various objects involved in the grammar structure, namely types, phrase structure rules and macros (or templates). For instance, whenever a type or a macro is used as the value of an attribute in a linguistic description of any sort (i.e. a type declaration, a rule, or the body of a macro definition), an HTML anchor is produced, pointing to the definition of the relevant type or macro; when a type is introduced in the type declaration, it is anchored to the fragments of hierarchy where it appears. And so on.</Paragraph>
    </Section>
    <Section position="2" start_page="25" end_page="26" type="sub_section">
      <SectionTitle>
4.2 Integrated Report
</SectionTitle>
      <Paragraph position="0"> In order to produce an integrated HTML version of the documentation, the following preconditions have to be satisfied: * Every rule, or type declaration or macro definition in the lingware is labeled by means of an unambiguous identifier. This identifier can be expressed either as the value of a specific attribute in the body of the expression, or as an external comment.</Paragraph>
      <Paragraph position="1"> * Wherever a particular piece of lingware code is specifically documented in the report, a pointer to its identifier (in the sense specified above) is inserted, rather than a copy of the code itself; let us refer to that pointer as main pointer. If the code is referred to in other sections of the report, then a different pointer to the same identifier has to be established (secondary pointer).  Unlike the main pointer, which must be unique, it is possible to specify many secondary pointers to the same identifier.</Paragraph>
      <Paragraph position="2"> Once these relations between the documentation text and the documented code are made explicit by the grammar writer, the integrated hypertextual report is automatically produced by a compiler (the module labeled linking in the figure).</Paragraph>
      <Paragraph position="3"> The work done by this compiler is rather simple. It converts the pointers and identifiers described above into HTML anchors, with the following general organization: The pointers used in those sections of the report where parts of code are documented (i.e. the main pointers) are translated into anchors to the appropriate rules (or types or macros) in the HTML-lingwaxe files containing them; Similar anchors are established in all the other points of the report where a rule is referred to by means of a secondary pointer, In the HTML-lingware, each object is anchored to the section of the report where it is more specifically described: namely, where its main pointer is declared.</Paragraph>
      <Paragraph position="4"> In this way an updated, standard HTML-based hypertextual version of the whole grammatical module and of the related documentation is in principle available at any time for Intranet/Internet consultation. null</Paragraph>
    </Section>
    <Section position="3" start_page="26" end_page="27" type="sub_section">
      <SectionTitle>
4.3 Documentation Printing
</SectionTitle>
      <Paragraph position="0"> In spite of our belief that the best format to deliver grammar documentation is the hypertextual one, there might be case where also printed documentation is required. Thus we developed a module aimed at producing a printable version of the documentation, labeled as HG html21atex in fig. 1. A set of emaes-lisp functions is devoted to convert the original hypertextual documentation, which, as described above, is assumed to have been originally written in HTML format, into a printable LATEXdocument.</Paragraph>
      <Paragraph position="1"> The HG html21atex module interprets the pointers and the identifiers declared in the report and in the grammar files respectively, as described above in section 4.2. As a result, every rule or type or macro is included in the printed report in only one point,  namely where the main pointer to :it has been previously declared. This is automatically done by the program, which retrieves the parts of code associated to each pointer from the actual grammar files, and includes them in the report at the appropriate place.</Paragraph>
      <Paragraph position="2"> In all the other parts of the report where a piece of lingware is mentioned, but not specifically described, a ~,TF_ ~ internal cross-reference is introduced. This is precisely the reason for the use of different types of pointers in the report (see 4.2 above). Indeed, under this assumption, the point where the code must appear in the printed report is unambiguously specified by means of the unique main pointe.r. In the hypertextual version of the integrated report this kind of distinction is not relevant, as any reference to the lingware is simply an anchor to a specific part of a lingware file.</Paragraph>
    </Section>
    <Section position="4" start_page="27" end_page="27" type="sub_section">
      <SectionTitle>
4.4 Browsing and Editing the Lingware
</SectionTitle>
      <Paragraph position="0"> The interface chosen in the HyperGram model for the hypertextual navigation within the lingware and the associated documentation is the emacs-internal HTML browser emacs-w3.</Paragraph>
      <Paragraph position="1"> A set of specific emacs-lisp functions have been added in order to integrate the standard navigation procedures with the possibility for the user to access the source lingware, to edit it and, possibly, to compile it in the relevant grammar development platform. Crucially, the HTML version of lingware files should never be accessed by the grammar developer; it is automatically produced or updated once the lingware has been modified. Moreover, the user friendliness of the navigation through the lingware is enhanced by making explicit the type of relation expressed by an anchor (for instance the relation between a type used as a value in a rule and its definition in the type theory) by means of a special formatting, such as a particular font or color for the text.</Paragraph>
      <Paragraph position="2"> Here is how the browsing mechanism within grammar files will look from the point of view of the user: * having an existing grammatical file (call it rg._file), written in the relevant user language, a single command in an emacs buffer will allow the user 1) to create an updated HTML file (hg_.file) bearing all the information described above in terms of internal and external hypertextual links; 2) to invoke the emacs-w3 browser on that file; and 3) to browse it.</Paragraph>
      <Paragraph position="3"> * if an anchor that points to a different grammar file is followed, the relevant hg_file is generated if it does not exist, while if it is already existent, it is updated when necessary (i.e. if the corresponding rg_file has been modified after the date of its creation).</Paragraph>
      <Paragraph position="4"> when browsing an hg_file in a emacs-w3 buffer, a single command allows to switch to the underlying rg_file, with the cursor located in the same region. A parallel command allows to go back to the hypertext, which is automatically updated if necessary, namely if the rg_file has been modified; also in this case the cursor loca-tion is maintained.</Paragraph>
      <Paragraph position="5"> The whole mechanism allows the grammar writer to systematically use hypertextual navigation within the grammatical module, taking a possible advantage from the fact that the hypertextual model proposed here makes some relations among linguistic objects explicit. Since it is important to keep in mind these relations when working on a complex grammar, with a highly structured type theory, the hypertextual approach could provide a substantial help to the grammar writer. In many cases, it could represent a preferable alternative to the use of more sophisticated tools for graphical representation of linguistic objects, in that, on the one hand, it is fully integrated with the editing tool, and, on the other hand, it covers in an uniform way all the object used in the grammar module, not only the type theory.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>