Specify canonical interpretation of ISO8601 (perhaps RFC 3339)
Closed this issue · 7 comments
Currently, the xAPI spec uses ISO 8601 to define the format of timestamps. I think it would be worth specifying a particular interpretation of ISO 8601, namely RFC 3339.
The most obvious reason for this is that ISO 8601 is a closed standard, which somewhat defeats the purpose of making xAPI an open standard. After all, from recent back-and-forth it looks like even those working most closely have not even seen the full ISO 8601 spec: #874
The second reason is technical: ISO 8601 is actually very complicated, and I am skeptical that there actually are third-party libraries in most languages that support all of what is supported by ISO 8601. (Really, this is just a logical extension of the previous reason: ISO 8601 isn't an open standard, which makes it hard for there to be third-party open source support in the communities of different programming languages.) This means that an LRS vendor would, at minimum, have to write its own parser to validate timestamps, and to actually use timestamps and durations for datetime arithmetic the LRS might have to write its own date time implementation.
And finally, we are missing some guidance on the optional features of ISO 8601. Much of the ISO spec contains language along the lines of "if the sender and receiver agree" or "if necessary for a particular application". The xAPI spec does specify things like the level of precision or milliseconds, but it doesn't specify whether, say, we should except decimal hours or minutes.
RFC 3339 is a web-based "profile" of ISO 8601 and makes those decisions for us. Furthermore, while it doesn't specify much about the meaning of durations, it does include a BNF grammar for ISO 8601, which would not otherwise be available to people who haven't chalked up the cash to ISO.
Granted, there are some disadvantages here: RFC 3339 makes some decisions about the optional features, and so it is technically a subset of ISO 8601. For example, RFC3339 doesn't allow for specifying a duration as a decimal number of months. At the same time, I would be very surprised if actual existing xAPI statements are using those features.
Either way, I think there is a strong case that specifying that "Timestamps should be formatted according to ISO 8601" is insufficient to fully specify what our timestamps and durations should look like in xAPI. There are simply too many optional features to ISO 8601 that the xAPI spec leaves open.
I think it makes sense to go to at least RFC 3339 at least as a SHOULD* right away, even though that doesn't help us much on the validation side (perhaps we just note that the LRS has to be fairly loose with validation in 1.0.x).
Beyond that, due to the reporting issues that arise when trying to compare PT1M vs PT31D or even PT1D vs PT86400S (leap seconds), I think we should strongly consider SHOULD* the specific format PTnnnnn.nnnS , as it's not much of a burden to express duration in those terms initially, and it makes comparison of duration possible.
This seems like a sensible approach and a quick look through RFC 3339 didn't bring to light any obvious problems. A closer look will be worthwhile before merging any PR on this.
@bscSCORM re: PTnnnnn.nnnS 1.0.3 already says "Durations are expected to be presented in the format in which they are recorded. For example if a duration is tracked in seconds (or fractions of a second) there is no need to convert this to hours, minutes and seconds." For example, studying for a qualification might be measured in days/weeks/months/years - it doesn't make sense to translate that to seconds.
Per the 4/09/2016 call, reference the RFC 3339 as best practice. Conversions are always hard between units (leap seconds happen, months are obscure, etc.) Can recommend using fractional seconds for quick interactions. Strong case for going to milliseconds. Can we make a case to change the precision the spec captures? More conversation needed.
Solving this will solve #874 too, I believe
Can now be closed.
Bump @andyjohnson @mlefoster can this be closed please?