Hi,

what exactly is the error message?

Did you declare the a11y namespace at the root element with xmlns:a11y="..." ?

This is one of the needed updates for EPUB 3.1. It shouldn't have to be declared, although it's generally good practice to declare the prefixes.

As this is for a compact URI, the declaration needs to be done with the epub:prefix attribute:

<package ... epub:prefix="a11y: http://www.idpf.org/epub/vocab/package/a11y/#">

Thanks Matt, I'm adding the epub-3.1 label.

@garconvacher EpubCheck currently does not support EPUB 3.1 as we unfortunately have a severe shortage of development capacity. EPUB 3.1 support will take some time... Stay tuned...

Hi,
Sorry for my late answer.
I didn't see the a11y prefix is from the epub 3.1 specs.
Thanks for your replys.

I didn't see the a11y prefix is from the epub 3.1 specs.

Actually the prefix is defined in the EPUB Publications Reserved Prefixes document, which is a "living document". The "a11y" prefix was added while the WG worked on EPUB 3.1, but by being added there it should retroactively be allowed and pre-declared in EPUB 3.0.1 too (@mattgarrish correct me if I'm wrong).

The explicit prefix declaration suggested by Matt is a good workaround until the prefix is properly recognized by EpubCheck.

but by being added there it should retroactively be allowed and pre-declared in EPUB 3.0.1 too

Correct, it's not exclusive to 3.1. It's just one of the new things that we added during that revision that haven't yet been added to epubcheck.

I didn't see the a11y prefix is from the epub 3.1 specs.

Actually the prefix is defined in the EPUB Publications Reserved Prefixes document, which is a "living document". The "a11y" prefix was added while the WG worked on EPUB 3.1, but by being added there it should retroactively be allowed and pre-declared in EPUB 3.0.1 too (@mattgarrish correct me if I'm wrong).

I think that addition of reserved prefixes is a mistake in EPUB 3.0.1. In Extending and Versioning Languages: Terminology, there is a definition of forwards compatibility.

A language change is forwards compatible if consumers of the unrevised language can correctly process all instances of the revised language.

I heard that Apple does not support the added prefixes. I guess that they do not like this non-forwards compatible change.

I think that addition of reserved prefixes is a mistake in EPUB 3.0.1.

Apple not accepting them because they use of an older version of epubcheck is not the same as their not being forwards compatible. The specification requires that reading systems ignore unknown prefixes, so unless the reading system is non-conforming, actual lack of awareness isn't a problem.

But didn't we state somewhere in 3.1 that the addition of reserved prefixes is a convenience that should not be relied upon? I clearly remember @iherman pointed out this from the RDFa primer:

To alleviate this issue, RDFa introduces the concept of an initial context that defines a set of default prefixes. These prefixes, whose list is maintained and regularly updated by the W3C, provide a number of pre-defined prefixes that are known to the RDFa processor. Prefix declarations in a document always override declarations made through the defaults, but if a web page author forgets to declare a common vocabulary such as Dublin Core or FOAF, the RDFa Processor will fall back to those.
...
Since default prefixes are meant to be a last-resort mechanism to help novice document authors, the markup above is not recommended. The rest of this document will utilize authoring best practices by declaring all prefixes in order to make the document author's intentions explicit.

Or was it something we talked about doing but never formalized? If not, it should go in 3.2.

I think that addition of reserved prefixes is a mistake in EPUB 3.0.1.

Apple not accepting them because they use of an older version of epubcheck is not the same as their not being forwards compatible. The specification requires that reading systems ignore unknown prefixes, so unless the reading system is non-conforming, actual lack of awareness isn't a problem.

I do not exactly know why Apple does not support added prefixes, but I know that they rejected the request from a Japanese publisher Kadokawa.

Or was it something we talked about doing but never formalized? If not, it should go in 3.2.

Agreed.

I could be wrong, but the a11y prefix was only added in one of the 4.x epubcheck releases and it's a common complaint that vendors don't upgrade quickly as it's not a trivial change.

I couldn't find a note to prefix for compatibility reasons, so all in favour of rectifying that. I was sure we did this, as it's such a clear memory, but I can't even find an issue for it.

@rdeltour, @mattgarrish, what about reading systems? Epubcheck might know the a11y prefix implicitly, but would the absence of its declaration cause issues with readers?

Also, does that mean that there will be a

<package xmlns="http://www.idpf.org/2007/opf" version="3.0" xml:lang="…" unique-identifier="…" epub:prefix="a11y: …" prefix="ibooks: … foo: …">

i.e. two differently scoped prefix attributes?

Epubcheck might know the a11y prefix implicitly, but would the absence of its declaration cause issues with readers?

I don't believe so. Typically if a reading system actually supports metadata with pre-declared prefixes in some fashion, it will recognize the properties without the mapping (since that's what the spec requires). Not having a mapping is otherwise harmless, as prefixed property names aren't validated as xml.

i.e. two differently scoped prefix attributes?

No, only "prefix" is valid in the package document. epub:prefix is the same attribute but for use in HTML documents. I wrote the wrong one above.

Just a heads-up for future visitors of this issue. As of today and even though an EPUB validates without errors or warnings using the latest drop of epubcheck, uploading an EPUB to Ingram Spark still causes the following errors:

Those supposedly “undeclared prefixes” are reserved prefixes as per EPUB specification (link) and the spec says:

This specification reserves the following set of prefixes that Authors MAY use in package metadata without having to declare.

The spec goes on to say

Validation tools will often reject new prefixes until the tools are updated, for example. Authors are strongly encouraged to declare all prefixes they use to avoid such issues.

and that’s exactly what I had to do in order to get past Ingram’s checks using the same IRI values as the spec prescribes 🤦🏻‍♂️

<package xmlns="http://www.idpf.org/2007/opf" version="3.0" xml:lang="en" unique-identifier="bookalope-bc9f86f9-7b32-494d-8809-cf7b07915d09" prefix="ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/ schema: http://schema.org/ a11y: http://www.idpf.org/epub/vocab/package/a11y/#">

Ah well.