I don't think this is as big as issue here as it has been elsewhere. Activity definition description, extensions and possibly even name could in theory change and still be the same activity e.g. adding a new language. The same is not true of type. If the type changes, you've really got a different activity. I suppose there might be instances where an activity type becomes deprecated or a new and more appropriate one becomes available, but in those cases you would want to amend all the previous definitions anyway.

That said, in the instance above, I suppose a reporting tool might not know about the new type and still query on the old one. It would still expect to get the new statements too. We could either try and support that by returning all statements where the activity Id matches any activity id that has ever been used with the specified type, or not support it, and leave it as a wake up call for the reporting tool to update its activity type.

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> 
>
>@fugu13 would be curious to get your thoughts on this.
>
>I see how it could be important to filter. Besides philosophical resistance to adding too much to the query API, and concerns that this will need a long interpretation discussion, I think this will be more difficult than it sounds for LRSs to implement (efficiently).
>
>My biggest concern by far would be any confusion/discussion about the behavior, and if anyone is going to champion the "just filter activity type as written in each statement" approach I think it would be Russel, so curious to hear what he has to say there before I worry too much about the other points.
>
>—
>Reply to this email directly or view it on GitHub.￼
>