[alicebot-archcomm] [discussion] extension mechanism

[Noel Bush]

Okay, there are two ways I can imagine extensions looking in AIML:

1) in which "extension" is an AIML element:

<extension name="lisp-processor" namespace="http://xyz.com/AIML-ext">
  (+ <star/> <star index="2"/>)
</extension>

2) in which extensions have their own names, and are identified as
belonging to a particular namespace:

<lisp-processor xmlns="http://xyz.com/AIML-ext">
  (+ <star/> <star index="2"/>)
</lisp-processor>

In the second scheme, it would be likely that people would often wish to
place the namespace URI only once per document, and use a prefix on
individual elements, like so:

<aiml xmlns:xyz="http://xyz.com/AIML-ext">
  ...
  <xyz:lisp-processor>
    (+ <star/> <star index="2"/>)
  </xyz:lisp-processor>
  ...
</aiml>

#2 seems preferable to me, because it makes use of existing XML
approaches to mixing semantics.  The only advantage to an approach like
#1 is that we would be defining an actual extension element in AIML,
which would give us some kind of control over it (?).  But I suppose
this issue too could be handled by defining an abstract extension type
which any extension must extend.

Thoughts?

On Fri, 2002-05-17 at 10:42, Noel Bush wrote:
> 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
> 
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
>