search

adlnet / xAPI-Spec

The xAPI Specification describes communication about learner activity and experiences between technologies.
https://adlnet.gov/projects/xapi/
906 stars 404 forks source link

May need a way to exclude the voiding statements returned by a non-explicit param in a Statement Query. #547

Open nashyura opened 9 years ago

nashyura commented 9 years ago

If I search by a verb, then the query returns statements targeting the statements with that verb, even if the targeted statements have been voided. As such, I may get a bunch of voiding statements, which does not seem to me like it would be interesting for reporting. The spec seems to do this by intent 7.2.4:

The LRS MUST still return any Statements targeting the voided Statement when retrieving Statements using explicit or implicit time or sequence based retrieval, unless they themselves have been voided, as described in the section on filter conditions for StatementRefs. This includes the voiding Statement, which cannot be voided. Reporting tools can identify the presence and statementId of any voided Statements by the target of the voiding Statement.

This seems to leave it up to the client to wade through a possible buildup of voiding statements. Would it be reasonable to have a query definition that restricts the returned statements to exclude voiding statements?

bscSCORM commented 9 years ago

The primary use case for which querying the statement endpoint was designed is to synchronize statements, possibly a filtered sub-set of statements, from the LRS to an external system (which may or may not be another LRS). That other system could then report on the synchronized statements.

This does make some basic direct reporting possible.

So, this behavior with voided is a problem for direct reporting, but note also that it's not just about voided. If I filter on "completed", do I want to also see "commented on"? Probably not, but if there is a statement where someone "commented on" a completion, that will show up too. Again, this is perfectly appropriate for the synchronization case, as the synchronized set of statements would be incomplete without any statements "talking about" those statements as well.

There are other more substantial issues with directly reporting from the statement resource -- for example, it's only possible to sort statements (either ascending or descending) by "stored". Frequently this will be the same as "timestamp", but in the case that timestamp and stored are different, the statements will appear to be in a bizarre order from a reporting point of view unless the reporting tool re-sorts them by timestamp.

The additional overhead we'd add to an LRS by the time we came up with a good "direct reporting" solution would be substantial. Therefore, I suggest we add a "direct reporting" label for this sort of issue, and consider such issues either for an optional feature of 2.0 or for an add-on specification -- and I favor the latter as it seems much easier to manage for something this big. I'm strongly opposed to making "direct reporting" a use case that LRSs are required to support directly, since the interoperability goal is met by being able to synchronize statements into a system that does support direct reporting.

garemoko commented 9 years ago

Based on the discussion on yesterday's call, can we make a new tag for this and other issues "direct reporting".

I guess we should also bump this at least to minor?