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 and use 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 can generate an error since the nav can only link to things in the spine, but some navs may internally link back to itself (ie. use just a fragment). So you must remove any 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 this rule to the nav in epubcheck. I argued with them about it but got nowhere.

When another xhtml toc exists in the epub I typically just use approach 3 since it is the easiest. If no xhtml toc exists, then I use approach 1.

I have used approach 2 but in my opinion that hurts the nav by making it less informative and less accessible since not all landmarks are included.

[oston]

Originally Posted by KevinH

....

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.

Many thanks, indeed, for this really helpful reply.

Where does the Option 2 generate an error?

After posting my question, I tried this option just deleting the nav iten from the spine. After re-running epubcheck, I got No Problems Found when I ran epubcheck!.

Another option might be to just ignore that error. I think we did that for another book recently and the publisher was able to upload it to Amazon.

Many thanks for all this help Kevin.
Jim

[KevinH]

That nav must not link back to itself. So you should be good to go.

I updated my post to reflect that.

[oston]

Great news, Kevin. Many thanks

[KevinH]

The fix to prevent adding xml:lang to the OPF package tag for epub2 is now included in the latest release of Access-Aide v1.0.0

[oston]

Thanks very much Kevin.
Jim