Audio TF #4

16 Nov 2018


gpellegrino, wendyreid, laudrain, tzviya, duga, romain, Avneesh, DanielWeck, marisa, Garth, zheng_xu


<wendyreid> scribenick: DanielWeck

<wendyreid> https://www.w3.org/2018/10/12-pwg-audio-minutes.html

Wendy: maybe consider alternating time more convenient for other timezones

open issues

<wendyreid> https://github.com/w3c/wpub/issues/361

Wendy: the "big picture" for audio books, what about distribution process

websites, distributable packaged audio books, etc.

scribe: Publishers do not have a good way to validate content, users cannot easily download files (erm, DRM)
... variations for track listing, difficulty to share content

(...see issue for more details)

<wendyreid> https://github.com/wareid/audiopub-explainer

Brady: minor detail - downlaod of audio book not really an issue in the current ecosystem, more to do with DRM

Avneesh: valid descriptions, but user representation, participation of distributors is needed, lots of authoring by associations, volunteers, would be beneficial

Wendy: we had a call with Michele Cobb of Audio Publishing Association to explain what the audio group is doing.

Avneesh: W3C membership costly

<laurent_> https://www.audiopub.org/industry/about

Wendy: community group cheaper / free

<wendyreid> https://github.com/w3c/wpub/issues/352

<laurent_> APA -> web domain "audiopub.org" .... funny

Next topic: packaging for audio books

<garth> Yes, let’s packaage!

Wendy: all resources inside ZIP archive
... manifest at well-know root location

etc. (see issue)

Wendy: seems to be a consensus about what we want in packaging
... but what about HTTP CORS as noted by Daniel

Avneesh: WP also needs packaging
... how to manage overlap / cross-group effort

Wendy: audio book packaging needs more urgent / trickier (streaming?

Garth: lightweight OCF for audio books, but not necessarily have direct impact on generic Web Publications

Tzviya: create something new might get objections

Garth: agree (ref. light OCF), worth discussing: use OCF, remove signature mimetype thing, but keep backward compatible

Laurent: rationale for OCF: publications not born on the web

<garth> +1

Laurent: but Web Packaging more for web-born content
... publisher-provided content, OCF fine
... answer publishing needs for non-web content
... content not born on web

Brady: what about practical difficulties to reference OCF from the audio spec
... especially new version / OCF light

Tzviya: I think W3C ok to reference non-recommendation, but ISO more stringent requirement
... OCF-light, even though only removing features, is something *new*
... making case for why this is necessary is a matter of marketing/communication

Laurent: maybe alternate way - OCF is/will not be standard for the web
... no need to have OCF recommendation, can be other specification paper
... for example JSON-Schema (etc.) are not necessarily W3C

Wendy: who would take on OCF-light?

Tzviya: follow-up to Laurent: referencing is okay, but to avoid the W3C process seems abusing the process

Laurent: no bypassing, just that the format is not for the web

<Hadrien> http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip

Wendy: how to package an audio book
... OCF-light maybe viable solution
... what cases for packaged audio book might be different from web audio book
... are there potentially differences that might differentiate TOC (for example)
... JSON vs. HTML for example (TOC)

Garth: with regards to HTTP complexities (CORS headers, accept-ranges: bytes etc,)
... do not apply to packaged format
... the need is common format for audio books, focus on packaged version first, then look into specific web issues
... audio book content direct from publishers, TOC HTML vs. JSON
... all the ingest systems for audio books resellers (also handle ebooks, some of them) so HTML TOC fine,

Laurent: +1 to Garth, format compatible with Web Publications, WP group decides HTML entry page required
... navigation is HTML machine-processable inside entry page
... then audio book distributors may then convert to more suitable JSON format
... let's align with WP WG, but lets express our needs

Avneesh: +1 align with WP, don't want fork
... maybe profile, not fork
... question to Daniel: DAISY distributed on hardware storage devices
... but more and more DAISY streaming online
... (DAISY Online protocol)

Wendy: yes to align, not fork
... audio books produced in-house, current authoring process completely different from ebooks (no HTML etc.)
... audio files first, map with TOC (internal format, or spreadsheets)
... as we are going to ask them to produce maniifest JSON etc., might as well as TOC using same format

Garth: +1 to Wend
... if JSON version was dropped from WP
... but if its there, lets use it

Laurent: JSON vs. HTML can be done from spreadsheet / internal format
... either format is fine
... simple conversion script
... assuming already correct structure

<wendyreid> DanielWeck: Avneesh mentioned me so I should respond, the scope of this is much broader than web, including authentication and rights

<wendyreid> ... there's a lot of crossover, hopefully we will get to a point where we don't have multiple solutions for the same problem, perhaps in WP

Jeff: should we close door to JSON TOC?

<gpellegrino> +1 to Jeff

Jeff: difficulty to render HTML (no webview / browser engine) in audio books
... for packaged audio books: what is the use-case?
... reader / reading system vs. web browser
... browser storage limitations
... packed audio books only for publishers - retail connections
... but not so much for browser client?

Garth: use-case for packaging important - distribution
... interchange publisher - retailer

<Hadrien> there's no end user standard for audiobooks, that's a need as well

Garth: initial problem that EPUB set out to solve
... packaged audio book not envisioned as something delivered to end user
... but ingested in distribution pipeline

Laurent: what about download file of audio book at end-user side

Garth: standardizing the distribution as first and foremost, then may grow into a consumer format
... but I view that as secondary problem

Wendy: packaging solutions may help with download (stack of audio files with playlist)
... would be good for end users

<wendyreid> https://github.com/w3c/wpub/issues/351

Wendy: when type is "audio book" "sync media" "comic book", then user agent / reading system can know what it receives

<wendyreid> DanielWeck: As a RS implementor, I do not want to infer the type of UX from the content, I do not want to have to infer the switch between sync media, ebook, comic, from the reading order

<Hadrien> if we have a dedicated media type and extension for the package, problem solved

<wendyreid> ... How do we avoid that? Type is overloaded, we could use "kind" or "nature". As a spec, should we add new properties with set predefined values

<wendyreid> ... or would we diverge too much from schema

<wendyreid> laurent_: Comment from Ivan, we could override the data of type with media types or extension, or we define within our spec

<wendyreid> ... we could end up with confusion in the structure

<tzviya> https://schema.org/Role

<wendyreid> tzviya: we should be wary of adding too many media types in the spec, we could explore other options like role

<Hadrien> wendyreid is describing everything that's wrong with having FXL under the same media type

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/11/16 15:59:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/(?)/Michele Cobb of Audio Publishing Association/
Present: gpellegrino wendyreid laudrain tzviya duga romain Avneesh DanielWeck marisa Garth zheng_xu
Found ScribeNick: DanielWeck
Inferring Scribes: DanielWeck
WARNING: Could not parse date.  Unknown month name "11": 2018-11-16
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]