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

Regarding the deletion portion of this thread -- there is deliberately no delete support because delete can't be guaranteed in a distributed environment. That is, other systems may already have...

I should be a little slower to post in the morning, we do allow for filtering based on user permissions, so I suppose "deleted" statements could exist but not be...

It could be a true and accurate statement which contains information which the actor or someone else no longer wants published, possibly for privacy reasons. Since void is as close...

I thought we discussed this case in the context of the tests, but it looks like we just discussed other ETag related issues. @fugu13's take seems reasonable, and we should...

We could leave it as a string, and have it parse accept-language format. Then, browser based consumers could potentially just read that preference out of the browser and pass it...

Also, the spec calls for the LRS to respect the accept-language header when pulling statements

I don't recall that. If sparse = true in the statement query, language filtering isn't optional.

@falcon-git it's been brought up before on this thread, but have you taken a close look at the attachment capability? (https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#4111-attachments) The use case you describe at the start of...

@thomasturrell I'm seeing much difference in opinion about the current state of the spec here, maybe in terms of how urgent making a change would be, or even which strings...