Audiobooks

[TzviyaSiegman]

こんにちはTAG！

I'm requesting a TAG review of:

• Name: Audiobooks
• Specification URL: derivative of WPUB
• Explainer, Requirements Doc, or Example code: Audio Explainer
• Tests: to come
• Primary contacts: @wareid, @mattgarrish

Further details (optional):

• Relevant time constraints or deadlines: This is a very early review, prior to writing the audiobooks module of Web Publications. Initial impressions would be appreciated.
• [ ] I have read and filled out the Self-Review Questionnare on Security and Privacy. Work in Progess
• [x] I have reviewed the TAG's API Design Principles

You should also know that this is this first module of Web Publications Specification (see related issue #344). The PWG recently changed direction a bit as outlined in this blog post. The Publishing WG has not yet drafted specific language for this module. We are working to plan meetings with major audiobook distributors in the USA in March 2019 to obtain their feedback about our proposal.

We'd prefer the TAG provide feedback as (please select one):

• [ ] open issues in our Github repo for each point of feedback
• [x] open a single issue in our Github repo for the entire review
• [ ] leave review feedback as a comment in this issue and @-notify [github usernames]

cc @iherman @GarthConboy

[markcellus]

Looks like the Explainer link needs updating

[TzviyaSiegman]

Thanks @mkay581. I fixed it.

[TzviyaSiegman]

for those reading comments on email the Audiobooks explainer is at https://github.com/w3c/wpub/blob/master/explainers/audio-explainer.md

[cynthia]

Out of plain curiosity, why is this restricted specifically to audiobooks? It feels like taking a manifest and doing a regexp like s/mp3/mp4/g would make this a video playlist(?) format, such as what you would get through DVD/Bluray chapters.

[iherman]

@cynthia absolutely correct. The "core" document (wpub) should be the basis of different publication types, which may include audiobooks, good-old-digital-books, scholarly publications, or indeed video playlists. The various publication types (for the time being we use the term 'profiles') are build on top of this core, possibly adding terms and possible requirements that may be profile specific. It is the intention of the group to push any manifest term that may be usable in general into this core.

The reason audiobook is the focus right now is purely pragmatic: there is a dynamically growing market with a very messy practical situation right now. Creators of audiobook players have expressed their frustration with the current status, and a standard is badly needed. Hence the choice of audiobooks as a first incarnation of a specific profile. The WG intends to work (albeit not yet on a rec-track) on other profiles, too.

[torgo]

@TzviyaSiegman can we discuss a bit at the AC meeting next week?

[TzviyaSiegman]

@torgo more than happy to discuss!

[torgo]

@TzviyaSiegman we didn't get to discuss this at the A.C. unfortunately - let's find a time to talk sometime in the coming week.

[wareid]

@torgo @TzviyaSiegman is on vacation (a well-deserved one) for a few weeks, I'm happy to discuss anything with you if you want to this week, or we can wait until she returns!

[cynthia]

@hober and I discussed this during the Iceland F2F - we've been told that there is a updated explainer coming up, and we'd be glad to review this again when that is in place.

[rektide]

Really hoping to see https://github.com/w3ctag/design-reviews/issues/354 advance, reading this part of the spec on Web Packaging:

The Working Group is very interested in Web Packaging as a future option for Audiobooks (and other web publications), but due to timing, we have decided to proceed with a temporary option in the Lightweight Packaging Format (https://w3c.github.io/pwpub/), until there is a viable web option.

This audiobook spec includes a manifest.json, which among other things enumerates all the files & includes some metadata. This is a good thing for the future, because I don't believe there's any API as a part of Web Package or otherwise that a page can use to discover other bundled content.

In a webpackaging world, I feel like some adjustment to the manifest would be required. If the manifest refers to filenames, is it up to the browsing context to figure out what URL the manifest was at, and to join the paths together? Alternatively, the manifest could include canonicallized full urls, rather than filenames or paths, as these would be how the resources identify themselves inside the bundle.

Venturing further afield, the web's inability to observe available resources is also present in fetch, which won't tell you that, if you fetch a resource, that other resources are being PUSHed in reply to that fetch ( whatwg/fetch#65). In general, approaches to "audiobook" might be different if, when a bundle is loaded, or resources are pushed at the page, the page had some means to detect those resources which it now "has".

[hober]

Hi,

@dbaron, @plinss, and myself took another look at this during our Cupertino F2F. All of our previous feedback in w3c/audiobooks#9 has been duly considered, and design review issue #423 captures the remaining work on our side. We're therefore closing this. Please request a new review if the design substantially changes. Thanks!

[wareid]

Thank you!