<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-1013">
  <Title>Document Transformations and Information States</Title>
  <Section position="7" start_page="118" end_page="119" type="concl">
    <SectionTitle>
6 Discussion and Research Issues
</SectionTitle>
    <Paragraph position="0"> In this experiment we have looked at a few differences that occur in the rendering of the same information under different conditions of interactivity. Our little experiment brought out several differences in the 'rendering' of the same task plan as a written text and as a minimally interactive dialogue.</Paragraph>
    <Paragraph position="1"> * Conditionals and preconditions are handled differently if limited confirmations are possible.</Paragraph>
    <Paragraph position="2"> * The flexibility of access that written text allows needs to be modeled more explicitly in case of aural presentation. This can be done minimally by allowing the machine to interpret 'done' or 'don't understand' as moves that lead to the presentation of the next instruction or to a repetition of the latest instruction.</Paragraph>
    <Paragraph position="3"> Moreover the granularity with which the task plan is represented corresponds to the granularity of the control the user has over the presentations of the instructions. In this example we started from an existing manual text. Starting from a written manual helped us understand the importance of the information about the task structure. This comes of course not as a surprise: when the presentation mode is fixed as non-interactive, the the discourse structure can be very 'fiat': things need to be done in a certain order whether they are parts of subtasks or not is not relevant. It can be argued that giving more structure will help a user understand better what the instructions achieve but it will not influence the execution directly. Material that helps the user understand why she is doing something is typically given in introductory sections and not in the procedures themselves in this type of manual. But to make document transformations possible in the sense described in the beginning, it is important to clearly separate task plans and assumptions about interactions, i.e. about how the information states get updated. 4 Once the task plan is distinguished from the dialogue plan, assumptions about the type of interactions between participants can change the dialogue plan even when the task plan remains constant.</Paragraph>
    <Paragraph position="4"> In practice a completely automatic transformation of a written manual into even limited dialogue is most likely not possible, although one can isolate several linguistic flags for some of the aspects we have been discussing (e.g. expressions like &amp;quot;make sure that...&amp;quot; flag preconditions). A more realistic approach would be to create a blueprint document that is marked up to allow the derivation of several different types of discourse from the beginning on. Such an enterprise would need tools such as the TRINDIKIT to model the various cases 5 So far, we have only explored one extreme of the monologue-dialogue opposition where the interactivity stays very low. Obvious extensions are to allow the user to ask information that goes beyond the current procedure, e.g. 'where can i find the piece you mention' or 'how long does this take: i have only 1/2 hour here'. Further inquiry into the possible interactions will help us to define which information is needed and how it needs to be structured to fulfill these various needs. And of course we will never reach a system in which every user need can be anticipated but then even human beings are not that type of system. null  the relation between the linguistic expressions used in the various renderings of the base document. One can see this task as akin to that of multilingual generation or even simple document rendering. Formal approaches used for those tasks could be adapted to such an enterprise. XML supplemented with stylesheets and schemata could be another possibility.</Paragraph>
  </Section>
class="xml-element"></Paper>