[Kayadelenium]

Originally Posted by JSWolf

It points out some rather stupid changes to the ePub spec and epubcheck 4.5.0. Please don't follow the stupidness.

I read the thread, and I went to the specifications rather than to EPUBCheck before answering, because that is the order here: the specification is what epubveri is measured against, and EPUBCheck is how the rest of the world measures the same thing. I track it closely, but where the two disagree the specification wins. There is a live example of that one post up, in Doitsu's report: 5.4.0 rejects aria-label and aria-labelledby on a navigation document's nav elements, the specifications allow them, and epubveri accepts them. That is w3c/epubcheck#1726 — confirmed, marked critical, milestoned for 5.4.1. And where the fault is theirs rather than the specification's, I report it: w3c/epubcheck#1731, which I filed last Friday — a dc:date ending in a bare dot, such as a timestamp written 2010-01-01T10:00:00., throws an uncaught exception in EPUBCheck's date parser. It prints a stack trace, stops checking the rest of the book, and its JSON report comes out with zero messages and zero errors, so a pipeline reading that file sees a clean book. rdeltour reproduced it the same day and it is milestoned for 5.4.1 too. Both links are worth a click if you want to see how these get settled. So "follow EPUBCheck" is not the rule, and if 5.4.0 had invented these messages I would have said so.

It did not, and that is why I have to decline. EPUB 3.4 adds a new category called outdated features, and its list is exactly what OBS-001 reports: the NCX, the OPF 2 meta and guide elements, the collection element, font obfuscation, content fallbacks, the rendition flow, orientation and spread properties, and the -epub- prefixed CSS properties. The specification then tells conformance checkers not to raise alerts about them, and that is precisely why they arrive as usage notes rather than warnings — it was the specification's own editor who asked EPUBCheck for them, at usage or info severity, so that they could never fail a book. The safeguard you are asking for is already the design. HTM-062 is the same story: EPUB 3.4's normative reference for SVG is the unversioned one, which today is SVG 2, and SVG 2 is where xlink:href was deprecated. (That also answers the question elibrarian raised in the other thread about SVG 1.1.)

What I will not do is go quiet on a rule the specification and EPUBCheck agree on, because the way that failure reaches you is silence: you run epubveri, it tells you nothing, and you find out from whoever rejects the file. An error I decline to report does not stop existing — it just stops being mine to tell you about. Worth saying plainly, though: nothing is being asked of you here. OBS-001 and HTM-062 do not move a verdict and do not set the exit code, so a book carrying nothing but those is a book both tools call valid. The noise you are objecting to is a display question with a switch on it, not a correctness one.

Originally Posted by JSWolf

Or how about a warning that it breaks backward compatibility?

That one I want. It is a different and much better request, and it is a question EPUBCheck cannot ask — "is this valid?" and "will this still open on a 2012 reader?" are not the same question, and no conformance checker will ever answer the second. epubveri has a place built for exactly this: --advisory, an opt-in flag whose findings never touch the verdict or the exit code.

What it needs before a line of it is written is evidence, because an advisory that is wrong is worse than no advisory. Not "old readers may break" but which reader, which version, which markup. The thread already has the beginning of it: elibrarian found plain href fine in ADE 4.5 and not in Readest 0.12.8; you found it breaks older RMSDK. That is the shape of the data that turns this into a check — and it is the kind only people with the devices can produce. I cannot measure it from here.

This is the same family as epubveri#136, which came out of your last request — tell me when an EPUB 3 has no NCX, because an older RMSDK reader needs one. I would rather fold both into one honest answer to "will this book open on old hardware" than bolt on two unrelated warnings. It is research with no promised date, but it is open and it is the direction I want to go.

Two facts that take some of the pressure off in the meantime.

1. You do not have to choose between xlink:href and href. Doitsu worked this out in the Sigil thread and I verified it in both tools: an image carrying both attributes with the same value is silent — no HTM-062, no HTM-063, in EPUBCheck 5.4.0 and in epubveri alike. HTM-062 fires only when xlink:href stands alone; HTM-063 only when the two values disagree. So an SVG cover can keep the xlink:href that old readers need and add the href beside it, and both tools go quiet. I implemented that branch from EPUBCheck's own source (OPSHandler30.getSVGHrefs) rather than guessing, and re-ran it today to be sure.

2. The switch I mentioned above. On the command line, both tools hide usage messages unless you pass -u — EPUBCheck and epubveri alike. Worth knowing if you meet them in a panel rather than a terminal: the Sigil plugin and the calibre editor plugin show usage notes by default, which is their choice and not the tool's — the calibre library plugin does not — and all three have a switch for it in their settings.