<?xml version="1.0" standalone="yes"?>
<Paper uid="P06-2032">
  <Title>Pros Cons Practice Export Economy Name management Use in linguistically motivated Not with multiple inheritance sub-hierarchy Not with conjunction Not with disjunction Not with multiple reuse Colours Economy ++ Non deterministic Multiple reuse OK Not with inheritance Use when a given class and identically named identifiers combines with many classes Interface Global Name management Use for Syntax/Semantic interface Explicit identification Usable in all cases Uneconomical Last Resort solution</Title>
  <Section position="3" start_page="247" end_page="249" type="metho">
    <SectionTitle>
2 The XMG formalism
</SectionTitle>
    <Paragraph position="0"> We start by briefly introducing XMG (eXtended MetaGrammar). First, we show that it supports the description and the combination of blocks consisting of tree fragments and/or semantic representations. Then, we show that it supports a sophisticated treatment of identifiers.</Paragraph>
    <Section position="1" start_page="247" end_page="247" type="sub_section">
      <SectionTitle>
2.1 Defining blocks
</SectionTitle>
      <Paragraph position="0"> At the syntactic level, the basic units are tree descriptions which are specified using the following tree logic: 2Recently, (Villemonte de la Clergerie, 2005) has proposed a highly compact representation formalism for tree-based grammars which also features explicit identifier management. His approach differs from ours in that it includes neither a colouring mechanism (cf. section 3.4) nor interfaces (cf. section 3.3).</Paragraph>
      <Paragraph position="2"> where x, y represent node variables, - immediate dominance (x is directly above y), -+ strict dominance (x is above y), and -[?] large dominance3 (x is above or equal to y). Similarly [?] denotes immediate precedence, [?]+ strict precedence, and [?][?] large precedence. Finally x[f:E] constrains feature f with associated expression E on node x, and x = y indicates node identification.</Paragraph>
      <Paragraph position="3"> The XMG formalism also supports the association of semantic representations with elementary trees. The semantic representation language is a flat semantic representation language (Bos, 1995) with the following syntax:</Paragraph>
      <Paragraph position="5"> (2) where lscript is a label, p is a predicate and E1, .., En are parameters. Further, ! denotes negation and Ei lessmuch Ej expresses a scope constraint between Ei and Ej (Ej is in the scope of Ei).</Paragraph>
    </Section>
    <Section position="2" start_page="247" end_page="248" type="sub_section">
      <SectionTitle>
2.2 Combining blocks
</SectionTitle>
      <Paragraph position="0"> As in other existing tree-based formalisms, in XMG, blocks can be combined using inheritance.</Paragraph>
      <Paragraph position="1"> However, XMG additionally supports block conjunction and block disjunction.</Paragraph>
      <Paragraph position="2"> Specifically, a Class associates a name with a content: Class ::= Name - {Content} (3) A Content is either a Description (i.e., a tree description, a semantic formula or both), a class name, a conjunction or a disjunction of class name:</Paragraph>
      <Paragraph position="4"> Further, XMG allows multiple inheritance: a given class can import or inherit one or more classes  Class ::= Namenegationslash C1 [?] . . . [?] Cn - {Content} (5) The semantic of the import instruction is to include the description of the imported class within the current one. This makes it possible to refine a class e.g., by adding information to a node or by adding new nodes4.</Paragraph>
    </Section>
    <Section position="3" start_page="248" end_page="249" type="sub_section">
      <SectionTitle>
