Definition: Unique identifier for an interaction. Usage: Used to set a unique interactions id. SCO specific. Format: Alpha-numeric string. No internal spaces. LMS Behavior: Initialization: Value is controlled by the SCO. LMSGetValue(): LMS should set an error code according to the following and return an empty string (""). Error Code: 401 - Not implemented error. If this element is not supported an empty string is returned and an error code is set to indicate that the element is not supported. 404 - Element is write only. If a SCO tries to call LMSGetValue() on this element, the LMS should set the error code to 404 and return an empty string (""). LMSSetValue(): Sets the data model element to the supplied value. Value must match the data type for this element. Example API call: LMSSetValue(“cmi.interactions.0.id”,"I_001") Example Set Values: "I_001" "i1" Error Code: 205 – Incorrect Data Type: If an LMSSetValue() is invoked and the value to be used to set the element to is not of the correct Data Type. 401 - Not implemented error. If this element is not supported an error code is set to indicate that the element is not supported. SCO Usage Example: // Set the first interactions id LMSSetValue("cmi.interactions.0.id","I_001");Although nothing is said in the description, the example given uses "0" as a first index. The serious hint, though, comes from the _count property description:
Definition: The _count keyword is used to determine the current number of records in the cmi.interactions list. The total number of entries is returned. If the SCO does not know the count of the cmi.interactions records, it can begin the current student count with 0. This would overwrite any information about interactions currently stored in the first index position. Overwriting or appending is a decision that is made by the SCO author when he/she creates the SCO.
Usage: Used to determine the number of interactions stored by the LMS. SCOs could use this number to determine which interaction record to set. If "3'" is returned then the SCO knows that records 0-2 are occupied and the next available index is “3”.
Following these descriptions, we have decided in Dokeos to force the declaration of an interaction of index "0" before all possible other interaction declaration. Not doing so will return a SCORM API error, which will not be visible to the end user but will cause interactions *not to be* recorded.
Another way of doing it would have been to force the creation of all empty indexes between 0 and the one declared first, but I still feel this is wrong as it would introduce empty interactions, which could then be considered as accountable information by the SCO.
So if you have a problem with SCORM interactions in Dokeos, a good first step would be to check for this.