<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
<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
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]