2.3 Managing identifiers
</SectionTitle>
      <Paragraph position="0"> We now introduce the treatment of identifiers supported by XMG. We show in particular, that it integrates: null * a convenient way of managing identifier scope based on import/export declarations inspired from standard Object Oriented Programming techniques (section 2.3.1); * an alternative means of identifying feature values based on the use of unification * polarity- (here called colour-) based node identification as first proposed in (Muskens and Krahmer, 1998) and later used in (Duchier and Thater, 1999; Perrier, 2000).</Paragraph>
      <Paragraph position="1"> The next sections will detail the linguistic and technical motivations behind this variety of identifier handling techniques.</Paragraph>
      <Paragraph position="2">  In XMG, the default scope of an identifier is the class in which it is declared. However, export specifications can be used to extend the scope of a given identifier outside its declaration class. The export of identifier ?X ouside class A is written :5 A?X - {. . . ?X . . .} Export declarations interact with inheritance, conjunction and disjunction specifications as follows (where A,B,C are classes): Inheritance: if the class A is imported either directly or indirectly by a class B, then ?X is visible in B. In case of multiple inheritance 4Note that disjunctive inheritance is not supported which would allow a block to be defined as importing one or more classes from a given set of imported classes 5Similarly, import declaration can be used to restrict the set of accessible identifiers to a subset of it. e.g., if Bnegationslash C1 [?] . . . [?] Cn , then all identifiers exported by C1 [?] . . . [?] Cn are visible from B provided they have distinct names.</Paragraph>
      <Paragraph position="3"> In other words, if two (or more) classes in C1 [?] . . . [?] Cn export the same identifier ?X, then ?X is not directly visible from B. It can be accessed though using the dot operator.</Paragraph>
      <Paragraph position="4"> First A is identified with a local identifier (e.g., ?T = A), then ?T.?X can be used to refer to the identifier ?X exported by A.</Paragraph>
      <Paragraph position="5"> Conjunction: if classes A and B are conjoined inside a class C, then all the identifiers exported by A or B are visible within C using the dot operator.</Paragraph>
      <Paragraph position="6"> Disjunction: if classes A and B are disjoined inside a class C, then all the identifiers exported by A or B are visible within C using the dot operator. However in this case, both A and B have to be associated with the same local identifier.</Paragraph>
      <Paragraph position="7"> In sum, export/import declarations permit extending/restricting the scope of an identifier within a branch of the inheritance hierarchy whilst the dot operator allows explicit access to an inherited identifier in case the inheriting class either displays multiple inheritance or is combined by conjunction or disjunction with other classes. More specifically, inheritance allows implicit coreference (the use of an imported name ensures coreference with the object referred to when declaring this name) and the dot operator explicit coreference (through an explicit equality statement e.g., ?A.?X = ?B.?Y).</Paragraph>
      <Paragraph position="8">  In XMG, a class can be associated with a class interface i.e., with a feature structure. Furthermore, when two classes are related either by inheritance or by combination (conjunction or disjunction), their interfaces are unified. Hence class interfaces can be used to ensure the unification of identifiers across classes.</Paragraph>
      <Paragraph position="9"> Here is an illustrating example:</Paragraph>
      <Paragraph position="11"> In A (resp. B), the local identifier ?X (resp. ?Y) is associated with an interface feature named n1. If  these two classes are combined either by conjunction or by inheritance, their interfaces are unified and as a result, the local identifiers ?X and ?Y are unified. In the case of a disjunction, the interface of the current class (C here) is non deterministically unified with that of A or B.</Paragraph>
      <Paragraph position="12"> In practice, interface-based identification of values is particularly useful when two distinct features need to be assigned the same value. In (Gardent, 2006) for instance, it is used to identify the semantic index associated with e.g., the subject node of a verbal tree and the corresponding semantic index in the semantic representation associated with that tree.</Paragraph>
      <Paragraph position="13">  Finally, XMG provides a very economical way of identifying node variables based on the use of colours (also called polarities in the literature). The idea is that node variables are associated with a specific colour and that this colouring will either prevent or trigger node identifications based on the following identification rules:</Paragraph>
      <Paragraph position="15"> and on the requirement that valid trees only have red or black nodes. In effect, node colouring enforces the following constraints : (i) a white node must be identified with a black node, (ii) a red node cannot be identified with any other node and (iii) a black node may be identified with one or more white nodes.</Paragraph>
      <Paragraph position="16"> Contrary to other means of value identification, colours are restricted to node identifiers. Hence they are best used to induce node identification in those contexts where neither inheritance nor explicit identification are appropriate (see section 4).</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="249" end_page="250" type="metho">
    <SectionTitle>
