Publishing WG Telco, 2019-01-07: Packaging for audio

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

There was only one topic for discussion on the call: continue the discussion on the packaging format for Web Publications in general, but with a particular focus on audio books; this was a followup of the Audio Task Force meeting in December.

As a result of that audio task force meeting a draft has been created for “OCF Lite” (temporary name). The idea was to take the EPUB 3 OCF document as a starting point, and adapt it to the WP/Audiobook needs. The approach was to remove the EPUB3 specific requirements and files, add some WP specific ones (e.g., adding a Primary Entry page in HTML, a manifest in JSON). There is a separate comment listing the main differences in the relevant github entry.

A number of issues were discussed during the call. Some main ones:

  • Whether the removal of the manifest file is a good idea or not
  • Relationship to the “original” EPUB 3 OCF file, ie, whether the document should simply refer to it and list the differences only or be a standalone document
  • Relationship to the Web Packaging Work at W3C/IETF. This is actually the most important issue; some of the comments on the call:
    • The Web Packaging spec is more “Webby”, and would solve a number of issues like security, origin, etc. However, the specification is not yet there, and it may take longer than the audiobook community can wait to get it finalized, standardized, with a relevant tools being available, etc. The audiobook spec needs a packaging approach now.
    • It would be a hard sell to ask audiobook publishers to produce HTTPS request/response pairs, turn the results into CBOR, etc, when they just want to combine a bunch of MP3 files into a file. Web Packaging may be an overkill…
    • There may be a need for several packaging formats, depending on the circumstances, media, use cases.

There may be other packaging formats out there (e.g., HEIF), though, so due diligence requires looking at those, too, before making a final decision. A separate github issue has been setup, with a life-span of two weeks, to look at this and, possibly, a final decision will be made then.