16:23:01 RRSAgent has joined #pwg 16:23:01 logging to https://www.w3.org/2019/01/07-pwg-irc 16:23:02 rrsagent, set log public 16:23:02 Meeting: Publishing Working Group Telco 16:23:02 Chair: Wendy 16:23:02 Date: 2019-01-07 16:23:02 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jan/0001.html 16:23:02 ivan has changed the topic to: Meeting Agenda 2019-01-07: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jan/0001.html 16:30:17 wolfgang has joined #pwg 16:53:16 romain has joined #pwg 16:54:38 Yanni has joined #pwg 16:56:11 present+ 16:56:24 present+ 16:56:29 NickRuffilo has joined #pwg 16:56:35 present+ 16:57:03 gpellegrino has joined #pwg 16:57:13 present+ 16:57:47 laurent_ has joined #pwg 16:57:51 present+ 16:58:53 dkaplan3 has joined #pwg 16:59:02 present+ 16:59:03 present+ 16:59:10 present+ wolfgang 16:59:11 jbuehler has joined #PWG 16:59:27 present+ 16:59:30 prsesent+ 16:59:47 present+ ivan 17:00:01 present+ 17:00:02 EvanOwens has joined #pwg 17:00:03 laudrain has joined #pwg 17:00:11 present+ 17:00:38 ScribeNick: NickRuffilo 17:00:42 present+ 17:00:44 scribenick: NickRuffilo 17:00:47 in case it's case sensitive 17:01:30 prsent+ 17:01:34 present+ 17:01:38 Teenya has joined #pwg 17:01:42 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-12-17-pwg.html 17:01:49 Wendy: Happy new year, welcome to 2019. Lets approve last year's minutes... Comments? 17:01:55 ...: Approved. 17:01:58 User2 has joined #pwg 17:02:01 resolved: last meeting's meeting approved 17:02:08 present+ Luc 17:02:09 present+ 17:02:28 Topic: Audio TF discussion 17:02:41 josh has joined #pwg 17:02:42 regrets+ Rachel_Comerford 17:03:18 George has joined #pwg 17:03:30 ...: The audio taskforce got together to have a follow up from the last meeting to get ducks in a row about packaging. To summarize what we discussed: The main focus is OCF-lite. Nothing decided, but OCF-Lite is the forerunner. 17:03:31 present+ George 17:03:49 Bill_Kasdorf has joined #pwg 17:04:03 present+ 17:04:11 zheng_xu has joined #pwg 17:04:11 ...: Whatever we did with OCF-lite, we would keep it separate from the EPUB one, we would use epub 3.2 as the basis, but we want it separate to reduce confusion. it'll be only for audio (could be for WP, more decisions to be made) but it's being used as a basis, but not related to epub in any way. 17:04:14 present+ 17:04:16 garth has joined #pwg 17:04:22 present+ 17:04:23 present+ Garth 17:04:26 marisa has joined #pwg 17:04:40 https://github.com/w3c/wpub/wiki/Packaging-for-WP-Audiobooks 17:04:57 ...: As Ivan mentioned, we have to be cautious as it's not in our charter to create a packaging spec, so we have to be cautious. As a group, we did expand the packaging for audiobooks wiki page a little bit. The one thing we did - we added requirements & success criteria. 17:05:33 BenSchroeter has joined #pwg 17:05:43 present+ 17:05:50 ...: The group could help provide a few more criteria for success and requirements we need to meet to see where the potential options line up with our needs. We need to define success and requirements. One thing that came up - do we proceed in audio only or make a WP-wide solution... 17:06:06 q? 17:06:12 ...: Our requirements for audio maybe incompatible with other WP packaging, but that needs to be discussed. Laurent...? 17:06:27 caitlingebhard has joined #pwg 17:06:55 franco has joined #pwg 17:07:02 OCF-lite draft -> https://cdn.staticaly.com/gh/w3c/pwpub/95b98d4f09bd3ce107f6fb52f6edc391a3240408/spec/ocf-lite.html 17:07:04 Laurent: The document I drafted is a simplification of OCF 3.2... I took the spec as-is and removed everything that was only tied to epub. I supressed meta-inf directory, all XML files from the meta-inf (container, etc). I also removed the mimetype file. 17:07:19 Franco present+ 17:07:36 present+ franco 17:07:46 geoff_jukes has joined #pwg 17:07:47 ...: The mimetype signature file comes from ODF and it could be ready by some systems but it's not, and most reading systems don't use it, and it's more difficult to put inside, so we removed it. I also removed font obsfucation. 17:08:22 duga has joined #pwg 17:08:28 present+ 17:08:32 present+ 17:08:32 mateus has joined #pwg 17:08:37 Avneesh has joined #pwg 17:08:42 present+ 17:08:47 q+ 17:08:48 ...: I did add a file entry.html and the JSON LD file. I located both at the root of the package. I just also did a small specification on the way relative URIs work from the manifest on the entry page. It's the equivelent of what's in the OCF spec. It's compatible with OCF. Tied to web publications and not epub files. 17:08:51 present+ 17:08:53 q+ 17:08:54 ack ivan 17:08:59 rkwright has joined #pwg 17:09:20 Ivan: I very small tech question - in OCF we had stuff that there was 1 file that shouldn't be compressed... (the Mimetype file) That's gone, correct? 17:09:23 CharlesL1 has joined #pwg 17:09:36 present+ 17:09:50 q+ 17:10:03 q+ 17:10:04 q+ 17:10:05 Laurent: Yes - that was the mimetype file, it's gone from this spec. The processor, which wants to open the zip can know more than it's a zip file, but in the real world, no one was using this, so we felt it wasn't necessary. 17:10:10 ack dauwhe 17:10:25 ” 17:10:30 present+ 17:10:34 timCole has joined #pwg 17:11:30 Dave: Quickly on the last point. I have found reading systems that won't open an epub if you change the capitalization of mimetype. OCF without mimetype and container then just becomes a zip file with strict filenames and only certain compression types. So it limits things you can use within zip. The current OCF-lite draft also forbids embedded manifests, since the manifest must be a separate JSON LD file. 17:11:43 derekjackson has joined #pwg 17:11:56 q? 17:11:57 ack tzviya 17:11:57 ...: Copying from OCF right now is complicated. I've been reviewing it in detail from the epub3 perspective - and I think there are lots of ambiguitities. 17:11:58 present+ 17:12:16 Tzviya: Building on what Dave just said - I'm wondering what the benefit of writing OCF-lite vs ZIP. 17:13:14 Laurent: Zip is an application note - not a standard. It has many options that no one wants to use or no one uses much. Like encryption, splitting, and there are strictly no constraints on filenaming, so what has been done in OCF and what has been replicated, is putting constraints on ZIP to make it easier for authors and reading systems to read/write. 17:13:18 q? 17:13:19 ack George 17:13:32 George: Is there any requirement on the order of files within the zip in the container? 17:13:33 q+ 17:13:33 ack duga 17:13:39 Laurent: Not any more. 17:14:18 Brady: I did want to beat a dead horse and point out that the mimetype magic number is used, today, in production code that a large portion of the world uses. We don't HAVE to include it, but we shouldn't decide not to use it because it isn't used. it is, just not by reading systems. 17:14:25 ack garth 17:15:27 q? 17:15:29 q+ 17:15:33 ack ivan 17:15:36 Garth: I was going to say something similar. I don't find the mimetype burdensome - I think what you've done Laurent is great - removing meta-inf, certainly for audiobooks, but I can see keeping the mimetype and changing content for audiobooks may make sense. The last comment is maybe targeted best at Ivan - there might be more testability from 3.2 So maybe not draft something that looks like a packaging spec, and just point to 3.2 and note the ch[CUT] 17:15:43 q+ 17:16:40 ack dauwhe 17:16:42 Ivan: For other reasons we looked at the charter again, and the charter does not forbid us to do a spec in this area, it's not the charter that forbids us, but the comments we got. It is still to be checked, I would leave this issue open for the time. What makes it clearer for the user and the reader to handle. 17:17:10 Dave: Doing something in markdown and explaining the concepts might get us better feedback from vairous communities 17:17:12 +1 dauwhe 17:17:28 Wendy: We have a new member today - Jeff... 17:17:32 s/vairous/various/ 17:17:42 s/Jeff/Geoff 17:18:29 Geoff: I work at blackstone audio. We do audiobooks and have for nearly 30 years. We've packaged/repackaged audio files for several years, and worked with many publishers since then. This kind of format is new to me and I'm not really sure how the w3c works, but I thought it would be good for me to join in. 17:18:58 q+ 17:19:11 Wendy: OCF-lite still remains to be one of the options we do have. We are still exploring other options as listed in the wiki. Another big one we're hoping for an explainer in is HEIF. We're hoping to get that in a few weeks as a counterpoint. 17:19:15 ack ivan 17:20:06 Ivan: With OCF-lite and the others, My view of this is that what Laurent did is not only for audiobooks. We've had these discussions that yes, we'll focus on audiobooks, but whatever we do would be, should be, maybe reusable for a manga format within a year or so... 17:20:13 q+ 17:20:35 ...: OCF-lite has this generality which is good while we are waiting for something better, but going down anything audio-specific puts us in a corner that I would not like. 17:20:37 ack laurent_ 17:20:45 +1 Ivan! 17:21:19 Laurent: I would add that going through the OCF-lite is also compatible with OCF, so a standard book would be compatible with epub3 and the WP serialization. If you have both epub 3 files AND the manifest in the same container... 17:21:34 q+ 17:21:44 ack tzviya 17:21:44 ...: and you have one set of XHTML files, then you've got something that is compliant with epub3, web publications, and possibly even epub2. So with one container you have all. 17:22:06 q? 17:22:12 q+ 17:22:16 q+ 17:22:20 Tzviya: My hesitation with OCF/OCF-lite, while it is compatible, what happens when we look at the stuff going forward. What happens on a website? How does this unpackage on a website. We are supposed to be working on web publications... 17:22:32 q+ 17:22:44 q+ 17:22:50 ...: the format we're hoping for is web packaging (which doesn't exist yet) but we have to have this as a consideration before we decide on OCF-lite. Even if it has a layer on top of it (javascript overlay...) 17:22:51 ack laurent_ 17:24:00 laurent: I put some comments in the document - they are not used for web publications on the web - it's used for packaging. Our charter notes that we have to deal with packaged web publications. it's not about packaging something on the web, it's about packaging something that will be on the web soon. So it's about logically moving a package that will be on the web. 17:24:21 ack garth 17:24:23 ...: Then you need middleware. We have streamers... Yes, you need software set aside that can dynamically create a document from the package. 17:25:02 Brady: I view this as interesting in the package world, but I view tangential functionality in epub. This effort could get some traction in the short run. Reading systems now can injest epubs - so loading an audiobook package this way is not a huge step... 17:25:13 s/Brady/Garth/ 17:25:27 ack ivan 17:25:30 ...: In the future if we get back to WP proper, maybe enough time will have passed that web packaging is real... 17:25:32 +1 to Garth 17:26:07 Ivan: I must say I share the problems of Tzviya. I understand them. The way I see is slightly different from Laurent - we are forced into a corner. From the web point of view, it would be much nicer if we had a web-packaging. 17:26:38 ...: We expect a bunch of security issues are taken care of, but that's not there. We need a solution right now for which OCF-lite cuts it perfectly. What will happen in 2 years from now, because I don't expect it earlier... 17:27:10 ... in 2 years, when web packaging becomes a rec, we can just say it's an alternative packaging format for audio or anything else. Maybe we don't have to, but the user community will move with their feet. They will have 2 possibilities... 17:27:33 q? 17:27:33 ...: we will see which one we will alter, but we cannot wait 2 years. I must admit that I go into this with big reservations as well. On the other hand, that's where we are. 17:27:38 q+ 17:27:39 ack dauwhe 17:28:29 Dave: OCF does not solve the problems we need to solve for web publications. EPUB is running into difficulties because we don't have a clear solution for origin. We also have lots of non-web use-cases and OCF-lite and some other packaging mechanism that doesn't involved browsers seems useful. 17:28:32 +1 to dauwhe 17:28:38 +1 too 17:29:08 ... Audiobooks which is just MP3 or comics that are just JPEGs, we may need different mechanisms for different use cases. I suspect a single mechanism won't solve all situations. What google is doing is overkill... 17:29:14 +1 to dauwhe 17:29:29 q+ 17:29:31 that is actually a very good point, dauwhe 17:29:40 ack laurent_ 17:29:40 +1 to dauwhe 17:29:41 q+ 17:29:46 ... good luck telling an audio book publisher/author that they have to create HTTP response/requests - that's not going to work for everyone. We have different use cases based on the types of content. 17:30:17 Laurent: Ivan, you said that web packaging we have to wait 2 years. More than that. Once the spec is there, it'll take time to get into browsers, then in authoring software, etc. With HTTP security, it could take up to 4 years... 17:30:26 Dave: It's already partially implemented in chrome. 17:30:26 ack tzviya 17:31:16 Tzviya: Wendy mentioned in her email, or at the beginning, that we might consider doing something different. The more I learn about audiobooks, I'm thinking it's smart. Especially with Geoff's feedback, I'm wondering if we need to consider something slightly different for audiobooks... 17:31:32 present+ geoff_jukes 17:31:37 ... or make the specification so stripped down that audiobooks and the details are really audiobook specific... 17:31:59 q? 17:32:03 q+ 17:32:18 +1 Tzviya 17:32:19 ack ivan 17:32:19 ... instead of arguing to what is best for web publications, we clean up the web publication, and make it primarily about the data in the web publication and the audiobooks. It's possible that is the focus... 17:32:29 +1 tzviya 17:32:37 q? 17:32:38 +1 to Tzviya. ODRL took the same strategy: very stripped down spec designed to be augmented for specific uses (e.g., news) 17:33:06 ack dauwhe 17:33:06 Ivan: Just reacting on the last thing - I would prefer not to go to this extreme. I would prefer one packaging format. The reason why I was on the queue is that the points Dave made are good and important. Dave you may want to talk to the editor of the explainer... 17:33:50 Dave: Tzviya said something about web publication spec may be focusing on the manifest... I might go a little further there we've all experienced some difficulties in the group over the last years reaching consensus on our vision and what needs to be done... 17:34:24 ... it feels like there is a core of stuff that is required by everything we're talking about. Every sort of publication from audiobooks to web pubs to digital sequential art depends on a bit of info - having an ordered list (reading order)... 17:34:28 and metadata 17:35:16 ... that reading order can be expressed in many different serializations - epub has the spine, we have a JSON serialization in readium. Blackstone's audio format has YAML data structure... Maybe we can have this model for structural metadata that can be serialized in different ways and packaged in different ways... 17:35:19 q+ 17:35:37 q- 17:35:41 ... which might get us out of the trap of User Interface issues. If we have some really simple data model, we can go experiment and build things - because we don't know what's coming after that... 17:35:44 ack ivan 17:35:50 q+ 17:35:57 ack NickRuffilo 17:36:01 scribenick: wendyreid 17:36:06 +1 to dauwhe, building on a conceptual model is key 17:36:25 NickRuffilo: I have recently decided simple is always better, having worked with EPUB on all sides, spec is there and people will do what they want 17:36:35 q+ 17:37:19 ... what is important is that the simple and basic stuff works, and things did and didn't work in more complicated areas, if we keep it simple, accessibility is handled and a bulk of things are handled, and handle the exceptions from there 17:37:34 ... decide on our own that exceptions are handled as needed by the industry 17:37:38 ack George 17:37:39 scribenick: NickRuffilo 17:37:43 q+ 17:37:51 q+ 17:38:11 q+ 17:38:32 George: On the accessibility side - i'm highly in favor of simplicity as well. The JSON file and the HTML file should not preclude the ability to provide a text transcript. As soon as we get into textbooks and such, it's necessary. As long as we don't preclude it. The same goes for comics/manga... 17:38:44 ack tzviya 17:38:44 ... as long as we can have descriptions of the images, that's good 17:39:15 BenSchroeter_ has joined #pwg 17:39:39 Tzviya: RABIT HOLE. I would like to help bring back to the agenda. We're still looking at packaging in general. It sounds like lots of people like OCF-LITE (Zip with restrictions?) but there's some hesitation for Web Publications, but people want to ideally use the same package for all WPs... 17:39:40 q? 17:39:55 ... and the big concern is that - it comes back to the question of if there will be middleware... 17:39:57 Karen has joined #pwg 17:40:05 q+ 17:40:26 q= 17:40:28 a= 17:40:31 Tzviya: Maybe we want to start making the success criteria for packaging. 17:40:32 q? 17:40:41 q- Avneesh 17:40:45 ack laurent_ 17:40:45 ack laurent_ 17:41:15 Laurent: About accessibility - we will be ready to address the accessibility by having multiple renditions. Yes it will be good for audiobooks and comics as well - to have a full transcript of the content. It's to be studied... 17:42:03 ... Tzviya you were saying there is an issue with having a packing format - having the same for all different types. the epub file format won't be replaced by this new container because epub works - it's only for new kinds of publications - audio and comics. Because epub doesn't work there - which is why we need something else... 17:42:04 q+ 17:42:10 +1 for new kind of publication 17:42:35 ack ivan 17:42:37 ... If we consider that, we create a new container format. We don't say it will or won't be used for other - we know it won't be used for that. Then there won't be any more friction. 17:43:17 Ivan: The reason why I would be a little bit hesitant about having an audiobook format - the answer to George's question - with web publication and the OCF-Lite, it's a clear yes. It's not problem to add text information to the package, because it's a resource just like an audio... 17:43:48 q? 17:43:51 ... OCF-Lite handles that the way Laurent has handled that. As soon as we begin to lose the generality, and say 'lets have an audio-specific format' it might bite us later with the same question George asked. 17:43:51 ack NickRuffilo 17:44:19 q+ 17:44:37 NickRuffilo: If OCF-lite is a simpler format, and would work with the content of an EPUB, and I am a future publisher creating my content, why would i not want to package my content in OCF and have it work anywhere. 17:45:36 ... What does EPUB have that is better? There might be cases where the full OCF is needed, but if we are going to get traction and implementors do OCF-lite, if it's good enough for 90% and accessible, does this become the default and OCF becomes edge cases 17:46:24 Garth: It raises an interesting point. We can't replace OCF with OCF-lite today, because EPUB is XML based, and we have to find the container - and all these things Laurent proposed removed. If there's an epub 3.5 effort, and we get nice traction with audiobooks, back in IDPF days 'browser friendly format'... 17:46:55 ack garth 17:47:02 ... if we do something like that - a half-step for epub, I can see OCF-lite - we have reasonable agreement that it's OK for Audio. We should go there, and learn, and if that comes back to an epub 3.5 - more power to us but not sure it's a bridge we can burn yet. 17:47:18 https://github.com/w3c/wpub/issues/390 17:47:44 Wendy: One thing I've done is that we're learning towards OCF-Lite, but I've created an issue that is packaging for web publications and success criteria. Lets check our boxes and define what we need for Audio, WP, comics, etc. 17:47:58 q? 17:48:09 q+ 17:48:10 q+ 17:48:15 ack ivan 17:48:16 ... Lets define success, lets define what requirements need to be met. Security, Accessibility, and understand fully the decision we're making. It could be OCF-Lite, but lets do the due diligence. 17:48:59 Ivan: Agreed. 1) Somebody should come up with an initial list. The worst thing is to have a blank page. 2) Let us give a time limit on this. I would say 2 weeks. In those 2 weeks, we get what we get and then in 2 weeks, we process it. 17:49:00 +1 to time limit ! 17:49:20 Wendy: I will add my initial list to the first comment. Then I will work from there. I will also add the time limit to the issue. 17:49:22 ack garth 17:50:10 Garth: I would like to constrain us on Audiobooks and possibly comics as well. We're not looking at a packaging for WP - we don't have a constituency for WP and PWP. If, longer term, web packaging might be something, lets not get off in the weeds if we look there.. 17:51:20 Wendy: Next week - the rabit hole will be discussed. (Reminder: 2 weeks is MLK day in US, no meeting) Reminder - the F2F in May is May 6-7 (Monday/Tuesday) which is graduation weekend for Universities - so book EARLY if you can... 17:52:21 Garth: I didn't get a list of locations/Hotels. The meeting is scheduled to be at Google in Cambridge. I poked around a little and didn't see anything super great. I know Ivan got something nice in the Boston side... 17:52:48 ... There are still good deals in hotels.com - mass transit works pretty well, there is a T-stop right at Kendall square where we're meeting... 17:53:21 dkaplan3 has left #pwg 17:53:26 romain has left #pwg 17:53:50 CharlesL1 has left #pwg 17:57:15 rrsagent, draft minutes 17:57:15 I have made the request to generate https://www.w3.org/2019/01/07-pwg-minutes.html ivan