<?xml version="1.0"?><!DOCTYPE article SYSTEM "/project/take/software/searchbench_offline_processing/paperxml_generator/aclextractor/src/python/../resource/dtd/paperxml.dtd"><article><header><firstpageheader><page local="1"/><title>XML and Multilingual Document Authoring: Convergent Trends</title><author surname="Dymetman" givenname="Marc"><org  name="Xerox Research Centre Europe" country="France" city="Grenoble"/></author><author surname="Lux" givenname="Veronika"><org  name="Xerox Research Centre Europe" country="France" city="Grenoble"/></author><author surname="Ranta" givenname="Aarne"><org  name="Xerox Research Centre Europe" country="France" city="Grenoble"/></author></firstpageheader><frontmatter><p><b>XML and Multilingual Document Authoring: Convergent Trends</b></p><p><b>Marc Dymetman      Veronika Lux</b></p><p>Xerox Research Centre Europe 6, chemin de Maupertuis 38240 Meylan, France</p><p>{dymetman,lux}@xrce.xerox.com</p></frontmatter><abstract>Typical approaches to XML authoring view a XML doc­ument as a mixture of structure (the tags) and surface (text between the tags). We advocate a radical approach where the surface disappears from the XML document altogether to be handled exclusively by rendering mech­anisms. This move is based on the view that the author's choices when authoring XML documents are best seen as language-neutral semantic decisions, that the struc­ture can then be viewed as interlingual content, and that the textual output should be derived from this content by language-specific realization mechanisms, thus assimi­lating XML authoring to Multilingual Document Author­ing. However, standard XML tools have important limi­tations when used for such a purpose: (1) they are weak at propagating semantic dependencies between different parts of the structure, and, (2) current XML rendering tools are ill-suited for handling the grammatical combi­nation of textual units. We present two related proposals for overcoming these limitations: one (GF) originating in the tradition of mathematical proof editors and con­structive type theory, the other (IG), a specialization of Definite Clause Grammars strongly inspired by GF. </abstract></header><body><section number="1" title="Introduction"><p>The typical approach to XML authoring views an XML document as a mixture of tree-like <i>structure, </i>expressed through balanced labelled parentheses (the tags), and of <i>surface, </i>expressed through free text interspersed be­tween the tags (PCDATA). A Document Type Defini­tion (DTD) is roughly similar to a context-free gram-mar<footnote anchor="1"/> with exactly one predefined terminal. It defines a set of well-formed structures, that is, a <i>language over trees, </i>where each nonterminal node can dominate either the empty string, or a sequence of occurrences of nonter­minal nodes and of the terminal node .Theter-minal pcdata has a special status: it can in turn dominate any character string (subject to certain restrictions on the characters allowed). Authoring is typically seen as a top-down interactive process of step-wise refinement of the root nonterminal (corresponding to the whole document) where the author iteratively chooses a rule for expanding</p><footnote label="1">But see (Prescod, 1998) for an interesting discussion of the differ­ences.</footnote><p><b>Aarne Ranta </b>Department of Computing Science Chalmers University of Technology and Göteborg University S-412 96 Göteborg, Sweden aarne@cs.chalmers.se</p><p>a nonterminal already present in the tree,<footnote anchor="2"/> and where in addition the author can choose an arbitrary sequence of characters (roughly) for expanding the node.</p><p>One can observe the following trends in the XML world:</p><p>A move towards more typing of the surface: <i>Schemas </i>(W3C, 1999a), which are an influential proposal for the replacement of DTD's, provide for types such as float, boolean, ur i, etc., instead of the single type pcdata;</p><p>A move, already constitutive of the main purpose of XML as opposed to HTML for instance, towards clearer separation between content and form, where the original XML document is responsible for con­tent, and powerful styling mechanisms (e.g. XSLT (W3C, 1999b)) are available for rendering the doc­ument to the end-user.</p><p>We advocate an approach in which these two moves are radicalized in the following ways:</p><p><b>Strongly typed, surface-free XML documents. </b>The whole content of the document is a tree where each node is labelled and typed. For internal nodes, the type is just the usual nonterminal name (or category), and the label is a name for the expansion chosen for this nonterminal, that is, an identifier of which rule was chosen to expand this nonterminal. For leaves, the type is a semantically specific category such as Integer, Animal,etc., and the label is a specific concept of this type, such as three or dog.<footnote anchor="3"/> <b>Styling responsible for producing the text itself.</b><b></b></p><p>The styling mechanism is not only responsible for ren­dering the layout of the text (typography, order and pre­sentation of the elements), but also for producing <i>the text itself from </i>the document content.</p><p>What are the motivations behind this proposal? <b>Authoring choices carry language-independent meaning. </b>First, let us note that the expansion choices<page local="2"/></p><footnote label="2">We are ignoring here the aspects of this process relating to the regular nature of the right-hand sides of rules, but these particulars are unessential to the main argument.</footnote><footnote label="3">Note that Integer is of "logical type" e, whereas Animal is of log­ical type : there is no restriction on the denotational status of leaves.</footnote><p><b>&lt;! ELEMENT Risk (Caution </b>I <b>Warning) &gt; risk-rulel:     Risk --&gt; Caution</b> <b>&lt;!</b><b> ELEMENT Caution (  ...   </b>I ... I <b>...  ) &gt;       caution-rulel:     Caution --&gt; ...</b></p><doubt alpha="59.4" length="32" tooSmall="False" monospace="0.0">risk-rule2:     Risk --&gt; Warning</doubt><p><b>caution-rule2: Caution --&gt; ... caution-rule3:     Caution --&gt; ...</b></p><p>Figure 1: Context-free rules (shown on the right) corresponding to the aircraft DTD (shown on the left); for illustration purposes, we have assumed that there are in turn three semantic varieties of cautions. The rule identifier on the left can be seen as a semantic label for each expansion choice (in practice, the rule identifiers are given mnemonic names directly related to their meaning).</p><p>made during the authoring of an XML document gener­ally carry <i>language-independent meaning. </i>For instance, the DTD for an aircraft maintenance manual might be legally required to distinguish between risk instructions of two kinds: <b>caut ion </b>(risk related to material damages) and <b>warning </b>(risk to the operator). Or a DTD describing a personal list of contacts might provide a choice of gen­der ( , ), title ( , , ), country <b>(ger, f </b><b>ra,...),</b><b> </b>etc. Each such authoring choice, which formally consists in selecting among different rules for expanding the same nonterminal (see Figure 1), corre­sponds to a <i>semantic decision </i>which is independent of the language chosen for expressing the document. A given DTD has an associated <i>expressive space </i>of tree structures which fall under its <i>explicit </i>control, and the author is situating herself in this space through top-down expansion choices. There is then a tension between on the one hand these explicitely controlled choices, which should be rendered differently in different languages (thus <b>ger </b>as <i>Germany, Allemagne, Deutschland </i>and by a paragraph starting with <i>Warning! ... </i>; <i>At­tention, Danger! Achtung, Lebensgefahr! ...</i>), and on the other hand the uncontrolled inclusion in the XML document of free PCDATA strings, which are written in a specific language.</p><p><b>Surface-free XML documents. </b>We propose to com­pletely remove these surface strings from the XML doc­ument, and replace them with explicit meaning labels.<footnote anchor="4"/>The tree structure of the document then becomes the sole repository of content, and can be viewed as a kind of <i>in-terlingua </i>for describing a point in the expressive space of the DTD (a strongly domain-dependent space); it is then the responsability of the language-specific rendering mechanisms to "display" such content in each individual language where the document is needed.</p><p><b>XML and Multilingual Document Authoring. </b>In this conception, XML authoring has a strong connection to the enterprise of <i>Multilingual Document Authoring </i>in which the author is guided in the specification of the document content, and where the system is responsible for generating from this content textual output in several languages simultaneously (see (Power and Scott, 1998; Hartley and Paris, 1997; Coch, 1996)).</p><footnote label="4">There are authoring situations in which it may be necessary for the user to introduce new semantic labels corresponding to expres­sive needs not foreseen by the creator of the original DTD. To handle such situations, it is useful to view the DTD's as open-ended objects to which new semantic labels and types can be added at authoring time.</footnote><p>Now there are some obvious problems with this view, due to the current limitations of XML tools.</p><p><b>Limitations of XML for multilingual document au­thoring. </b>The first, possibly most serious, limitation originates in the fact that a standard DTD is severely re­stricted in the semantic dependencies it can express be­tween two subtrees in the document structure. Thus, if in the description of a contact, a city of residence is in­cluded, one may want to constrain such an information depending on the country of residence; or, in the air­craft maintenance manual example, one might want to automatically include some warning in case a dangerous chemical is mentioned somewhere else in the document. Because DTD's are essentially of context-free expressive power, the only communication between a subtree and its environment has to be mediated through the name of the nonterminal rooting this subtree (for instance the nonter­minal ), which presents a bottleneckto informa-tionflow.</p><p>The second limitation comes from the fact that the cur­rent styling tools for rendering an XML document, such as CSS (Cascading Style Sheets), which are a strictly layout-oriented language, or XSLT (XSL transformation language), which is a more generic tool for transforming an XML document into another one (such as a display-oriented HTML file) are poorly adapted to linguistic pro­cessing. In particular, it seems difficult in such for­malisms to express such basic grammatical facts as num­ber or gender agreement. But such problems become central as soon as semantic elements corresponding to textual units below the sentence level have to be com­bined and rendered linguistically.</p><p>We will present two related proposals for overcom­ing these limitations. The first, the <i>Grammatical Frame­work (GF</i>)(Ranta, 2000), originates in constructive type-theory (Martin-Löf, 1984; Ranta, 1994) and in mathe­matical proof editors (Magnusson and Nordström, 1994). The second, <i>Interaction Grammars (IG), </i>is a specializa­tion of Definite Clause Grammars strongly inspired by GF. The two approaches present certain formal differ­ences that will not be examined in detail in this paper, but they share a number of important assumptions:<page local="3"/></p><p>The semantic representations are <i>strongly typed trees, </i>and rich dependencies between subtrees can be specified;</p><p>The abstract tree is <i>independent </i>of the different tex­tual realization languages;</p><p>The surface realization in each language is obtained by a <i>semantics-driven compositional process</i>;that is, the surface realizations are constructed by a bottom-up recursive process which associates sur­face realizations to abstract tree nodes by recur­sively combining the realizations of daugther nodes to obtain the realization of the mother node.</p><p>The grammars are <i>reversible, </i>that is, can be used both for generation and for parsing;</p><p>The authoring process is an interactive process of repeatedly asking the author to further specify nodes in the abstract tree of which only the type is known at the point of interaction <i>(type refinement). </i>This process is mediated through text in the lan­guage of the author, showing the types to be refined as specially highlighted textual units.</p></section><section number="2" title="GF — the Grammatical Framework"><p>The Grammatical Framework (GF; (Ranta, 2000)) is a special-purpose programming language combining <i>con­structive type theory </i>with an annotation language for concrete syntax. A <i>grammar, </i>in the sense of GF, defines, on one hand, an <i>abstract syntax </i>(a system of types and typed syntax trees), and on the other hand, a mapping of the abstract syntax into a <i>concrete syntax. </i>The abstract syntax has <i>category </i>declarations, such as</p><p><b>cat Country ; cat City ;</b></p><p>and <i>combinator </i>(or <i>function) </i>declarations, such as</p><doubt alpha="62.4" length="101" tooSmall="False" monospace="0.0">fun Ger : Country ; fun Fra : Country ; fun Ham : City ; fun Par : City ; fun cap : Country -&gt; City ;</doubt><p>The type of a combinator can be either a basic type, such as the type of the combinator , or a function type, such as the type of the combinator . Syntax trees formed by combinators of function types are com­plex functional terms, such as of type .</p><doubt alpha="85.7" length="7" tooSmall="False" monospace="0.0">cap Fra</doubt><p>The concrete syntax part of a GF grammar gives <i>lin­earization </i>rules, which assign strings (or, in general, more complex linguistic objects) to syntax trees. For the abstract syntax above, we may have</p><doubt alpha="58.2" length="122" tooSmall="False" monospace="0.0">lin Ger = "Germany" ; lin Fra = "France" ; lin Ham = "Hamburg" ; lin Par = "Paris" ; lin cap Co = "the capital of" ++ Co ;</doubt><p>Thus the linearization of is</p><p><b>the capital of France</b></p><subsection number="2.1" title="GF in XML"><p>Functional terms have a straightforward encoding in XML, representing a term of the form by the XML object</p><doubt alpha="55.6" length="9" tooSmall="False" monospace="0.0">f ai...an</doubt><doubt alpha="18.8" length="16" tooSmall="False" monospace="0.0">&lt;/&gt; a[...a'n&lt;//&gt;</doubt><p>where each    is the encoding of   . In this encoding, is</p><doubt alpha="60.0" length="5" tooSmall="False" monospace="0.0">&lt;cap&gt;</doubt><doubt alpha="60.0" length="5" tooSmall="False" monospace="0.0">&lt;Fra&gt;</doubt><doubt alpha="46.2" length="13" tooSmall="False" monospace="0.0">&lt;/Fra&gt; &lt;/cap&gt;</doubt><p>The simple encoding does not pay attention to the types of the objects, and has no interesting DTD. To express type distinctions, we will hence use a slightly more complicated representation, in which the category and combinator declarations of GF are represented as DTDs in XML, so that GF <i>type checking </i>becomes equiv­alent with XML <i>validation. </i>The representation of the GF grammar of the previous section is the DTD</p><p><b>&lt;!ELEMENT Country (Ger </b>I <b>Fra) &gt; &lt;!ELEMENT Ger EMPTY &gt; &lt;!ELEMENT Fra EMPTY &gt;</b> <b>&lt;!</b><b>ELEMENT City (Ham </b>I <b>Par </b>I   <b>(cap,Country))&gt; &lt;!ELEMENT Ham EMPTY &gt; &lt;!ELEMENT Par EMPTY &gt; &lt;!ELEMENT cap EMPTY &gt;</b></p><p>In this DTD, each category is represented as an ELE­MENT definition, listing all combinators producing trees of that category. The combinators themselves are repre­sented as EMPTY elements. The XML representation of the capital of France is which is a valid XML object w.r.t. the given DTD.</p><doubt alpha="66.7" length="6" tooSmall="False" monospace="0.0">&lt;City&gt;</doubt><doubt alpha="42.9" length="7" tooSmall="False" monospace="0.0">&lt;cap /&gt;</doubt><doubt alpha="58.8" length="17" tooSmall="False" monospace="0.0">&lt;Country&gt; &lt;Fra /&gt;</doubt><doubt alpha="61.1" length="18" tooSmall="False" monospace="0.0">&lt;/Country&gt; &lt;/City&gt;</doubt><p>The latter encoding of GF in XML enjoys two impor­tant properties:</p><p>All well-typed GF trees are represented by valid XML objects.</p><p>An XML represents a unique GF tree.</p><p>The first property guarantees that <i>type checking </i>in the sense of GF (and type theory) can be used for <i>validation </i>of XML objects. The second property guarantees that GF objects can be stored in the XML format. (The second property is already guaranteed by the simpler encoding, which ignores types.) Other properties one would desire are the following:</p><page local="4"/><p><b>the capital of France</b></p><p>All valid XML objects represent well-typed GF trees.</p><p>• A DTD represents a unique GF abstract grammar.</p><p>These properties cannot be satisfied, in general. The rea­son is that GF grammars may contain <i>dependent types, </i>i.e. types depending on objects. We will return to this notion shortly. But let us first consider the use of GF for multilingual generation.</p></subsection><subsection number="2.2" title="Multilingual generation in GF"><p>Multilingual generation in GF is based on <i>parallel gram­mars: </i>two (or more) GF grammars are parallel, if they have the same abstract syntax. They may differ in con­crete syntax. A grammar parallel to the one above is de­fined by the concrete syntax</p><p><b>param Case = nom </b>I <b>gen ;</b></p><doubt alpha="56.2" length="32" tooSmall="False" monospace="0.0">oper noml : Str -&gt; Case =&gt; Str =</doubt><doubt alpha="32.5" length="40" tooSmall="False" monospace="0.0">\s -&gt; tbl {{nom} =&gt; s, {gen} -&gt; s+"n"} ;</doubt><doubt alpha="50.0" length="42" tooSmall="False" monospace="0.0">oper nom2 : Str -&gt; Case =&gt; Str = \s -&gt; tbl</doubt><doubt alpha="35.1" length="37" tooSmall="False" monospace="0.0">{{nom} =&gt; s+"ki", {gen} -&gt; s+"gin"} ;</doubt><doubt alpha="57.8" length="64" tooSmall="False" monospace="0.0">lincat Country = Case =&gt; Str ; lincat City       = Case =&gt; Str ;</doubt><doubt alpha="62.4" length="117" tooSmall="False" monospace="0.0">lin Ger = noml "Saksa" ; lin Fra = noml "Ranska" ; lin Ham = noml "Hampuri" ; lin Par = noml "Pariisi" ; lin cap Co =</doubt><doubt alpha="54.8" length="42" tooSmall="False" monospace="0.0">tbl {c =&gt; Co Igen ++ nom2 "pääkaupun"!c} ;</doubt><p>This grammar renders GF objects in Finnish. In addition to linearization rules, it has rules introducing parameters and operations, and rules defining the <i>linearization types </i>corresponding to basic types: the linearization type of , for instance is not just string ( ), but a func­tion from cases to strings.</p><p>Not only the linearization rules proper, but also param­eters and linearization types vary a lot from one language to another. In our example, we have the parametre of case with two values (in larger grammars for Finnish, as many as 16 may be required!), and two patterns for inflecting Finnish nouns. The syntax tree produces the</p><doubt alpha="100.0" length="7" tooSmall="False" monospace="0.0">strings</doubt><p><b>Ranskan pääkaupunki Ranskan pääkaupungin</b></p><p>which are the nominative and the genitive form, respec­tively.</p></subsection><subsection number="2.3" title="Dependent types"><p>DTDs in XML are capable of representing <i>simple types, </i>i.e. types without dependencies. Even a simple type sys­tem can contribute a lot to the <i>semantic control </i>of doc­uments. For instance, the above grammar permits the formation of the English noun phrase but not of</p><p><b>the capital of Paris</b></p><p>Both of these expressions would be well-formed w.r.t. an "ordinary" grammar, in which both France and Paris would be classified simply as noun phrases.</p><p><i>Dependent types </i>are types depending on objects of other types. An example is the following alternative dec­laration of and :</p><p><b>cat Country ; cat City (Co:Country) ;</b></p><p>Under this definition, there are no objects of type <b>City </b>(which is no longer a well-formed type), but of types <b>City Ger </b>and <b>City Fra. </b>Thus we define e.g.</p><doubt alpha="60.3" length="78" tooSmall="False" monospace="0.0">fun Ham : City Ger ; fun Par : City Fra ; fun cap :  (Co:Country) -&gt; City Co ;</doubt><p>Observetheuseofthevariable inthetypeofthecom-binator capital: the variable is bound to the argument type and then used in the value type. The capital of a country is by definition a city of the same country. This involves a generalization of function types with depen­dent types.</p><p>Now consider a simplified format of postal addresses: an address is a pair of a country and a city. The GF rule is either using simple types or</p><doubt alpha="52.8" length="72" tooSmall="False" monospace="0.0">fun addr : Country -&gt; City -&gt; Address ; lin addr Co C = C ++ "," ++ Co ;</doubt><p><b>fun addr :</b></p><doubt alpha="50.7" length="69" tooSmall="False" monospace="0.0">(Co:Country) -&gt; City Co -&gt; Address ; lin addr Co C = C ++ "," ++ Co ;</doubt><p>using dependent types. The invalid address</p><p><b>Hamburg, France</b></p><p>is well-typed by the former definition but not by the lat­ter. Using the latter definition gives a simple mechanism of <i>semantic control </i>of addresses. The same idea can ob­viously be extended to full addresses with street names and numbers. Such dependencies cannot, however, be expressed in DTDs: both of the address rules above cor­respond to one and the same ELEMENT definition,</p><p><b>&lt;!ELEMENT Address (addr, Country, City) &gt;</b></p><p>This example also shows that XML validity is not enough for GF well-formedness: the object is valid w.<page local="5"/>r.t. the DTD, but the corresponding GF object</p><doubt alpha="64.3" length="28" tooSmall="False" monospace="0.0">&lt;Address&gt; &lt;addr /&gt; &lt;Country&gt;</doubt><doubt alpha="56.0" length="25" tooSmall="False" monospace="0.0">&lt;Fra /&gt; &lt;/Country&gt; &lt;City&gt;</doubt><doubt alpha="53.8" length="26" tooSmall="False" monospace="0.0">&lt;Ham /&gt; &lt;/City&gt; &lt;/Address&gt;</doubt><p><b>addr Fra Ham </b>is not well-typed. <b>2.4   Computation rules</b></p><p>In addition to categories and combinators, GF grammars may contain <i>definitions,such </i>as</p><doubt alpha="63.2" length="19" tooSmall="False" monospace="0.0">def cap Fra = Par ;</doubt><p>Definitions belong to the abstract syntax. They define a <i>normal form </i>for syntax trees (recursively replace de-fienda by definientes), as well as a <i>paraphrase </i>relation (sameness of normal form). These notions are, of course reflected in the concrete syntax: the addresses</p><p><b>the capital of France, France Paris, France</b></p><p>are paraphrases, and the latter is the normal form of the former.</p><p>text.</p></subsection><subsection number="2.5" title="GF editing tools"><p>An editing tool has been implemented for GF, using <i>metavariables </i>to represent yet undefined parts of expres­sions. The user can work on any metavariable, in various different ways, e.g.</p><p>by choosing a combinator from a menu, by entering a string that is parsed, by using an automatic search of suitable instantia­tions.• by reading a previously defined object from a file,</p><p>These functionalities and their metatheory have been used for about a decade in a number of syntax edi­tors for constructive type theory, usually known as <i>proof editors </i>(Magnusson and Nordström, 1994). From this point of view, the GF editor is essentially a proof edi­tor together with supplementary views, provided by the concrete syntax. The current implementation of GF is a plugin module of the proof editor Alfa (Hallgren, 2000). The window dump in Figure 2 shows a GF ses­sion editing a mathematical proof. Five views are pro­vided: abstract syntax in type-theoretical notation, En­glish, French, Finnish, and XML. One metavariable is seen, expecting the user to find a <b>Proof </b>of the proposi­tion that there exists a number such that is smaller than ,where is an arbitrary number given in the con­text (for the sake of Universal Introduction).</p></subsection></section><section number="3" title="IG : Interaction Grammars"><p>We have just described an approach to solving the limita­tions of usual XML tools for multilingual document au­thoring which originates in the tradition of constructive type-theory and mathematical proof editors. We will now sketch an approach strongly inspired by GF but which formally is more in the tradition of logic-programming based unification grammars, and which is currently un­der development at Xerox Research Centre Europe (see (Brun et al., 2000) for a more extended description of this project).</p><p>Definite Clause Grammars, or DCG's, (Pereira and Warren, 1980), are possibly the simplest unification-based extension of context-free grammars, and have good reversibility properties which make them adapted bothto parsing and to generation. A typical view of what a DCG rule looks like is the following:<footnote anchor="5"/></p><doubt alpha="38.6" length="57" tooSmall="False" monospace="0.0">a(al(B,C,...)) --&gt; &lt;textl&gt;, b(B), &lt;text2&gt;, c(C), &lt;text3&gt;,</doubt><p><b>{constraints(B,C,...)}.</b></p><p>This rule expresses the fact that (1) some abstract structure is in category   if the structure</p><p>is in category , the structure in category , ... , and furthermore a certain number of constraints are satisfied by the structures <b>B</b>, <b>C,</b>(2) if the structures <b>B</b>, <b>C,</b>... can be "rendered" by character strings , , ... , then the structure can be rendered by the string obtained by concatenating the text (that is, a certain constant sequence of terminals), then ,then ,then ,etc.</p><p>In this formalism, a grammar for generating English addresses (see preceding section) might look like:</p><footnote label="5">Reminder: according to the usual logic programming conventions, lowercase letters denote predicates and functors, whereas uppercase letters denote metavariables that will be instantiated with terms.</footnote><table caption="Figure 2: GF session for editing a mathematical proof" class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>■ *fc£.:&lt;M<b>-ÛE</b>-M nr* <b>lî </b><b>-nu</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>'h </b><b>9</b>|l* B|"4b* BI<b>&lt;V"h Ü </b>|Ulb 4ll</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>■MVt </b>W<b>)lt-*hl*.].fJ f1l»|   ■ T*rt</b></p><p><i>(.W </i>*t ■: \ ■ <i>-■• </i><b>E</b><b>-LFi </b>IW U       <i>IW: ■ ■ ))) </i>OM^HfJIltt^e^lHlthH'-kUIHHH-UUH <i>—Infi </i><b>tara. rar </b><b><i>mil</i></b><b><i> </i></b><b>1</b><b>.ÉVTH, </b>1tn»Mi <b>1 nj</b><b>Ér</b><b> </b><b>H</b><b><footnote anchor="1"/> Euzh </b><b><i>Ornln </i></b>linllrtta'^ <b>. rVcnl</b><b><i>. </i></b><b>Lmj </b>v <b><i>m </i></b><b>rtaLlrmy</b></p><p><b>rxiic^--' îuchv»t ■ J s SMLUr Vanx'..</b></p><p><b>Im'^m </b><b>fT</b><b>.rn.'. &gt;'.iinf^«,   </b><b>II</b><b> kiilimmlwr' </b>1</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>rnrin x vtl-jm <b>x</b><b><i>.</i></b><b><i> </i></b><b>lL </b><b>wLrl* </b><b>LM1 </b>m</p><p><b>Lux. </b>DLLnfelàlk x.\ JùLlwWM. <b>.1.</b></p><p>ei&gt;w« Wu ■■ <b>^itjj</b></p><p><b>jiLLa </b>fulM-, Kti -</p><p>rted' tfMUfa-Pra <b>■ftin </b><b>- ■£nlÄ<footnote anchor="1"/>:' </b>ilr Cjfrùp&gt; <b>■/Kl*; &lt;ff </b>■ ."Hoi ■   Pv^o- ■&gt;!■«</p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>«■Min-] ur. x<b>^hrn</b></p><p>*r|       Hjno « (H « Prw. ■ » hw •VM     <b>fenE </b>* (C • <b>ft-np. </b><b>e </b>4 ft<b>-n* </b>Cxlxtl <b>«in«</b><b> </b>In. ! « <b>Ix </b><b>4 </b><b>•PCI                   </b>|r - <b>Frnrf T</b>.-.l- <b>1 .</b></p><p>W « <b>h &lt; </b><b>EJt- - </b>1 <b>E</b>'Lill ,        <b>Dl-. </b>»4 Ix 4 " ',t<b>&lt;IW</b><b>!bi) </b><b>UlLvt * JR </b>4 <b><i>Om.</i></b><b><i> </i></b>111'.,-</p><p>•fl      [iolEctH.gePMx.ce* 1</p><p><b>* <footnote anchor="1"/>                'id - (Vu h™f *| -   </b><b>1 </b><b>JJ</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>1</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table><page local="6"/><doubt alpha="59.4" length="32" tooSmall="False" monospace="0.0">address(addr(Co,C)) --&gt; city(C),</doubt><p><b>country(Co). country(fra) --&gt; "France". country(ger) --&gt; "Germany". city(par) --&gt; "Paris", city(cap(Co)) --&gt; "the capital of", country(Co).</b></p><p>The analogies with the GF grammars of the previous section are clear.  What is traditionally called a cate­gory (or nonterminal, or predicate) in the logic program­ming terminology, can also be seen as a type ( , ,       ) and functors such as      ,      , , can be seen as combinators. If, in this DCG, we "forget" all the constant strings by replacing them with the empty string, we obtain the following "abstract grammar":</p><p><b>address(addr(Co,C)) --&gt; city(C), country(Co).</b></p><p><b>country(fra) --&gt; </b><b>[].</b></p><p><b>country(ger) --&gt; </b><b>[].</b></p><p><b>city(par) --&gt; </b><b>[].</b></p><p><b>city(cap(Co)) --&gt; country(Co).</b></p><p>which is in fact equivalent to the definite clause <i>pro-</i></p><doubt alpha="66.7" length="6" tooSmall="False" monospace="0.0">gram:6</doubt><p><b>address(addr(Co,C)) :- city(C), country(Co). country(fra). country(ger). city(par).</b></p><p><b>city(cap(Co)) :- country(Co).</b></p><p>This program is language-independent and recursively defines a set of well-formed trees to which it assigns types (thus is a well-formed tree of type ).</p><p>As they stand, such definite clause grammars and pro­grams, although suitable for simple generation tasks, are not directly adapted for the process of interactive multi­lingual document authoring. In order to make them more appropriate for that task, we need to specialize and adapt DCGs in the way that we now describe.</p><p><b>Parallel grammars. </b>The first move is to allow for parallel English, French, ... , grammars, which all have the same underlying abstract grammar (program). So in addition to the English grammar given above, we have the French grammar:</p><doubt alpha="65.5" length="29" tooSmall="False" monospace="0.0">address(addr(Co,O)--&gt;city(C),</doubt><p><b>country(Co). country(fra) --&gt; "la France". country(ger) --&gt; "l'Allemagne". city(par) --&gt; "Paris", city(cap(Co)) --&gt; "la capitale de", country(Co).</b></p><footnote label="6">In    the    sense    that    rewriting    the    nonterminal goal to the empty string in the DCG is equivalent to proving the goal in the program (Deransart</footnote><p>and Maluszynski, 1993).</p><p><b>Dependent Categories. </b>The grammars we have given are deficient in one important respect: there is no de­pendency between the city and the country in the same address. In order to remedy this problem, a stan­dard logic programming move would be to reformulate the abstract grammar (and similarly for the language-dependent ones) as:</p><doubt alpha="60.0" length="35" tooSmall="False" monospace="0.0">address(addr(Co,C)) --&gt; city(C,Co),</doubt><p><b>country(Co) .</b></p><p><b>city(par,fra) --&gt; </b><b>[].</b></p><p><b>city(cap(Co),Co) --&gt; country(Co) .</b></p><p>The expression is usually read as the relation "C is a city of Co", which is fine for computational purposes, but this reading obscures the notion that the object is being <i>typed </i>as a ; more precisely, it is being typed as a of . In order to make this read­ing more apparent, we will write the grammar as:</p><doubt alpha="61.8" length="34" tooSmall="False" monospace="0.0">address(addr(Co,C)) --&gt; cityCo(C),</doubt><p><b>country(Co).</b></p><p><b>country(fra) --&gt; </b><b>[].</b><b> country(ger) --&gt; </b><b>[].</b><b> cityfra(par) --&gt; </b><b>[]</b><b> </b><b>.</b><b> cityCo(cap(Co)) --&gt; country(Co).</b></p><p>That is, we allow the categories to be indexed by terms (a move which is a kind of "currying" of a relation into a type for its first argument). Dependent categories are similar to the dependent types of constructive type the­ory.</p><p><b>Heterogeneous trees. </b>Natural language authoring is different from natural language generation in one cru­cial respect. Whenever the abstract tree to be generated is incomplete (for instance the tree ), that is, has some leaves which are yet uninstantiated variables, the generation process should not proceed with nonde-terministically enumerating texts for all the possible in­stantiations of the initial incomplete structure. Instead it should display to the author as much of the text as it can in its present "knowledge state", and enter into an inter­action with the author to allow her to further refine the incomplete structure, that is, to further instantiate some of the uninstantiated leaves. To this purpose, it is use­ful to introduce along with the usual combinators ( , , , etc.) new combinators of arity 0 called <i>type-names, </i>which are notated <b>type, </b>and are of type . These combinators are allowed to stand as leaves (e.g. in the tree <b>country </b>) and the trees thus obtained are said to be <i>heterogeneous. </i>The typenames are treated by the text generation process as if they were standard se­mantic units, that is, they are associated with text units which are generated "at their proper place" in the gen­erated output. These text units are specially phrased and highlighted to indicate to the author that some choice has to be made to refine the underlying type (e.g. obtaining the text "la capitale de PAYS").<page local="7"/> This choice has the effect of further instantiating the incomplete tree with "true" combinators, and the generation process is iterated.</p><p><b>Extended semantics-driven compositionality. </b>The simple DCG view presented at the beginning of this sec­tion sees the process of generating text from an abstract structure as basically a compositional process on strings, that is, a process where strings are recursively associated with subtrees and concatenated to produce strings at the next subtree level. Butsuch a direct process ofconstruct-ing strings has well-known limitations when the seman­tic and syntactic levels do not have such a direct corre­spondence (simple example: ordering a list of modifiers around a noun). We are currently experimenting with a powerful extension of string compositionality where the objects compositionally associated with abstract subtrees are not strings, but syntactic representations with rich in­ternal structure. The text itself is obtained from the syn­tactic representation associated with the total tree by sim­ply enumerating its leaves.</p><p>The picture we get of an IG grammar is finally the following:</p><doubt alpha="39.0" length="59" tooSmall="False" monospace="0.0">aD)...(al(B,C, . . . ))-Syn --&gt; bE,...(B)-SynB, cF(C)-SynC,</doubt><p><b>{constraints(B,C,...,D,E,F,...)}, {compose_english(SynB, SynC, Syn)}.</b></p><p>The rule shown is a rule for English: the syntactic representations are language dependent; Parallel rules for the other languages are obtained by replacing the constraint (which is unique to this rule) by constraints appropriate to the other languages under consideration.</p></section><section number="4" title="Conclusion"><p>XML-based authoring tools are more and more widely used in the business community for supporting the pro­duction of technical documentation, controlling their quality and improving their reusability. In this paper, we have stressed the connections between these practices and current research in natural language generation and authoring. We have described two related formalisms which are proposals for removing some of the limitations of XML DTD's when used for the production of multi­lingual texts.</p><p>From a computational linguist's point of view, there might be little which seems novel or exciting in XML representations. Still XML has a great potential as a <i>lin­gua franca </i>and in driving a large community of users towards authoring practices where content is becoming more and more explicit. There may be a great opportu­nity here for researchers in natural language generation to connect to a growing source of applications.</p></section><section title="Acknowledgements"><p>Thanks for contributions, discussions and comments to Ken Beesley, Caroline Brun, Jean-Pierre Chanod, Marie-Hélène Corréard, Pierre Isabelle, Bengt Nordström, Syl­vain Pogodalla and Annie Zaenen.</p></section><references><p>C. Brun, M. Dymetman, and V. Lux. 2000. Document structure and multilingual authoring. In <i>Proceedings of First International Natural Language Generation Confer­ence (INLG '2000), </i>Mitzpe Ramon, Israel, June.</p><p>J. Coch. 1996. Evaluating and comparing three text production techniques. In <i>Proceedings of the 16th International Confer­ence on Computational Linguistics.</i></p><p>P. Deransart and J. Maluszynski. 1993. <i>A Grammatical View of Logic Programming. </i>MIT Press.</p><p>Thomas Hallgren. 2000. Alfa Home Page. Available from http ://www.cs.Chalmers.se/~hallgren/Alfa/</p><p>A. Hartley andC. Paris. 1997. Multilingual document produc­tion: from support for translating to support for authoring. In <i>Machine Translation, Special Issue on New Tools for Hu­man Translators, </i>pages 109-128.</p><p>L. Magnusson and B. Nordström. 1994. The ALF proof editor and its proof engine. In <i>Lecture Notes in Computer Science 806. </i>Springer.</p><p>P. Martin-Löf. 1984. <i>Intuitionistic Type Theory. </i>Bibliopolis, Naples.</p><p>W. Pardi. 1999. <i>XML in Action. </i>Microsoft Press.</p><p>Fernando C. N. Pereira and David H. D. Warren. 1980. Defi­nite clause grammars for language analysis. <i>Artificial Intel­ligence, </i>13:231-278.</p><p>R. Power and D. Scott. 1998. Multilingual authoring using feedback texts. In <i>Proceedings of the 17th International Conference on Computational Linguistics and 36th Annual Meeting ofthe Association for Computational Linguistics, </i>pages 1053-1059.</p><p>P. Prescod. 1998. Formalizing SGML and XML In­stances and Schemata with Forest Automata Theory. http ://www.prescod.net/forest/shorttut/.</p><p>A. Ranta. 1994. <i>Type-Theoretical Grammar. </i>Oxford Univer­sity Press.</p><doubt alpha="62.3" length="53" tooSmall="False" monospace="0.0">Aarne Ranta.   2000.   GF Work Page.   Available from</doubt><p>http://www.cs.Chalmers.se/~aarne/GF/</p><p>pub/work-<b>index/ </b>W3C, 1998. <i>Extensible Markup Language (XML) </i>1.0,Febru-</p><doubt alpha="63.6" length="77" tooSmall="False" monospace="0.0">ary. W3C recommendation. W3C, 1999a.XML Schema - Part 1: Structures, Part 2 :</doubt><p><i>Datatypes -, </i>December. W3C Working draft. W3C, 1999b. <i>XSL Transformations (XSLT), </i>November. W3C recommendation.</p></references></body></article>