Parameters and filters  Resolving ambiguity

Chapter 2: Developer Features

Intent XML

Intent XML is the information returned by Answers Anywhere. Here is an example of Intent XML:

<DejimaInterpretation>
   <Input><![CDATA[find info for wall]]></Input>
   <Understood><![CDATA[find info for wall]]></Understood>
   <System>
    <Execute explicit=“true”>
    <Application>
    <Header>
     <IdList match="info">
      <id>251</id>
     </IdList>
    </Header>
    <Parameter explicit="true"><![CDATA[wall]]></Parameter>
   </Application>
 </Execute>
 </System>
</DejimaInterpretation>

This example shows that the original query was “find info for wall.” Using the agent network, the Answers Anywhere runtime resolved this query using the Execute, Application, and Header agents. In the agent network for UA Answers Anywhere, the Header agent is connected to a data source that is linked to the portal database through the portaldb connection cache. The data source is used to determine whether there is an available application that matches the query. In this example, application 251 (the application ID) has been determined to be the relevant application.

Another feature of the Intent XML is the determination of parameters in the query string. The parameter XML node is present in the Intent XML whenever the Parameter agent in the agent network determines there is a parameter. Using this information, the parameter value can be passed along to the application as a parameter during application playback. Certain synonyms for parameters have already been specified in the agent network. These are:

If multiple applications match the query, the Intent XML contains several id nodes as shown in the example below:

<DejimaInterpretation>
<Input><![CDATA[get test]]></Input>    <Understood><![CDATA[get test]]></Understood>    <System>        <Execute explicit="true">            <Application>                <Header>                    <IdList match="test">                        <id>281</id>                        <id>211</id>                    </IdList>                </Header>            </Application>        </Execute>    </System></DejimaInterpretation>

Both applications 211 and 281 matched the query. When at least one matching application is located, the matching value is placed in the match attribute of the IdList node. This match value is then tested against the field headers and field header synonyms to determine if a grid filter rule must be dynamically generated and executed against the application content. If the match attribute is not determined to be a field header or a field header synonym, the dynamic rule is not generated.





Copyright © 2005. Sybase Inc. All rights reserved. Resolving ambiguity

View this book as PDF