EPUB 3 Working Group Telco — Minutes

Date: 2022-03-31

See also the Agenda and the IRC Log


Present: Dave Cramer, Murata Makoto, Toshiaki Koike, Shinya Takami (高見真也), Masakazu Kitahara, Matthew Chan, Matt Garrish

Regrets: Rick Johnson, Wendy Reid, Ben Schroeter


Chair: Dave Cramer

Scribe(s): Matthew Chan


1. Expand and fix resource explanations (pr epub-specs#2101)

See github pull request epub-specs#2101.

Dave Cramer: https://pr-preview.s3.amazonaws.com/w3c/epub-specs/2101/017a47c…6a76ddc.html#sec-publication-resources.

Dave Cramer: this is a very comprehensive re-working of how we define and explain publication resources.

Matt Garrish: ivan had some diagrams in the PR, and this was also a useful exercise for identifying areas where terminology had gotten kind of wonky.
… it looks big, but the bulk of the PR is adding an introduction and some examples.
… ultimately we broke it down to 3 “planes”.
… the top one is manifest plane: everything in the container.
… we had a term called publication resources, which described anything used in rendering, and then we had non-publication resources for everything else.
… what we’ve done is to formalize the term linked resource to describe these other resources.
… moving down from that we have the spine plane and epub content documents.
… it was kind of a mix, sometimes we called things in the spine publication resources, sometimes we referred to foreign resources.
… so we’ve made it either epub content document or foreign content document.
… finally the lowest level is the content plane: everything that gets rendered in an epub content document.
… this is where CMT and foreign resource live as concepts.
… and we created a 3rd category of exempt resources that collects together all these exemptions to CMT/fallback rules, e.g. fonts.
… this PR basically just sets up this understanding and these terminology.
… ivan went and did an extensive example in the appendix.
… and how each of the parts of the example would match up to the 3 planes.
… 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.

Dave Cramer: I wish I could wipe my memory of epub and start over with this.

Matt Garrish: yes, it was a really helpful exercise, and discussing without this was very convoluted.

Dave Cramer: yes, I’ve witnessed confusion because of the lack of terminology.
… about remote resources, does that concept stay the same as part of this picture?.

Matt Garrish: we described where remote resources exist in the planes, but they aren’t a class unto themselves.
… 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.

Dave Cramer: right, both remote resources and manifest fallbacks need to serve these other roles.

Murata Makoto: i’ve been a bit skeptical about the publication resources. Now we have a class of linked resources and publication resources.
… so now SSML and PLS are publication resources, right?.

Matt Garrish: yes.

Murata Makoto: so rendering means not just visual rendering, but any sort of rendering.

Matt Garrish: 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.

Dave Cramer: ancillary to the publication.

Murata Makoto: wondering if we really need the term publication resources, maybe just resource, or resources which are not linked.

Matt Garrish: 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?.

Murata Makoto: so you are saying resources within the zip file are one category, and that resources outside the zip file are something else.

Matt Garrish: resources is just a very general term, so i’m worried that it becomes too broad.
… and part of it is that publication resources is just always the term we’ve used.

Dave Cramer: resources as a term is so overloaded, i don’t think it gains us clarity.

Murata Makoto: not happy with the definition of publication resources because it depends on rendering, which is not well defined in itself.
… can we say that it is all non-linked resources in the epub?.
… if some data is used for braille, are they publication resources? I guess so, but it is not so clear.

Dave Cramer: i think we’re clear that rendering is anything presented to the user.

Murata Makoto: is that in the spec?.

Dave Cramer: i think it’s a term of art in the web/graphics world.

Murata Makoto: before i got involved in a11y, i never thought of braille as rendering.

Matt Garrish: it’s still presented to the user.
… to be honest, use of rendering was intentional, we specifically avoided use of display.
… not sure how we would define that beyond the common definition of rendering.

Murata Makoto: how about adding a note on the scope of rendering?.
… specifically referring to braille terminals.

Matt Garrish: that’s fine with me, not sure where it would fit, but we could do this.

Dave Cramer: maybe in the terminology section?.

Matt Garrish: we could make a defined term out of it, like ‘encompasses all the ways content may be presented, whether visual, tactile, or auditory’.
… we do define some common terms, so probably no harm in providing some basic definition.
… just worried about having to link it then (we are supposed to link each term the first time it is used).
… but we don’t have to settle this now.

Dave Cramer: in general i think this is a massive improvement to the legibility of the spec.
… it’s also one of these things that is hard to sort out all the issues before merging it.
… with big PRs there is always the possibility of typos sneaking in.
… 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.

Proposed resolution: Merge PR 2101. (Dave Cramer)

Matt Garrish: the bulk of this is informative, so likely nothing normative changes as a result of this.
… doesn’t really block move to CR.

Dave Cramer: +1.

Murata Makoto: will we close this issue too?.

Shinya Takami (高見真也): +1.

Dave Cramer: yes, and then we can open more detailed issues on subsets of this.

Matt Garrish: there’s no actual issue, the PR is based on discussions i had with ivan.

Murata Makoto: so nothing wrong with raising smaller issues related to this?.

Dave Cramer: yes.

Matt Garrish: and it’s hard to raise issues off a PR.

Matt Garrish: +1.

Murata Makoto: +1.

Dave Cramer: anyone else, please vote now.

Matthew Chan: +1.

Toshiaki Koike: +1.

Masakazu Kitahara: +1.

Resolution #1: Merge Pull Request #2101.

Dave Cramer: mgarrish please merge at your convenience.

2. Remove restriction on mathml deprecated features (pr epub-specs#2137)

See github pull request epub-specs#2137.

See github issue epub-specs#2118.

Matt Garrish: duga had opened this initially, and we went back and forth.
… 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.
… they are deprecated, but you’re still allowed to have them in MathML.
… we are imposing on their spec.
… he’s asked that we not restrict these deprecated features.
… I agree, and I don’t think us putting a ban on MathML features moves the needle on MathML rendering.
… math rendering is made for web browsers, and we just use what they do.
… if getting rid of these restrictions smooths over a spec weirdness, that is fine.
… people don’t hand write MathML anyway.
… so this PR takes out the MUST NOT that was there before.

Dave Cramer: this is in keeping with changes we’ve been making incrementally over the last 5-10 years.
… initially we were intervening with the goal of making it easier for people who were trying to write RS from scratch.
… to allow them to skip support for complicated features.
… this PR is in keeping with our take on epub as a container for these other technologies.
… we leave it up to these other specs.

Matt Garrish: I don’t think these restrictions work anymore, but they were important at the time.

Dave Cramer: so I would propose we merge this.

Murata Makoto: +1.

Proposed resolution: merge PR 2137, close 2118. (Dave Cramer)

Dave Cramer: +1.

Shinya Takami (高見真也): +1.

Masakazu Kitahara: +1.

Matt Garrish: +1.

Toshiaki Koike: +1.

Matthew Chan: +1.

Resolution #2: merge PR 2137, close issue 2118.

3. REMINDER: Please complete document review by meeting time.

Dave Cramer: if you have signed up as a reviewer, please remember to do so!.
… we’ve already gotten a bunch of useful feedback, so thank you to everyone who has reviewed so far.
… sounds like we are hoping to vote on move to CR at next weeks meeting.

Murata Makoto: you have to close all issues by next week?.

Dave Cramer: 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.
… there will be issues that come up during CR as we open review to community.
… some issues are marked deferred, and many open issues are editorial in nature.
… but no expectation that we have zero issues as we go into CR.
… and due to timing of what W3C management and Director have to do for it, we’d expect to publish around May 5th (there will be publication moratorium in April).

Murata Makoto: when will the upcoming AC meeting be?.

Dave Cramer: I think there is a meeting April 25-26, a virtual meeting.
… this will cause a little slowdown in publications.

4. Accessibility Usage and Metadata report for CR criteria.

Matt Garrish: we came up with a template for it, and it is currently with Charles to add data from GCA cert publishers.

Dave Cramer: I can follow up with Wendy to clarify what needed to be discussed.
… and I think just the data from Charles will be sufficient.

Matt Garrish: I think the certifierReport property might be problematic, but other than that, everything else we need is part of GCA certification.

Dave Cramer: we have definitely done some of it in our books.
… thank you mgarrish for all your work.
… looking forward to CR!.

5. Resolutions