I find the eBraille specification is not always very clear about how it —normatively— to EPUB.

How eBraille/EPUB is currently defined

As a reminder, the way it currently articulates is as follows:

• the normative relationship to EPUB stems from the "eBraille publication conformance" section, which —similar to how it's done in EPUB— contains normative statements on the high-level MUSTs pointing to subsequent eBraille sections (package document, primary entry page, publication resources, packaging, etc).
• then, each of the eBraille main sections typically contain a normative statement linking to EPUB. For instance for the package document:

At the root of the eBraille package document is the package element. This element MUST conform to the requirements for the package element in [epub3].

Note: eBraille better explains the relationship to EPUB in the "Relationship to EPUB 3" section, but this is non-normative

Some issues

1. some normative statements in EPUB are not propagated to eBraille

For instance, for package documents, by only normatively referencing to the requirements for the package element in EPUB 3, eBraille in some way leaves out EPUB's normative "Parsing URLs in the package document" section.

2. some dependencies to EPUB are not expressed as RFC2119 statements

For instance, in the "XML conformance" section:

The requirements for XML-based media types [rfc2046] defined in XML conformance [epub3] also apply to eBraille publications.

or in the "Resource location" section:

eBraille does not support the file: URL scheme [rfc8089] for referencing resources in an eBraille publication.

Suggestion for improvement?

I'm wondering if the entire relationship to EPUB could be made more explicit if eBraille said something like:

a conforming eBraille publication MUST be a conforming EPUB publication, except for the willful violations documented in this specification.

using the willful violation terminology form Infra.

The only willful violation, as far as I can tell, being that eBraille does not require to be packaged as an OCF ZIP Container.

All this is mostly editorial, but I believe it would clarify some normative bits. Also, it may be easier to maintain since anything added to EPUB, any editorial change in EPUB's spec organization, will be automatically ported to eBraille.

@mattgarrish what do you think?