Closed GrantBailey closed 8 years ago
As a local interface TinCanPHP will allow a single instance of TinCan\Agent
to have multiple IFIs, but during serialization for sending to the LRS it will only serialize one, in a somewhat arbitrary decision order made by me for one of the other libraries a long time ago. The spec does limit a stored Agent to a single IFI (this goes back to what was available in the 0.9 version of the spec that had Agent merging which after seeing in the wild was a mess and was subsequently removed). See first two bullets here: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#details-2
The order is account
, mbox_sha1sum
, mbox
, openid
which is essentially the order from most specific to least specific in my mind. The code for this is here: https://github.com/RusticiSoftware/TinCanPHP/blob/master/src/Agent.php#L48
So your sample is working as I'd expect, the mbox
is null
because that IFI was not sent to the LRS when serializing the statement, and the account.name
is a string because it was the one sent.
Note: This is the reason for the Person
object and the read only Agent Profile resource, if you can find an LRS that implements it in a suitably complex fashion. (Most will just return the Agent provided via the query string.)
Brian, Thanks so much for your response - on the weekend too. I cannot believe that I missed the specification restriction - thanks for setting me straight. Grant
👍
It appears that an Agent may have more than one IRI. The SCORM Cloud LRS permits it and there appears to be nothing in the specification against it.
If that is the case, does the Account IRI take precedence over any other IRIs present? I have found that when both an mbox and an account are specified as IRIs, the value of the mbox appears to be ignored in some cases.
To illustrate: in the code below, the output is 'NULL' and 'string' contrary to my expectations (I was expecting 'string' and 'string').
I may well have overlooked something. In any event I would be grateful for clarification.
Thank you and regards,
Grant Bailey
// code //