[alicebot-archcomm] AIML architecture vs. application architecture

[Conan Callen]

Your point that it is easier to distinguish this problem now is a credit
to your's, Tom's and others work to get this project cleaned up. Kudos to
all involved with the cleanup.

The worms were already out of the can, this issue has surfaced many
times, sometimes mingled in with other issues. From an aiml intreperter
vendor perspective, I also feel that the implementation should be kept seperate
from the AIML spec. What the spec should call out is how to create an
intrepreter that will work with any compliant aiml, similar to how ansi c
code should compile on any ansi c compliant compiler (of course, taking
versions into consideration).

In research or competition, developing better data structures and
algorithms is what differentates one implementation from another, If all
implementations use the same internals ... where does that lead to?


By driving the implementation into the AIML spec, a situation is
created where the AIML spec needs to be updated everytime a data structure or
algorithm is modified. At every contract I have worked on the client has
had a Product Spec (at least an idea of what they are trying to build).
This product spec will typically identify the standards that the client
wants to support in their product.

As an engineer I will usually have to figure out what kinds of data structures
and algorithms will be needed. If I'm really lucky this design work has
already been done and I just have to grind out code.

Q) If someone comes up with a faster algorithm does this replace the
existing feature in the spec, or are they told not to use it if they want
to remain compliant? Although this could be an interesting way to limit
the competition, which is just the kind of crazy idea that will light up
the eyes of the marketing folks?

Conan

> Even though this may be opening up a can of worms, I feel obligated to
> mention that I notice a positive development: a clearer distinction
> between two tasks:
>
> 1) architecture of an abstract AIML interpreter
> 2) architecture of Program D
>
> Some of our disputes in the past may be seen as having missed this
> distinction, so that at times we were talking about *both* the Program D
> architecture and the architecture of an abstract AIML interpreter.  For
> instance, the question of "how to set things at startup" looks like an
> application architecture question, not (necessarily) an AIML
> architecture question.  On the other hand, the question of "how <random>
> should behave" is clearly an AIML architecture question.
>
> I mention this because I've recently been doing some cleanup,
> optimization and enhancement work on Program D, and I've found it much
> easier than in the past to see this distinction.  The AIML spec WD does
> still stipulate a few things which perhaps impinge too much on
> application architecture, but for the most part it sticks with AIML
> interpreter architecture.
>
> This gives me the feeling (perhaps mistaken) of liberty to introduce
> changes in how Program D is configured, so long as they do not change
> the runtime interpretation of AIML.  For instance, in looking at how to
> make Program D support externalized substitutions, it seems clear that
> these can be specified in an XML file using a <substitute> tag (a la
> TinyAlice) without causing any controversy, since <substitute> makes no
> claims on being an AIML element.  Program D could just as well implement
> this using a non-XML format (unlikely) or by requesting substitution
> information at a command-line on startup (obviously silly) -- the point
> is that nothing is changed about the behavior of the AIML interpreter.
>
> I hasten to add that all such changes are being reviewed continuously by
> Kim Sullivan and Tom Ringate, who have distinguished themselves as
> high-profile, energetic advocates of usability with respect to both
> Program D and AIML in general.  The present work is on an incremental
> version "4.1.3" which will include not only cleanup and optimization
> fixes grounded on Tom's & Pedro's AIML compliance work, but also bug
> fixes, some forward-looking architectural improvements, as well as some
> functional enhancements (user authentication option, external
> substitution specification).  As in most user community-driven
> scenarios, it is expected that the smaller advocacy group (in this case,
> Kim and Tom) will be widened to a larger group with either a beta
> release (something we haven't done yet), or just a "point release" (less
> than ideal, but it works), from which additional user feedback will be
> gathered and factored into future releases.
>
> We're making heavy use of CVS, so all changes are traceable, reversible,
> documented, etc.
>
> Any comments are welcome.  If somebody feels like this is not the way to
> go -- that small changes to the reference implementation also need to go
> through committee -- please do say so.  In such a case I think we need
> to work up an actual Program D spec, which I personally feel will
> introduce an unnecessary delay.
>
> Noel
>
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo.cgi/alicebot-archcomm
>