possible problem xml:lang item

[oston]

After running access-aide on an old epub file, epubcheck gives the following error for a line in the opf file.
Col: 105: ERROR(RSC-005): Error while parsing file: attribute ""xml:lang"" not allowed here; expected attribute ""id""

The Package version shows 2.0, so I thought this might be a version issue.
I tried the latest version of epub3-itizer. The conversion went OK, but the package still shows 2.0 and epubcheck gave the same error.

Any suggestions for where to look for the cause of this problem and fix it?

Thanks,
Jim

[Karellen]

Can you post the full line from the opf file.

[KevinH]

The epub3-itizer plugin is an output plugin. You need to load the file it creates into Sigil. It does not not change your current file. And it definitely updates the package tag to "3.0".

My guess is you kept using the file you ran epub3-itizer on.

According to Daisy -

EPUB 2 does not allow a global language declaration using the xml:lang attribute on the package element. You must declare an xml:lang attribute on every metadata tag. With a global language declaration on the package element, you only need to override that declaration if metadata is written in another language.

I will make sure to modify Access-Aide to only add the xml:lang to the package tag on epub3, not epub2.

But given how long epub3 has been out now, and that epub2 is long deprecated, no newly created epub2s should be being created anymore. An epub3 made backwards compatible with epub2 can do everything an epub2 can do and more.

You might want to move to epub3.

[oston]

Thanks, Kevin, Karellen
Karrellen, Here is the full line
<package version="2.0" unique-identifier="bookid" xml:lang="it-IT" xmlns="http://www.idpf.org/2007/opf">

But after I used epub3-itizer correctly and reran access-aide, epubcheck no longer reports that error.

We have been using epub3 for quite a few years now, but we are now examining all our published epub files to see if they conform to the upcoming European Accessibility Act. Some of those files go back to 2013.

I had forgotten about epub2, so this example was a really valuable eye opener.
We will add the step of converting all our epub2 files to epub3.

Many thanks, Kevin
Jim

[oston]

I am very rusty about the technical differences between epub2 and 3. So I am not really clear about what to do about this new epubcheck error that came after converting the epub2 to epub3.

Col: 92: ERROR(OPF-096): Non-linear content must be reachable, but found no hyperlink to "OEBPS/nav.xhtml".

I tried to correct that, but ended up making more errors :-((
????

[KevinH]

This is due to a recent change in epubcheck. The meaning of using linear="no" on the spine itemref in the opf is not clear from the specification. Some e-readers do not show anything that has linear="no" whereas other ereaders do. So to force the issue, epubcheck wants an external link to anything listed as "linear="no" from some other document in the spine without the linear="no".

But this is a silly restriction that should never include the nav.xhtml as it is machine parsed and presented to epub reader by the e-reading software always. No external link to it is needed. But epubcheck treats the nav like every other xhtml file.

The only solutions are:

1. remove linear="no" from the spine itemref entry for the nav. But then the nav will be seen as an xhtml toc and be part of the reading order. You should then remove any xhtml TOC using the nav instead and add to the nav css stylesheet to make it look like what you want.

2. remove the nav entry from the spine completely. But this generates an error since the nav can only link to things in the spine, and the nav internally links to itself. So you must remove the internal link in the nav.xhtml to itself on the nav landmarks.

3. Add a small footnote with a link to the nav from the xhtml table of contents. Or any other place that it might makes sense.But then you must have an xhtml table of contents to put the link in.


Personally since the nav is always accessible to the end user just like the old NCX was, they should not be applying to rule in epubcheck. I argued with them about it but got nowhere.