23:23:34 RRSAgent has joined #epub 23:23:34 logging to https://www.w3.org/2021/04/01-epub-irc 23:23:36 RRSAgent, make logs Public 23:23:37 please title this meeting ("meeting: ..."), dauwhe 23:23:45 Meeting: EPUB 3 Working Group Telecon 23:23:55 Date: 2021-04-01 23:24:01 Chair: dauwhe 23:24:05 guest+ dauwhe 23:49:41 Garth has joined #epub 23:53:02 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Mar/0030.html 23:56:11 MattChan has joined #epub 23:57:44 BenSchroeter_ has joined #epub 23:59:01 shiestyle has joined #epub 23:59:11 MasakazuKitahara has joined #epub 23:59:12 toshiakikoike has joined #epub 23:59:17 present+ 23:59:31 present+ 23:59:35 present+ 23:59:57 present+ 00:00:36 present+ 00:01:47 dlazin has joined #epub 00:01:52 present+ 00:03:06 scribe+ 00:03:10 mgarrish has joined #epub 00:03:29 wendyreid has joined #epub 00:03:45 present+ 00:04:10 TOPIC: TF Dates 00:04:20 present+ 00:04:21 wendyreid: i sent an email out earlier this afternoon/evening 00:04:36 ... we have dates now for the first two meetings of the virtual locators TF and the FXL a11y TF 00:05:13 ... FXL a11y meeting 9am tuesday, virtual locators on wed 7th 11am 00:05:32 ... still seeking people to lead these TFs 00:05:43 ... no date yet for scripting meeting 00:05:52 q+ 00:05:54 ... still waiting on a few people to submit their availability 00:06:05 q+ 00:06:08 q- 00:06:13 ack dl 00:06:22 duga has joined #epub 00:06:44 dlazin: for the TFs, i was talking to book indexer friend, and she mentioned there was some discussion between pro indexes and adobe around getting page number like things from INDD into epubs 00:07:00 ... she asked if we could involve some indexers 00:07:29 wendyreid: really good Q. If you would like to put them in touch with us? We can invite them to the TF 00:07:39 dauwhe: we want them, yes 00:07:51 ... delighted to have them as guests at the meeting 00:08:02 dlazin: great, i'll help make that happen 00:08:16 present+ 00:08:24 https://github.com/w3c/epub-specs/pull/1468 00:08:25 TOPIC: Clarify base IRI 00:08:37 dauwhe: this is a PR about base IRI in package documents 00:09:16 https://github.com/w3c/epub-specs/issues/1374 00:09:25 mgarrish: basically all the PR does is define base IRI for package because it wasn't clear how that was to be calculated 00:09:34 https://github.com/w3c/epub-specs/issues/1456 00:09:56 ... it is defined for container.xml, but for package doc there was just a stray sentence that absolute IRIs are to be calculated from base IRI of document 00:10:01 ... Ivan wanted some clarification 00:10:12 ... PR pulls out that statement and elaborates on it 00:10:51 ... Laurant suggested that maybe we define everything in core docs as paths rather than IRIs 00:10:56 q+ 00:11:13 ... not sure why we'd want to do that since we already define abstract container to allow us to use IRI language 00:11:28 ... how far do we want to get into relative paths vs absolute paths 00:11:52 ack dau 00:11:59 ... can we just clean up what we already have, or do we want to take up this IRI vs path question at this point? 00:12:09 dauwhe: i'm happy with PR 00:12:48 ... worried about Laurent's idea because not sure we want to start talking about paths when all the other specs that we rely upon are already happy about how we define things 00:13:22 ... also, this issue didn't come out of a concrete problem with a RS or similar, it came from abstract issue about spec language 00:13:43 mgarrish: the PR seemed to make Ivan happy 00:14:16 ... from the perspective of what we need to describe here, I think we've done enough 00:14:29 ... the question about changing to path language leads off into other areas 00:15:27 dauwhe: i think we should accept the PR, and then if Laurent wants to raise the other question, maybe he can come back with a more detailed rationale 00:16:18 mgarrish: there was an issue about whether relative IRIs MUST be resolved, but it was only ever the intention that it be possible if you need to do it 00:16:35 Proposed: Merge PR 1468 00:16:37 +1 00:16:42 +1 00:16:42 +1 00:16:42 +1 00:16:43 +1 00:16:43 +1 00:16:44 +1 00:16:46 +1 00:16:52 +1 00:17:06 Resolved: Merge PR 1468 00:17:41 https://github.com/w3c/epub-specs/pull/1588 00:17:42 TOPIC: Pagelist Requirements 00:18:27 dauwhe: we had required that the order of the nav elements had to match the order of the elements in the spine 00:18:44 ... then when this was implemented in epubcheck, it turned out that it made a bunch of epubs invalid 00:19:17 q+ 00:19:28 ... we eventually got that sorted out, but we never went back to address the corresponding issue in the pagelist 00:19:43 ... mgarrish is this going to be covered in epub a11y instead of core now 00:20:18 ack dug 00:20:22 mgarrish: yes. The issue is that this forces the pagelist to match the order of the digital version, which is not at all helpful when there is an expectation that the pagelist correspond to print 00:20:37 duga: why are we removing this requirement? 00:20:57 ... the toc is not without controversy because it breaks UIs 00:21:08 ... we didn't want to make publishers go back and fix their content 00:21:12 ... is this similar? 00:21:23 https://github.com/w3c/epub-specs/issues/1471 00:21:32 mgarrish: here we're just removing the strict requirement that the pagelist match 00:21:38 ... so we wouldn't be invalidating anything 00:21:51 ... not the same as the toc because the toc is being used by RSes in various ways 00:22:10 ... but we don't know that RSes are using pagelist in the same way 00:22:31 ... allowing authors to reorder pagelist might actually make it align with expectations 00:22:47 duga: so, does this mean, for e.g., that page 7 could come after page 10? 00:23:02 mgarrish: yes, but you could still do that right now if that was the order of content in the spine 00:23:29 wendyreid: with the current requirements we might accidentally be forcing the page 7 after page 10 thing 00:23:34 q? 00:23:45 ... with the PR that might still happen, but it would be by choice, as opposed to being forced by spec 00:24:07 BenSchroeter_: you could also have a case where the print book has a sidebar that in the digital version comes after the body text 00:24:42 ... in cases like that you might want the pagelist to come out of order intentionally 00:25:37 mgarrish: i'm not sure if that would be an example of where we'd want that for a11y purposes or not, but there are situations where you'd want the pagelist to match print content rather than spine order 00:26:28 dauwhe: i'm seeing several cases where we're making the choice that these "best practices" are better off being in the a11y spec when the directly impact a11y rather than try to bake good practice into the epub spec itself, especially when there is such a diversity of content 00:26:45 BenSchroeter_: but i've always wonder why pagelist is an a11y feature 00:26:50 ... it is, but it is also useful for everyone 00:27:25 mgarrish: that's a possibility we could take up, i.e. just recommend something about page sequencing 00:27:38 Proposed: Merge PR 1588 00:27:43 +1 00:27:44 +1 00:27:44 +1 00:27:44 +1 00:27:50 +1 00:27:52 +1 00:27:52 0 00:28:02 +0 as I don't fully understand all the implications 00:28:07 0 00:28:27 Resolved: Merge PR 1588 00:28:44 wendyreid: i understand your concern duga 00:28:55 ... and this is something we can take a look at when we do virtual locators as well 00:29:00 ... as there is crossover 00:29:25 duga: it may be fine, but i'd just like to think about it some more first 00:30:11 TOPIC: Republish Drafts 00:30:25 dauwhe: there have been some significant changes to our WDs 00:30:33 ... we'd need a resolution to republish 00:30:41 ... i prefer to publisher early and often 00:30:52 ... this reduces confusion in general 00:31:04 ... did we want to do a11y too, or maybe just core and RS? 00:31:30 wendyreid: has there been enough changes to a11y that its worth it to republish? 00:31:44 mgarrish: yes, there have been changes, and there is no reason not to 00:32:00 s/has there been/have there been 00:32:20 Proposed: Publish new drafts of the core, reading systems, and accessiblity documents 00:32:26 +1 00:32:26 +1 00:32:27 +1 00:32:27 +1 00:32:27 +1 00:32:29 +1 00:32:31 +1 00:32:38 Resolved: Publish new drafts of the core, reading systems, and accessiblity documents 00:32:54 s/prefer to publisher/prefer to publish 00:33:06 TOPIC: Virtual F2F 00:33:32 wendyreid: i think we were putting this off in hopes of in person meeting instead of virtual 00:33:45 ... there is usually one a TPAC and one in spring 00:34:06 ... we were thinking of just having two longer meetings, back to back (like we did for the TPAC one) 00:34:37 ... we were considering the 13th/14th or the 27th/28th of May 00:35:10 dauwhe: these meetings allow us to have some longer discussions, which might not fit into the ordinary 1hr a week 00:35:39 ... this is just informational at this point. We'll try to send out an email later to see what works for everyone 00:35:49 wendyreid: we're working around May holidays 00:36:23 dauwhe: one other thing is that we haven't yet come up with a standard for how to review tests 00:36:38 ... do we assign a certain number of reviewers for PRs related to tests? 00:36:43 ... who are those people? 00:36:52 ... maybe we can have this on the agenda at the next meeting 00:37:06 ... we can also talk about the scope of testing, how granular the tests should be? 00:37:54 dlazin: i have one PR out right now that merges in all of dauwhe's existing tests 00:38:05 ... and then I have another one out to add some new tests 00:38:46 wendyreid: have a great weekend everyone, we'll see you next week! 00:39:03 zakim, end meeting 00:39:03 As of this point the attendees have been MasakazuKitahara, toshiakikoike, MattChan, BenSchroeter_, shiestyle, dlazin, wendyreid, mgarrish, duga 00:39:05 RRSAgent, please draft minutes 00:39:05 I have made the request to generate https://www.w3.org/2021/04/01-epub-minutes.html Zakim 00:39:08 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:39:12 Zakim has left #epub 00:39:26 RRSAgent: make logs public 00:39:40 RRSAgent: bye 00:39:40 I see no action items