Epub-specs: Must an EPUB Reading System display book metadata to the user?

[dauwhe]

I'm trying to understand what the spec expects of reading systems. The spec says,

The Package Document metadata element has two primary functions:

1. to provide a minimal set of meta information for Reading Systems to use to internally catalogue an EPUB Publication and make it available to a user (e.g., to present in a bookshelf).

Reading Systems MUST recognize the first title element in document order as the main title of the EPUB Publication (i.e., the primary one to present to users). This specification does not define how to process additional title elements.

It MUST process the Package Document in conformance with all Reading System conformance constraints expressed in Package Document Definition.

We have phrases like "must process" and "must recognize," but these do not appear to impose any requirement on the reading system.

Is an EPUB reading system required to display the book title to the user? Is a reading system obligated to have a bookshelf? Are there any testable assertions around publication metadata here?

—Dave (who has been thinking about how to actually test the EPUB spec)

[frivoal]

I am of two minds about this:

• I am very strongly in favor of phrasing all requirements as requirements on the UA rather than on the document. That includes using specific verbs, otherwise the requirement is too vague to be useful, as you observe here.
• A general principle of web specs is that we do not make requirements about the user interface. That's both a matter of principle (UAs should be free to do what they want in that area) and out of pragmatism: if a UA processes the document correctly in all way except that it violates requirements on the UI, if users actually prefer that UA, there's no stopping it.

To me this suggests that the spec can/should:

• State very precisely how such information should be parsed from the document, including when it is stored incorrectly.
• State what the information means and what the UA can use it for
• Do not require that the UA display it, this requirement is not enforceable anyways
• Possibly require linters/validators to complain when this information is missing or incorrect

[murata2makoto]

I strongly prefer requirements on documents to those on programs. Requirements on documents are easily testable, but those on programs are not.

[GarthConboy]

I think the two above comments are actually agreeing.

"Say what the UA can do with the metadata, but place no requirement on the UA to do so."

As you'd expect, I'm a "Spec the content, not the Reading System" kind of guy!

[frivoal]

Requirements on documents are easily testable, but those on programs are not.

Requirements on documents are easily testable for a particular document, but they do not lead to interoperability, as they don't say what the program is supposed to do if the document does not meet the requirements.

[murata2makoto]

Requirements on documents are easily testable for a particular document, but they do not lead to interoperability, as they don't say what the program is supposed to do if the document does not meet the requirements.

I think that fidelity is a better term than interoperability. For a particular class (i.e., browsers) of applications, fidelity can be achieved by making clear requirements on applications. But there are are many other applications. For example, there is an embedded EPUB3 reader which has a few buttons, a speaker, and no screen. We cannot impose the same set of requirements on such EPUB3 readers.

[frivoal]

This seems like a big debate, and I am not sure we should go down that rabbit hole, but the web itself is meant to work on all sorts of devices, including speech only devices and/or devices with very limited input capabilities like the one you mentioned, yet specs like HTML/CSS/DOM/SVG etc are focused on requirements on the UA, not on the document. With an important caveat: they do not impose requirements on the UA's user interface. But they are focused on saying what the UA must/should/may do in all sorts of situations rather than on what the document must/should/may be, and I would argue that this model is a large part of why the web works everywhere, and why it has such good forward/backward compatibility.

[GarthConboy]

+1 to not going down this rabbit (or rat) hole.

To Dave's original:

We have phrases like "must process" and "must recognize," but these do not appear to impose any requirement on the reading system.

Is an EPUB reading system required to display the book title to the user? Is a reading system obligated to have a bookshelf? Are there any testable assertions around publication metadata here?

I would answer "no, no, no" at least for EPUB 3.2.

[laudrain]

I'm ok to impose requirements on documents not on program.
I hope Reading System of WP/PWP/EPUB4 will display the title, have a some sort of bookshelf, but that's not the scope of these spec to impose it.