[KevinH]

And if you make your nav non-linear in the spine and no links exist to it, epubcheck will complain in the exact same way. The key is here is that Sigil built nav code actually links to itself as the "nav" in its landmarks section. This link from the nav to itself is enough to prevent the epubcheck error as technically a link does point to the nav.

Frankly, this error and its epubcheck "workaround" are both for the birds, as all valid epub3 e-readers can display the nav to the user as part of its navigation features just like the older epub2 ncx could be displayed by the epub2 e-readers.

So this error could apply to other non-linear content without any links landing in it, but should never have been applied to the epub3 nav in the first place!

I argued this with the epubcheck devs to no avail. Their tests for correctness just looks for urls that land inside any xhtml file with no exceptions made for it being the nav.xhtml.

My guess is, the epubverif devs are not running the test to see if a url link lands in an xhtml part. So the self-linking trick to workaround epubcheck's stupidity concerning the nav will not work for epubverif.

Hope this explains this better.

Ps. The reason for this rule by epubcheck is because some xhtml marked non-linear in the spine can never be reached on some e-readers yet, on other e-readers they can still be reached but at the end of the spine by page turning.

The Idpf do not want this, so epubcheck created the rule that nonlinear xhtml resources must have a destination link to them. They just did not properly special case the nav.xhtml nor handle the case of javascripted access to an xhtml file either. So I never pointed out to the epubcheck devs that an internal link to itself in no way helps to solve their problem because the nav.xhtml never should have been treated like the other xhtml files. To top it off the landmarks section is rarely even visible on some e-readers.

The same internal link trick works for any xhtml file listed as non-linear and always has.