[alicebot-archcomm] [proposal] <get pattern=
Noel Bush
alicebot-archcomm@list.alicebot.org
Sun, 4 Nov 2001 17:57:07 +0300
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C1655A.1F71AC90
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Let's try this again; there were a lot of "spurious" things there.
> -----Original Message-----
> From: alicebot-archcomm-admin@list.alicebot.org
> [mailto:alicebot-archcomm-admin@list.alicebot.org] On Behalf
> Of Noel Bush
> Sent: Sunday, November 04, 2001 5:56 PM
> To: alicebot-archcomm@list.alicebot.org
> Subject: RE: [alicebot-archcomm] [proposal] <get pattern=
>
>
> The text file had a spurious item ii attached to item i under
> 2; ignore
> the spurious item ii.
------=_NextPart_000_0012_01C1655A.1F71AC90
Content-Type: text/plain;
name="get-pattern-that-topic.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="get-pattern-that-topic.txt"
(View without word wrap. The long lines are that way on purpose.)
0. Each input path is stored, with the most recent first. One way might =
be:
<user> RICHARD WALLACE <matched> HELLO ALICE <that> * <topic> * <with> =
Hello, Alice! <that> CONNECT <topic> *
<user> RICHARD WALLACE <matched> * <that> WHAT ARE YOU DOING <topic> * =
<with> I am writing more targets. <that> WHAT ARE YOU DOING <topic> *
0a. Matches on identical paths overwrite one another.
1. Each time a <set> is performed, the new value is stored and =
associated with=20
the input path. The previous values are retained. Might look like:
<user> RICHARD WALLACE <predicate> doing <after> I am writing more =
targets. <was> writing more targets
<user> RICHARD WALLACE <predicate> doing <after> I'm eating lunch. <was> =
eating lunch
2. Each time a <get> with a pattern and/or that and/or topic attribute =
is=20
performed, the engine "reconstructs" the original situation, by going =
through=20
the following steps:
i. The given path (from the pattern, that and topic attributes) is =
sought in=20
the stored inputs. ii. The template associated with the path is =
retrieved.
ii. The category associated with the path is retrieved.
iii. Each time a <get> with a name attribute is encountered in the =
retrieved=20
category's template, the engine steps backwards through the =
different values=20
that may have been assigned to the predicate. It does this by =
stepping=20
backwards through inputs until it finds the first one that =
matches an input=20
associated with the setting of a predicate value. iv. The value =
that the=20
predicate had at the time the retrieved template was used, is =
used to=20
re-process the template. iv. The value that the predicate had at =
the time the=20
retrieved template was used, is used to re-process the template. =
iv. The=20
value that the predicate had at the time the retrieved template =
was used
iv. The value that the predicate had at the time the retrieved =
category was used
is used to re-process the template.
v. Srais are handled no differently: the values captured by the =
wildcards in the
category's pattern, that and topic will be the same because the =
entire path
was retrieved.
3. It's true that <random> probably presents the funniest problem. How =
to=20
retain the notion of reconstructing the response?
To me it is worth giving up the idea of retrieving the exact random =
response, in=20
order to retain this "reconstruction" notion.
I like the notion of reconstructing the response better than just =
storing the=20
response because it offers the change to *use* the contents of the =
template,=20
rather than just returning the whole thing.
------=_NextPart_000_0012_01C1655A.1F71AC90--