01:35:29 <Karen> Karen has joined #pwg
03:06:27 <plinss> plinss has joined #pwg
11:06:23 <plinss> plinss has joined #pwg
12:29:37 <ivan> ivan has joined #pwg
12:35:06 <dauwhe> dauwhe has joined #pwg
13:16:02 <ivan> github-bot, bye
13:16:02 <github-bot> github-bot has left #pwg
13:45:38 <Rachel> Rachel has joined #pwg
13:48:52 <tzviya> tzviya has joined #pwg
13:56:00 <Karen> Karen has joined #pwg
14:58:02 <CharlesL1> CharlesL1 has joined #pwg
14:58:39 <CharlesL1> trackbot, start meeting
14:59:02 <CharlesL1> CharlesL1 has left #pwg
15:04:49 <ivan> ivan has joined #pwg
15:26:53 <Karen> Karen has joined #pwg
16:02:50 <ivan> ivan has joined #pwg
16:04:04 <ivan> ivan has joined #pwg
16:29:45 <Zakim> Zakim has joined #pwg
16:29:49 <ivan> rrsagent, set log public
16:29:49 <ivan> Meeting: Publishing Working Group Telco
16:29:49 <ivan> Chair: Wendy
16:29:49 <ivan> Date: 2019-02-11
16:29:49 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Feb/0003.html
16:29:49 <ivan> ivan has changed the topic to: Meeting Agenda 2019-02-11: https://lists.w3.org/Archives/Public/public-publ-wg/2019Feb/0003.html
16:29:50 <ivan> Regrets+ dauwhe, avneesh
16:56:39 <geoffjukes> geoffjukes has joined #pwg
16:58:11 <laudrain> laudrain has joined #pwg
16:58:38 <laudrain> present+
16:59:38 <wendyreid> present+
17:00:01 <simon_collinson> simon_collinson has joined #pwg
17:00:10 <CharlesL1> CharlesL1 has joined #pwg
17:00:17 <simon_collinson> present+
17:01:23 <gpellegrino> gpellegrino has joined #pwg
17:01:46 <dkaplan3> dkaplan3 has joined #pwg
17:01:55 <josh> josh has joined #pwg
17:02:06 <franco> franco has joined #pwg
17:02:21 <George> George has joined #pwg
17:02:46 <rkwright> rkwright has joined #pwg
17:02:52 <david_stroup> david_stroup has joined #pwg
17:02:52 <dkaplan3> present+
17:02:59 <josh> present+
17:03:06 <George> present+ George
17:03:10 <rkwright> present+
17:03:23 <gpellegrino> present+
17:03:50 <wendyreid> zakim, pick a victim
17:03:50 <Zakim> Not knowing who is chairing or who scribed recently, I propose simon_collinson
17:04:07 <franco> franco has joined #pwg
17:04:09 <Rachel> present+
17:04:15 <Teenya> Teenya has joined #pwg
17:04:17 <franco> present+
17:04:25 <mattg> mattg has joined #pwg
17:04:26 <Teenya> present+
17:04:26 <ivan> present+
17:04:43 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-02-04-pwg
17:04:50 <BenSchroeter> BenSchroeter has joined #pwg
17:04:54 <CHayes> CHayes has joined #pwg
17:04:56 <BenSchroeter> present+
17:05:03 <CHayes> present+
17:05:05 <ivan> present+ simon_collinson
17:05:07 <mattg> present+
17:05:11 <simon_collinson> Wendy: Minutes accepted
17:05:21 <dkaplan31> dkaplan31 has joined #pwg
17:05:21 <tzviya> present+
17:05:28 <wendyreid> https://github.com/w3c/pwpub/issues/33
17:05:30 <laurent_> laurent_ has joined #pwg
17:05:43 <ivan> Topic: PEP in a package
17:05:46 <laurent_> present+
17:05:48 <simon_collinson> Wendy: First topic today is final topic from last week: issue 33 from the Packaged Web Publication repo, about primary entry page becoming optional…
17:06:17 <simon_collinson> …a quick recap, and clearing up some questions. The main proposal right now is Ivan's…
17:06:36 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
17:06:39 <simon_collinson> …PWPs may give you the option to make index.html or a JSON manifest the primary entry page…
17:07:02 <ivan> present+ david_stroup
17:07:05 <Bill_Kasdorf> present+ Bill_Kasdorf
17:07:05 <simon_collinson> …an alternate proposal was brought up on GitHub, the so-called 'minimal' PWP. The index.html only exists to point to the manifest
17:07:26 <ivan> q+
17:07:26 <simon_collinson> …this is specific to PWPs – just for the package context, not for web publications as a whole. Does anyone have comments?
17:07:31 <wendyreid> ack ivan
17:07:39 <duga> duga has joined #pwg
17:07:45 <duga> present+
17:07:49 <garth> garth has joined #pwg
17:07:56 <garth> present+ Garth
17:07:58 <simon_collinson> Ivan: Matt came with a proposal which I personally consider complimentary to the previous proposal, but some people might disagree
17:08:07 <simon_collinson> …but I would prefer Matt to make the proposal
17:08:27 <ivan> zakim, who is here?
17:08:27 <Zakim> Present: laudrain, wendyreid, simon_collinson, dkaplan, josh, George, rkwright, gpellegrino, Rachel, franco, Teenya, ivan, BenSchroeter, CHayes, mattg, tzviya, laurent_,
17:08:31 <Zakim> ... david_stroup, Bill_Kasdorf, duga, Garth
17:08:31 <Zakim> On IRC I see garth, duga, Bill_Kasdorf, laurent_, dkaplan31, CHayes, BenSchroeter, mattg, Teenya, franco, david_stroup, rkwright, George, josh, dkaplan3, CharlesL1,
17:08:31 <Zakim> ... simon_collinson, laudrain, geoffjukes, Zakim, ivan, Karen, tzviya, Rachel, plinss, Travis, wendyreid, RRSAgent, astearns, hober2, bigbluehat, jyasskin, dmitry, florian[m]
17:08:41 <mateus> mateus has joined #pwg
17:08:42 <marisa> marisa has joined #pwg
17:08:44 <simon_collinson> Matt: In the discussion around primary entry pages and whether it's required, we may be overlapping too much with audiobooks and web publications, expecting audiobooks to always be web publications…
17:08:46 <mateus> present+
17:08:51 <marisa> present+
17:09:05 <simon_collinson> …what I proposed was separating the manifest so the primary entry page doesn't always have to be present with a packaged audiobook/epub… but it can be
17:09:11 <ivan> present+ rkwright
17:09:18 <simon_collinson> …if the publisher wants it to be a conformant PWP, the publisher can include the entry page
17:09:39 <ivan> q+
17:09:42 <simon_collinson> …Ivan posted a better clarification of this morning this morning, which is that the packaged formats are somewhat separate from a WP… the package format doesn't always have to be a WP
17:10:25 <simon_collinson> …everything becomes compatible. In its packaged form, the audiobook can be valid. It's essentially making everything more abstract…
17:10:46 <bigbluehat> present+
17:10:50 <simon_collinson> …getting out of the mess of how something remains logically consistent, even if these other formats don't want all these other WP requirements to be present
17:10:50 <wendyreid> https://github.com/w3c/pwpub/issues/33#issuecomment-462309272
17:10:55 <wendyreid> ack ivan
17:11:29 <simon_collinson> Ivan: I want to re-emphasize: everything that Matt said is obviously true, but one important thing is missing: a reading system must be able to understand the packaged version of full web publications…
17:11:35 <mateus_> mateus_ has joined #pwg
17:12:05 <laurent_> q?
17:12:09 <laurent_> q+
17:12:15 <wendyreid> ack laurent_
17:12:16 <simon_collinson> …must be able to understand the primary entry, find the manifest out of that, so that a WP in the traditional sense, by just zipping it, even if I called the manifest file something else (although the index file must be kept) it's still valid
17:13:24 <simon_collinson> Laurent: I totally agree with Matt's point. This is conceptual. Nevertheless, when we describe the spec, it will be very complex to express that conceptual model and at the same time to explain what Ivan said: a reading system must be able to understand everything with a primary entry page
17:13:39 <simon_collinson> …I propose we follow what Ivan suggested before: stating the primary page OR the manifest: one or the other…
17:13:54 <ivan> +1 to laurent_
17:13:59 <simon_collinson> …which for processing is easy to understand. It doesn't mean we don't have to explain this model, but I'd be careful not to make the concept to complex…
17:14:31 <ivan> q+
17:14:36 <simon_collinson> Wendy: We're back to the original proposal. The resolution would be: a PWP may include either the primary entry page or manifest but must contain one of those two
17:15:03 <tzviya> ack ivan
17:15:03 <simon_collinson> Ivan: I think the proposal has two equally important parts.
17:15:06 <wendyreid> ack ivan
17:15:12 <simon_collinson> Wendy: So there are two resolutions
17:16:12 <wendyreid> Resolution: Restructure the document to reflect the publication structure as primary, with web publications and pacakaged web publications as modules
17:16:27 <ivan> -> Matt's proposal for the proposal: https://github.com/w3c/pwpub/issues/33#issuecomment-460369726
17:16:34 <dkaplan31> +1
17:16:37 <tzviya> +1
17:16:37 <ivan> +1
17:16:47 <geoffjukes> +1
17:16:51 <josh> +1
17:16:55 <Rachel> +1
17:17:00 <rkwright> +1
17:17:07 <franco> +1
17:17:07 <mateus_> +1
17:17:09 <simon_collinson> +1
17:17:13 <gpellegrino> gpellegrino has joined #pwg
17:17:13 <BenSchroeter> +1
17:17:14 <laudrain> +1
17:17:14 <Bill_Kasdorf> +1
17:17:21 <gpellegrino> +1
17:17:24 <simon_collinson> Wendy: Resolution accepted
17:17:36 <simon_collinson> Ivan: It's not that simple…
17:17:37 <ivan> Resolved: Restructure the document to reflect the publication structure as primary, with web publications and pacakaged web publications as modules
17:17:55 <dkaplan31> dkaplan31 has left #pwg
17:18:05 <dkaplan31> dkaplan31 has joined #pwg
17:18:56 <wendyreid> Resolution: WP keeps PEP as a reguirement, PWP will give the option of using the PEP or the Manifest, but one must be present in the package
17:19:01 <ivan> -> Ivan's consensus proposal: https://github.com/w3c/pwpub/issues/33#issuecomment-458905788
17:19:12 <dkaplan31> -1
17:19:15 <laurent_> +1
17:19:17 <ivan> +1
17:19:51 <dkaplan31> q+
17:19:54 <simon_collinson> ??: How does this fit in with what Laurent just said about or/both?
17:20:02 <ivan> s/??/Garth/
17:20:04 <simon_collinson> Wendy: OR/BOTH would work here, but at least one has to be present
17:20:13 <George> q+
17:20:17 <mattg> q+
17:20:18 <gpellegrino> gpellegrino has joined #pwg
17:20:29 <wendyreid> ack dkaplan31
17:20:33 <simon_collinson> Deborah: I'm -1 unless it becomes EXACTLY one must be present
17:20:35 <wendyreid> ack dkaplan
17:20:49 <simon_collinson> …one, but only one, must be present…
17:20:49 <ivan> q+
17:21:15 <simon_collinson> …from my experience of working with small producers, people will be confused, which means publications will be wrong, which means reading systems will behave inconsistently…
17:21:27 <duga> q+
17:21:27 <simon_collinson> …creators will have to come up with workaround due to inconsistent implementation…
17:21:30 <garth> q?
17:21:35 <simon_collinson> …the option of having two will end up with badness.
17:21:35 <ivan> q-
17:22:30 <simon_collinson> Ivan: The resolution which I proposed said that the processor MUST look for an entry page (?) and if it finds it, must process according to the rules, and if it doesn't find it, it looks for a manifest
17:22:48 <simon_collinson> Deborah: As long as it's 100% clear to creators and reading systems what will happen, that's fine
17:23:02 <garth> q?
17:23:06 <simon_collinson> Laurent: I was very clear about that
17:23:08 <duga> q-
17:23:34 <dkaplan31> in that case I am changing my vote to a +0 from a -1
17:23:34 <wendyreid> ack George
17:23:35 <simon_collinson> Wendy: Would it be better to rephrase the resolution as either or but at least one must be present?
17:23:40 <simon_collinson> Ivan: This isn't correct
17:24:04 <simon_collinson> George: As someone producing a publication, I'm going to start with my manifest. For an audiobook, I zip that up and distribute it to various places and they process it…
17:24:31 <simon_collinson> …if I want to add a primary entry page then I could serve it up on the web and all is well. To my mind, I'm progressively enhancing the publication
17:24:37 <simon_collinson> Ivan: That workflow is correct
17:24:40 <wendyreid> ack mattg
17:24:52 <timCole> timCole has joined #pwg
17:25:07 <simon_collinson> Matt: My question is one of consequences. When we require specific names, it's going to mean that if you unpackage it on the web, you can only do this with one WP in a directory due to collisions
17:25:09 <gpellegrino> gpellegrino has joined #pwg
17:25:25 <ivan> q+
17:25:27 <laurent_> q+
17:25:32 <simon_collinson> …are we putting a limitation that we got away from earlier back into play – that you can't have multiple articles in one directory?
17:25:33 <wendyreid> ack ivan
17:25:50 <dkaplan31> +0 and not +1 because I still dislike giving people choices, because small creators are confused by choices, while meanwhile large publishers can create a PEP trivially as part of production workflow whether they need one or not. But not -1 as long as clear flow is documented.
17:26:21 <simon_collinson> Ivan: Matt is right. If we don't have a name restriction, we have to do something to the package itself to find where to start. This is zip, we aren't having web packaging, so I'm not sure what else we can do
17:26:31 <laurent_> q-
17:26:42 <tzviya> q+
17:26:53 <simon_collinson> Matt: It's a circular problem: if we don't have specific names, how do you find what you're looking for - if you have something else finding the names, how do you prevent those from colliding?…
17:26:58 <bigbluehat> q+ to ask if PEP's inclusion is still to be allowed in audiobooks (etc)
17:27:03 <wendyreid> ack tzviya
17:27:09 <simon_collinson> …trying to prevent the index.html problem from reoccuring, but I'm not sure how much of an issue it is…
17:27:41 <simon_collinson> Tzviya: This makes me uncomfortable too – it's something we've always tried to avoid doing. In the world of scholarly publishing, if I have a journal of 30 articles, each published on their own, each will have this problem…
17:27:51 <simon_collinson> …I feel like this is going to come back to bite us…
17:27:52 <wendyreid> ack bigbluehat
17:27:52 <Zakim> bigbluehat, you wanted to ask if PEP's inclusion is still to be allowed in audiobooks (etc)
17:28:23 <CharlesL1> q+
17:28:26 <simon_collinson> Benjamin: My question was similar: if we have specified names for these things and a tree of inheritance where down a certain road you have index.html and down another road you don't…
17:28:38 <simon_collinson> …is it possible to make a web audiobook in that world, or do they no longer intermingle?…
17:28:43 <rkwright> Forgive my ignorance...  PEP?   Not  http://support.pep-web.org/about-the-pep-archive/books/  ?
17:28:58 <ivan> q+
17:29:01 <wendyreid> ack CharlesL1
17:29:06 <wendyreid> ack CharlesL
17:29:09 <simon_collinson> Wendy: PEP = Primary Entry Page
17:29:38 <simon_collinson> Charles: Thinking about a journal made up of multiple article, wouldn't each article be its own subdirectory, hence no collisions?
17:29:42 <wendyreid> ack ivan
17:29:52 <rkwright> Thanks.  Should have known that it wasn't Psychoanalytic Electronic Publishing ....
17:30:10 <simon_collinson> Ivan: This whole filing thing reflects that what we're using is a packaging format that isn't web friendly. And we know that, which is why we consider the current format as a lightweight temporary solution…
17:30:53 <simon_collinson> …I'd be happy if we had today a format which allowed me to refer to a URL for every file, and maybe we'll have one before I retire. But we've agreed to define a lightweight packaging format now, and we have to live with it… we don't really have a choice
17:31:21 <garth> q?
17:31:21 <simon_collinson> …we could require a specific way of zipping which puts the file first in the zip file, which makes the publication more complicated, because I can't just take a directory and zip it… this isn't the solution…
17:31:33 <simon_collinson> Wendy: We have to find a compromise
17:31:35 <garth> q+
17:31:40 <simon_collinson> Ivan: We have to accept the deficiencies of the system right now
17:31:41 <wendyreid> ack garth
17:31:50 <BenSchroeter_> BenSchroeter_ has joined #pwg
17:32:13 <simon_collinson> Garth: I agree with Ivan. We dislike the alternatives more – anything that makes it harder is a no-no…
17:32:22 <simon_collinson> …there's a manifest.json and index.html which are both magic names…
17:32:30 <simon_collinson> …the actual manifest can be standalone or included in the PEP…
17:32:45 <simon_collinson> …what are the changes that we propose to ensure there is no possible duplication?
17:33:09 <simon_collinson> Ivan: What I propose: the first step the reading system does is locate the PEP. If it finds that, then it follows the processing steps that are described in the WPUB document…
17:33:23 <simon_collinson> …at first look at your own file, otherwise look for an XML file (?) and that's your manifest…
17:33:23 <mattg> q+
17:33:30 <garth> q?
17:33:31 <wendyreid> ack mattg
17:33:49 <ivan> s/XML file (?)/Manifest file/
17:33:58 <simon_collinson> Matt: We're making our WP format dependent on the packaging… I can live with this, but what if a better packaging format comes along in future?…
17:34:08 <laurent_> q+
17:34:08 <simon_collinson> … would we drop these restrictions?
17:34:18 <wendyreid> ack laurent_
17:34:21 <simon_collinson> Ivan: If we found a packaging format that allowed that, then yes
17:35:11 <simon_collinson> Laurent: In future, this packaging will be used by publishers as a booster for leaving earth. When the publication is exposed on the web, pure web packaging becomes important then
17:35:32 <bigbluehat> q+ to ask about openness to webbier formats
17:35:45 <wendyreid> ack bigbluehat
17:35:45 <Zakim> bigbluehat, you wanted to ask about openness to webbier formats
17:36:04 <ivan> q+
17:36:08 <gpellegrino> gpellegrino has joined #pwg
17:36:21 <simon_collinson> Benjamin: A general question: are we open to analysing other formats for web archiving and distribution, the primary component being that they keep URLs around, or continue with zip?
17:36:59 <simon_collinson> Wendy: If you recall a few weeks ago, we did open up the request for analysis of the different potential formats. They were analysed based on the pros and cons of that table. If we missed anything in that table, it's good to know about…
17:37:05 <wendyreid> ack ivan
17:37:14 <simon_collinson> …we made the decision based on the ~7 formats we looked at in that table
17:37:36 <simon_collinson> Ivan: Let's not reopen closed issues. For now we've decided to go with what we have, knowing that eventually the committee will produce a webby packaging format
17:37:57 <simon_collinson> …we explicitly said that if and when that happens, then this working group or its successor will look at it and consider it…
17:38:10 <simon_collinson> …but we need something today if we want to produce anything before the end of the life of the working group, 18 months from now
17:38:12 <garth> Restated proposal: WP keeps PEP as a requirement, PWP will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not president look for standalone manifest]), but one must be present in the package.
17:38:22 <simon_collinson> …we decided on something and shouldn't reopen today
17:38:49 <tzviya> s/president/present
17:39:05 <Bill_Kasdorf> q+
17:39:11 <wendyreid> ack bigbluehat
17:39:14 <wendyreid> ack Bill_Kasdorf
17:39:32 <simon_collinson> Bill: Quick question: if we're seeing that not all packaged audiobooks are web publications, then we shouldn't call them packaged web publications, right?
17:39:42 <garth> Less typos version: WP keeps PEP as a requirement, Lightweight Packaging will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not present, look for standalone manifest]), but one must be present in the package.
17:39:42 <simon_collinson> Laurent (?): in fact we don't.
17:39:52 <simon_collinson> Bill: Then they aren't really PWPs, then
17:39:54 <laudrain> s/(?)//
17:39:58 <ivan> +1
17:40:03 <garth> +1
17:40:04 <CharlesL1> +1
17:40:05 <tzviya> +1
17:40:05 <mattg> +1
17:40:07 <laurent_> +1
17:40:09 <Rachel> +1
17:40:11 <BenSchroeter_> +1
17:40:11 <josh> +1
17:40:11 <Bill_Kasdorf> +1
17:40:12 <timCole> +1
17:40:12 <geoffjukes> +1
17:40:13 <laudrain> +1
17:40:13 <George> +1
17:40:15 <mateus_> +1
17:40:17 <gpellegrino> +1
17:40:32 <wendyreid> Resolved: WP keeps PEP as a requirement, Lightweight Packaging will give the option of using the PEP or the Manifest (with rules agreed to resolve any possible duplication [start with looking for PEP, and process that first; if not present, look for standalone manifest]), but one must be present in the package.
17:40:51 <ivan> q+
17:40:52 <simon_collinson> Wendy: We've made a decision, with 20min to spare… moving on to our next issue…
17:40:57 <wendyreid> ack ivan
17:41:12 <simon_collinson> Ivan: I propose that we merge the two requests from Laurent whenever he feels comfortable…
17:41:27 <simon_collinson> …reading that document via the pull request is a pain, and it's better if we merge it in
17:41:27 <laurent_> q+
17:41:32 <wendyreid> ack laurent_
17:41:40 <simon_collinson> Laurent: I prepared the merge last week. We can work from that
17:41:55 <simon_collinson> Wendy: If no opposition, we'll merge as soon as Laurent is ready
17:42:14 <wendyreid> Resolved: Laurent will merge the pull request as soon as he can
17:42:26 <ivan> present+ timCole, mateus_
17:42:27 <simon_collinson> Wendy: Next issue is related to tables of contents
17:42:30 <wendyreid> https://github.com/w3c/wpub/issues/376
17:42:31 <ivan> present+ laurent_
17:42:39 <ivan> Topic: Table of content issue
17:42:43 <simon_collinson> …posting link to GitHub issue, regarding the location of the TOC…
17:42:57 <simon_collinson> …should we be directly encoding the TOC into the manifest, or should it be a separate file referenced in the manifest?
17:43:15 <simon_collinson> …the main issue is formatting. Keeping it HTML allows for rich formatting, but a separate file would be easier to process…
17:43:32 <ivan> present+ josh
17:43:33 <simon_collinson> …a lot of user agents aren't currently using styling, but it doesn't have to remain that way…
17:43:37 <ivan> zakim, who is here?
17:43:37 <Zakim> Present: laudrain, wendyreid, simon_collinson, dkaplan, josh, George, rkwright, gpellegrino, Rachel, franco, Teenya, ivan, BenSchroeter, CHayes, mattg, tzviya, laurent_,
17:43:40 <Zakim> ... david_stroup, Bill_Kasdorf, duga, Garth, mateus, marisa, bigbluehat, timCole, mateus_
17:43:40 <Zakim> On IRC I see gpellegrino, BenSchroeter_, timCole, dkaplan31, mateus_, marisa, garth, duga, Bill_Kasdorf, laurent_, CHayes, mattg, Teenya, franco, david_stroup, rkwright, George,
17:43:40 <Zakim> ... josh, CharlesL1, simon_collinson, laudrain, geoffjukes, Zakim, ivan, tzviya, Rachel, plinss, Travis, wendyreid, RRSAgent, astearns, hober2, bigbluehat, jyasskin, dmitry,
17:43:41 <Zakim> ... florian[m]
17:43:47 <simon_collinson> …some providers may prefer a JSON file
17:43:53 <ivan> q+
17:43:57 <wendyreid> ack ivan
17:44:24 <simon_collinson> Ivan: I have a question to various reading system implementers: at the moment, the TOC is defined to be in HTML and we've spent an inordinate amount of time defining the format in HTML…
17:44:47 <simon_collinson> …my favourite option is to say that that's where we stop, realising that this means reading systems must be able to parse an HTML file, extract the TOC out of it, even if it doesn't use any styling…
17:45:19 <simon_collinson> …what I have difficulty judging, is it really such a huge deal for reading systems, knowing that these days taking a public domain HTML parsing library and running it to extract the TOC is really not such a huge deal…
17:45:40 <simon_collinson> …it would make things much clearer if we had one and only one format for the TOC, and we didn't have yet another option we have to define…
17:45:45 <simon_collinson> …is it really such a big deal?
17:45:54 <garth> q+
17:45:58 <wendyreid> ack garth
17:45:58 <simon_collinson> …(to process the HTML file)
17:46:19 <laurent_> q+
17:46:20 <geoffjukes> +q
17:46:24 <wendyreid> ack laurent_
17:46:27 <simon_collinson> Garth: I'm fine with HTML and I'm also fine with only HTML, just because my take is that any reading system taking this packaged audiobook is likely to also be taking EPUB
17:47:15 <simon_collinson> Laurent: I still agree that if we can make something simple in HTML, something easy to create by the publisher/studio, then I agree with only HTML
17:47:18 <wendyreid> ack geoffjukes
17:47:24 <ivan> present+ geoffjukes
17:47:52 <simon_collinson> Geoff: I would be against (?) HTML due to the assets we receive - hundreds and hundreds a week…
17:47:59 <garth> q+
17:48:06 <tzviya> q+
17:48:22 <simon_collinson> …putting it in the manifest is eminently usable for us
17:48:24 <wendyreid> ack garth
17:48:51 <simon_collinson> Garth: It's a serialization issue: is it that much easier to encode in JSON than HTML? I don't understand why that's hard
17:49:12 <ivan> q+
17:49:14 <simon_collinson> Geoff: It's not hard, but for me it's redundant in a lot of our use cases. I can't think of a use case where creating an HTML file is of any use
17:49:15 <duga> q+
17:49:17 <laurent_> q+
17:49:54 <simon_collinson> …but a structured manifest, when we're processing third party books, extracting structured metadata is easy. In the B2B world, if the specification requires HTML, some people will just ignore it…
17:50:23 <simon_collinson> …turning HTML as something freeform, into something structured, is harder. Whereas a manifest is structured
17:50:35 <simon_collinson> Garth: It sounds like you don't want a TOC - you just want the manifest
17:51:03 <simon_collinson> Geoff: From an audiobook perspective, what publishers produce and what we exchange is just a bunch of files. They have filenames that are supposed to aid in sorting, but it's super loose…
17:51:16 <simon_collinson> …we sometimes add what we call a chapter list, but not every book conforms to that…
17:51:24 <simon_collinson> …sometimes it's literally just track 1, track 2, track 3…
17:51:37 <simon_collinson> …publishers don't necessarily cut at chapter/part boundaries, it could be random or every X minutes…
17:51:37 <ivan> q-
17:51:43 <garth> q+
17:51:54 <simon_collinson> …the list of files doesn't correlate 1:1 to a neat book structure…
17:52:08 <simon_collinson> …every publisher has their own approach to displaying a chapter which might be broken into two or more parts…
17:52:09 <wendyreid> q+
17:52:12 <wendyreid> ack tzviya
17:52:45 <simon_collinson> Tzviya: I'm growing confused about what Geoff is describing. I can think of numerous scenarios for audiobooks where the TOC isn't necessarily designed…
17:53:04 <geoffjukes> https://github.com/blackstoneaudio/audiobook-spec/blob/cfd468bb27b890b0e4a59a3345e806221a702fce/draft.yaml#L138
17:53:12 <simon_collinson> …a lot of reading systems strip out CSS, but publishers and users want more information than just the filename. eg if chapter 3 is read by a special narrator, that should be visible…
17:53:31 <simon_collinson> …we want to align with the work in synchronised media that ? is working on…
17:53:42 <mateus_> +1 to tzviya
17:53:51 <simon_collinson> …if it's just going to be a list in HTML, with CSS from the publisher, you can discard the CSS
17:53:58 <wendyreid> ack duga
17:54:20 <simon_collinson> Brady: One of the uses for HTML: you could have ruby for eg Japanese chapter titles. This would be hard in JSON…
17:54:21 <tzviya> s/?/Marisa
17:54:32 <simon_collinson> …you can recreate the properties of HTML in JSON if you want to, but it's hard…
17:54:54 <simon_collinson> … what we want to do with the TOC is something that doesn't exist in audiobooks: create a rich table of contents around the audio that has nothing to do with the structure of the audio files…
17:55:08 <George> q+
17:55:18 <simon_collinson> …I don't care how the files are actually structured, I want to say 'here are the chapter breaks throughout the audiobook' - can reference one or many files…
17:55:35 <wendyreid> ack laurent_
17:55:40 <simon_collinson> …I want something analogous to an ebook TOC. It's not something that exists today in the audiobook market
17:55:48 <wendyreid> zakim, close the queue
17:55:48 <Zakim> ok, wendyreid, the speaker queue is closed
17:55:51 <wendyreid> ack garth
17:56:42 <wendyreid> ack wendyreid
17:56:42 <simon_collinson> Garth: What Geoff is saying is that your classic audiobook doesn't have this TOC in it - if you want to create a new audiobook with no or a barebones TOC, so be it - but doing a good job of Brady's enriched TOC clearly doesn't have to be part of the spec, but we want a way to do it
17:57:18 <ivan> q+
17:57:30 <simon_collinson> Wendy: We're talking about this in the context of the core spec. Maybe a better way to consider this is how each module can deal with TOCs. This problem could look very different in eg manga, academic publications
17:57:31 <wendyreid> ack George
17:58:10 <simon_collinson> George: I understand with the audiobook that you might get a flat list of filenames - I've seen different reading systems throw away the styling and add a machine-readable version of the TOC…
17:58:36 <simon_collinson> …I totally get lost, I don't know what the subsections are when it's just a flat list. The accessibility features of HTML provide me with useful information…
17:58:57 <simon_collinson> …I can understand that this is a subsection rather than a higher level chapter heading. Not in CSS, just natively in HTML
17:59:17 <geoffjukes> +1 if optional
17:59:25 <simon_collinson> Ivan: Maybe it's not clear: the TOC is optional - this is already the case
18:00:06 <simon_collinson> …the modular approach could be ok (?), provided we make it clear that an audiobook reader must understand the HTML version
18:00:21 <simon_collinson> …every reading system must understand how the TOC is supplied
18:00:42 <evan> evan has joined #pwg
18:00:44 <simon_collinson> Wendy: We will continue this discussion next time. No meeting next week
18:00:57 <dkaplan31> dkaplan31 has left #pwg
18:01:18 <ivan> rrsagent, draft minutes
18:01:18 <RRSAgent> I have made the request to generate https://www.w3.org/2019/02/11-pwg-minutes.html ivan