Does xAIML "compete" with AIML?
From aitools.org
(from a message to the pandorabots mailing list.)
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".
...
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.
