W3C home > Mailing lists > Public > public-publ-wg@w3.org > December 2018

Re: [AudioTF] Some helpful comments from an audio publisher

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Thu, 20 Dec 2018 14:48:05 +0100
Message-ID: <CA+KS-13i2UtUwqY=xp1f+8x9Ck_zQW8o+GcQ9jStxK__ZKFw=w@mail.gmail.com>
To: "Reid, Wendy" <wendy.reid@rakuten.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Well, this feedback is almost completely aligned with what was proposed in
the first comment of the issue: https://github.com/w3c/wpub/issues/352

There's a very strong anti-M4B feeling, which I'm not really surprised
about.

Some additional feedback though:

Avoid HTML. Seriously. Same for XML. Let the applications (and there will
> need to be application support) read and render the JSON data


I don't think we've solved this issue entirely. I've seen discussions about
forcing an audiobook to have an entry page (even if it doesn't need one)
and the issue about the ToC in JSON is still open.

Store metadata in a manifest file, not in the audio


I'm not entirely sure what that means. In our case, metadata about the
publication are in the manifest but metadata about audio resources are in
the resource.

This potentially goes back to https://github.com/w3c/wpub/issues/229

Array items can be hashes, containing **anything**. This is where I would
> include file hashes, runtimes, and anything specific to the display of the
> file (font, format, label, etc etc)


We don't have a way to indicate the hash of a resource currently. Is it
worth considering?

image001.png
(image/png attachment: image001.png)

image002.png
(image/png attachment: image002.png)

image003.png
(image/png attachment: image003.png)

image004.png
(image/png attachment: image004.png)

Received on Thursday, 20 December 2018 13:48:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:33 UTC