<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-1504">
  <Title>Hypertextual Grammar Development *</Title>
  <Section position="4" start_page="24" end_page="24" type="intro">
    <SectionTitle>
2 Desiderata
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="24" end_page="24" type="sub_section">
      <SectionTitle>
2.1 Documentation in Software and
Grammar Engineering
</SectionTitle>
      <Paragraph position="0"> In Booch (1996) documentation-driven projects are described as a &amp;quot;...degenerate of requirements-driven processes, a case of bureaucracy gone mad in the face of software...&amp;quot;. Their most salient feature is the need of producing documentation packages as deliveries for the various phases of the project. What usually happens in these cases is that the implementative work stops a couple of weeks before the deadline, and a massive documentation work is performed, all in once, until the delivery is pushed out of the door. On the contrary, in standard requirements-driven projects there is no temporal gap between code writing and documentation writing (cf. also Metzeger &amp; Boddie, 1996).</Paragraph>
      <Paragraph position="1"> This situation can be generalized to grammar writing, where the standard practice seems to confine the writing of the documentation to a kind of leftovers. As a consequence, in many cases, documentation does not reflect the rationale under certain choices of the implementation, but reduces to an informal description of formally represented linguistic structures. Moreover, in successive releases of the same implementation, the links between the documentation and the implementation tend to become weaker and weaker. In big projects it is almost impossible to ensure the coherence between the implementation and the documentation.</Paragraph>
      <Paragraph position="2"> This situation is particularly problematic in cases of distributed grammar development, when more sites are involved in cooperative work. Under these circumstances, lack of synchronization between documentation and real code could cause serious communication problems and a general delay in the work flOW.</Paragraph>
      <Paragraph position="3"> Also, both reusability and usability are affected by poor or incoherent documentation. On the side of reusability, the costs for learning and maintaining an undocumented grammar are often comparable to the costs of a development from scratch. On the side of usability, grammar documentation is the base for producing final user documentation, without which no natural language system will ever be able to attract any industrial user (cf. Zoeppritz, 1995).</Paragraph>
    </Section>
    <Section position="2" start_page="24" end_page="24" type="sub_section">
      <SectionTitle>
2.2 Documentation in Grammar
Engineering
</SectionTitle>
      <Paragraph position="0"> One of the key point of recent developments in Grammar Engineering is represented by the convergence of certain linguistic theories (e.g. LFG and HPSG) and real grammar development (cf. Cole &amp; al 1997, Ch. 3.3). Thus, certain theoretical results can be easily incorporated in actual implementations, and certain computational treatments have proved to be able to provide valuable hints to theoretical research. This mutual relationship constitutes a good rationale for the view of grammar writing mainly as documentation writing. Both the phase of grammar design and implementation could be conceived as the production of a set of abstract linguistic generalizations, where the actual implementative platform only plays a role in restricting the power of the tools to express such generalizations. Indeed, as soon as migration tools among different platforms are available (cf. Dini 1997, Bloch 1997, EAGLES 1996) the concrete syntax of the implementation plays a much lighter role than in the past, and the documentation becomes, in a sense, the grammar. 1 From the opposite perspective, the availability of clear and well designed documentation would would make grammar reports attractive for theoretical linguists (Cf. Erbach &amp; Uszkoreit 1990).</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>