Are multiple overlapping launched sessions in one registration allowed?

[fugu13]

There are a number of places in the spec where things seem to get a bit odd if they are, but I didn't find an outright prohibition.

[brianjmiller]

Ref: https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#936-abandoned

In the absence of a "Terminated" statement, the LMS MUST make the determination if an AU abnormally terminated a session by monitoring new statement or state API requests made for the same learner/course registration for a different AU.

I thought we had other language too, but the above should be sufficient.

[MrBillMcDonald]

Are multiple overlapping launched sessions in one registration allowed? Short Answer: No.

Unless we need to consider better clarifying language, I consider the issue closed.

[fugu13]

I don't see how that language could support that conclusion, especially for the particular scenario I'm thinking, relaunching the same AU (since different AUs necessarily have different registrations in context)--only activity "for a different AU" indicates abnormal termination as described.

I really don't see any restriction on this in the spec. If it was intended, I'm pretty sure it was left out entirely (though requirements are scattered enough in the spec there may be something that I missed), and will either need to be accommodated or need to be added to the language.

[brianjmiller]

If a different AU is making requests and the existing session is immediately abandoned then that session can no longer be active, which necessarily means you can't have multiple simultaneous sessions for a registration, as a session is tied to a registration.

[fugu13]

The case I'm focused on is the same AU, in a different session, in the same registration. There's no technical barrier to that happening right now, and the text you pointed at only applies to different AUs.

[brianjmiller]

I suppose you could argue that re-launching the same AU within a registration obliterates the State data as it is based on the same identifiers which is in effect abandoning that session as you would have to get the new session id from the updated state before initializing the second session.

At the same time, I would expect you to argue that that is a stretch and that we should be more explicit. I seem to recall thinking that the addition of "different AU" was entirely unnecessary there and should be tied to the session instead.

I am curious about your statement that: "since different AUs necessarily have different registrations in context"?

[fugu13]

I am curious about your statement that: "since different AUs necessarily have different registrations in context"?

They absolutely must. The rules make no sense as written otherwise. In particular:

Only one "Completed" cmi5 defined statement is allowed per registration.

Only one "Passed" cmi5 defined statement is allowed per registration.

A "Failed" statement must not follow a "Passed" statement (in cmi5 defined statements) [per registration].

Presumably someone can complete and pass different AUs in a course, so as only one completed verb is allowed per registration, the different AUs must have different registrations.

If those were intended to be per AU, that definitely didn't get written there (including the prefatory language; they're definitely AU verbs, they're within an AU session, but the rule reaches out across a whole registration, otherwise it doesn't restrict anything, and it doesn't say anything about per AU).

There's also this:

A Registration ID corresponding to the learner's enrollment for the AU being launched.

[fugu13]

I suppose you could argue that re-launching the same AU within a registration obliterates the State data as it is based on the same identifiers which is in effect abandoning that session as you would have to get the new session id from the updated state before initializing the second session.

Certainly launching two sessions too close to each other could trample and prevent successful launch, but there'd be no technical conflict if one had gotten a bit along before the other was started.

For example, the probably very common scenario of: person goes to AU in LMS, clicks launch, works in new tab/window. Comes back after having wandered off, sees LMS page still open, clicks launch again.

If "different AU" isn't intended to be there, that's fine, but of course it should be deleted (and I'd recommend the language around overlaps be made more specific instead of imprecisely implied at the same time, just outright saying that if the first timestamp for a given session is at a time X, the last timestamp for that session must not be after any first session timestamp after time X).

[brianjmiller]

They were intended to be per AU (at least as far as I've always understood it). And I believe that was the intention of including "within an AU session" as the header, but tacking on the "per registration" thing.

So, a registration is effectively learner + course structure (instance):

• which has 0 or more, non-concurrent sessions where each session is unique to a launch of an AU,
• which may have one "passed" per AU
• which may have one "completed" per AU
• which may have multiple "failed" per AU so long as they do not follow a "passed" for that AU

I guess you could implement such that each AU gets a separate registration but that seems to make it really difficult to tie everything together, and you'd have to create a (one or more) registration(s) for the satisfied handling, etc.

I agree the wording likely needs to be improved. There is at least some historical precedence for the concept of a "registration" given this is for the LMS use case.

For the "enrollment" bit, it is for the "enrollment" for the AU being launched given the location of the sentence in constructing the launch string. Granted, that is a big leap to what an "enrollment" is which is effectively learner + course structure (instance).

[brianjmiller]

I don't follow what is imprecise (other than the language) about "launched" -> "initialized" ... -> "terminated"|"abandoned" -> "launched" repeat... subsequent launch of an AU (any AU) in the same registration (assuming unique "course structure + learner (instance)") causes abandonment which terminates access (or triggers post mortem voids).

[fugu13]

The imprecision is when the abandonment statement occurs. In your scenario the abandonment could conceivably (and even likely in a naive implementation) be given a timestamp after the "launched" in the case when it is detected due to new statements, causing sessions to overlap.

[fugu13]

They were intended to be per AU

If the rules were intended to be per AU, they weren't remotely written like that. The plain language is that they're for the entire registration, and the use of registration everywhere it isn't called "course registration" is consistent with that (and consistent with course registration being interpreted as a broader concept).

I mean, if the cmi5 working groups wants to do the edit, and retroactively, that's fine, it isn't my standard, and I assume most people implementing it implemented it per-course structure. But right now the very direct implication of the language is that registrations are per-AU, not per-course structure, and there's barely even a hint, textually, that it is intended to be otherwise.

[fugu13]

I've got another huge bunch of revisions to trying to translate what's here into profiles, now, though ;)

[fugu13]

Btw, I did a pass and found another place registration could more easily read to be per AU that should probably be updated:

The LMS SHOULD use the same generated activityId (for the same AU) for all registrations.

I've also found a place that's best (though not only) interpretation is registration is per course, deep in the document, which I discounted since some of the first rules in the document contradicted it:

registration: Registration id representing the LMS learner enrollment in the course. This MUST match Registration ID used by the LMS at AU launch time.