HI Ben. In the case you outline, yes the reporting tool would want courses and questions, but might well not want all of the data stored in the LRS that might belong to an entirely different thing to what's being reported on e.g. activity type Washington or Eskimo. Currently if the reporting tool wants to get all statements relating to a particular activity type or group of activity types, it has to get every single statement in the LRS. 

Take a look at the profile here for example: https://github.com/garemoko/TinRepo#profile 
Now imagine that this profile instead of creating its own verbs uses existing verbs. How do you get all statements relating to that profile without getting all statements in the LRS? 

If forcing a reporting tool to get all the statements in the LRS is acceptable then why bother having query parameters at all? Why is being able to filter by instructor more important? Indeed, why bother with an LRS at all, why not just send the statements straight to the reporting system since its got to hold them all anyway?

I could understand if you were advocating removing filtering by activity as that is a smaller subset. A reporting tool could get a specific activity by getting all of the relevant activity type and then throwing out the activities it doesn't need. The same can't be done in reverse though as the reporting tool has no way of knowing all the activities within a type. 

Andrew

bscSCORM <notifications@github.com> wrote:

>In xAPI.md:
>
>> @@ -1844,6 +1846,9 @@ Returns: 200 OK, [Statement Result](#retstmts) (See section 4.2 for details) > 			against object property of statements. > 		</td> > 	</tr> > +	<tr><td>activityType</td><td>String</td><td> </td> > +		<td>Filter, only return statements matching the specified activity type id.</td> > +	</tr> 
>
>@garemoko I'm coming back around to question the use case of filtering on Activity Type -- I can see it being desired in a UI, but as I've mentioned before I don't think we should let reporting UI use cases drive the query API.
>
>What came to mind, is a reporting system might only be doing 'high level' reporting, so it only wants to get information about "Courses" and not "Questions" etc. That strikes me as a little odd though, since reporting systems generally provide drill-down capability, for which they would need the questions as well. Again, I don't think we should be designing for "user decides they want some data, report system fetches it from LRS", so the reporting system should have already fetched all the question data for that drill down.... which leaves me with: why do we need this filter at all?
>
>—
>Reply to this email directly or view it on GitHub.￼
>