Bookish nature of recommended resources?

[mattgarrish]

In separating out the link relations from the properties, I'm questioning now why we place such strong emphasis on identifying/including the following resources:

• privacy-policy
• accessibility-report
• cover
• pagelist

Even EPUB with its admittedly book-centric world view doesn't recommend that these resources be included. These also really take us from defining the technical aspects of a format into what kinds of content we expect to be authored with it. (Only table of contents strikes me as worthy of a recommendation, which I've left off the list, but I suppose even that is debatable.)

If we expect adoption beyond professional publishers, how relevant or common are these resources really going to be, too? What are we expecting from user agents that necessitates their inclusion?

I don't have any issue with detailing their existence and expected uses, of course, but I think we should reconsider making these optional resources and let specific implementations, like an EPUB 4, ratchet up their necessity, as appropriate.

[iherman]

Just to make it clear for others, we are talking about sections 2.6.6.2, 2.6.6.1, 2.6.7.1, and 2.6.7.2 in the WP draft.

[iherman]

I just want to clarify your question. At this moment, these four sections do two things:

• They each define a specific type of resource and tell us how to add reference to these resources into the manifest
• They "qualify" their required usage: the privacy policy and the a11y report are labeled as RECOMMENDED (i.e., as SHOULD), whereas the cover and pagelist are qualified as MAY

So is your question:

• Should they appear in the document in the first place?
• Or, if it is all right to have them in the document, why do we have some as SHOULD-s and others as MAY-s

[mattgarrish]

The problem I have is when you reach the Web Pub manifest requirements you find they are all listed in the "Recommended" category: https://w3c.github.io/wpub/#wp-requirements

I don't know how to read that as leaving their inclusion optional, or adhering to a "should" identify only when included.

I would argue that the WP requirements for these should be lowered to MAY to be consistent with their usage descriptions.

[mattgarrish]

But to your other question, yes, I'm a bit uncomfortable with the publication manifest getting into recommending resources, even if loosely. There's no way to enforce a requirement to "identify when included". Why wouldn't you identify it? Let's leave that to authors.

[mattgarrish]

To be honest, I'm now questioning why we have so much "recommended" descriptive metadata.

What does it mean, for example, that accessibility metadata is recommended, when accessibility metadata encompasses 6 properties? If they're all recommended, does that mean every type of creator is recommended? We're just seeding confusion without more information.

But more philosophically, what does it mean to recommend descriptive metadata when such metadata is often not universally applicable?

The "descriptive" properties that have the most general utility, in my opinion, are the language, base direction and reading progression direction. I put descriptive in quotes, because these seem perhaps a bit mis-characterized given their more prominent influence on processing and rendering.

Without a compelling use case for the rest, we're just asking for metadata for metadata's sake, or we're asking for it in the wrong place (i.e., an epub profile could have stricter requirements, as could an accessibility specification).

[llemeurfr]

I tend to agree with @mattgarrish. Descriptive metadata are displayed to the user in a certain form, used for filtering / searching, but not used by the reading system.

I would argue that every descriptive metadata listed in the specification is recommended (when it applies). If not useful, it would simply not be listed in the spec.

[iherman]

@mattgarrish wasn't this issue handled in the WP (now pub-manifest) draft already? If so, you should close it...)

[mattgarrish]

Ya, I guess if we ever resurrect WP we won't inherit any recommended metadata from the manifest, so we'd have to review why we need to recommend so much regardless.