Example needs to be clearer it's talking about statement requests

[garemoko]

The LRS SHOULD* reject any request with 400 Bad Request status where the content type header does not match the content included in the request or where the structure of the request does not match the structure outlined in this specification for a particular content type. For example, if the content of the request is formatted as JSON, the content type is expected to be application/json. If the content type is application/x-www-form-urlencoded it is expected that the request will include a method parameter as outlined in Alternate Request Syntax.

The "for example" here refers specifically to the case "where the structure of the request does not match the structure outlined in this specification for a particular content type" but that's not totally clear in the text. I suggest we split this out into two requirements to make that clearer. ie.

The LRS SHOULD* reject any request with 400 Bad Request status where the content type header does not match the content included in the request.

The LRS SHOULD* reject any request with 400 Bad Request status where the structure of the request does not match the structure outlined in this specification for a particular content type. For example, if the content of the request is formatted as JSON, the content type is expected to be application/json. If the content type is application/x-www-form-urlencoded it is expected that the request will include a method parameter as outlined in Alternate Request Syntax.

[andyjohnson]

I'm fine with this change as compound requirements are nothing but trouble. Would be a patch change as the meaning of the requirement doesn't change, just that the example follows from the second half of the original requirement and now is placed as such.

[garemoko]

Discussed on today's call: perhaps this whole requirement was intended only to apply to statements API. It would be very onerous to expect the LRS to validate every possible content type that could be stored in the document API.

[hallshouse]

I agree with Andrew. Why should a specification bend for those who do not conform to it? ;)

I have already described Articulate Rise xAPI (among other) issues to their engineers and have also assisted another group member with (in-general) the same xAPI issues a second time to Articulate. Articulate engineers have been telling us they are working on it, but its been months now.

My statement to my clients: "My xAPI products do not support Articulate Rise". Pointe-Finale.

I have not found xAPI issues with Captivate yet.

Just my 2 cents...

[ryasmi]

Hey @garemoko, happy with this change and I agree that "this whole requirement was intended only to apply to statements API" as it would be "onerous to expect the LRS to validate every possible content type that could be stored in the document API".

[ryasmi]

What, when and where are these calls by the way? I wouldn't mind listening in.

[garemoko]

@ryansmith94 from https://groups.google.com/a/adlnet.gov/forum/#!forum/xapi-spec

Meeting schedule

• xAPI Spec Technical Working Group Meeting - 1st and 3rd Wednesday of each month, 2:30-3:30 (Eastern)
• xAPI Conformance Testing Meeting - 2nd Wednesday of each month, 2:30-3:30 (Eastern)

GotoMeeting Information

https://global.gotomeeting.com/join/686232837

You can also dial in using your phone. United States: +1 (669) 224-3217

Access Code: 686-232-837

More phone numbers Australia: +61 2 9087 3604 Canada: +1 (647) 497-9350 Germany: +49 692 5736 7317 Italy: +39 0 230 57 81 42 Netherlands: +31 207 941 377 Norway: +47 21 93 37 51 Sweden: +46 853 527 836 Switzerland: +41 225 4599 78 United Kingdom: +44 330 221 0088

[ryasmi]

Thanks for the info. I now understand why I don't jump on those calls, they're at 7:30pm here haha

[garemoko]

Most of the year. Sometimes they are 6:30pm due to daylight savings differences.