xAPI helpers¶

The statements courses actually send, pre-built.

XApiVerbs¶

The ten ADL verbs this package uses, each returning a fully-formed XApiVerb with the right IRI and display name: Experienced, Attempted, Initialized, Completed, Passed, Failed, Answered, Suspended, Resumed, Terminated.

They are methods rather than static readonly fields because an XApiVerb is a mutable serializable class — a shared instance could be modified by one caller and observed by the next.

The IRIs matter. http://adlnet.gov/expapi/verbs/passed is what reporting tools recognize; a verb spelled passed with a different authority is a different verb as far as an LRS is concerned, and it will store it happily and report it nowhere.

XApiStatements¶

One method per thing a course does, each building the statement and sending it:

InitializedAsync, ExperiencedAsync, AnsweredAsync, CompletedAsync, PassedAsync, FailedAsync, SuspendedAsync, ResumedAsync, TerminatedAsync.

These are where the specification's rules get applied without the caller thinking about them — a score built through XApiScore.Raw so the range is valid, a registration checked for being a UUID, a verb and activity checked for non-empty ids. Each returns Task<bool> with the same meaning as SendStatementAsync: false only when the LRS refused.

XApiConfigExtensions is the small one — it fills statement fields from an XApiEndpointConfig so the activity id and registration do not have to be passed to every call.

Building something else¶

The helpers are a convenience, not a gate. Construct an XApiStatement directly and send it through IXApiRuntime.SendStatementAsync for anything they do not cover. The checks that protect against LRS rejection live in the runtime and in XApiScore.Raw, not in these helpers, so you do not lose them by going around.