Possible replacement for EPUBCHECK

[KevinH]

You misunderstand. dc:language is for the book. xml:lang is for the contents of the opf (metadata, etc).

[JSWolf]

Originally Posted by KevinH

You misunderstand. dc:language is for the book. xml:lang is for the contents of the opf (metadata, etc).

Thanks for the clarification.

[Kayadelenium]

Thank you all — four reports since 0.11.0, four issues, and all four are things we miss rather than things we wrongly report, which is the direction I much prefer them to arrive in.

Doitsu, enc:EncryptedData with no enc:CipherData — #88 (https://github.com/veripublica/epubveri/issues/88). Our encryption.xml check validates the root element's children and never looks inside them. Worth flagging what I found while writing it up: the requirement inverts between versions. EPUB 3 requires CipherData and makes EncryptionMethod optional; OPF 2.0.1's schema does exactly the opposite. So this needs a version check rather than one rule, or it becomes a false positive on EPUB 2.

JSWolf, empty <tours> — #87 (https://github.com/veripublica/epubveri/issues/87). The grammar knows the element exists and never got its content model. <guide> sits three lines above it in the same file with the right shape already, so the fix is small.

JSWolf, RSC-004 on the encrypted font — #89 (https://github.com/veripublica/epubveri/issues/89). You are right: epubcheck names the font, we name the file that mentions it. The finding is a fact about the font, so epubcheck's location is the correct one. Location only — the message, severity and everything machine-readable stay as they are.

JSWolf, xml:lang on an EPUB 2 <package> — #90 (https://github.com/veripublica/epubveri/issues/90). Wider than the one attribute: epubcheck's EPUB 2 <package> takes only version, unique-identifier and id, and ours takes anything at all. I checked all 312 EPUB 2 books on my test shelf — 310 carry nothing extra, two carry prefix (an EPUB 3 attribute in a 2.0 package, which epubcheck also rejects). So closing this costs nothing and gains two correct findings. Not one book of the 312 has xml:lang on <package>, which is a useful reminder that my shelf can only tell me about constructs it has actually seen.

KevinH — your reading is right, and your last post puts the part that matters better than I would have: dc:language is about the book, xml:lang is about the OPF's own contents, and they are not the same fact. That is exactly why an OPF-specific schema should not have overridden something XML makes available on every element.

It does not change what I will do, though. epubcheck owns the verdict here. A book that fails epubcheck has to fail epubveri too — otherwise someone whose retailer gates on epubcheck has no way to tell my judgement from my bug, and that is the one thing I cannot afford to be ambiguous about. Disagreeing with a rule is a reason to take it upstream, not a reason to stay quiet about it. So I will implement it, and if that argument does go to w3c/epubcheck it should go as yours rather than second-hand from me.

JSWolf — "changing an ePub3 to ePub2 without changing the rest of the code is actually pretty good at finding errors in epubveri" is a fair description of where my weakest surface is, and I am going to steal it. Doing that deliberately across my shelf is a great deal cheaper than waiting for the next one to surface.

All four are queued for the next release.

[JSWolf]

I really appreciate your quick responses and new versions with the fixes. You are doing very well. Thank you.

[Kayadelenium]

epubveri 0.12.0 is out — crates.io, npm and the eight pre-built binaries. This is the release I said the four reports were queued for, so all of them are in it: release notes (https://github.com/veripublica/epubv...es/tag/v0.12.0).

Why 0.12.0 and not 0.11.1, since a third minor bump in three days invites the wrong conclusion. One public Rust function changed shape, which for a pre-1.0 crate forces a minor bump — that is the whole reason. Nothing moves for the CLI, the JSON output or the browser build, with one deliberate exception noted below. And unlike 0.10.0 and 0.11.0, this one is actually about the validator: four real gaps close.

Empty <tours> is now an error (JSWolf, #234). OPF 2.0.1 makes the <tour> child mandatory. I had added <tours> to my grammar in July for the opposite reason — I was wrongly rejecting a legacy book that used it — and what I added was the element's existence, with a permissive placeholder standing in for its content model. Its <guide> neighbour, three lines above in the same file, had required a child all along.

RSC-004 now names the encrypted font, not META-INF/encryption.xml (JSWolf, #235). You were right: the finding is a fact about the font, and epubcheck locates it that way. It carries no position now either, for the same reason epubcheck prints -1,-1 — there is nothing inside a binary to point at. Doitsu, this one is visible in the JSON: the location value changes; code, severity, rule and params do not.

encryption.xml's encrypted items are checked now (Doitsu, #233) — and the part I did not expect is that the requirement inverts between the two versions:

inside <enc:EncryptedData> EPUB 2 EPUB 3
nothing missing EncryptionMethod missing CipherData
EncryptionMethod only accepted missing CipherData
CipherData only method must come first accepted
empty CipherData needs Reference/Value same

Every cell was measured against epubcheck 5.3.0 with one book per shape rather than read off the two schemas, and all eight now agree. That was worth the trouble: my first attempt filed the ordering rule as EPUB 2-only, on the reasonable-sounding grounds that only OPF 2.0.1's grammar is a sequence. Both are — so EPUB 3 was left silent on a file epubcheck reports. Building each shape and asking is what caught it; re-reading my own code would not have.

An EPUB 2 <package> no longer accepts any attribute (JSWolf, #236). epubcheck's list is exactly three — version, unique-identifier, optional id — and mine was a wildcard, so xml:lang and every EPUB 3 attribute passed silently. Across the 312 EPUB 2 books on my shelf this produced two new findings, both prefix="calibre: …" on a 2.0 package, both matching epubcheck exactly, and no false positives. The EPUB 3 grammar is untouched, with a test that says so in both directions: prefix and xml:lang are perfectly valid on a 3.0 package, and closing both lists would have traded a legacy gap for a false positive on most modern books.

KevinH — my view has not changed, only what I ship. Your objection is now written into the source beside the rule, so whoever reads that code next meets the argument and not just the constraint.

Two things I have not done, so they do not sit here looking finished. JSWolf's "changing an ePub3 to ePub2 without changing the rest of the code is actually pretty good at finding errors in epubveri" — I said I would steal that as a test, and I have not started; doing it properly means running it across the whole shelf, not on one book. And the EPUB 2 unused-resources check from earlier in the thread is still where I left it: measured, not promised.

As always — if anything here reports a problem on a book that is actually fine, that is the report I want most, and it jumps the queue ahead of everything else.