How will I know when to use this command?
Particularly with long templates with lots of conditional logic, you can get one or both of the following situations: either the interview responsiveness is very sluggish, and/or you get an “Out of Memory” exception being thrown by the system.
What is going on under the hood?
One of the powerful things in XpressDox is the Relevance Engine. This is the ability that XpressDox has to analyse the template, and based on the conditional logic in the template, make sure that only the relevant data elements appear on the interview.
For example,
«ChooseFromRDBList(Option,,Opt1,Opt2)»
«If(Option = 'Opt1')»
Number of items is «NumOfItems»
«End()»
«If(Option = 'Opt2')»
Price is «Price»
«End()»
If the above template were to be run, then at first only the Option data element would appear, and it the user chooses Opt1 then NumOfItems would appear. And Price will appear if Opt2 is chosen.
It is the Relevance Engine that causes the Price and NumOfItems data elements to appear and disappear when the value of Option changes.
And why can that be a problem?
Under the hood, there is an XML structure called a Schema that XpressDox creates and which drives the interview. All the logic of the Relevance Engine is contained in the Schema, as well as everything else needed to create the interview. In particular, attached to every data element definition in the Schema, there is a condition, which is the “condition” part of the DetectLongConditions command name.
In the above example, the condition which attaches to the NumOfItems data element in the schema is
Option = 'Opt1'
and the condition for Price is
Option = 'Opt2'
That’s pretty straight forward.
But have a look at this slightly more complex template:
«ChooseFromRDBList(Option,,Option1,Option2,Option3)»
«If(Option = ‘Option1’)»
The rain in «Name» falls mainly in the plain.
«Address»
«Else()»
«If(Option = ‘Option2’)»
The rain in «Name» falls mainly in the summer.
«Address»
«Else()»
«If(Option = ‘Option3’)»
In Hertford, Hereford and «Name», hurricanes hardly happen.
«Address»
«End()»
«End()»
«End()»
It turns out that the condition in the schema for data element Name (and the same for Address) is this:
((Option = 'Option1' or not(Option = 'Option1') and Option = 'Option2') or not(Option = 'Option1') and not(Option = 'Option2') and Option = 'Option3')
This is probably unexpected, but there are good reasons for it. Then what happens is, the more conditions that get applied to the Name and Address elements in the template, the more complex their conditions in the Schema become.
In a really big template with many such conditions, the Schema can become very large and cause the responsiveness of the interview to become very sluggish, and, in a really bad case, XpressDox will run out of memory to execute.
What’s the way out?
If you have a look at the last example template, you will see that actually Name and Address are required regardless of the value of Option. It’s easy(ish) for us humans to see this, but computers need to be told how to recognise this situation. Surprisingly, it’s not easy – have a look at Quine-McClusky algorithm for how to do it.
In any case, the way to shorten any long condition in XpressDox is to use the InterviewRelevance command. In the above example, there would be one InterviewRelevance each for Name and Address:
«
InterviewRelevance(Name,'')»«
InterviewRelevance(Address,'')»
Finding out where to apply InterviewRelevance
In the absence of Quine and McCluskey, we have to use a more or less brute-force mechanism to shorten the very long conditions. This is the DetectLongConditions command. As said earlier, there are two symptoms of long conditions in the Schema:
1 – Out of Memory
If this happens, there are probably very, very long conditions in the schema. These can be more than 50,000 characters long. And there can be more than one such very long condition. In this case, the following command should be used:
«DetectLongConditions(Fail,5000)»
This will cause the analysis of the template to stop as soon as a condition of 5000 characters has been found, and a report will be produced indicating what action should be taken. The 5000 characters is fairly large anyway, but should at least allow the template analysis to reach the point where the report can be produced, i.e. before an Out of Memory situation is reached.
After applying the InterviewRelevance command to the data element reported, if you still get an Out of Memory error, then increase the 5000 to, say, 10000 and repeat the process until at least you get an interview.
2. The interview is sluggish
If there are no memory problems, then it is not necessary to use the Fail option in the command, but rather use this:
«DetectLongConditions(Warn,5000)»
Then XpressDox will run through and create the schema, but also create a report showing all of the data elements for which the condition created is longer than 5000 characters. Then the InterviewRelevance commands can be included at least for the data elements with very large conditions.