3 XMG at work
</SectionTitle>
    <Paragraph position="0"> Recall (section 1) that one main problem when developing a factorised specification of tree based grammars is to ensure a consistent treatment of identifiers and in particular, of identifier unification. That is, when combining two units of information, the grammar writer must ensure that her specification correctly states which objects are the same and which are distinct.</Paragraph>
    <Paragraph position="1"> In what follows, we show that XMG supports four different ways of identifying objects. We illustrate this by demonstrating that the following tree can be obtained in four different ways:  In section 4, we will show that these four ways of identifying nodes and/or features values support both explicitness and economy thereby reducing the risks of specification errors.</Paragraph>
    <Section position="1" start_page="249" end_page="249" type="sub_section">
      <SectionTitle>
3.1 Using explicit identification
</SectionTitle>
      <Paragraph position="0"> The most basic way to identify two identifiers is to explicitly state their identity. Thus the above tree can be produced by combining the following two</Paragraph>
      <Paragraph position="2"> To improve readability, we use from now on a graphical representation. For instance, the classes above are represented as follows (exported identifiers are underlined and boxed letters indicate class</Paragraph>
      <Paragraph position="4"> Thus, the class Adescribes the left branch of the tree in Figure 1 and the class B1 its right branch.</Paragraph>
      <Paragraph position="5"> The root of A and B are named ?X and ?U respectively. Since ?X is exported, ?X is visible in B1. The explicit identification ?U=A.?X then enforces that the two roots are identified thus constraining the solution to be the tree given in Figure 1.</Paragraph>
    </Section>
    <Section position="2" start_page="249" end_page="250" type="sub_section">
      <SectionTitle>
3.2 Using inheritance
</SectionTitle>
      <Paragraph position="0"> Using inheritance instead of conjunction, the same nodes identification can be obtained in a more economical way. We reuse the same class A as before, but we now define a class B 2 as a sub-class of A:a3</Paragraph>
      <Paragraph position="2"/>
      <Paragraph position="4"> Since the identifiers ?X and ?Y are exported by A, they are visible in B2. Thus, in the latter we only have to indicate the precedence relation between ?Y and ?Z.</Paragraph>
      <Paragraph position="5"> In sum, the main difference between explicit identification and identification through simple exports, is that whilst inheritance of exported identifiers gives direct access to these identifiers, class combination requires the use of a prefix and dot statement. Note nevertheless that with the latter, identifiers conflicts are a lot less likely to appear.</Paragraph>
    </Section>
    <Section position="3" start_page="250" end_page="250" type="sub_section">
      <SectionTitle>
3.3 Using interfaces
</SectionTitle>
      <Paragraph position="0"> A third possibility is to use interfaces to force node identifications as illustrated in figure 2.</Paragraph>
      <Paragraph position="2"> Class A is the same as before except that the identifiers ?X and ?Y are no longer exported. Instead they are associated with the interface features root and nNode respectively. Similarly, classB3 associates the identifiers (?Uand?V) with the interface features root and nNode. As the tree fragment of class B3 is conjoined with A, the interface features of A and B3 are unified so that ?X is identified with ?U and ?Y with ?V.</Paragraph>
    </Section>
    <Section position="4" start_page="250" end_page="250" type="sub_section">
      <SectionTitle>
3.4 Using node colours
</SectionTitle>
      <Paragraph position="0"/>
      <Paragraph position="2"> Now, class B4 contains three nodes: two white ones whose categories are s and n and which must be identified with compatible black nodes in A; and a black node that may but need not be identified with a white one. To satisfy these constraints, the black s node in A must be identified with the white s node in B and similarly for the n nodes.</Paragraph>
      <Paragraph position="3"> The result is again the tree given in Figure 1.</Paragraph>
      <Paragraph position="4"> Note that in this case, none of the identifiers need to be exported. Importantly, the use of colours supports a very economical way of forcing nodes identification. Indeed, nodes that are identified through colouration need neither be exported nor even be named.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>