I don't like MAY in this case. Surely we want consistent behaviour either way?

I see this as a way of the uri owner maintaining a canonical definition. If the activity provider isn't going to keep it up to date it shouldn't use it. 

Regarding languages, the LRS should never remove a language from a map on the basis of not getting that language as part of a more recent or authoritative map. Maybe we need to state that somewhere?


fugu13 <notifications@github.com> wrote:

>In xAPI.md:
>
>> -Note that multiple activities may be defined in the same metadata document. The LRS > -MAY choose whether to store information about activities other than those for > -which it has received statements. > - > -As part of each group of activities, the activity metadata document may define > -information about an associated activity provider, which the LRS SHOULD consider > -the authoritative source for statements about the activity. > +<a name="actmeta"/> > +__Activity Metadata__ > +* Activities with URL identifiers MAY may host metadata using the <a href="#actdef"> > +activity definition</a> JSON format which is used in statements, with a Content-Type of "application/json" > +* If the activity URI is a URL, LRS's SHOULD attempt to GET that URL, and include in HTTP > +headers: "Accept: application/json, */*". This SHOULD be done as soon as practical after the LRS > +first encounters the activity id. > +* If the LRS loads JSON which is a valid activity definition from a URL used as an activity id, > + the LRS SHOULD replace its internal representation of that activity definition with the loaded definition. 
>
>I don't think it should. Hosted metadata is frequently going to be stale (most data on the web is, after all), while metadata sent in a recent statement is likely to be up to date. There'll be exceptions, of course, but I'm pretty sure that's going to be the normal case for when they're in disagreement. In a case like that, an LRS taking the metadata from a URL will be hurting, not helping itself. Also, it's unlikely the hosted version will include numerous languages, while if the activity (or verb or whatever) is heavily reused, I'd expect the senders to describe it in a number of languages. As we talked about at the workshop, I prefer a "MAY incorporate into its internal representation" language.
>
>—
>Reply to this email directly or view it on GitHub.￼
>