[alicebot-archcomm] [discussion] extension mechanism

[Noel Bush]

Several times in several forums the topic of an extension capability for
AIML has come up, but we haven't addressed it (at least neither recently
nor conclusively) in the ArchComm.  I would like to ask that we open up
this topic. 

First, I think we should agree on some high-level requirements for an
extension mechanism. 

I would characterize the extension mechanism as a generalization of the
<system> and <javascript> functions currently available.  The
requirements I would like to propose are: 

1. Unrestricted text content, within the guidelines given for XML, for
extension elements. 
-- Meaning, any kind of CDATA is acceptable (although in cases where
characters need to be "escaped" to avoid conflicts with XML they should
be).

2. Unrestricted ability to make requirements of context.
-- I want to say that someone may publish an extension that can only
work on a Haskell-based AIML interpreter running under Solaris 2, or
whatever.  Of course it should be clear to the implementor that this
will jeopardize the chances of the extension being considered for
inclusion in a future version of the core AIML spec.

3. Must return text.
-- Like all AIML template elements, an extension element must return
text.

4. URI-based specification authority. 
-- That is, a URI designates a unique extension.  We might want to
recommend something like RDDL as the standard for providing
documentation or other resources at a URI (though it should not be
required).  The point is that anyone who can publish a legitimate URI
can thereby publish an extension, and the URI is the ultimate determiner
of uniqueness for an extension element, rather than any other
characteristics of the element (name, attributes, namespace, etc.)

5. Ability to independently specify how and whether the extension
element's content may have access to other AIML functions.
-- This is a tricky one.  For instance, the JavaScript processor in
Program D still allows you to put the string "<star/>" just about
anywhere in the js code, and Program D will substitute the value
captured by wildcard 1 before processing the script.  But I would
propose that this sort of behavior, and how it can be accomplished,
should be something that an implementor can specify independently. 
Essentially, it should be "anything goes".  Here Jon's or Pedro Colla's
approaches to a "bot environment" could be given free rein.

6. Strong encouragement to provide performance/reliability parameters.
-- I mean that we should encourage each extension to have a way of being
timed out, specifying a fallback behavior, etc.  Maybe we should even
provide some standard facilities for this.

Okay, that's what I can come up with.  Now, I know there have been
several proposals for what extensions might look like in AIML.  I think
it would be nice if we could review those (whichever people are still
interested in) in parallel with discussing these requirements.  At the
end, I think that a specification for the extension mechanism should be
no more than a short paragraph.

Noel