{"action":"created","issue":{"url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/494","labels_url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/494/labels{/name}","comments_url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/494/comments","events_url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/494/events","html_url":"https://github.com/adlnet/xAPI-Spec/issues/494","id":41958991,"number":494,"title":"When PUTing a statement, MUST the statement object have an id? Yes. ","user":{"login":"garemoko","id":1363163,"avatar_url":"https://avatars.githubusercontent.com/u/1363163?v=3","gravatar_id":"","url":"https://api.github.com/users/garemoko","html_url":"https://github.com/garemoko","followers_url":"https://api.github.com/users/garemoko/followers","following_url":"https://api.github.com/users/garemoko/following{/other_user}","gists_url":"https://api.github.com/users/garemoko/gists{/gist_id}","starred_url":"https://api.github.com/users/garemoko/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/garemoko/subscriptions","organizations_url":"https://api.github.com/users/garemoko/orgs","repos_url":"https://api.github.com/users/garemoko/repos","events_url":"https://api.github.com/users/garemoko/events{/privacy}","received_events_url":"https://api.github.com/users/garemoko/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/adlnet/xAPI-Spec/labels/patch","name":"patch","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2014-09-04T16:47:55Z","updated_at":"2015-01-20T21:52:04Z","closed_at":null,"body":"For context see: https://github.com/LearningLocker/learninglocker/issues/346\r\n\r\nLooking at the current spec, I can see no requirement for a statement to have an id within the statement object itself when it is PUT. There has to be a statementId parameter in the PUT request, but not (explicitly) in the statement. \r\n\r\nAt the same time ```` Ids MUST be generated by the LRS if a Statement is received without an id. ```` so it's clear that the LRS MUST NOT use the statement id passed with the PUT for the statement, but must generate a new one, which is nonsensical. \r\n\r\nOn that basis, I think we can say it's implied that the activity provider MUST include a statement id within the statement object when making a PUT request. \r\n\r\nThis implication is also supported by https://github.com/garemoko/xAPI-Spec/blob/master/xAPI.md#721-putstatements which describes the ````statementId```` as ````Id of Statement to record````. This assumes that the statement has an id. We also say in a description ````POST must be used rather than PUT to save multiple Statements, or to save one Statement without first generating a Statement id```` (you could argue that the requirement to generate a statement id doesn't require you to including it in the statement, but clearly that's not what's intended). \r\n\r\nSo we should amend ````Ids SHOULD be generated by the Activity Provider.```` to \r\n````Ids MUST be generated by the Activity Provider when using PUT requests.````\r\n````Ids SHOULD be generated by the Activity Provider when using POST requests.```\r\n\r\nThis is a patch. "},"comment":{"url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/comments/70741504","html_url":"https://github.com/adlnet/xAPI-Spec/issues/494#issuecomment-70741504","issue_url":"https://api.github.com/repos/adlnet/xAPI-Spec/issues/494","id":70741504,"user":{"login":"andyjohnson","id":1325035,"avatar_url":"https://avatars.githubusercontent.com/u/1325035?v=3","gravatar_id":"","url":"https://api.github.com/users/andyjohnson","html_url":"https://github.com/andyjohnson","followers_url":"https://api.github.com/users/andyjohnson/followers","following_url":"https://api.github.com/users/andyjohnson/following{/other_user}","gists_url":"https://api.github.com/users/andyjohnson/gists{/gist_id}","starred_url":"https://api.github.com/users/andyjohnson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andyjohnson/subscriptions","organizations_url":"https://api.github.com/users/andyjohnson/orgs","repos_url":"https://api.github.com/users/andyjohnson/repos","events_url":"https://api.github.com/users/andyjohnson/events{/privacy}","received_events_url":"https://api.github.com/users/andyjohnson/received_events","type":"User","site_admin":false},"created_at":"2015-01-20T21:52:04Z","updated_at":"2015-01-20T21:52:04Z","body":"We have an interesting problem here.  I think the original requirement of a Statement property id is valid in that we don't need to dump the requirement of generating a GUID on anyone creating Statements (imho).  Unfortunately, some service down the line needs to pick up the slack if the designer does not, whether that be an AP (in the sense of a trusted system of the LRS) or the LRS itself.  The language needs to change somewhere because one requirement dictates the LRS picks up the slack if no one else does, but the other indicates the requester (AP or otherwise) can't submit a PUT without a Statement ID.  \r\n\r\nSince this requirement doesn't exist for POST, I motion that we remove it from PUT, as the type of request shouldn't dictate the owner of responsibility.  In other words, just because someone batches their Statements, they shouldn't be any more or less responsible about IDs than if they submitted single PUTs. I'm seeing the paradigm as PUT = single vs. POST = multiple.  If we'd rather that paradigm be PUT = use ids vs. POST = don't use ids, I'm fine with that too, but we need to establish something clearer."}}