Publishing WG Telco, 2018-12-10: Audiobook issues

See minutes online for a more detailed record of the discussions.

The meeting fully centered around issues related to the audiobook discussion

Editorial structure for WP and Audiobooks

The practical issue that has to be solved is whether the audiobook represent a separate document (specification) with its own set of editors and a separate repository. There was no consensus yet on this:

• Some worried that having a separate document and repo may raise the difficulties for a newcomer to join the discussion and to have an overall view; managing the issues over several repositories also create challenges.
• It is unclear whether having everything in one document scales. What if we get new modules, like educational books or mangas?
• On the other hand, everything in one big document may also make things unreadable (and difficult to manage by editors).

To be followed up.

Packaging

(Issue #352)

Audiobooks need some form of packaging for immediate deployment. Because Web Packaging is not available yet, one possibility may be to go for OCF like for EPUB. However, there are number of technical and practical issues:

• OCF is an ISO standard, which makes it usable and referenceable, but what we would need in fact is an "OCF Lite": dropping some features like the order requirements as used in EPUB. That makes it more complicated.
• Are we talking about packaging for audio books or for WPUB in general? What are exactly the borderlines between what is audiobook specific and what is generic WP?

There was also a proposal that, in the case of a packaged audiobook the required, HTML primary entry point would be dropped from the audiobook. However, that would mean a packaged audiobook is not round trippable any more: if unpacked, it is not a Web Publication. This was raised as a problematic issue as well.

Typing

(Issue #351)

At the moment it is possible to add an Audiobook type to the manifest for, well, audio books. There may be other types coming (e.g., for mangas) for which there is not yet a corresponding type in schema.org. The question is whether it is possible to add our own type; if yes, how, and what does it exactly mean for user agents.

The answer to the first question turns out to be 'yes'. As discussed at TPAC with DanBri, we can add such a type to, say, WikiData, and that works potentially well with schema.org. We are talking about 5-6 additional types, not more. However, we have to be careful about not getting to the analogous situation as "this feature is working best with X browser". User agents should be able to do something sensible with all publications, even with that specific type set.