[alicebot-style] what happens to pattern or pattern side that

[Kim Sullivan]

A reply almost exactly a month too late? Well, stranger things have happened
;-)

> Given:
>
> <category>
> <pattern/>
> <that/>
> <template/>
> </category>
>
> What happens when pattern is null?  It cannot match - right?  Is
> it allowed?
>
> What happens what pattern side that is null (found a few categories in an
> old AAA set like this)?  Does it turn into * or is it illegal?
>
> Is a null template allowed?
>
> I'm not aware of these being clear in the specs.

As Noel has correctly pointed out, the working draft of the specification
(commonly referred to simply as "the specification") doesn't allow empty
patterns. My personal opinion is that this is an unnecesary complication of
the specification, and should be disregarded - there is no real reason to
disallow matching an empty input (you can implement the matching algorithm
in such a way that it will work with an empty input and an empty pattern).

The inclusion of this additional constraint has resulted in several other
parts of the specification being complicated more than necessary (combined
with the fact that, according to the specification, if you omit a pattern,
it defaults to the wildcard which means one or more words):

1. An empty pattern is illegal. Values in conditions are patterns.
Therefore, the following is illegal:
<condition name="somevar" value="">The variable is empty</condition>

2. Allthough a single wildcard clearly means "one or more words", an empty
input (zero) words also has to match a single wildcard (because you are not
allowed to write a null pattern, and omision of a pattern doesn't mean "I
don't care" but explicitly means "one or more words"). Empty inputs
therefore have to be preprocessed so they act as if they were not empty, and
then processed again on output.

3. Because testing for an empty value in a condition is illegal, all
variables need to have a non-empty empty value (default) that you can test
in conditions (so you can determine if a variable has been set or not, makes
sense, right?).

4. But even if you explicitly set a variable to an empty string, the
following (while valid and seemingly reasonable) will not work:
<set name="somevar"></set>
<condition name="somevar">
<li value="*">Somevar is not empty</li>
<li>Somevar is empty</li>
</condition>

Why is that? Well, because the same algorithm as in pattern matching is
used, and of course - that has special hacks so that empty inputs match a
single wildcard (the general rule seems to be - if there is no value, let
the value be the character '*' to be consistent with the matching behaviour
for the topic, which is described in section 8.4).

5. Just saying "you can use empty patterns" isn't an option either, because
of the fact that the specification requires you to implement pattern
matching in a very particular way. While the sematics of an ommited topic or
that are clear (I don't care if there was an input, or if the input was
empty, or whatever), the specification prescribes a complicated
implementation where an ommited topic or that mean "one or more words" and
then goes on to describe a way to "circumvent" this self-imposed limitation
to allow an empty input to match a wildcard. Besides, the ommision semantics
are only present for that and topic, while you could have the same thing for
a pattern, ommiting the pattern is not allowed. Basically you'd have to
completely rewrite the part of the specification that describes the pattern
matching - and no-one wants to go through that again. I think we're
extremely lucky to at least have some sort of specification (and even though
there are many bugs in it, Noel has put in a tremendous effort to write it,
which should not be forgotten).

In conclusion just do what you think is best for your implementation and
your users. Let the working draft of the specification guide you, but always
keep in mind that it was written at a particular time, with particular
implementations of that time in mind, and during very specific circumstances
(I think there was quite some pressure to get "something" official out fast,
with the idea that the specification could later be revised... which never
happened, because too many people had too different ideas).

Maybe I should get interested in the xAIML project, which tries to summarize
the issues at http://aitools.org/AIML_spec_open_issues...

Kim