Assuming we can work out the issues about which definition to use, I think this is an important case. Currently if a reporting tool wants to get all statements about an activity type, it's got nothing to filter on. I'm getting round this in my repository reporting tools by simply getting all verbs in the profile, but if I was using verbs that were not unique to the profile, or didn't care or know about the verbs I'd have to get all statements in the LRS.

Maybe I'm missing something in your vision of a reporting system. Is this an extra layer between LRS and reporting tools? If so, do we need to consider standardizing its behaviour?

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 this at minimum needs more definition / discussion. This brings us back to face the "activity definitions by reference or by value" discussion. Specifically, does this filter look at the activity definition that was stored with the statement, or consider what the LRS considers to be the cannonical definition of the activity instead?
>
>See my comments above about the LRS itself not being a reporting system... This is certainly a "must-have" feature for a reporting system, but I'd rather avoid the confusion in an LRS
>
>—
>Reply to this email directly or view it on GitHub.￼
>