[alicebot-archcomm] [discussion] extension mechanism

[Jon Baer]

I like # 2's case with the namespaces.  BeVocal does this approach to items in
their interpreter which are not VoiceXML 2.0 related (like call control) and
it works smoothly.

- Jon

Noel Bush wrote:

> 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
> >
>
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo/alicebot-archcomm