EPUB 3 Working Group Telco — Minutes

Date: 2021-08-13

Attendees

Present: Dave Cramer, Wendy Reid, Avneesh Singh, Masakazu Kitahara, Ivan Herman, Murata Makoto, Charles LaPierre, George Kerscher, John Foliot, Matthew Chan, Dan Lazin, Ben Schroeter, Brady Duga, Aimee Ubbink

Regrets: Gregorio Pellegrino

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

1. Welcome back

Dave Cramer: welcome back everyone
… we’re hoping for CR later this fall
… and there’s a fair amount that needs to be done, including horizontal review
… we’ve done a lot with i18n, a lot with a11y, some action items around security and privacy
… i’ve done a draft of the questionnaire for the security and privacy review
… I’ll probably send that in, although I’m not an expert, and there are some epub specific security issues that aren’t in the broader web
… and then of course testing
… ivan has built some tooling for test reporting
… and we’re also working on documentation about how to write tests
… once that doc is ready, we’ll get help from other WG members to write the tests
… anything else?
… we’re going to have more virtual F2F for TPAC?

Ivan Herman: yes

Wendy Reid: its the latter half of october, the 28th and 29th are the tentative dates
… following the same pattern as last time, so 28th is the evening meeting, and 29th would be a morning meeting

Ivan Herman: we can create a simple environment where people can write tests
… but we have to organize how we will get implementers to run our tests, and how they report back to us
… we have a few implementers here

Ben Schroeter: Pearson’s systems don’t really expose epubs, they go to VitalSource etc.

Ivan Herman: okay, so we can talk to VitalSource
… the big question is what happens for Apple and Amazon
… someone could of course run our tests through the Apple RS, but maybe its a little unfriendly to report results without them saying so?

Dave Cramer: no, I don’t think so. They are a public UA.

Ivan Herman: okay, but I think we should try to get them to participate on their own

Dan Lazin: as we go along and write tests, I think it would be helpful to have a way to log whatever tests as part of the test development process
… being able to share those preliminary results might help convince people to participate (who otherwise wouldn’t)

Brady Duga: this is different from the way we’ve done testing in the past. We’re just trying to find two positive test results. (i.e. two implementations)

Ivan Herman: well, the report at the end will expose whether each UA passes or fails each test

Dan Lazin: I was thinking that maybe the tool could show that table in a state of partial completeness (i.e. update as more results become reported)

Brady Duga: have we communicated at all with Apple? Trying to get a sense of where Apple is on all this.

Dave Cramer: I’ve emailed Tess and got no reply. I can try again.

Ivan Herman: Yeah, this outreach would be the sort of thing that would normally happen at TPAC

Ben Schroeter: isn’t part of the reason for testing to ensure that we’re keeping backwards compatibility, and isn’t that something UAs want?

Dave Cramer: we’d love to meet with APA at TPAC
… if there are other groups that we should be meeting with please let the chairs know

Avneesh Singh: there is a meeting with APA already. Mainly for the a11y vocabs, but not specific to epub. For publishing in general.

John Foliot: there’s a new activity at W3C over setting up registries. I believe its going to be voted on at TPAC. We want to coordinate with other groups to make sure everyone is using these vocabs.
… the APA is noticing that different groups are building out a11y vocabs that are generally the same, but with nuanced differences
… so this is going to be discussed at the upcoming meeting

Avneesh Singh: from a publishing point of view, it would be challenging to have these vocabularies in the W3C registries because so much of the ownership over these is outside W3C (ONIX, MARC, etc.)

John Foliot: right, so we’ll do our best and not let perfect be the enemy of good

2. Structural Vocabularies

See github issue #1763.

Dave Cramer: this all started on the mailing list with a chain about SSV. About the nuance between the different terms. Some are common in the publishing world, but not used outside. Over the years we’ve had questions about the SSV. And as part of the formal spec process, how do we show usage or implementation of these terms?

Ivan Herman: There are 2 different things here.
… at the moment, the way the document is written is such that the entire vocab is normative
… all the terms are normative. What this means in practice is proving that these terms are used by the community (e.g. epub authors). In analogy to traditional testing, the criteria that we had was that there should be at least two independent significant epub publishers that use that term in production.
… if there are two of these, then it is normative
… question is whether there is any probability that this test would show that the entire vocab is really normative
… my feeling is no. There are specific terms that would pass this definition of normative, but not all
… just a note that epubcheck is not a concern here as it has been changed to not flag terms in epub:type even if they are outside the SSV
… one thing we can do is make the SSV non-normative
… then it can come out of the spec, go into a registry
… but we need to determine which terms should be normative vs non-normative before we go to CR
… the other issue is whether some of the terms are vaguely defined
… but this later is an editorial job, whereas the first issue is more about process

John Foliot: i can speak to the perspective of a11y concerns. One of the issues we have to deal with in terms of WCAG is that our spec has been taken up by regulators and adopted into law
… for that reason we have to make sure that definitions are not changed on the fly, which could put people out of spec and cause legal consequences
… e.g. for micro-formats, the definitions existed on a public wiki that anyone could change. Presented legal risk for organizations relying on it.

Dave Cramer: To ivan’s point on usage of these terms, I’m optimistic. Hachette uses 80% of these terms regularly.
… problem is that very few of the terms have any effect on many UAs
… some stuff about footnotes, endnotes, and the toc
… so it doesn’t support a11y, and it doesn’t do much outside of a11y

Avneesh Singh: +1 Dave, epubtype is not for accessibility

