Skip to content

OPF : Undeclared prefix: 'a11y' #810

Closed
@garconvacher

Description

Hi,
the metadata 'a11y' prefix in OPF occurs an error.
e.g. <meta property="a11y:certifiedBy"> from EPUB Accessibility Vocabulary

Activity

tofi86

tofi86 commented on Nov 24, 2017

@tofi86
Collaborator

Hi,

what exactly is the error message?

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

mattgarrish

mattgarrish commented on Nov 25, 2017

@mattgarrish
Member

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/#">

added and removed
status: waiting for feedbackThe development team needs feedback from the issue’s creator
on Nov 25, 2017
tofi86

tofi86 commented on Nov 25, 2017

@tofi86
Collaborator

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

tofi86

tofi86 commented on Nov 25, 2017

@tofi86
Collaborator

@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...

garconvacher

garconvacher commented on Nov 28, 2017

@garconvacher
Author

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

rdeltour

rdeltour commented on Nov 28, 2017

@rdeltour
Member

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.

added
type: bugThe issue describes a bug
and removed on Nov 28, 2017
mattgarrish

mattgarrish commented on Nov 28, 2017

@mattgarrish
Member

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.

murata2makoto

murata2makoto commented on Feb 1, 2018

@murata2makoto
Contributor

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.

mattgarrish

mattgarrish commented on Feb 1, 2018

@mattgarrish
Member

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.

13 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    status: has PRThe issue is being processed in a pull requesttype: bugThe issue describes a bug

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      OPF : Undeclared prefix: 'a11y' · Issue #810 · w3c/epubcheck