-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LTS: Issues with 005-1-invalid-au.zip #20
Comments
Per section 9.3.6 Abandoned ( https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#936-abandoned ): Given this, the spec specifically disallows multiple AUs launched in parallel, which the LMS is responsible for. From there, you can verify that the only active launch is the one making the learner preferences check, and if an "initialized" comes before a learner preferences check on this launch, you have a violation.
It's reasonable to state that there is a derived requirement here, as if the AU must do something, the LMS must prevent the AU from not doing something wherever possible. CATAPULT has a collection of derived requirements for situations like this. That having been said, we will be reviewing this specific item at the next spec group meeting, and will decide on what (if any) the appropriate action or clarification should be in either the spec itself or in CATAPULT.
To address the "what is wrong" part first: 11.0.0.0-5 (d) is the actual requirement failing, which comes from https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#110-xapi-agent-profile-data-model : As far as bubbling up more helpful errors in the responses, we'd be happy to review any PRs that would improve the messaging about requirements and test failures. |
Thanks for the quick answer!
I do not agree on this, i think this only disallows launching the same AU multiple times. It does not say anything about launching two completely different AUs with a different registration at the same time.
Thanks, this was not clear to me.
I will look into this in the future. Personally i expected something similar to the lrs-conformance-test-suite that uses assertions for status codes etc. |
Because these words are so overloaded in learning, I'm going to include the cmi5 definitions here to help clarify things.
So there's a couple things to take apart in your message:
This was a topic in the cmi5 WG earlier this year, specifically around making sure the language was clear that Abandoned also included the same AU as well as any other AU within a single registration. https://github.com/AICC/CMI-5_Spec_Current/wiki/CMI-5-Working-Group-Meeting-Minutes-%E2%80%93-June-25th . You can see the most relevant note here at the bottom:
The last item matches with the current Abandoned text, and the standard's definition of "registration". |
But isn't the last point exactly what this issue is about?
This says that it IS allowed to run two different AUs from different courses (and therefore different registrations) at the same time. And if this is allowed then there is no way to check if the Or did i misunderstand you? |
That's an implementation detail of your LMS, not one defined by a specific approach in the cmi5 specification. For example, the CTS launches all courses with a session ID in the xAPI endpoint. From my local CTS launch:
Decoded, that endpoint is |
I know, but i am still asking for guidance because we had trouble coming up with a solution for this.
This is a very interesting idea, thanks! We didn't think of that, adding the session ID to the xapi base url seems like a great idea. We will probably use something similar for our lms.
Personally i still think that this is debatable, because then you could argue that every MUST for the AU is also a requirement for the LMS to check (and even vice-versa). But i guess this is a topic for a future version or the weekly meeting. Thanks for the help and explanation! |
For future readers, besides modifying the URL path, the most reliable way to pair the session with the learner preferences is that every xAPI request to the LRS must have the Authorization Token in it. 8.2.1: 8.1.2: With these combined, looking up your authorization token at the LRS request level is the most reliable way to proceed. Modifying the LRS endpoint URL can provide other benefits, but this is probably the most secure way to identify the session. |
Hi, we have some issues with
005-1-invalid-au.zip
, maybe you can give us some hints.1. send statement before loading learner prefs
1.1
The requests to retrieve the
cmi5LearnerPreferences
does not contain any session or AU information at all. I think there is no way for an LMS to check if the learner preferences were requested for this specific AU, at least not if users are potentially able to execute multiple AUs in parallel. How are we supposed to solve this?1.2
Where does this requirement even come from? The spec only says that the AU MUST request the learner preferences. It does not say that the LMS actually has to verify this.
2. save learner prefs with invalid language preference values
We currently return a
400 BAD REQUEST
for invalid learner preferences but the testsuite fails. It shows the following error message:This error message has nothing to do with the specific test so we are not sure what is wrong. Also, something that we noticed through the whole testsuite: it tells you that (in this case) a 400 is the wrong status code. But it never tells you what the correct one would be, why?
The text was updated successfully, but these errors were encountered: