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:
param
arg
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.
In the following example of a query that could cause conflict, there is an application called “chart” and “stock” is assigned as an application synonym for chart. When the request get stock is made, the system sees two applications–“stock” and “chart.” When this happens the system executes the first application returned from the database. This shows the intent XML for the query:
<DejimaInterpretation> <Input><![CDATA[get stock for SY]]></Input> <Understood><![CDATA[get stock for SY]]></Understood><System> <Execute explicit="true"> <Application> <AppSyn> <IdList match="stock"> <id>221:21:chart</id> </IdList> </AppSyn> <Header> <IdList match="stock"> <id>281:21:stocks</id> <id>211:21:stock</id> </IdList> </Header> <Parameter> <ParameterName> <IdList match="for"> <id><![CDATA[2510:251]]></id> <id><![CDATA[2810:281]]></id> <id><![CDATA[2610:261]]></id> </IdList> </ParameterName> <Value><![CDATA[SY]]></Value> </Parameter> </Application> </Execute> </System> <Question> <AppSyn> <IdList match="stock"> <id>221:21:chart</id> </IdList> </AppSyn> <Header> <IdList match="stock"> <id>281:21:stocks</id> <id>211:21:stock</id> </IdList> </Header></Question> </DejimaInterpretation>
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
