16:42:30 RRSAgent has joined #pwg 16:42:30 logging to https://www.w3.org/2019/02/04-pwg-irc 16:42:31 rrsagent, set log public 16:42:31 Meeting: Publishing Working Group Telco 16:42:31 Chair: Wendy 16:42:31 Date: 2019-02-04 16:42:31 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jan/0021.html 16:42:31 ivan has changed the topic to: Meeting Agenda 2019-02-04: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jan/0021.html 16:42:32 Regrets+ Garth, Caroline_Hayes 16:56:42 laudrain has joined #pwg 16:57:03 present+ 16:57:08 present+ 16:57:13 present+ 16:57:14 present+ 16:57:20 User2 has joined #pwg 16:58:24 present+ 16:58:24 present+ 16:58:31 Vlad has joined #pwg 16:59:05 NickRuffilo has joined #pwg 16:59:30 rkwright has joined #pwg 16:59:34 geoffjukes has joined #pwg 17:00:21 romain has joined #pwg 17:00:26 present+ 17:00:35 present+ 17:00:44 present+ 17:00:48 present+ 17:00:58 present+ 17:01:13 zakim, who is here? 17:01:13 Present: tzviya, laudrain, dkaplan, Rachel, ivan, wendyreid, dauwhe, Vlad, romain, rkwright, NickRuffilo 17:01:16 On IRC I see romain, geoffjukes, rkwright, NickRuffilo, Vlad, User2, laudrain, RRSAgent, Zakim, dkaplan3, Rachel, Karen, tzviya, dauwhe, plinss, ivan, github-bot, hober2, 17:01:16 ... bigbluehat, wendyreid, astearns, jyasskin, Travis, dmitry, florian[m] 17:01:24 simon_collinson has joined #pwg 17:01:32 +present 17:01:35 scribenick: NickRuffilo 17:01:36 Teenya has joined #pwg 17:01:39 present+ 17:01:44 laurent_ has joined #pwg 17:01:49 Avneesh has joined #pwg 17:01:53 present+ 17:01:54 present+ mateus 17:01:56 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-01-28-pwg 17:02:00 present+ 17:02:09 Wendy: Last week's minutes - any comments or questions/suggestions? Otherwise, approved 17:02:13 josh has joined #pwg 17:02:17 JunGamo has joined #pwg 17:02:20 present+ 17:02:23 gpellegrino has joined #pwg 17:02:25 present+ 17:02:27 present+ 17:02:33 present+ 17:02:38 franco has joined #pwg 17:02:44 resolved: last week's minutes approved 17:02:46 present+ 17:02:57 ... Next topics - list of issues that were sent around Thursday. I've reviewed issues in the project because we have 68 open issues - and that's quite a bit. Many have not been touched in a while or there was a consesus that never made it to call... 17:03:11 q+ 17:03:15 ... so I want to close a bunch of those if we can - so if there are any strong feelings or pet issues, now is the time to speak up. 17:03:25 ack ivan 17:03:29 ... If you don't want to speak up, you can re-open with more details on something. 17:03:38 George has joined #pwg 17:03:45 BenSchroeter has joined #pwg 17:03:45 jasminemulliken has joined #pwg 17:03:50 present+ 17:03:50 Ivan: Avneesh comments on one issue about a full accessibility reading order, he isn't on the call but I wanted to point that out. 17:03:50 present+ George 17:03:57 present+ 17:03:58 zakim, who is here? 17:03:58 Present: tzviya, laudrain, dkaplan, Rachel, ivan, wendyreid, dauwhe, Vlad, romain, rkwright, NickRuffilo, present, simon_collinson, laurent_, mateus, Teenya, Avneesh, JunGamo, 17:04:01 ... josh, gpellegrino, franco, BenSchroeter, George, jasminemulliken 17:04:01 On IRC I see jasminemulliken, BenSchroeter, George, franco, gpellegrino, JunGamo, josh, Avneesh, laurent_, Teenya, simon_collinson, romain, geoffjukes, rkwright, NickRuffilo, Vlad, 17:04:01 ... User2, laudrain, RRSAgent, Zakim, dkaplan3, Rachel, Karen, tzviya, dauwhe, plinss, ivan, github-bot, hober2, bigbluehat, wendyreid, astearns, jyasskin, Travis, dmitry, 17:04:02 ... florian[m] 17:04:09 Wendy: OK _ I'll leave that one open. Any other opposition? 17:04:30 Thanks for highlighting, Ivan 17:04:31 ... expect to see a much smaller github issues list. 17:04:39 CharlesL has joined #pwg 17:04:49 Topic: affordances document 17:04:57 ... Next agenda item: Josh and Franco have been doing work on the affordances - especially now that we've changed the format of the main document. Franco/Josh? 17:05:03 present+ 17:05:39 Franco: I can speak to this. We'd like to go through the current UCR requirements and document what the user agent behaivour should be. We'd like to be more explicit about the UA behavior. We'd like a rep for the different user agents to help us to determine how the UAs should behave. 17:05:44 q+ 17:05:47 ... that is what we spoke about and would like to bring to all of you 17:05:49 ack tzviya 17:06:24 Tzviya: In case you missed that - that was a call to action to the user agents here. We talked about having an implementers meeting, for those who think we shouldn't specific user agent here, we're trying to set expectations about what is needed. 17:07:04 ... this is based off feedback from browsers where they wanted to know what it is they needed. This doesn't have to be a huge commitment - maybe just one meeting, but we would love to hear from kobo, blackstone, microsoft books, etc. Readium... 17:07:10 q+ 17:07:20 q? 17:07:27 rebus 17:07:27 mattg has joined #pwg 17:07:37 ack dauwhe 17:07:40 ... but if you could be there... We can set up a time that works for everyone. 17:07:55 s/kobo,/kobo, google,/ 17:07:56 David_Stroup has joined #pwg 17:08:04 Dave: speaking of everyone, but something of extreme interest to everyone in the group - I guess I'm uncomfortable of a 'implementer only' call. 17:08:07 +1 Dave 17:08:16 marisa has joined #pwg 17:08:16 Wendy: We could just make it the agenda for a meeting in a couple weeks. 17:08:17 q+ 17:08:23 present+ 17:08:26 present+ 17:08:34 Tzviya: that works for me - as long as the implementers are welcome to speak up in a regular call 17:08:37 ack NickRuffilo 17:08:44 I will participate in a larger call. 17:09:08 NickRuffilo: I like the idea of using a regular meeting for this. Make sure that time slot works for the implementors as well. I know it is difficult to get everyone together. 17:09:10 q+ 17:09:15 ack George 17:09:46 George: Would it - Microsoft was... I don't know if Apple has or other implementors - should we reach out to them and let them know that this is happening? 17:10:23 Wendy: Why don't we set up a meeting for a few weeks from now. And then sound out any invitations to other implementors who might want to be there. Is that agreeable? 17:10:25 +1 17:10:31 +1 17:10:32 Is this something a publisher without a specific platform (other than web in general) should or would be part of? 17:10:34 q+ 17:10:34 +1 17:10:34 +1 17:10:36 +1 17:10:47 +1 17:10:49 (Sorry can't use mic.) 17:10:51 Jasmine: Is this something a publisher without a specific platform (other than web in general) should or would be part of? 17:11:04 Wendy: Non implementors could raise questions or comments. 17:11:05 ack tzviya 17:11:13 duga has joined #pwg 17:11:20 present+ 17:11:37 Tzviya: The goal here is still writing the use cases document. We're not talking about real-world implementations, we're worried about getting this documented so that implementors know what to do. If Apple doesn't show up, it doesn' tmean they won't implement... 17:11:40 Would we want the browser developers to be there? 17:12:22 ... they just aren't putting their input in. We need to get the use cases written, so I don't want to push this out too long. We're talking about calling it User Agent Behavior to clarify what it is we are talking about. We need to get to real-world implementations, but we need to tell implementors what we want first 17:12:30 q+ 17:12:35 ack laurent_ 17:12:37 ... but if we invite people who might not have been following along, there might not be much to say. 17:12:49 Laurent: Which UCR will be working on? The new drafts? 17:12:58 old one https://www.w3.org/TR/pwp-ucr/ 17:13:11 Bill_Kasdorf has joined #pwg 17:13:13 ... We have the old pwp-ucr, but is that totally obsolete so far? 17:13:22 present+ Bill_Kasdorf 17:13:23 Josh: I hope not, because we've been working on it. 17:13:25 sorry to be late 17:13:30 Laurent: are we discussing from the pull request? 17:13:34 this one is the latest and greatest (afaik) https://w3c.github.io/dpub-pwp-ucr/ 17:13:38 Wendy: we are just modifying the original 17:13:52 the TR stays the same. Editor's Draft has the updates 17:14:04 regrets+ yanni 17:14:09 Josh: OK - the new one is different, so the DPUB-PWP-UCR is the right one, not the old one. 17:14:34 q+ 17:14:35 Wendy: OK we will make this an agenda item, and we can invite implementors, but if they don't show up it is not the end of the world. 17:14:47 ack dauwhe 17:14:49 Dave: Are we at a place where we should republish the UCR? 17:14:51 q+ 17:14:55 ack ivan 17:15:41 Ivan: So far, what we said, is that we will republish the document on the same PR - so taking over from the DPUB Interest group. It's a note, so we can do it without further ado. but that's what we discussed in the past. 17:15:45 Dave: Can we publish now? 17:15:48 Ivan: doesn't depend on me 17:15:55 mateus has joined #pwg 17:16:01 present+ 17:16:04 q+ 17:16:06 Wendy: Can we resolve to publish the current draft of the UCR document in advanced of discussing it? 17:16:18 ack josh 17:16:25 Ivan: it depends on the editors, but I ask for a 1 week delay because i'll be away starting tomorrow. 17:16:59 Josh: I would vote to publish what we have because what we currently have out there is very old. As the editor, I was confused about how old the TR - my vote - I want to know what Franco and Tzviya have to say... 17:17:29 Iva: As I said Josh, it cannot be done automatically, it requires my intervention, and I cannot do it this week, but next week i'm happy. 17:17:39 Josh: I can wait a week. It's two, what's one more week? 17:17:56 Resolution: We will publish the latest draft of the UCR document to replace the out-of-date draft 17:17:59 timCole has joined #pwg 17:18:00 Wendy: As a resolution we'll publish the draft of the UCR document next week. 17:18:24 Josh: I just wanted to ask 1 question about the title. The title is PWP UCR - the whole PWP is deprecated - shoudl we retitle the document? 17:18:25 Ivan: Yes 17:18:37 Josh: So it's the WP UCR? Or the DPUB UCR? 17:18:40 Wendy: WP 17:18:53 ... Everyone in agreement? 17:18:56 +1 to publish 17:19:02 +1 to publish 17:19:03 +1 17:19:04 +1 to publish 17:19:05 +1 - publish 17:19:05 +12 17:19:06 +1 17:19:09 +1 to publish 17:19:12 +1 17:19:12 +1 17:19:15 +1 17:19:18 +1 17:19:20 +1 17:19:21 +1 17:19:42 RESOLVED: We will publish the latest draft of the WP UCR document next week 17:19:49 present+ 17:20:02 https://github.com/w3c/pwpub/issues/33 17:20:22 Wendy: Next item - the primary entry page. If anyone is not prepped up on this, it's because the github is in the Packaged web publication github - so I don't blame you for missing this one. 17:20:58 ... picking up on the github comment, we might have come to a mild consensus. Ivan had a great comment: The question is about the primary entry page - and whether it should exist or not. 17:21:40 https://www.irccloud.com/pastebin/2sKIT0kg/ 17:22:04 Wendy: Ivan do you want to elaborate? 17:22:10 Ivan: Are there any questions? 17:22:16 q+ 17:22:21 q+ 17:22:23 ack bigbluehat 17:22:29 q+ 17:22:55 q+ 17:22:58 q+ 17:23:12 q- later 17:23:21 Benjamin: If we disallow the index.html or make it optional - we're going to make some sorta-works-on-the-web and sorta-not - so I'm finding it confusing. The more we diverge from 'unzip this and put it on the web' VS the naming conventions of a zip file... 17:24:04 ... so some of this is related to our vision of packaging - if this is a web package, or a package for moving around pieces of the web, that are themselves webby and have a 1:1 mapping to something on the web. Or if something has webby pieces but isn't meant for the web, like epub... 17:24:19 ... so defining which one we are after defines if the landing page is browser ready is required or not. 17:24:24 ack dkaplan 17:25:33 Deborah: To speak to the same concerns as Benjamin - there are - if we say that index.html is optional - then we are ... by doing so - we are saying that either it won't natively work - or be openable in a browser - or we have strong expectations that the native browsers will become WP aware... 17:25:47 q+ 17:26:09 ack George 17:26:10 ... because this is a standard... OR - that we are saying - they are webby as long as you have a polyfill or some sort of extension in your browser. Those are the things we are saying if index.html are optional, but only if we're trying to say one of those things. 17:26:45 George: I think I have the same question as Deborah - but stated my own way - if there is no index.html, and the JSON-LD is referenced, the expectation is that the index.html will be generated from the information in the manifest. Is that correct? 17:26:53 Laurent: Yes 17:27:13 George: would that be a script/polyfill that would ship with the manifest? Or would we expect the browser to fill that. 17:27:13 q+ 17:27:18 Wendy: It could be either-or 17:27:20 ack laurent_ 17:27:52 Laurent: As you said, it could be either or. We're speaking first about the package. So the package would not be consumed by the browser. It would need to be translated first. The conversion will involve the generation of a landing page. 17:28:24 ... it can be done statically or dynamically. By having the entry page option, we care keep it mandatory and generate automatically. 17:28:49 George: If the script is transferred in the package, that would auto-generate the index. Would a browser who is aware - would they know not to do that and run their own? 17:29:00 this is sounding messy 17:29:04 q+ you can't polyfill without HTML 17:29:11 Bill_Kasdorf agreed 17:29:12 q+ to point out you can't polyfill without HTML 17:29:47 +q 17:30:02 Laurent: it's open - and it's outside the packaging mechanism itself. If we set the scope is 'what do we put in the package' then it's out of scope - if it's 'what will the user agent do' then it is a WP aware agent? Then it could even process something that has no index.html. I don't think it's the best, but it could. If not WP aware, it must have an embedded reader, and this reader could be inside... 17:30:18 ... the package - but it depends what we do when we explode the package. It comes down to what we do within the package. 17:30:21 q+ 17:30:22 ack ivan 17:31:00 Ivan: Lets look at it from the history - It's easy to get lost in the details. As an aside, we are not talking of making the primary entry page optional - so something that is on the web MUST have a primary entry page. Lets put that issue aside. 17:31:06 thank you for clarifying that Ivan; that was unclear to me! 17:31:51 ... The issue is - if you look back - the whole discussion that has been going on - is if you have a publisher who publishes an audiobook, and the only thing they want to do is publish it as a package thing and carry it from one place to another, and they don't care about the web - for those, having the primary entry page is completely unnecessary burden... 17:31:53 q- 17:31:57 +1 Ivan 17:32:08 q+ 17:32:33 ... we can say we don't care about that use case, and we care when everything is on the web, but I don't think we should. We should have a situation where we say: "if a publisher cares about publishing their content on the web, they should zip it up and it can be a perfectly valid audiobook... 17:33:25 Based on Ivan's explanation, I am a happy guy. 17:33:38 ... and the UA should be able to render it. But if you have a publisher who doesn't care about the web, then they should be able to create a WP without the index.html. If you take a package without it, then the primary entry page can be done pretty easily. And that whole thing is orthagonal if the browser works with a polyfill or not. 17:33:59 q+ 17:34:03 so we are saying you can distribute a publication on the web that is not a web publication. I buy that; e.g. a PDF can be distributed on the web. 17:34:07 gret explanation Ivan 17:34:07 ... that is not what we're talking about. We want to give an option to publishers who do not want to publish to the web. That's the sort of consensus solution we came up with - no more no less 17:34:09 ack tzviya 17:34:16 q+ 17:35:01 Tzviya: Thank you for clarifying Ivan. I think that when we put this in the spec, we need to make it much more explicit what the UA does when it encounters these things. What happens if you encounter both. I expect this is where the concern is coming from - right now our primary instance is audiobooks... 17:35:33 ... in the world we're living in, it's just something that lives in the package. We don't have the use case of the audiobook written on the web or living on the web. I think that we're hearing - I'm concerned that if we have other types of publications - this duality is going to create problems. 17:35:56 +1 17:36:00 q+ 17:36:07 ack dauwhe 17:36:07 ... so if I want scholarly packaged material, having these options will create problems down the line. So the concern is about tunnel vision when it comes to audiobooks - so we're doing things in a way that is too closely tied to audiobooks. 17:36:15 +1 to Tzviya 17:36:42 zheng_xu has joined #pwg 17:37:03 if we do this we just need to be very clear that that audiobook is not a Web Publication 17:37:12 Dave: I think that variety can help us. We have an industry need for packaged audiobook format that seems largely to industry publications. There seems no need for an index.html. I fear that trying to use the full machinery for web publications on this use case will prevent adoption or scare publishers away. We don't have to use every piece everywhere. We'll have... 17:37:16 present+ zheng_xu 17:37:45 q+ 17:37:57 ... more flexibility if everything has to use everything - such as having an HTML page where we don't need it out of theoretical purity. We try to solve our audio use-case as best as we can. It's best if we can find simple pieces that work in large spots of our use cases, but we won't find one solution for everything... 17:37:59 +1 to dave 17:38:05 ... i don't want cross polination making things worse. 17:38:06 ack bigbluehat 17:38:06 bigbluehat, you wanted to point out you can't polyfill without HTML 17:38:45 Benjamin: A bit off what Dave said - and Laurent's point of polyfills, if it's for audiobooks not on the web, eschew the index.html - but since it's for audiobooks, and possibly on the web, we'll need the HTML page to polyfill... 17:39:19 ... to assume something somewhere will generate an HTML file - it won't compute. The only way to polyfill is via a javascript, and you do that through an HTML file, otherwise it'll just show you the JS code - so html is the conduit... 17:39:55 ... including things that read JSON. Sure - browsers display HTML files for images, but images have been here forever. So to think that browsers will display HTML files for the custom JSON we're creating... that's a bit far... 17:40:23 ... so when it comes to audiobooks, if we just want something that reads audiofiles, in a package, then lets create something new with a different name, that handles those things properly... But if we want to focus 17:40:31 ack NickRuffilo 17:40:40 ... on browsers and make things work on the web, then lets focus on that use case. 17:41:09 NickRuffilo: I like bigbluehat's comment, we're focusing on web publications, we not only have to think of the now and the past, but also the future 17:41:40 ... nothing is stopping a publisher from using things against spec, if someone is only using it to package audio, and may not have a index.html 17:42:04 q? 17:42:18 ... anyone who is new, and wants to develop an app that reads audiobooks in the browsers, they would have an index.html to reference to and it allows for availability 17:42:58 ... maybe it is too much for implementors, outputting an HTML file does not seem like a stretch for software, it is not rocket science, I think as much as we can keep the web in mind, there is value in that 17:43:04 ack dkaplan 17:43:40 Deborah - I will not -1 on Ivan's language - it's not a hill I'm going to die on. I think it's a bad idea to reopen the issues at writ large. We have resolved some things and I don't think they are broken... 17:43:54 +1 to dkaplan3 17:44:03 +1000 to dkaplan3 17:44:17 ... what I do think is true - in my experience - working with usually small publishers. One thing that is most confusing is anything that is optional. In practice, reading systems will not deal the same way with things that are optional... 17:44:21 +1 dkaplan3, bigbluehat, NickRuffilo 17:44:53 +1 tzviya 17:45:02 +1 there is no SHOULD or MAY there is only MUST 17:45:03 ... perhaps if we say something like: "this is optional ONLY if there are no HTML pages in the document..." because anytime anything is optional, publishers will get it wrong and reading systems will not get it consistently - take for example covers in epub... 17:45:09 ack mattg 17:45:43 Matt: Alot of what I was going to say has been said. The problem that we're trying to solve is the distribution of audiobooks. The web is a nice to have. We're trying to enforce that everything must be a web publication. We should be looking at harmony of the two. 17:46:19 ... if the primary is distributing audiobooks, great, but if the publisher wants to publish to the web, then we should make an easy path for that - but I would rather find a harmony in terms of allowing the author decide what it is they want to do. 17:46:40 +10000 to matt 17:46:46 ack Avneesh 17:46:47 +1 to Matt 17:46:48 ... let it work for audio publishing, but not disallow the index, but don't push everything into one box because then there is too much compromise for requiring the index.html 17:47:21 Avneesh: the entry page has another important function - it gives access to the non-WP aware browser. It was not the original plan, but it became the gateway for a non-WP aware agent to actually display the content to the user 17:47:51 ... if we say it's optional, in a way, it looks OK, but it means we're saying that the entry page can be neglected forever. So the question is - how much effort are we asking them to make... 17:48:20 +1 to Avneesh 17:48:24 ... it can be easily automated by a production tool. Slowly we can encourage them to make a TOC and have it more valuable to a non-WP aware browser, but it's hard to get people to come back to that later. 17:48:26 +1 17:48:51 ... I would like to discuss again - and all of these problems are focused that we're focused on audiobooks. We don't want things skewed because of this. 17:48:53 ack ivan 17:48:55 +1 that it can be easily automated in production 17:48:59 +1 Avneesh 17:49:36 Ivan: A number of things - We are influenced by the Audiobook profile, but I don't think that it's true to say that we're working exclusively with the audiobook profile. For example manga may want to be distributed only via packages, which hit only the same problems as audiobooks. 17:50:24 ... Nick said some things I don't agree with - the text that I propose made it very clear - and it must be part of the document - a user agent MUST understand a primary entry page and handle it accordingly. A compliant user agent can understand a WP. The choice is up to the publisher and the publisher only... 17:51:00 q+ 17:51:11 ... it's up to the publisher if they want to address a specific area or not. A scholarly publisher will have a primary page and it will handle it. But the publisher does not want to go that way because the only constituancy only have special vendors, then they won't have to do it... This is the only goal... 17:51:36 ... you might say that adding that extra primary entry page is no big deal - but on the other hand, if there seems to be no consensus in having that, why forcing it? 17:51:41 ack geoffjukes 17:52:18 Geoff: Speaking as an audiobook publishers, aggrigator, and distributor. From our perspective - the index would be an indicator if the publisher has desires on how the audiobook is presented. 17:52:57 ... I could well imagine a publisher wanting to theme all their books with the same font. Certainly, home publishers will never have the warewithall for making index.html for all their books - they will rely on aggregators to "package" their books in the way they see fit. 17:53:30 ... From my perspective - i came from the data driven point of view - the manifest is the most important part of the publication. From a data perspective, how to deal with it. What you call reading order... 17:54:12 ... any additional items like bonus materials - it's described in the manifest. The index.html would be this desire for themeing of how to present. As a distributor, we have our web sales. We read in a JSON file now - then render the content themed for our site... 17:54:49 q+ 17:54:52 ... we use HTML5 to pull in the audio as needed - it's a thin client. In summary - the manifest is the thing that describes everything. The index, which seems optional to me, would be a way for publishers to define their theme 17:54:54 ack Bill_Kasdorf 17:55:27 Bill: I hope a simple question - What we're calling the audiobook format - the simple format without the index.html, is there anything about it that would prevent us from distributing any proprietary not webby content. 17:55:39 Wendy: If you're referring to the packaging format - that's not audio specific 17:56:06 Bill: so it could be any non-web content. This is why I'm wondering how it can be part of our web-publication work. Unless we specifically say 'we're addressing non-web publications in our work' 17:56:09 +1 17:56:13 q+ 17:56:55 Bill: Two common formats that I want to get on the table. PDF - a perfectly fine way to distribute PDFs. Something more ammenable to this group - is it a way to distribute a 3.N that is not a web-publication. It's still an XML, etc. You see where I'm going 17:57:07 ack ivan 17:57:15 zakim, close the queue 17:57:15 ok, wendyreid, the speaker queue is closed 17:57:22 q- 17:57:30 ok that's what I wanted to say also 17:57:35 Ivan: Reacting to what bill said - if I take a web publication today - if there's a resource that's accessible to the web - like PDF, that's already a web publication, it doesn't matter what resources you refer to. 17:58:27 ... so we can have a web publication today that refers to a PDF or an epub. I don't think that's such an issue in this case. Let me go back to a question to Geoff. If I take the position that we MUST have an index.html, the minimal index.html is, as I said, 5 lines with no body and a link to the manifest file... 17:58:59 ... We could, and that was part of the discuss, require the minimal index.html be part of the package and then close it - the feedback I always got was that the audiobook publishers will not want to do that, they'll run away screaming... 17:59:37 Geoff: I cannot speak for the publishers, but for blackstone, the idea of injecting an index.html is trivial. We have audio delivery systems that injest 10s of thousands of books, and we repackage them for our distribution partners. 18:00:06 ... if the index.html becomes required - because it doesn't describe the book directly, it will be difficult. What we end up doing is that we end up generating the file itself... 18:00:32 Ivan: The manifest, as we define it, there's just an index.html that refers to the manifest and allows the browser to read and find that page. 18:01:05 Geoff: I agree with that and from my perspective, I would turn it on it's head - if there's an index... For me, I would treat the manifest as - if there was an index or multiple index, they would be linked within the manfiest... 18:01:31 ... so the manfiest would be mandatory, not the index.html and all browsers and such look for the manifest, and then figure out the landing page from there. Are you following? 18:01:47 Wendy: We are out of time, we'll continue - if there are additional comments, comment on the issue. 18:02:01 rrsagent, draft minutes 18:02:01 I have made the request to generate https://www.w3.org/2019/02/04-pwg-minutes.html ivan 18:02:01 zakim, bye 18:02:01 rrsagent, bye 18:02:01 I see no action items 18:02:01 leaving. As of this point the attendees have been tzviya, laudrain, dkaplan, Rachel, ivan, wendyreid, dauwhe, Vlad, romain, rkwright, NickRuffilo, present, simon_collinson, 18:02:01 Zakim has left #pwg 18:02:01 JunGamo has left #pwg 18:02:05 ... laurent_, mateus, Teenya, Avneesh, JunGamo, josh, gpellegrino, franco, BenSchroeter, George, jasminemulliken, CharlesL, marisa, mattg, duga, Bill_Kasdorf, bigbluehat, zheng_xu