Specify the format of the evaluation date

[mattgarrish]

This pull request clarifies that the dc:date value for the evaluation has to match one of the patterns: YYYY-MM-DD, YYYY-MM, or YYYY be an iso 8601 conformant datetime.

---

Accessibility 1.1.1: Preview | Diff

[iherman]

This was discussed during the pmwg meeting on 26 June 2025.

View the transcript

PR 2731 - w3c/epub-specs#2731

wendy: seeing none, we will move on

wendyreid: formulating the evaluation dates

mgarrish: we didn't formalize a format for the date
… the problem is how to localize the date when we don't know the format of the date
… we could choose an existing format, and likely exclude the time
… and will this affect existing content
… and have we already committed to bumping the conformance number
… if not, this affect all existing content that conforms to the current version
… are we proceeding on requiring access mode sufficient and is it OK to add this when we bump up the number?

AvneeshSingh: we will discuss this in an upcoming meeting in the WG
… we will elevate it to a must follow and see how the community responds
… we are moving ahead with precautions ACE will flag it
… I am worried if we make the date a must at this point, we would get downstream errors

mgarrish: maybe we keep a separate list of items that we would return to if we change conformance numbers

Hadrien: I don't see the point of this change as a must statement
… what is the value of this change to the user? When you localize the date
… you can choose what to display. At best this could be a "should"
… especially since there are potential validation problems

mgarrish: I see what you're saying, but at this time we have no suggestion about how to express the date

Hadrien: as long as it is based on an existing format, we can work with it

George: identifying the date format seems like standards work
… if we change the conformance number, it gives us more freedom

CharlesL: the reading system or bookstore can always display it how they choose
… having a standard format will help it be changed to the local language
… so we need to go with the ISO
… as far as requiring it, we can start requiring, it has been optional, but we tell everyone to put it in
… we can discuss this in our next WG call
… I agree with George that we should plan to update the conformance number

mgarrish: if we don't make it a requirement we will never really be sure what we get when processing this data
… if we made it a must we would know we could trust the required date format after a certain point
… we don't know what the date will contain if we don't do some testing

AvneeshSingh: does the backward compatibility clause get violated if we make these kinds of changes

ivan: the conformance in the charter never really explicitly refers to the accessibility metadata, we are in a gray area
… it refers to in practice what epub check checks

CharlesL: similar to "conforms to" if you have that then you must put in "certified by"
… maybe it could be if you include a certified date it should conform to an ISO standard

mgarrish: that is what this change does

wendyreid: This change is OK, but we shouldn't make it a must?

mgarrish: right now we will accept any date format from the date section, make it a "should" and see what happens

CharlesL: I don't know that we need to include the date/time, but its OK as long as the time is ISO standard

Hadrien: One of the reasons we should be looser about the format is we don't know what people have in their systems
… if people use a timezone for instance, we can deal with that
… we shouldn't force things that aren't necessary

<CharlesL> +1 to Hadrien

Wendy: any opposition to making this a "should" and adding date/time

AvneeshSingh: let's wait to merge this until after the Accessibility WG

<CharlesL> I also agree this should be a MUST

duga: I prefer making it a must and updating the conformance number

mgarrish: if it isn't a must, ACE can bump it up as a serious error

shiestyle: This date is not mandatory, right?
… from a publisher's point of view we generate epub, and we have to change it because the date appeared, many publishers will use this, but this looks like tricky metadata

mgarrish: it isn't required, but it is a good record, for knowing when their accessibility was last done

mgarrish: the more important part is getting the accessibility review is done

wendyreid: if you're running ACE, you'll get an error, but not from EPUB check

CharlesL: does ONIX have a similar field?

<wendyreid> https://ns.editeur.org/onix/en/196/91

wendyreid: it is number 91, latest accessibility assessment date
… so we'll let the Accessibility TF talk about this first, if they are happy, then we can merge it

---

[mattgarrish]

After discussing with both the WG and CG, the current proposal is to keep the requirement for now but modify it to allow both date and time. We're also adding an issue to the specification to alert people that the change depends on the version number changing so if there is pushback against that change the requirement would have to drop.

[mattgarrish]

I'm going to merge this and #2746 as we've discussed pretty thoroughly now. Until we merge them, we can't get any further feedback from the issue markers that will stay in them.