<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-1428">
  <Title>EXEMPLARS: A Practical, Extensible Framework For Dynamic Text Generation</Title>
  <Section position="4" start_page="267" end_page="270" type="metho">
    <SectionTitle>
2 Dynamically Generating HTML
</SectionTitle>
    <Paragraph position="0"> In this section we sketch how the EXEMPLARS framework can be used to dynamically generate HTML, using Project Reporter as an example. Project Reporter is an innovative web-based tool for monitoring the status of a project. Using information obtained from a project management database, Project Reporter automatically generates fluent natural-language reports describing task progress, staffing, labor expenditures, and costs for a project. It also displays project data in tables and in Gantt chart form,  providing a complete multimodal viewof the project's status. See Figure 1 for a screenshot.</Paragraph>
    <Paragraph position="1"> The main idea behind the EXEMPLARS framework is to enable the designer to determine the behavior of a dynamic (hyper-) text generation system by writing a set of object-oriented text planning rules and arranging them into a specialization hierarchy, where more specialized rules can augment or override the more general ones they specialize. * By text planning rules, we mean rules that determine the content and form of the generated text. Each such rule has a condition and an action: the condition defines the applicability of the rule in terms of tests on the input application objects, the discourse context, and the user model, whereas the action defines what text to add to the current output and how to update the discourse context and user model.</Paragraph>
    <Paragraph position="3"> For purposes of exposition, we have extracted a subset of Project Reporter's exemplars and simplified them to use a much-reduced application object model, part of which is shown in the UML diagram in Figure 2. As the diagram indicates, tasks and milestones in a project are represented using Task and Milestone classes, where their common features are abstracted into the base class TaskOrMilestone. To generate an HTML page for a task or milestone along the lines of the one shown in Figure 1, the generator invokes the top-level exemplar ShowTaskOrMilestone with the given task or milestone. This exemplar sets up the HTML page, adds a table with basic data, and then calls * other exemplars *, including the DescribeTaskOrMilestoneStatus exemplar, to add appropriate text for the task or milestone. The call from ShowTaskOrMilestone to DescribeTaskOrMilestoneStatus is reflected in the UML diagram in Figure 3 by the dependency arrow between the two. The other two dependency arrows in the diagram show that</Paragraph>
    <Paragraph position="5"> DescribeTaskOrMilestoneStatus in turn makes use of AddBaselineStatusModifier and IdentifyDate.</Paragraph>
    <Paragraph position="6"> A call to DescribeTaskOrMilestoneStatus produces text such as This task started last Saturday, June 13, and is scheduled to finish July 9, three days ahead of the baseline schedule. It is Currently 10% complete.</Paragraph>
    <Paragraph position="7"> Exemplar calls are mediated by the text planner component of the framework, which automatically selects the most specific applicable exemplar to actually apply in the current context. For example, the above text would be produced by the DescribeTaskStatus exemplar, whose source is shown in Figure 4; this exemplar is chosen when the given task or milestone is in fact a task, and is currently in progress.</Paragraph>
    <Paragraph position="8"> To find the most specific applicable exemplar, the text planner traverses the specialization hierarchy top-down and left-to-right, 2 evaluating applicability as it goes; the traversal is similar to that of a decision 2 Left-to-right order is determined by the order in which exemplar definitions appear in the source file.</Paragraph>
    <Paragraph position="9">  tree, insofar as applicability conditions are implicitly conjoined, except that the search may end at a non-leaf node in the hierarchy. To determine whether a particular exemplar is applicable, the text planner first checks the type constraints on the exemplar's arguments, then evaluates any explicitly defined conditions.</Paragraph>
    <Paragraph position="10"> Once the most specific applicable exemplar is found, its exclusion conditions (if any) are checked, to see if it is optional and should be skipped in the given context; if not, its action is invoked at this point. In the Case of the exemplars* shown in Figure 3, the exemplars under DescribeTaskOrMilestoneStatus define their applicability conditions using the methods of the task or milestone's associated CompletionStatus object; the exemplar AddBaselineStatusModifier is optional, and defines its exclusion conditions using  the methods of the task or milestone's associated BaselineStatus object.</Paragraph>
    <Paragraph position="11"> As mentioned in the introduction, exemplars are defined using a superset of Java, and then compiled down to pure Java. A source file normally contains a set of related exemplars, each of which is compiled * into a separate Java class files (though all in the same package). The compilation process consists of (i) translating the signatur e into a set of constructors and methods that implement it; (ii) translating any * statements to add annotated HTML, including any embedded simple substitutions or exemplar calls, such as those shown in Figure 4; and (iii) passing through any Java code in-between. While the DescribeTaskStatus exemplar in Figure 4 happens to not contain additional Java code, exemplars often contain loops, local variables, try-catch blocks, auxiliary methods, and so on.</Paragraph>
    <Paragraph position="13"> From the perspective of everyday object-oriented design, the way in which exemplars are treated as first-class objects is quite similar to the way methods are promoted to objects in certain design patterns, such as the Command pattern in \[Gamma et al. 95\]. While the Command pattern promotes methods to objects so that they can be tracked and possibly undone, the primary reason for doing so with exemplars is so that they can become essentially self-specializing. Additionally, the way in which type constraints are used in specialization resembles the Visitor pattern, whose primary purpose is to group closely related methods.</Paragraph>
    <Paragraph position="14"> for various classes in one place, rather than having them scattered over many classes. Exemplars are much more flexible than visitors, however, since they support arbitrary applicability conditions plus type-</Paragraph>
    <Paragraph position="16"> based selection on multiple arguments.</Paragraph>
  </Section>
  <Section position="5" start_page="270" end_page="271" type="metho">
    <SectionTitle>
3 Specialization and Extensibility
</SectionTitle>
    <Paragraph position="0"> To further illustrate the role of specialization and extensibility in managing *textual variation, we will now examine how dates are referred to in a context-sensitive way in Project Reporter. The IdentifyDate exemplar referenced in Figure 4, along with its specializations, form a separate reusable package. These exemplars are shown in the annotated UML diagram in Figure 5.</Paragraph>
    <Paragraph position="1"> The IdentifyDate exemplars yield descriptions that are sensitive both to the current date and the last *date mentioned. If the given date is the same as the last one mentioned, the phrase the same day is used, as in  This task is scheduled tostart next Thursday, June 25, and to finish the same day. If the givendate is not the same as the last one mentioned, the phrase used depends on how close it is to the current date, as Figure 5 shows.</Paragraph>
    <Paragraph position="2"> The apply method calls addDescription \[~ \[ and updateDateFocus, so that the .  |\] IdentlfyDate &amp;quot; description can be separately augmented  ||  Several aspects of the diagram merit further explanation. First, the context object associated with each instance of IdentifyDate is required to implement the DateContext interface, which provides the indicated methods for tracking the last date mentioned. Second, the IdentifyDate exemplar breaks down its apply method (its action) into two methods, addDescription and updateDateFocus, so that the description can be separately specialized in descendant exemplars. Third, it should be emphasized that the ability to extend the framework in this way follows from the treatment of exemplar.s as first-class objects plus the *. 272 | ! definition language allowing for arbitrary Java code. Finally, note that while some exemplars, such as IdentifyDatelnFocus and IdentifyDateWithinADay, simply override the description of their parent exemplar (a.k.a. their 'super', in Java terminology), most of these exemplars instead augment the less specialized phrase with additional modifiers.</Paragraph>
  </Section>
class="xml-element"></Paper>