[pandorabots-general] Newbie Problem

[Noel Bush]

It is not accurate to say that xAIML is a competitor to AIML.  In fact, 
it's quite the opposite: xAIML implicitly asserts that there is *no 
point* in "competing" with AIML -- if you are going to use a 
pattern-matching oriented, stimulus-response sort of approach, then it 
is much wiser to use AIML as a basis than to go off and try to reinvent 
the wheel for the hundredth time.

Remember that xAIML is *not* an alternative to AIML -- xAIML is not 
"another language" or "another standard".  This is true of xAIML to AIML 
far much moreso than it is true of XHTML to HTML, for instance.

xAIML is, in fact, a wholehearted embrace of the "embrace and extend" 
attitude.  xAIML just offers a way for people to describe and share 
their embracings and extensions in a slightly more formal and useful 
way.  At present, if some AIML interpreter includes an additional 
feature, or does not implement a core AIML element, or implements an 
AIML element differently from other interpreters, you just have to hope 
that the documentation tells you so.  But in this case the notion of 
"what AIML is" gets a little fuzzy, since, for instance, "what AIML is 
to Pandorabots" may be different from "what AIML is to RebeccaAIML".

xAIML is a way for each interpreter to specify precisely how it matches 
up with the base AIML functionality set.  The idea is that you can tell 
"at a glance" whether a given interpreter has the functionality you're 
looking for, and whether it will be able to use your (x)AIML set, and if 
not, why.

At the same time, developers of "xAIML interpreters" can feel freer in 
implementing extended functionality sets, or even altering some basic 
AIML functionality, without a fear of falling out of the "circle of 
trust" that a standard like AIML provides.  That circle of trust is 
extremely useful, but it should not be a hindrance.  So xAIML provides a 
suggested path for developers to follow in pursuing innovation while 
retaining "measurable compatibility".

Brian's message brings up an important category of extensions to or 
variations on AIML.  There are many "macro extensions" that people would 
like to use in AIML, that can be implemented purely as transformations 
from some alternate markup to AIML, via XSLT.  For instance, 
"implementing" a <sr2/> element would be as simple as:

<xsl:template match="sr2">
   <xsl:element name="srai">
     <xsl:element name="star">
       <xsl:attribute name="index">2</xsl:attribute>
     </xsl:element>
   </xsl:element>
</xsl:template>

Now, if you have an interpreter that will recognize an XSL stylesheet 
directive at the top of your document, and will apply the designated 
stylesheet to the document before loading it, you have the means for 
creating your own "dialect" that can vary considerably from "orthodox" AIML.

But now that you've got your own dialect, what to do with it?  You still 
want to be able to validate it, like you can validate AIML.  There are 
so many pieces of software out there -- free and commercial -- that 
allow you to validate AIML against a schema...even while you are typing 
it, so you never need worry about submitting invalid AIML to your 
interpreter.  But when you've written your own dialect, you also want 
this same ability.  So you could just write your own schema -- copy the 
existing AIML schema and make your changes, for instance.  (Or write 
your own schema.)  But then you'd be firmly "out of the circle", because 
your dialect would no longer be "true AIML".  What to do?

The answer (I think) is xAIML, because it provides a structured means 
for expressing the relationship of your derived dialect to its parent, 
and offers a kind of "schema diff" functionality that should make it 
easier to customize a schema for your own needs.  If you have an 
xAIML-Spec for your dialect, then when you feed it to an xAIML 
interpreter, that interpreter will know how to handle it.

And I think that the specific matter of "macro extensions" -- all those 
extensions that can be handled with XSLT -- suggests that there should 
be a certain level of xAIML interpreter which consists of nothing more 
than the ability to apply a designated stylesheet to an input document. 
  It would make a lot of sense to have a designation of "pure-transform" 
or something like that as an available attribute on an xAIML spec element.

Noel

Dr. Rich Wallace wrote:
> Brian, the simple answer to your question is that there does exist a body,
> the AIML Architecture Committee, to debate, propose and adopt changes and
> additions to the AIML spec.   For various reasons, that committee has been
> dormant since 2002, and the 1.0.1 spec has remained frozen in place.  One
> reason has been that the guy we relied on to write the spec (who is not a
> computer scientist, but a "musician") has decided to compete with us
> rather than cooperate, and has now announced his own confusing attempt to
> create an "XAIML" standard right here on this mailing list and elsewhere. 
> I personally don't see any standards efforts moving forward until someone
> starts making more money from AIML applications.  So far the various
> projects have adopted an "embrace and extend" approach, which has been
> fertile ground for innovation.
> 
> One way to handle a simple macro extension like yours is at the authoring
> level.  You can have the botmaster write <sr2/> but internally expand that
> expression into <srai><star index="2"/></srai> in the AIML file.  That way
> you get the best of both worlds.  "AIML Authoring Tools" has been a
> subject of ongoing discussion for some time.
> 
> Rich
> 
>> Below is a category out of the Alice AAA Reducer.aiml file.
>>
>> <category>
>> 	<pattern>_ HOWEVER *</pattern>
>> 	<template>
>> 		<srai><star/></srai>
>> 		<srai><star index="2"/></srai>
>> 	</template>
>> </category>
>>
>> My question is this...
>>
>> If.....  <srai><star/></srai> = <sr/>
>> Then...  <srai><star index="2"/></srai> = <sr2/>???
>>
>> Then this would be oh so much briefer if stated as:
>>
>> <category>
>> 	<pattern>_ HOWEVER *</pattern>
>> 	<template>
>> 		<sr/>
>> 		<sr2/>
>> 	</template>
>> </category>
>>
>> Thoughts?