Re-declaration of reserved prefix 'rendition'

9 posts / 0 new
Last post

Hello. I'm creating an EPUB3 fixed layout children's book. When I validate it with IDPF's online validator, I get the following error: Re-declaration of reserved prefix 'rendition'.

Here is my code in my OPF file:
version="3.0" xml:lang="en">

I've tried using the following code because I read somewhere that this is actually the correct code for EPUB3:
<package xmlns=""
unique-identifier="ISBN" version="3.0"
prefix="rendition: ibooks:">

But I get the same error. How do I fix this?

Prior to fixed-layouts being integrated fully into EPUB 3, you had to declare the rendition: prefix to include the fixed-layout properties.

Now that they have been integrated, you don't have to declare the prefix anymore; the prefix is reserved for that use.

So, to stop epubcheck from complaining simply remove the prefix attribute. I doubt you have to declare the ibooks prefix, as you would have received an error if you were inserting ibooks metadata that hadn't been declared. It's certainly not required for EPUB conformance.

I'm going to open an issue in epubcheck that redeclarations should be ignored if they redeclare the prefix to the reserved URI.

Well, I think the problem here is, that the version indication 3.0 is both for Version 3.0 and 3.0.1 but rendition is only a predefined prefix for 3.0.1.
Because a vaidator cannot identify, which version an author uses, it cannot get it right for all books.
The epubchecker version 3.0 (I typically use) does not know the rendition prefix, for this one it is necessary for authors to provide the prefix information, maybe newer variants know the prefix and claim it an error, because they asume version 3.0.1 instead of 3.0.
Such time dependent check results are clearly a bug of EPUB 3, because is has no own version indication.

So I removed the rendition:prefix, and the IDPF validator clears it, but when I validate it in Pagina EPUB-checker, which uses epubcheck 3.0.1., I get the following error: Undecleared prefix: rendition

There are different ways to work around this bug of EPUB 3.0.1
a) Ignore error messages of new checker versions about redefining predefined prefixes and do no assume at all, that a prefix can be predefined (or at least more than are predefined in version 3.0). This follows the general concept of EPUB 3, that such a book should not depend on external resources like DTDs etc
b) Use another version indication for EPUB 3, for example version="3.0.1" - typically a good checker will notice this an will provide a message, that it cannot check such a version.
c) Simply use another than the predefined prefixes mentioned currently in
For example use simply the prefix 'r' instead of 'rendition', it is shorter and currently not predefined.
d) Do not use constructs from the rendition namespace at all and remain with EPUB 3.0.

The problem with b) is of course, that there is no specification for such a version, therefore the book gets formally undefined.
The remaining risk of approach c) is of course already mentioned in the document defining the predefined prefixes: 'This document is subject to change at any time.'
This means, new entries in the future can corrupt already published books - surely a serious bug of EPUB 3.0.1 and this predefined prefix approach, but this was already discussed, without any attempts to fix such bugs and logical inconsistencies in EPUB.
Therefore one cannot expect, that such checkers can provide reliable results, their reports are only hints about problems, one always has to find out, whether the problems are in the book itself, in the checker or in the EPUB specification the checker assumes for the check ;o)
Most bugs will be in the books itself of course, but some are in the checker as well, a few in the specification ;o) I think, currently this applies for all non trivial digital formats and validations.

Changing the version number is awful advice to give anyone, as there's no guarantee if you change the version to something a reading system isn't expecting that it will open the file. That's why the reading system developers advocated for no change to the version number for 3.0.1 as it was a minor revision.

It's also an warning to redefine a reserved URI to another prefix, and a warning that won't be removed. I wouldn't trust all reading systems not to ignore mappings and simply fall back on string value processing.

There's also nothing in the specification that says if you declare a prefix it will become invalid in the future if it happens to be the same as one that gets reserved. The actual wording is that reading systems must respect the prefix as it is declared. The warning is to alert users that they're colliding with another usage.

Considering that only two non-industry prefixes have been reserved in four years since 3.0 was released, the fear of future collisions seems to be your usual hyperbole. There's also a lot of interest in moving EPUB away from inlined bibliographic metadata to external records in the ongoing 3.1 revision, and metadata that effects rendering, which will remain, falls under IDPF stewardship.

If you have to stick with an older validator -- and Pagina is being updated to 4.0, or so it appears from Tobias' comments in the epubcheck isssues -- then leave the prefix declaration in and ignore epubcheck's warning for now. Warnings don't typically have any impact on the rendering of your book.

As I mentioned earlier, the warning in 4.0 is an overly-literal interpretation of the specification that needs to be removed, and will be in the next release. The specification only says to warn people if they override a reserved prefix, but redeclaring is not overriding.

Long story short, FXL exposed a problem with prefixing exactly because we couldn't update the core specification to reserve "rendition:" until the next EPUB revision, so for a couple of years everyone had to declare the prefix because until the revision it wouldn't be clear if the prefix was retained or dropped. By decoupling the list, we can now avoid a repeat of this situation, with no real-world impact.

Are there really viewers, which refuse to display books just because the value of the version attribute is different from what they know? As several other digitals formats EPUBs provides options to create backwards compatible books, even accessible for older viewers. Such a behaviour to refuse the display completely would be against such attempts of authors providing backwards compatible books - maybe not really a good idea to publish such a viewer ...
I observed more the opposite for EPUB 2 viewers, a few freeze or crash with the attempt to interpret something unknown, exposing obviously an internal bug of the viewer, but most just try to do the best. One viewer indicated already for EPUB 3, I tried, can crash/freeze as well with specific valid content instead of rejection unknown/not yet implemented features or even more useful - to present only a warning.

If a viewer does not manage to interpret other prefixes for such namespaces with predefined prefixes, it is as well clearly an indication of a bug - a good test to see, whether they have implemented interpreation of this prefix attribute at all.

And sure, in theory and according to the specification the prefix of the author has always priority, but this does not really help, if publishers use such checkers and rely on the result and rejecting valid books just because they believe in the result of a checker/validator - there is no validator, that really works complete for the prose recommentations of (X)HTML and SVG,
even if it would work for the EPUB fraction. Validation is a good help for authors, but in several cases problematic, if one only relies on such automtatic results.
Of course, they will reject books with an unknown/undesired version indication as well, remain
options c) and d) to satify them, if this is the goal of the checker-game.

I think, finally it is not good, if authors permanently work around bugs and limitations of viewers or validators instead of reporting such such bugs.
If bugs are exposed by valid books, it is much more likely, that the bugs are fixed. If authors help to cover bugs, there is not much need for implementors to increase the quality of their products.

The problem is that the distributor doesn't accept the files if it has any errors.

Did you already try to report the problem to the distributor, that the error/problem is not in your book but in the validator (respectively the EPUB 3.0.1 recommendation)?

And if it is really only a warning, the checker indicates, not an error, the rejection is indeed a problem of the distributor as well...

And if the distributor ignores these arguments, do you see any problems with the suggested workarounds such as using another prefix?

Some distributors seem not to accept EPUB 3 at all yet, therefore other options can be to try another or to publish yourself...
If this distributor is of some importance, it might be necessary to provide a special, simplified edition just for them not using any construction of the questionable namespace.

Secondary menu