Should EPUBCheck differentiate EPUB 3.x versions?

[rdeltour]

An EPUB publication with a version="3.0" attribute on the package element is (currently) expected to conform to either EPUB 3.0, EPUB 3.0.1, or EPUB 3.2. Theoretically, an EPUB conforming to 3.0 would also conform to 3.0.1; and and EPUB conforming to 3.0.1 would also conform to 3.2.

By default, EPUBCheck should validate conformance to the latest backward-compatible 3.x spec (currently 3.2).

Now, the question is: do we want to have an option to run EPUBCheck in a strict "3.0.1" mode (any new EPUB 3.2 features would be rejected as invalid, and EPUBCheck would only check conformance to EPUB 3.0.1, as it currently does)? Or do we just "ignore" 3.0.1 from now on and make no difference between EPUB 3.2-only checks and EPUB 3.0.1 checks?

The EPUBCheck development team would need to know this as soon as possible, as this has an impact on how we implement new EPUB 3.2-related checks.

/cc @RachelComerford @dauwhe @mattgarrish @avneeshsingh @w3c/publ-steering-committee

[mattgarrish]

For the record, I'm not in favour of trying to have "point-in-time" validation on specification releases, as we're supposed to be treating EPUB 3 as a single evolving standard.

If we do this, I think we raise the spectre of illusory incompatibility in validation (e.g., the compression element being allowed in some settings, but an error in "3.0.1" and "3.0"). That's not the way the specification is supposed to evolve.

It also opens the door to the kind of fragmentation that 3.2 is supposed to solve. Instead of having a version number that is not supported, or that requires duplication of content, authors may have to make content compatible with each revision of the standard to accommodate different vendor rules.

Finally, I'm just not even sure what benefit is accrued. Most revisions are incrementally clarifying aspects of EPUB 3, so what constitutes a 3.2-only change, for example? The only thing that revision-specific validation seems to do is allow some set of deprecated features to continue to be valid, and disallow certain things that by right should be allowed as I mentioned earlier.

I realize the current ISO version is going to lag behind the evolving standard, but that doesn't seem like a great case in itself for supporting such validation.

[rdeltour]

With my EPUBCheck-maintainer hat off, +1 to what @mattgarrish said above 🙂

[mteixeira-wwn]

+1 to the above. Concerns about unmasking a "spectre of illusory incompatibility" and fragmentation aside, from a publisher/implementer's point of view, most teams working with and relying on EPUBCheck will need a tool that "just works" without worrying about "point-in-time validation," in @mattgarrish's words. If we adopt a list-wide shift from EPUB 3.0.1 to 3.2, production teams shouldn't necessarily notice or worry about adjusting protocol between the backlist's maintenance and the frontlist's production. I suspect that a silent transition will also encourage more widespread adoption and stronger internal evangelism from those of us aware of the spec update.

[rdeltour]

Just a quick clarification:

I suspect that a silent transition will also encourage more widespread adoption and stronger internal evangelism from those of us aware of the spec update.

The default behavior of EPUBCheck will definitely be to validate EPUB 3.2; so it would be transparent and seamless for the end-user, while promoting EPUB 3.2 at the same time. The question is about an optional EPUB 3.0.1 forced-mode, that would be triggered with some kind of configuration (a command line switch).

If we adopt a list-wide shift from EPUB 3.0.1 to 3.2, production teams shouldn't necessarily notice or worry about adjusting protocol between the backlist's maintenance and the frontlist's production.

Right.
The biggest challenges here are the spec details that are not-so-strongly backward compatible (see @w3c/publ-epub-revision#1185 and @w3c/publ-epub-revision#1186), and deciding what EPUBCheck should do about that.

[toshiakikoike]

I dont' think to need "point-in-time" validation.

I hope that EPUB 3.0.1 files with no errors or warnings by EPUBCheck 4.0.2(and latest 4.1.0) will be no errors or warnings by the future version of EPUBCheck.

[RachelComerford]

Proposed Solution:
EPUBCheck will check conformance to EPUB3.2 as this the equivalent of EPUB3. (Edit: this is a vote that it will only check 3.2 rules, we won't try to create a 3.0.1 flag).

Please vote using Thumbs Up (approve) or Thumbs Down (do not approve) emojis, or by commenting with a +1 or -1

Voting is open until our next meeting on Thursday December 6th at 1700 UTC.

[mattgarrish]

Sorry, just to be pedantic, this is a vote that it will only check 3.2 rules, correct? (i.e., we won’t try to create a 3.0.1 flag)

[rickj]

I hope that EPUB 3.0.1 files with no errors or warnings by EPUBCheck 4.0.2(and latest 4.1.0) will be no errors or warnings by the future version of EPUBCheck.

This is the key question. Given a clean EPUB 3.0.1 (no errors or warnings) what is the expected result?

[toshiakikoike]

Given a clean EPUB 3.0.1 (no errors or warnings),
the expected result for me is "no errors or warnings in this epub file."

I regard this important because there had been confusion in epub production lines at the time EPUBCheck 4.0.0 was released.
(The new version showed warnings against existing "clean" epubs. In Japan, the warnings mainly came from w3c/epubcheck#585 )

If the Proposed Solution matches this condition, I vote +1.

[mattgarrish]

the expected result for me is "no errors or warnings in this epub file."

As I mention in w3c/epub-specs#1186 there are going to be new warnings for the elements we removed from 3.1 but have returned and deprecated in 3.2. Given the general lack of implementation and use of these elements, most files won't be affected, but it can't be broadly stated that there won't be any issues for anyone. Warnings don't make a file invalid; this issue is a problem with vendor acceptance rules.

HTML has also removed features since 5.0, for example:

• https://www.w3.org/TR/html51/changes.html#features-removed
• https://www.w3.org/TR/html/changes.html#features-removed

SVG 2 also contains a number of changes that may affect validation:

• https://www.w3.org/TR/SVG2/changes.html

It doesn't really benefit us to preserve features that never gain adoption, so it's inevitable that some files that were once error/warning-free will need remediation.

[toshiakikoike]

Thank you for the clarification about warnings and validity.
I understand that supported features may change from time to time in the future.

[rdeltour]

Closing the issue, as the voting was overwhelmingly in favor of the proposed solution.

RESOLUTION: EPUBCheck will not differentiate EPUB 3.x versions; i.e. it will validate EPUB publications which declare version "3.0" in their Package Document against the conformance criteria defined in the latest 3.x family of specifications (currently EPUB 3.2), without no option to validate against older versions of the specifications.