APs should be able to obtain a list of all registrations associated with a learner, activity or learner/activity pair

[garemoko]

It would be helpful for an activity provider to be able to obtain a list of all registrations that have data in the Document APIs. For example this might be used to display a list of previous attempts to the learner to choose from, or for a reporting tool reporting on state data (with a small 's' in the sense of all the Document APIs deal with the state of play, I'm not referring explicitly to the State API).

_Breaking change:_ The LRS MUST maintain a list of registrations in some JSON document we define with a key of http://adlnet.gov/xapi/keys/registration-list

_Non-breaking change:_ APs MAY maintain a list of registrations in some JSON document we define with a key of http://adlnet.gov/xapi/keys/registration-list

For examples of applications that might use this feature, see https://github.com/garemoko/moodle-mod_tincanlaunch and adlnet/xAPI-SCORM-Profile#7

[aaronesilvers]

+1

On Nov 21, 2014, at 8:12 AM, Andrew Downes [email protected] wrote:

It would be helpful for an activity provider to be able to obtain a list of all registrations that have data in the Document APIs. For example this might be used to display a list of previous attempts to the learner to choose from, or for a reporting tool reporting on state data (with a small 's' in the sense of all the Document APIs deal with the state of play, I'm not referring explicitly to the State API).

Breaking change: The LRS MUST maintain a list of registrations in some JSON document we define with a key of http://adlnet.gov/xapi/keys/registration-list

Non=breaking change: APs MAY maintain a list of registrations in some JSON document we define with a key of http://adlnet.gov/xapi/keys/registration-list

For examples of applications that might use this feature, see https://github.com/garemoko/moodle-mod_tincanlaunch and adlnet/xAPI-SCORM-Profile#7

—
Reply to this email directly or view it on GitHub.

[brianjmiller]

Can't the AP already do this with State? Or any of the document APIs, or a combination of them?

[garemoko]

By "this" do you mean "maintain a list of registrations in some JSON document we define with a key of http://adlnet.gov/xapi/keys/registration-list" ?

[brianjmiller]

Yep, or any other key they so desire. The bottom line being, the AP(s) can store whatever they like, that could be a history of launched registrations, requiring the key to be something specific doesn't seem necessary within the spec itself. Requiring an LRS to provide a list of registrations seems like a can of worms, particularly with the eventual consistency aspect of statements vs. immediately consistency (and concurrency control) of documents.

[bscSCORM]

If we take on "direct reporting" use cases in general, this issue becomes a reasonable one to address. Therefore I make the same suggestion as I did for #547

[garemoko]

In response to @brianjmiller - yes the AP can maintain their own list now using any key. My point was that it'd be helpful for the LRS to maintain this list, though that's a breaking change. If we decide to include that LRS requirement in future, it might be nice to encourage APs to use the same key now for forwards compatibility. I guess as well there's nothing to stop an LRS maintaining a list with that key now either. It could happily be in a separate document as @bscSCORM suggests.

[garemoko]

Waiting to discuss @bscSCORM's comment on a call before PRing this.

[andyjohnson]

Discussion on 2/04/15 - Examine as a larger effort the querying purposes and capabilities of the LRS. If we are going to enable new use cases, we should really enable them and not just solve pieces at a time (another piece brought up was the querying of Document APIs). An exception may be timestamp sorting, which is currently impossible without pulling every Statement (can only limit by "stored"). This will be tagged as a 2.0, with timestamp sorting potentially being a 1.1.

The management use case should also be further vetted before determining if this additional requirement is helpful.

[canweriotnow]

Sounds great except for this:

in some JSON document

Specifying the server-side representation of a resource is the AntiREST, and I think we can do better. Perhaps

• The LRS (term) maintain as a resource list of registrations we define with a key of http://adlnet.gov/xapi/keys/registration-list"
• The LRS (term) support MIME type "application/json" for representation of this resource.

Just to try to start being RESTful.

[garemoko]

Yep, I meant that it would be retrievable as json; the LRS can store the data as carefully arranged fish in a frying pan for all I care! This wasn't at all intended to be final language, though I can see how the way I laid it out might give that impression.

[canweriotnow]

@garemoko Yeah, I figured that, it's one of those editing things that I think needs to happen in a bunch of places 😸