I support that method of filtering. I can't see any use that would benefit from doing it any other way.

In regards to the reporting system vision, is the idea that the LRS deals primarily with inputs and the reporting system deals with outputs? The LRS obviously has some basic output functionality for simple reporting so it can stand alone for basic reporting. 

I can see that vision makes sense and you're right, it's about where we draw the line. I take your point about ordering by timestamp, but I think though that since we're allowing queries by verb, and even things like instructor, we should also allow activity type as a filter. I see that as a pretty core thing to be able to filter by. 

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 all the above aside, if we were to filter on 'activity type' (and presumably the same rules that apply to filtering on activity wrt: object vs context), I would be strongly in favor of requiring the LRS to decide whether each activity ID it considered had that activity type or not, and then consistently apply that decision.
>
>Which is to say, a filter for activity type "...course" would return either all or none of the statements about a particular activity, even if some statements mentioned the activity type was "...course" and others did not.
>
>—
>Reply to this email directly or view it on GitHub.￼
>