22:59:11 RRSAgent has joined #epub 22:59:11 logging to https://www.w3.org/2022/03/31-epub-irc 22:59:14 RRSAgent, make logs Public 22:59:16 please title this meeting ("meeting: ..."), dauwhe 22:59:23 Meeting: EPUB 3 Working Group Telecon 22:59:58 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2022Mar/0019.html 23:34:24 mgarrish has joined #epub 23:49:18 MURATA has joined #epub 23:51:18 present+ 23:51:30 present+ 23:54:32 ShinyaTakami has joined #epub 23:59:12 MattChan has joined #epub 23:59:52 toshiakikoike has joined #epub 00:00:02 present+ 00:00:04 MasakazuKitahara has joined #epub 00:00:11 present+ 00:00:26 present+ 00:00:39 present+ 00:01:36 present+ 00:02:25 scribe+ 00:02:53 regrets+ RickJ 00:03:05 regrets+ Ben S. 00:03:27 https://github.com/w3c/epub-specs/pull/2101 00:03:31 TOPIC: Review PR for Resource Explanations 00:03:37 https://pr-preview.s3.amazonaws.com/w3c/epub-specs/2101/017a47c...6a76ddc.html#sec-publication-resources 00:04:00 dauwhe: this is a very comprehensive re-working of how we define and explain publication resources 00:04:52 mgarrish: ivan had some diagrams in the PR, and this was also a useful exercise for identifying areas where terminology had gotten kind of wonky 00:05:04 ... it looks big, but the bulk of the PR is adding an introduction and some examples 00:05:11 ... ultimately we broke it down to 3 planes 00:05:22 ... the top one is manifest plane: everything in the container 00:05:50 ... we had a term called publication resources, which described anything used in rendering, and then we had non-publication resources for everything else 00:06:07 ... we we've done is formalize the term linked resource to describe these other resources 00:06:20 s/we we've/what we've 00:06:35 ... moving down from that we have the spine and epub content documents 00:06:59 ... it was kind of a mix, sometimes we called things in the spine publication resources, sometimes we referred to foreign resources 00:07:13 ... so we've made it either epub content document or foreign content document 00:07:50 ... finally the lowest level is the content plane: everything that gets rendered in an epub content document 00:08:04 ... this is where CMT and foreign resource live as concepts 00:08:33 ... and we created a 3rd category of exempt resources that collects together all these exemptions to CMT/fallback rules, e.g. fonts 00:08:47 ... this PR basically just sets up this understanding and these terminology 00:08:56 q+ 00:09:07 ... ivan went and did an extensive example in the appendix 00:09:26 ... and how each of the parts of the example would match up to the 3 planes 00:10:13 ... the rest is just clean-up, to make sure that our use of terminology is consistent, try to weed out places where we previously lacked defined terminology so meaning was muddier 00:10:31 dauwhe: I wish I could wipe my memory of epub and start over with this 00:10:36 ack da 00:10:48 mgarrish: yes, it was a really helpful exercise, and discussing without this was very convoluted 00:11:02 dauwhe: yes, I've witnessed confusion because of the lack of terminology 00:11:13 ... about remote resources, does that concept stay the same as part of this picture? 00:11:35 mgarrish: we described where remote resources exist in the planes, but they aren't a class unto themselves 00:11:47 +q 00:11:53 ... i don't want to make it so complex in explaining it that we go back into the state of confusion where we were before 00:12:13 dauwhe: right, both remote resources and manifest fallbacks need to serve these other roles 00:12:19 ack MUR 00:12:58 MURATA: i've been a bit skeptical about the publication resources. Now we have a class of linked resources and publication resources 00:13:08 ... so now SSML and PLS are publication resources, right? 00:13:09 mgarrish: yes 00:13:21 MURATA: so rendering means not just visual rendering, but any sort of rendering 00:13:47 mgarrish: publication resources are just the big giant bucket of everything used in rendering the epub, c.f. linked resources which are not directly part of the publication 00:13:54 dauwhe: ancillary to the publication 00:14:23 MURATA: wondering if we really need the term publication resources, maybe just resource, or resources which are not linked 00:14:48 mgarrish: yeah, but then aren't we just going back to not have a direct term for it? would it conflict with other contexts where people talk about resources? 00:15:17 MURATA: so you are saying resources within the zip file are one category, and that resources outside the zip file are something else 00:15:30 q? 00:15:38 mgarrish: resources is just a very general term, so i'm worried that it becomes too broad 00:15:50 ... and part of it is that publication resources is just always the term we've used 00:16:07 dauwhe: resources as a term is so overloaded, i don't think it gains us clarity 00:16:26 MURATA: not happy with the definition of publication resources because it depends on rendering, which is not well defined in itself 00:16:41 ... can we say that it is all non-linked resources in the epub? 00:17:00 ... if some data is used for braille, are they publication resources? I guess so, but it is not so clear 00:17:14 dauwhe: i think we're clear that rendering is anything presented to the user 00:17:21 MURATA: is that in the spec? 00:17:35 dauwhe: i think it's a term of art in the web/graphics world 00:17:53 MURATA: before i got involved in a11y, i never thought of braille as rendering 00:18:03 mgarrish: it's still presented to the user 00:18:45 ... to be honest, use of rendering was intentional, we specifically avoided use of display 00:19:00 ... not sure how we would define that beyond the common definition of rendering 00:19:11 MURATA: how about adding a note on the scope of rendering? 00:19:23 ... specifically referring to braille terminals 00:19:37 mgarrish: that's fine with me, not sure where it would fit, but we could do this 00:19:57 dauwhe: maybe in the terminology section? 00:20:28 mgarrish: we could make a defined term out of it, like 'encompasses all the ways content may be presented, whether visual, tactile, or auditory' 00:20:43 ... we do define some common terms, so probably no harm in providing some basic definition 00:21:02 ... just worried about having to link it then (we are supposed to link each term the first time it is used) 00:21:07 ... but we don't have to settle this now 00:21:22 dauwhe: in general i think this is a massive improvement to the legibility of the spec 00:21:49 ... it's also one of these things that is hard to sort out all the issues before merging it 00:22:22 ... with big PRs there is always the possibility of typos sneaking in 00:22:50 ... given broad support for the goals and language here, I propose we merge, and then we can file issues and fix as necessary, as with the definition of rendering above 00:22:51 Proposal: Merge PR 2101 00:23:03 mgarrish: the bulk of this is informative, so likely nothing normative changes as a result of this 00:23:10 ... doesn't really block move to CR 00:23:10 +1 00:23:24 MURATA: will we close this issue too? 00:23:31 +1 00:23:34 dauwhe: yes, and then we can open more detailed issues on subsets of this 00:23:48 mgarrish: there's no actual issue, the PR is based on discussions i had with ivan 00:24:00 MURATA: so nothing wrong with raising smaller issues related to this? 00:24:03 dauwhe: yes 00:24:09 mgarrish: and it's hard to raise issues off a PR 00:24:26 +1 00:24:35 +1 00:24:36 dauwhe: anyone else, please vote now 00:24:38 +1 00:24:39 +1 00:24:43 +1 00:25:11 Resolved: Merge Pull Request #2101 00:26:04 dauwhe: mgarrish please merge at your convenience 00:26:19 https://github.com/w3c/epub-specs/pull/2137 00:26:25 TOPIC: Review PR for MathML features 00:26:33 https://github.com/w3c/epub-specs/issues/2118 00:26:55 mgarrish: duga had opened this initially, and we went back and forth 00:27:19 ... i think his concern is that we're imposing a restriction on MathML's deprecated features that MathML itself doesn't impose on its features 00:27:32 ... they are deprecated, but you're still allowed to have them in MathML 00:27:40 ... we are imposing on their spec 00:28:03 ... he's asked that we not restrict these deprecated features 00:28:22 ... I agree, and I don't think us putting a ban on MathML features moves the needle on MathML rendering 00:28:36 ... math rendering is made for web browsers, and we just use what they do 00:28:52 ... if getting rid of these restrictions smooths over a spec weirdness, that is fine 00:29:04 ... people don't hand write MathML anyway 00:29:15 ... so this PR takes out the MUST NOT that was there before 00:29:28 dauwhe: this is in keeping with changes we've been making incrementally over the last 5-10 years 00:29:43 ... initially we were intervening with the goal of making it easier for people who were trying to write RS from scratch 00:29:52 ... to allow them to skip support for complicated features 00:30:16 ... this PR is in keeping with our take on epub as a container for these other technologies 00:30:23 ... we leave it up to these other specs 00:30:56 mgarrish: I don't think these restrictions work anymore, but they were important at the time 00:31:12 dauwhe: so I would propose we merge this 00:31:17 +1 00:31:25 Propose: merge PR 2137, close 2118 00:31:28 +1 00:31:30 +1 00:31:30 +1 00:31:30 +1 00:31:31 +1 00:31:32 +1 00:32:01 Resolved: merge PR 2137, close issue 2118 00:32:26 TOPIC: REMINDER: Please complete document review by meeting time 00:32:40 dauwhe: if you have signed up as a reviewer, please remember to do so! 00:32:57 ... we've already gotten a bunch of useful feedback, so thank you to everyone who has reviewed so far 00:33:11 ... sounds like we are hoping to vote on move to CR at next weeks meeting 00:33:22 MURATA: you have to close all issues by next week? 00:34:17 dauwhe: no, we are just saying that we've largely finished the technical work, have completed horizontal reviewer, have made related normative changes based on same, have a test plan, and are shifting focus to testing 00:34:28 ... there will be issues that come up during CR as we open review to community 00:34:41 ... some issues are marked deferred, and many open issues are editorial in nature 00:34:56 ... but no expectation that we have zero issues as we go into CR 00:35:29 ... and due to timing of what W3C mgmt and Director have to do for it, we'd expect to publish around May 5th (there will be publication moratorium in April) 00:35:47 MURATA: when will the upcoming AC meeting be? 00:36:14 dauwhe: I think there is a meeting April 25-26, a virtual meeting 00:36:26 ... this will cause a little slowdown in publications 00:37:28 TOPIC: Accessibility Usage and Metadata report for CR criteria 00:37:52 mgarrish: we came up with a template for it, and it is currently with Charles to add data from GCA cert publishers 00:38:10 dauwhe: I can follow up with Wendy to clarify what needed to be discussed 00:38:25 ... and I think just the data from Charles will be sufficient 00:38:50 mgarrish: I think the certifierReport property might be problematic, but other than that, everything else we need is part of GCA certification 00:38:59 dauwhe: we have definitely done some of it in our books 00:39:33 dauwhe: thank you mgarrish for all your work 00:39:56 ... looking forward to CR! 00:40:07 Zakim, end meeting 00:40:07 As of this point the attendees have been dauwhe, MURATA, toshiakikoike, ShinyaTakami, MasakazuKitahara, MattChan, mgarrish 00:40:10 RRSAgent, please draft minutes 00:40:10 I have made the request to generate https://www.w3.org/2022/03/31-epub-minutes.html Zakim 00:40:13 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:40:17 Zakim has left #epub 00:40:20 rrsagent, bye 00:40:20 I see no action items