[alicebot-archcomm] [discussion] extension mechanism

[Anne Kootstra]

It seems like this path has already been chosen by the introduction of the
<javascript> tag. This is, from my point of view, a processor processing
JavaScript sever-side. So continueing this way would make sense to me.

However, looking forward - instead of backward. If I would load AIML from a
third party who created its own extension-processor than it would be
possible to filter out the code for non-present processors in situation 1
and that way not polute the bot's output. This is something that would most
likely be harder to achieve in the second situation.

On top of that, it would make the serverside scripting of the <javascript>
tag less confusing. Especially if one would implement processors that would
process, PHP, ASP or Perl that are quite similar in nature.

I think I'm in favour of the first option.

--Anne

-----Oorspronkelijk bericht-----
Van: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]Namens Noel Bush
Verzonden: maandag 20 mei 2002 9:05
Aan: Alicebot and AIML Architecture Committee
Onderwerp: Re: [alicebot-archcomm] [discussion] extension mechanism


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