required properties needs updating

[mattgarrish]

I noticed that @context and conformsTo aren't listed as required in https://w3c.github.io/audiobooks/#audio-requirements

Is it the case that title and readingOrder are never harvested from the PEP? If not, they should only be recommended in the authored manifest.

[mattgarrish]

2.2.4.2 also only recommends author and readby, but the recommended property list suggests all creators are recommended. (I doubt any publication would ever need every possible kind of creator, so this was a beef I had with wpub's list before we closed that work down.)

[mattgarrish]

The validation step in the processing algorithm will also need to be updated to issue validation errors when any of the recommended metadata is missing.

[mattgarrish]

Is it the case that title and readingOrder are never harvested from the PEP? If not, they should only be recommended in the authored manifest.

I see these two are still required. If that's the case, it complicates the processing algorithm in pub manifest as we don't define a way to skip the harvesting of values. /cc @iherman

[mattgarrish]

Although I was thinking last night that if the reading order is empty we could make it a critical failure at the end of the validation stage, which would prevent falling through to harvesting defaults.

I don't think there's any way to stop harvesting of the title, but that's not the end of the world since the UA has to generate one anyway during processing. It'll just require a validation error.

[mattgarrish]

Trying to extend the validation algorithm, I see some problems in the list:

• if the resource list is recommended, you get a warning if you just have a reading order with all your audio/PEP. Is it necessary that you have extra resources beyond the reading order?
• similarly, is it necessary to warn people if they don't have a links section? Even if privacy policy and accessibility report are recommended, it's not required they be in the links
• recommending a global language and direction for manifest entries also seems a bit burdensome, and will take some creative extending to work in a check for

I'd at least suggest taking those items out of the list.

[wareid]

I agree an empty readingOrder would be a critical failure, since... what's the point of a publication with no content?

I'm not sure I want to take resourceList out of recommended, I'm ok to remove privacyPolicy and accessibilityReport, though I do want the latter to be encouraged. These are recommendations afterall, not requirements.

[mattgarrish]

They may be recommendations, but warnings have a bad history in epub. Issuing a warning because someone doesn't have any resources so they didn't include an unneeded property seems a bit heavy handed. Same with links.

But to be clear, it wasn't the relationships I'm worried about as much as resources, links, language and direction. Nothing is wrong with a manifest that omits those properties when they aren't needed.

[mattgarrish]

Although looking at "base direction", it points to inLanguage in the published version but has since become the global language and direction, so maybe I'm just misreading that.

Change the name to "publication language" and the link to https://www.w3.org/TR/pub-manifest/#inLanguage and my concern disappears (for language and direction).

[mattgarrish]

Closing this as the remaining items are raised in other issues now. I cluttered this one up enough. :)