On Fri, Sep 20, 2024 at 11:24:06PM +0200, Patrice Dumas wrote: > On Fri, Sep 20, 2024 at 10:53:12PM +0200, Patrice Dumas wrote: > > If we use the current date, the dcterms:modified, in theory, should > > never be set in the past of the current date for the same publication > > identifier. The current specification > > https://www.w3.org/TR/epub-33/#sec-metadata-last-modified > > refers to the previous specification that explains the difference between > > the Unique Identifier, which does not change with each minor revision > > and the Release Identifier > > https://www.w3.org/publishing/epub32/epub-packages.html#sec-metadata-elem-identifiers-pid > > It is said, in particular "The sequential, chronological order inherent > > in the format of the timestamp also places EPUB Publications in order > > without requiring knowledge of the exact identifier that came before." > > The Release Identifier became the dcterms:modified metadata. > > That being said, after rereading the specification, I realize that I may > have mistaken the last modification date dcterms:modified with the > dc:date element, which is the publication date, and is optional. Having > the last modification date that is too recent may not be such an issue. > If it was the publication date, it would have been more problematic.
Ok. I'd also point out that the EPUB 3.2 specification is superseded and EPUB 3.3 does not strictly define the semantics of dc:modified. It is for "compatibility" with EPUB 3.2 and earlier but this would mainly be for automatic processing, I believe. We don't need to worry too much about the wording of EPUB 3.2.
