16:24:23 RRSAgent has joined #pwg 16:24:23 logging to https://www.w3.org/2018/12/10-pwg-irc 16:24:24 rrsagent, set log public 16:24:24 Meeting: Publishing Working Group Telco 16:24:24 Chair: Tzviya 16:24:24 Date: 2018-12-10 16:24:24 Regrets+ 16:24:24 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Dec/0011.html 16:24:24 ivan has changed the topic to: Meeting Agenda 2018-12-10: https://lists.w3.org/Archives/Public/public-publ-wg/2018Dec/0011.html 16:24:38 Chair: Wendy 16:46:33 mgarrish has joined #pwg 16:53:42 wolfgang has joined #pwg 16:55:24 present+ 16:55:38 present+ 16:55:48 nickruffilo has joined #pwg 16:55:52 present+ wolfgang 16:56:57 present+ 16:58:02 present+ george 16:58:20 Yanni has joined #pwg 16:58:45 laudrain has joined #pwg 16:59:22 present+ 16:59:43 George has joined #pwg 16:59:56 present+ George 17:00:59 Teenya has joined #pwg 17:01:03 present+ 17:01:11 present+ 17:01:18 present+ 17:01:52 present+ 17:01:56 Avneesh has joined #pwg 17:02:18 present+ 17:02:23 ScribeNick: NickRuffilo 17:02:34 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-12-03-pwg.html 17:02:35 EvanOwens has joined #pwg 17:02:44 Wendy: First item - lets approve last week's minutes. 17:02:48 JunGamo has joined #pwg 17:02:51 resolved: last week's minutes approved 17:02:58 dkaplan3 has joined #pwg 17:03:03 ...: Last week's minutes approved. 17:03:10 present+ 17:03:11 Simon_Collinson has joined #pwg 17:03:19 topic: structure of wp spec & audiobooks 17:03:25 marisa has joined #pwg 17:03:25 ...: First topic - discussing the structure of web publication spec as well as audiobooks. Tzviya wrote the explainer so she will explain. 17:03:30 present+ 17:03:36 Bill_Kasdorf has joined #pwg 17:03:42 franco has joined #pwg 17:03:43 present+ 17:03:43 +present 17:03:51 present+ 17:03:52 JuanCorona has joined #pwg 17:03:52 present+ 17:03:54 jasminemulliken has joined #pwg 17:03:58 present+ 17:04:06 Tzviya: Over the weekend there was lots of work on the TOC. In the past few weeks we've simplified the web IDL and shifted focus on the minimum viable publication. We want to make a lean/simple version of the spec. 17:04:07 present+ 17:04:12 present+ 17:04:15 rkwright has joined #pwg 17:04:20 present+ 17:04:42 present+ 17:04:43 ...: We're making this a simplified spec and anything that needs to be built upon will be a module. The first of these is audiobooks. It will be based on web publications, but it will be an extension. 17:04:46 josh has joined #pwg 17:04:49 derekjackson has joined #pwg 17:04:55 q+ 17:04:59 present+ 17:05:01 ack ivan 17:05:11 jbuehler has joined #pwg 17:05:16 present+ 17:05:21 present+ 17:05:23 present+ 17:05:28 duga has joined #pwg 17:05:33 Ivan: My understanding is that there will be a separate document for audiobooks. Putting my administrators hat on, does this mean that we would have a separate repository with separate editors? I can set it up, but we would need editors. 17:05:35 present+ 17:05:46 laurent_ has joined #pwg 17:05:53 Wendy: I'm not sure it needs a separate repo. 17:06:26 Ivan: The repository is, in practice, better to have it separately so it makes it easier with the publication process. It's a practicality. More importantly, we would need editors with whom I could set up the whole thing. 17:06:29 q+ 17:06:31 q+ 17:06:36 ack dauwhe 17:06:38 present+ 17:06:52 q+ 17:07:14 Dave: I'm a bit concerned with separate repos - if issues come up in the audio work, we'll have to hunt through several repositories. There are ways of handling this with issues. 17:07:15 +1 to a single repo 17:07:18 +1 for a single repo 17:08:06 Ivan: What I have to check... I don't know how the CSS group works... but I have to check if the current auto-publishing process is something that can work by having multiple documents in a single repository. Having a repository is a separate place for the document. it doesn't mean we have to use the issue list of that repository. 17:08:07 q- 17:08:22 CharlesL has joined #pwg 17:08:22 ack tzviya 17:08:23 ...: We can use a single issue list, but having a physical 2nd repository, would make it easier longer term for publishing. 17:08:31 present+ 17:08:40 Tzviya: The issue of how many repositories aside, we do need editors. (This is where people volunteer) 17:08:50 Wendy: I can volunteer 17:08:54 q+ 17:09:04 mateus has joined #pwg 17:09:13 ack nickruffilo 17:09:17 present+ 17:09:38 JuanCorona_ has joined #pwg 17:09:54 CharlesL has left #pwg 17:09:55 nickruffilo: If it sounds like we'll be creating new documents for each extension, are we then creating new reops for every extension? Could this become a lot of repos? Not a bad thing if we have a good process, but the CSS example is compelling 17:10:01 CharlesL has joined #pwg 17:10:05 q+ 17:10:12 s/reops/repos/ 17:10:34 Karen has joined #pwg 17:10:41 Ivan: Fair statement. I can't comment on the CSS working group, as they have a different publishing process. I do know that there are groups that have multiple repositories. But yes, if we add more extensions, we would need more repos. 17:10:43 ack George 17:11:01 CSS uses Echidna 17:11:05 George: The overarching specification and the audiobook module - would that go to rec together and each subsequent module would go to rec? 17:11:14 Ivan: That is the idea 17:11:30 q+ 17:11:38 ack Avneesh 17:11:46 User2 has joined #pwg 17:11:59 q+ 17:12:10 ack ivan 17:12:12 Avneesh: Just thinking about the formal process. Just the charter has a note about extending the specification like this. I don't remember if there is a probation for extensions like this. I don't want issues when we come to rec stage. 17:13:22 Ivan: We have to talk to Ralph - and we may have to recharter. The reason why I haven't had this discussion is because there was no such decision. We have no working-group decision of doing it. There is the whole issue around the recommendation for 3.2 We know there is a recommendation that would lead to a rechartering. So if we do need a recharter for audiobooks, we should wait to see if we need it for 3.2 17:13:46 ...: waiting to do both at once would be easier if we need. We could possibly do this without a rechartering, but I'm not in a position to say yeah or nah. 17:14:08 q? 17:14:18 Wendy: Next topic - Audiobooks 17:14:20 Topic: Audiobooks 17:14:32 BenSchroeter has joined #pwg 17:14:37 present+ 17:14:50 ...: The Audiobooks taskforce met a couple weeks ago to discuss the next challenges as a group. One of the first is the discussion of packaging. It's important UC for us. One of the big issues is a lack of a good distribution model. 17:14:53 https://github.com/w3c/wpub/issues/352 17:15:07 Subtopic: packaging 17:16:07 ...: A very high-level summary: we would do something OCF light - a zipped archive, the manifest is present and has a well-known location. There is an optional entry page. Resources should be listed, and there would need to be a dedicated media-type. The proposal, because it's not the same as OCF for an epub... 17:16:16 http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip 17:16:41 q+ 17:16:42 q+ 17:16:46 ...: It is a published ISO spec - so there is prescedence for this - because it is a packaging spec, and we wanted input from the group. 17:16:50 q+ 17:16:54 ack tzviya 17:17:03 Tzviya: One thing I didn't catch - did you say no entry page would be required? 17:17:07 Wendy: It's optional 17:17:30 q+ 17:17:33 Tzviya: If we're building on the WP spec, even if it's not necessary for audiobooks, it's a must for the core spec - so maybe we need to have it anyway. So maybe it's just something that comes with WP 17:17:55 q+ 17:18:15 ack ivan 17:18:16 Wendy: That's possible. We discussed it because there was some idea that a packaged audiobook, in the distribution model, would not use the entry page. So why include a file that wouldn't be used. But arguable - it's there if needed, but if not read, no big deal. 17:19:03 Ivan: Two things - the administrative side - if there is an ISO standard, and we use that, that is fine. So there's not administrative issues there. Tzviya said what I wanted to say originally. I am a bit bothered by creating a prescendence where the module becomes different from our core. 17:19:55 ...: To drop a requirement we have bothers me. That means if I have an audiobook, and for some reason I want to unpack it and put it on my website, it's no longer a web publication. It also binds to the open issue about whether the TOC will be possible in JSON LD or not. If that issue is decided against... 17:20:25 ack rkwright 17:20:27 ...: then the HTML page could also be the TOC - so it has a specific use as well. Not just a placeholder. I'm more inclined to do that then let modules go their own way. 17:20:46 q+ 17:21:24 ack dauwhe 17:21:28 Rick: Going back to multiple repos and such - one of the feedback we get at readium is that it's way too complex for newbies. They don't know how to deal with 24 repos... In an epub 3.x along the way - those of us on the working group had difficulty. I'm concerned we'll create a labrynth of specs and it will be hard for people. 17:22:07 Dave: This is a working group of the WWW consortium. One of the fundamental principles is that web publications have a URL, and when you resolve that URL, you get an HTML. That's the foundation of webiness and what we do. So I agree with Tzviya and Ivan. 17:22:08 q+ 17:22:10 q+ 17:22:10 q- 17:22:15 ack Avneesh 17:22:16 s/labrynth/labyrinth/ 17:23:04 Avneesh: +1 to the previous comments. Packaging and unpackaging should not be affecting the document. The second piece is regarding OCF. There was originally strong objections to it because of DRM. Are we going to address this? 17:23:16 q+ 17:24:02 Wendy: The objections I recall - there was only one major issue and it was relating to the fact that this would disallow encryption - the way we have it. The problem I have with that is that DRM is outside of our purview. There was one disagreement about this particular issue around encryption. 17:24:31 Leonard's issue was void 17:24:38 https://github.com/w3c/wpub/issues/352#issuecomment-439700768 17:24:46 ...: Leonard noted that it doesn't address well-known file naming, disallows encryption, and dig-sig, which would prevent tamper detection. Instead the proposal was to make changes to OCF, or use adobe's UCF 17:24:49 q+ 17:25:06 ack laurent_ 17:25:43 Laurent: Just to say that in the ISO standard, the only encryption that is available is the ZIP encryption. There has nothing to do with global DRM, there is no issue outside of the W3C to use some encryption method to use with this. 17:26:02 Thanks Laurent 17:26:08 ...: There is nothing that precludes or makes any problem with using DRM with this ISO standard 17:26:09 q- 17:26:20 ...: it's only about the ZIP encryption.... 17:26:28 ack duga 17:26:54 Brady: My question goes back to something Ivan talked about referencing an ISO standard. it's fine to reference it, but we can't just do that. We'll have to make modifications because we can't take OCF as is... Can we do that? 17:27:06 q+ 17:27:13 Ivan: I didn't understand that is what you need. If you change the standard, then I'm not sure what that means. I have to check. 17:27:38 Brady: OCF has the signature, I suppose adding restrictions may work, but we can't say - change the signature. Otherwise people would think it's an epub... 17:27:46 Ivan: Changing the ISO standard, that's a big no-no. 17:28:06 Brady: That's my worry. Just because it's an ISO standard, doesn't mean we can reference it, unless we take it directly as OCF. 17:28:14 ack josh 17:29:13 Josh: I wanted to - I'm going back to the spec + module - I wanted to agree with what Rick said about being newbie friendly. I have further concerns that if we follow spec + module approach, we're going to invariably have certain modules that get more love than others. The audiobooks module may have wonderful packaging spec that just belongs in the main document... 17:29:52 ...: things could be useful to everything. With different editors, things that were written well for one, may not make it back to the main. So we'll end up with different modules with different degrees of completeness. 17:29:55 ack laurent_ 17:30:00 https://github.com/w3c/wpub/issues/352#issuecomment-439700768 17:30:44 Laurent: There is also a comment about ISO standards - it is true that if the ISO standard doesn't give us what we need - and we have to re-write it, it may be better to take the OCF document and simplify it... 17:30:52 Ivan: You want to republish the OCF document as...? 17:31:01 Laurent: As an OCF-lite. 17:31:10 q+ 17:31:16 Ivan: Republishing has lots of copyright and trade issues, so it is not that simple. 17:31:21 q+ 17:31:22 https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html 17:31:24 Laurent: It's not ISO, but IDPF 17:31:49 Ivan: That is more doable, but it would be extra work. That could be done. 17:31:53 ack tzviya 17:31:57 q+ 17:32:39 Tzviya: I realize there is urgency for audiobooks, but we do plan on publishing something packaged. Yes, there is urgency, but if we're talking about redoing OCF... if we re-write OCF, would we have different version for epubs and audiobooks? 17:32:49 q- 17:32:52 ...: But we'd have issues with a new OCF? 17:33:10 Laurent: There was just one thing we wanted to remove, and then the question of which name we want to give to a manifest... 17:33:13 ack Avneesh 17:33:53 Avneesh: I was just thinking of how to structure thoughts... We have a proposal on how to package the audiobooks. Maybe we should handle this problem from the other side - what is the minimum features we want in packaging, and then evaluate the spec/process fits in. 17:34:14 q+ 17:34:24 @laurent_ what was the one thing we need to remove from OCF? I didn't catch it 17:34:28 ...: The second is regarding the extension point spec. If Audiobooks just have 1 extension point which is different from WP - Packaging, maybe we don't need to separate the spec. We would just have one additional item then... 17:34:29 ack ivan 17:35:19 Ivan: As far as I could follow, that's not the only thing where audiobooks have their specificities. The audiobook specification would also include additional entries in the manifest that belongs to them and not the core. It might be a relatively thin layer, but it's not only the packaging. 17:35:29 @duga the order of the files in the archive. There is a file which MUST be first in the OCF package, for streaming purposes, that makes no more sense. 17:36:30 ...: Why we keep going back to the previous discussion - we'll have to play around with minutes - the alternative is to have a huge document that would include all the various modules. If we put together all in one document. Being an editor of the core document, I know it's difficult to manage. It's already a pretty sizable document. If we add 2-3 other modules, it's a monster. 17:36:38 q+ 17:36:47 ack bigbluehat 17:36:49 ...: forget a separate repo, but having a single document, it becomes unmanageable and unreadable. 17:38:08 Benjamin: My concern with splitting, even into two documents, we already have a split brain - and inheretence is confused already. There have been two groups discussing. If we ship them together as the same group, we should think about how that inheretence works - within and without the package. Who builds them, who renders them, etc. There are possibly two answers. 17:38:09 q+ 17:38:15 q+ 17:38:18 ...: I'm concerned we'll make that worse not better 17:38:20 ack nickruffilo 17:38:52 s/inheretance/inheritance/ 17:39:01 nickruffilo: bigbluehat wins comment of the day. An important question for me is are we trying to solve all of the publishing industry's problems, or are we trying to create a web publication? 17:39:24 q? 17:39:57 ... how many hoops do we go through? Would a video book have to fit into a wp, if we think about what is the best and most logical web publication we might come up with something better than thinking of what audio needs now 17:40:01 ack tzviya 17:40:40 q+ 17:40:44 Tzviya: I think there are going to be some things that are unique to different types - such as audiobooks. We haven't come up with any solutions, just problems. I'm concerned about packaging for audiobooks. we've decided not to make a decision on WP, but for audiobooks, we need to make a decision today. 17:41:22 ...: OCF is on shaky grounds because we need to know what the revisions on the spec are. If they are minor, then it may not be an issue, but I don't want two different major versions of OCF. I don't know if people are comfortable with all the differences. But - what's wrong with ZIP, why can't that work? 17:41:26 ack josh 17:42:01 q+ 17:42:11 q+ 17:42:17 Josh: To wrap up what Tzviya said - audiobooks needs packaging right away, so that means that web publications needs packaging right away. If an important implementation of WP (like audiobooks) needs packaging right away, I think we need to address it for all WPs. 17:42:24 +1 to what josh said 17:42:53 q+ 17:42:59 Wendy: We are running out of time. It sounds like the audio TF needs to rethink the proposal and not just for audiobooks, but packaging in the webby sense. What should work for audio should also work for the web. 17:43:02 ack George 17:43:43 George: I think that's a good idea. We manage to shoehorn media overlays into an epub publication, so we might be able to shoehorn an audio publication into the same publication. The Audio Taskforce may want to look at that as a possible avenue. 17:43:58 Wendy: I've seen one proposal for how that might possiblye work, but it needs more work. 17:44:00 ack mgarrish 17:44:24 s/possiblye/possibly/ 17:44:49 Matt: I just wanted to jump back on the things Ivan said. It's too early to decide if different specs are needed, different repos. It's more an exercise in 'what is WP missing?' Maybe bringing it back to WP - maybe it's something the audiobook should be working up their requirements and that could become a pull request into the WP itself.. 17:45:12 ...: I wouldn't launch into new specs at this moment. I would want to focus on what it is that is needed in WP. Only if there are incompatibilities would we need different specs. 17:45:13 +1 to Matt 17:45:22 +1 mgarrish 17:45:41 Laurent: When you said the Audiobook TF should review packaging for all - they are not a packaging taskforce, so it's not the goal. 17:46:11 q+ 17:46:17 ack laurent_ 17:46:18 Wendy: We are the first group that needs packaging. We want to stay as close to WP as possible. So maybe we should lead the way on that. We could just add audio and packaging. I worry that it obfuscates what we're doing. 17:46:26 ack Bill_Kasdorf 17:47:06 +1 to Bill_Kasdorf 17:47:08 Bill: I've always envisioned that WP is the broadest most accomodating of the specs - and it allows any packaging format that is legal in the open web platform, and more specific modules like audiobooks, epubs, etc... would just say 'for this module, use this one..." 17:47:21 +1 to Bill 17:47:32 s/accomodating/accommodating/ 17:47:34 q+ 17:47:41 zakim, close the queue 17:47:42 ok, tzviya, the speaker queue is closed 17:47:46 ack Avneesh 17:47:50 ...: I view the modules as narrowing down the broader WP spec. I would be worried about WP making a change because audiobooks needed it, when a different module might not want what audiobooks needs. 17:48:31 Avneesh: My direction of thinking is going in the same direction - jumping on that we want extension points. Maybe the approach should be that we keep working on single spec, and let things get mature, but until then, let the taskforces come up. 17:48:40 https://github.com/w3c/wpub/issues/351 17:48:40 zakim, open the queue 17:48:40 ok, tzviya, the speaker queue is open 17:48:56 subtopic: json type property 17:49:05 Wendy: We have 12 minutes, and i want to address one more issue. This is for the spec at large, but we discussed with Audiobooks. it's about JSON-type. It's defined for book and audiobook. 17:49:22 https://github.com/w3c/wpub/issues/351 17:49:52 ...: As we work with sync-media group, how would a sync-media book be different. The current solution is to use both book and audio, but would it possibly be better and clearer to use additional types for something like sync-media publication, manga, and other things that have specific use cases. 17:50:12 q+ 17:50:13 ...: so a user agent could make decisions. Would that be permissable in WP? 17:50:14 q+ 17:50:18 ack ivan 17:51:22 Ivan: My answer is 'yes' and If I remember well, this question was specifically asked at TPAC as well. Somehow by some magic, we already have types that we use and define for ourselves, so adding new types is perfectly possible. it's probably a good idea for reasons of discovery by schema.org to say that it's clear... 17:51:38 ...: Semantically I'm not sure it'd be required, then I don't see it as a problem 17:51:38 ack nickruffilo 17:52:23 nickruffilo: I think it is a good idea to have specifics, especially for dedicated reading systems, but when we think of what is the standard, a basic UA might only have support for "book" or "audiobook" 17:52:43 q+ 17:52:55 ... would allowing a second level give the same ability for an RS that can support it, and a basic RS can just focus on book or audiobook 17:53:09 +1 for nickruffilo's suggestion of progressive enhancement in books 17:53:09 ack laurent_ 17:54:11 q+ 17:54:22 +1 to nickruffilo's proposal to give UAs a hook for specialized functionality based on the type of book 17:54:31 Laurent: Agree with nick - audiobook is already a subtype of book in schema.org. We don't have a very large set of subtypes. We know there is audiobook and visual novel (comics and image based). We have synced media (read aloud book). But we have maybe 5 subtypes. Each corresponding to a different type of user agent. That would allow different packages. It would be very easy to create 4-5 types, then use the schema.type for that. It should be[CUT] 17:54:36 ... soon but not be too generic. 17:54:40 +1 to laurent_ 17:54:40 ack bigbluehat 17:55:30 q+ 17:55:31 Benjamin: I have grave concern about 5 different user agents. There are audiobook listeners that just play audiobook. Perhaps the sub-typing is not as bad as it sounds, but there are generic browsers that browse generic web and it doesn't care if it's an audiobook or manga in HTML, it's the value of the web, VS having to find the right app... 17:55:33 q+ 17:55:52 +1 bigbluehat - question value of strict type taxonomies vs contextual cues 17:55:55 ... I'm not sure how we marry those two, but I have concern that we might switch too heavily on this type field and get ourselves into trouble subsetting these spec.s 17:55:55 ack Avneesh 17:56:58 ack dkaplan 17:56:58 Avneesh: This rolls back to Ivan's comment. If there's something unique to audiobooks, beyond packaging... The main reason is not to provide browser support, it's for reading systems. What if there is an HTML page in the reading order... This flag/metadata will tell the reading system that it's a collection of audiobooks, etc. Browser may ignore it, but it's for the reading systems. 17:58:20 Deborah: This is a general variant - Benjamin added to Nick's comments - there are two competing and important issues. One is the idea of saying 'some features will only work in X browser' then we're back in 2002. That is not a behavior we want. But it is also true that within publishing, there are complex use-cases. 17:58:41 s/That would allow different packages.// 17:59:23 ...: When we talk about WPs we want things displable everywhere. There may be features of RS or browsers that aren't shared, but as long as the usability and accessibility is there, all the content is available. it's a complex negotiation. Yes, browsers may have simple functionality, as long as it's done mindfully 17:59:28 +1 to deborah 17:59:34 q+ 17:59:44 ack nickruffilo 18:00:14 evan has joined #pwg 18:00:56 CharlesL has left #pwg 18:01:05 rrsagent, draft minutes 18:01:05 I have made the request to generate https://www.w3.org/2018/12/10-pwg-minutes.html ivan