Dear Forum

AIML v2 has the useful new var attribute to declare variables local to a category. Eg we can do this:

The above code is is easy - we get the ‘star’ parameter, store it in the variable ‘best’, then check it using a condition. But the AIML v2 document also says attributes can be expressed as sub-elements:

It has taken me many years to grudgingly appreciate the zen-like beauty of AIML - however I think allowing attributes to be sub-elements is a big mistake because:

- It is much more verbose as can be seen above (20 lines instead of 12)
- It is conceptually confusing which will deter AIML beginners, and that is a bad thing.
- In the <think> tag above, it looks as if <var> and <star> are possible attributes of <set> which is not always the case.
- There is ambiguity about whether sub-elements (var, index, value) are attributes or elements, which makes it difficult to construct an XML schema for an AIML v2 document. Although this may seem esoteric, it will make it difficult to convert AIML v2 to or from other XML formats.

Therefore I would ask the AIML v2 committee (whoever they may be) to reconsider this decision.

If it’s both (which it might be, as I haven’t gotten around to reading the AIML 2.0 source yet) why not use the 1st definition of the Var option? I see no problem with this, and I am excited to start using AIML 2.0. While yes it may be a *bit* harder to get a hold of then AIML 1.0.1, it is also a lot more powerful. Also the Var attribute sounds like a simpler way of declaring the <set> variables, which I see as a plus in my book, as you won’t have to write as many categories to do what you want. I started working on an AIML emotions set and I had an AIML file of just listed emotions to ease the creation of them, this seems like it could help a little there, but mostly with adding stuff like mood-reading to the bot. I see this as a plus personally.

You can still use either method in AIML 2.0. I don’t plan on changing from the first method in your thread.

I agree that var is really handy and I’m not questioning that. It’s the ‘improved’ syntax that permits attributes to be expresses as sub elements that I have issue with. It looks verbose and spoils the clarity of AIML, also it means there are several ways of expressing the same thing which is a no-no in language design. Also it makes it more difficult to write an AIML v2 interpreter (which I am attempting to do). It even makes it more difficult to design an AIML XML schema.

Putting these minuses aside, the only advantage I can see is for specifying the ‘value’ when used in a ‘li’ tag - the value can be dynamically obtained from a sub element instead of from a fixed attribute. An easier solution would be a new ‘value_from_var’ attribute which specifies the ‘li’ value is obtained from a variable instead of from the ‘value’ attribute.

I happen to agree with you, Will. In fact, for me (as a developer of an AIML interpreter/chatbot engine) it’s even worse, as I have to figure out a way to parse such a mess, which is a very daunting task. I don’t want to use the term “ill considered”, but…

Hi Will, you make some interesting points however it’s worth pointing out that the debate over elements vs. attributes is broader than just AIML.  See http://stackoverflow.com/questions/1096797/should-i-use-elements-or-attributes-in-xml

Another reference http://www.ibm.com/developerworks/library/x-eleatt/ suggests the design rule “If the information in question could be itself marked up with elements, put it in an element.”  This statement captures my motivation for migrating to elements in AIML 2.0: we sometimes want to make the value of an attribute dependent on the value of other AIML elements. 

As Steve and Joseph said, AIML 2.0 is backwards compatible with AIML 1.0.1.  You can still write the old-style AIML and use its elements. 

Dave, it’s not that hard to parse.  Take a look at the getAttributeOrTagValue method in AIMLProcessor for Program AB at https://code.google.com/p/program-ab/source/browse/src/org/alicebot/ab/AIMLProcessor.java

Dave Morton - Feb 2, 2014:

I happen to agree with you, Will. In fact, for me (as a developer of an AIML interpreter/chatbot engine) it’s even worse, as I have to figure out a way to parse such a mess, which is a very daunting task. I don’t want to use the term “ill considered”, but…

As someone programming NLP, those are exactly my sentiments about the whole English language

Dave - I agree that parsing the new form is a pain. Also I’m using MS SQL instead of Java (with the aim of handling 1m+ categories) so I compile the AIML to an intermediate table form instead of building a tree. Out of interest, who decides or debates these new Features before they are added to AIML v2? From reading the AIML v1 docs there seemed to be some sort of committee.

Richard - the stack overflow article is interesting but I don’t think it supports the arguments for elements in this case. In the cases under discussion (eg providing a dynamic value in an ‘li’ tag) the ‘li’ content is the output text and the ‘value’ attribute is meta data determining whether the particular ‘li’ is active. The stack overflow article actually suggests meta data should be kept as attributes.

I think another key point is a well designed language should have a single clearly defined means of carrying out each task. If the language designers cannot choose a single means of approaching a task, what chance do the users of the language have?

I also think there are few cases where nested sub elements are required (‘li’ value attributes and ‘star’ index attributes are the only ones I can think of). So what about *extending* the value and index attributes to allow vaue_from_var and index_from_var? This would be more in keeping with the current style of AIML.

So for these reasons, I would respectfully request the designers of AIML v2 reconsider this aspect of the new version.

Thanks for the links, Rich. I’ll see what inspiration I can glean from the code.