Recommend a format for the evaluation date

[mattgarrish]

Section

https://www.w3.org/TR/epub-a11y-111/#sec-evaluation-date

Describe the problem

The section on the evaluation date doesn't say anything about the format which is problematic when it comes to displaying the metadata to users. As it is, the date could be iso 8601 conformant, which would make it localizable, or it could be in a localized form which would cause issues for machine translation.

Describe the fix or new feature you propose

We should at least recommend to use an iso 8601 conformant string.

[iherman]

I think the various documents should be consistent. EPUB authoring, e.g., the "last modified date" in EPUB 3.4 requires explicitly to use 8601 (this is probably inherited from DCMI, actually, but that is all right). 8601 is also one of the formats advised by W3C I18n in https://www.w3.org/International/questions/qa-date-format.

All this to say: yes, I agree we should use ISO 8601 (there and elsewhere).

[mattgarrish]

Pull request #2731 requires that the date be one of the following formats:

• YYYY-MM-DD
• YYYY-MM
• YYYY

But before merging that pull request, are we sure we want to have this as a requirement (a "MUST") given the time that has already elapsed since we did 1.1? It could invalidate existing content.

If we change the conformance identifier to 1.2, which switching accessModeSufficient to required will necessitate, then it won't be an issue to have this as a new requirement.

Alternatively, we could make this a recommendation (a "SHOULD").

[iherman]

Can we introduce a "grace period"? Use SHOULD, but add a note to the spec whereby we will switch to MUST at the time of the next major version? Of course, this would be really effective only if A11y checkers would also issue some sort of a warning from now on.

[mattgarrish]

The proposal is now similar to the recommendation for the dc:date element:

It is REQUIRED that the date string conform to [iso8601-1], particularly the subset expressed in W3C Date and Time Formats [datetime], as such strings are both human and machine readable.

Keeping this issue open as the requirement will have to be lowered to a recommendation if the version number of the standard is not changed.

[rickj]

If we make this a MUST, we find ourselves running in circles with this and other items from 1.1, namely, there is no way to query the EPUB file to determine if it is a version that requires this MUST, or if it is an earlier version that does not require the MUST.

We decided to not deal with this for 1.1... are we ignoring it for 1.2 as well? At some point we need to figure out how to put something in the EPUB that informs evaluation systems, or reading systems that this file requires a different set of SHOULD and MUST requirements.

[mattgarrish]

namely, there is no way to query the EPUB file to determine if it is a version that requires this MUST, or if it is an earlier version that does not require the MUST

This is for conformance with the accessibility specification, not epub 3 generally, so requirements are always tied to the conformance identifier string. You can gather from that metadata whether the publication conforms to 1.0, 1.1, and, if we accept this change, 1.2, and subsequently what metadata is required or not.