Avneesh Singh: aria roles have taken over. Media Overlays uses some EPUB-type.

Dave Cramer: how to maintain? We’ve ported the main terms over to DPUB-ARIA
… in terms of pure epub:type, not sure

Avneesh Singh: the definite list that JF was referring to should be ARIA roles, which are fairly stable
… epub:type is not really for RS, but more for production systems
… so I think we should pull this out and put it in a registry or a WG note

John Foliot: what about a must not clause in the spec? “SSV must not be used for a11y considerations”
… I was told that SSV should not be used to replicate nav functions, but it seems that this is something that Thorium does
… so this change would deter people from misusing

John Foliot: SHOULD NOT (Ref RFC 2119)

Dave Cramer: one thing is not sure how I would test that must not, would seem to require knowing why a SSV terms was put into an epub
… I see this as a matter of educating the community

Ivan Herman: agree that MUST NOT is not appropriate here as we couldn’t test it
… but we could make the purpose of SSV much clearer in the spec, and think this should be done
… back to epubcheck thing, it seems it would do no harm to take SSV out of spec and turned into a separate note, and then we see what happens
… but there might be 1 or 2 terms that are used by RS (e.g. ‘cover’)
… so these we’d keep as normative

Avneesh Singh: we can also consider W3C registries for this

Wendy Reid: as far as i know, the only epub:type that is categorically relied upon by RS is footnote
… there are other ways for the cover to be identified

Dave Cramer: over the course of the last few revisions of epub we’ve made a concerted effort to bring in all the registries that were floating around because having them separate made spec hard to read
… i think some of those registries just ended up being not needed
… in this case its maybe not a bad idea to move the SSV away from the core spec because of its lack of utility

Ivan Herman: at present the SSV is subsection 8 of appendix D. While we are at it, we may want to take another look at all the subsections there
… try to be consistent in how we treat these

Dave Cramer: i’m wary of having some of these terms be normative, and the rest non-normative. I think this will confuse people.
… although I see the distinction

Avneesh Singh: in the pub manifest WG we’re relying a lot on Schema.org vocabs

Ivan Herman: but references to Schema.org were considered to be as strong as normative, but yes, formally its not normative
… Schema.org is on the borderline of whether something is normative by virtue of being used by so many sites

George Kerscher: we have footnote in DPUB-ARIA so i would suggest moving all of this vocab into a note, and then just recommend using DPUB-ARIA for semantics
… and not have epubcheck report on this

Avneesh Singh: just flagging that we need to maintain backwards compatibility

Dave Cramer: right, using epub:type won’t invalidate an epub. Consistent with how HTML is supposed to ignore attributes it doesn’t understand
… so little harm to allowing epub:type to continue existing in epubs
… but want to move away from using it to convey information about a11y, semantics

George Kerscher: agree

John Foliot: where would we move the SSV?

Ivan Herman: into a WG note

Brady Duga: so there would be no normative way of doing footnotes (even though they would still exist)

John Foliot: what about the proposal to have registries that would be normative even though they aren’t full spec

Ivan Herman: if we can’t test these terms then they can’t be normative

Dave Cramer: does Google Play do pop-ups?

Brady Duga: yes

Dave Cramer: based on epub:type?

Brady Duga: yes, but we also look for numbers that have <sup> around them, but excepting certain cases, etc. etc. It’s involved.

Wendy Reid: Kobo has the exact same thing

Dave Cramer: does anyone look at the DPUB-ARIA vocab for this?

Wendy Reid: no

Brady Duga: no?

Wendy Reid: but it would be trivial to change over to looking for DPUB-ARIA, since we already have the logic of checking for epub:type

Dave Cramer: so could we migrate the things that rely on epub:type to refer to DPUB-ARIA?

Charles LaPierre: our Global Certified Accessible program is pushing for use of DPUB-ARIA vocab, especially for footnotes
… and we’re de-emphasizing the use of epub:type
… we’re fine if there’s duplication between EPUB and DPUB-ARIA, but we don’t require use of both vocabs

Dave Cramer: not quite ready to resolve here. Could we put the question of how to separate out the SSV to the group?

Ivan Herman: we could resolve that this is the direction we want to take with the SSV, with language to decided upon

Avneesh Singh: in epub a11y 1.0, we required both epub:type and DPUB-ARIA. But in recent revision we de-emphasized epub:type. In MO we do use epub:type, but this could be changed over time
… one thing about DPUB-ARIA is difficult to modify. Good for a11y, but might not work for publishers who rely on it for process

Proposed resolution: Explore removing the epub:type vocabulary from the specification and into it’s own note (Wendy Reid)

John Foliot: +1

Ben Schroeter: +1

Ivan Herman: +1

Matthew Chan: +1

Charles LaPierre: +1

Wendy Reid: +1

Brady Duga: +1

Murata Makoto: +1

Masakazu Kitahara: +1

Dave Cramer: +1

Aimee Ubbink: +1

Avneesh Singh: +1

Resolution #1: Explore removing the epub:type vocabulary from the specification and into it’s own note

Dan Lazin: +1

3. Custom Attributes

See github pull request #1756.

Dave Cramer: we took out the custom attributes section, but it turns out there are RS that use these
… so now we want to put it back

Dan Lazin: can we get some documentation on what exists in terms of custom attributes? So people can make use of them in their books?

Dave Cramer: we can see about including some examples

Proposed resolution: Merge PR 1756 (Wendy Reid)