Meeting minutes
<ivan> Date: 2021-08-13
<dlazin> thanks, Ivan :)
dauwhe: welcome back everyone
Welcome back
dauwhe: 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: yes
wendyreid: 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: 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
BenSchroeter: Pearson's systems don't really expose epubs, they go to VitalSource etc.
ivan: 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?
dauwhe: no, I don't think so. They are a public UA.
ivan: okay, but I think we should try to get them to participate on their own
dlazin: 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)
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: well, the report at the end will expose whether each UA passes or fails each test
dlazin: 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)
duga: have we communicated at all with Apple? Trying to get a sense of where Apple is on all this.
dauwhe: I've emailed Tess and got no reply. I can try again.
ivan: Yeah, this outreach would be the sort of thing that would normally happen at TPAC
BenSchroeter: isn't part of the reason for testing to ensure that we're keeping backwards compat, and isn't that something UAs want?
dauwhe: 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
avneeshsingh: there is a meeting with APA already. Mainly for the a11y vocabs, but not specific to epub. For publishing in general.
JF: 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
avneeshsingh: 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.)
JF: right, so we'll do our best and not let perfect be the enemy of good
Structural Vocabularies
<ivan> scribejs, issue 1763
<Aimee> + present
dauwhe: 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: 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
ivan: 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
JF: 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.
<avneeshsingh> +1 Dave, epubtype is not for accessibility
dauwhe: To ivan's point on usage of these terms, I'm optimistic. Hachette uses 80% of these terms regularly.
<avneeshsingh> aria roles have taken over. Media Overlays uses some EPUB-type.
dauwhe: 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
… how to maintain? We've ported the main terms over to DPUB-ARIA
… in terms of pure epub:type, not sure
avneeshsingh: 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
<Zakim> JF, you wanted to ask about a MUST NOT clause there Dave
avneeshsingh: so I think we should pull this out and put it in a registry or a WG note
JF: 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
<JF> SHOULD NOT (Ref RFC 2119)
dauwhe: 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: 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
<avneeshsingh> we can also consider W3C registries for this
wendyreid: 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
dauwhe: 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: now, 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
dauwhe: 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
avneeshsingh: in the pub manifest WG we're relying a lot on Schema.org vocabs
ivan: 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: 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
avneeshsingh: just flagging that we need to maintain backwards compat
dauwhe: 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: agree
JF: where would we move the SSV?
ivan: into a WG note
duga: so there would be no normative way of doing footnotes (even though they would still exist)
JF: what about the proposal to have registries that would be normative even though they aren't full spec
ivan: if we can't test these terms then they can't be normative
dauwhe: does Google Play do pop-ups?
duga: yes
dauwhe: based on epub:type?
duga: yes, but we also look for numbers that have <sup> around them, but excepting certain cases, etc. etc. It's involved.
wendyreid: Kobo has the exact same thing
dauwhe: does anyone look at the DPUB-ARIA vocab for this?
wendyreid: no
duga: no?
wendyreid: but it would be trivial to change over to looking for DPUB-ARIA, since we already have the logic of checking for epub:type
dauwhe: so could we migrate the things that rely on epub:type to refer to DPUB-ARIA?
CharlesL: 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 it
… s/require it/require use of both vocabs
dauwhe: not quite ready to resolve here. Could we put the question of how to separate out the SSV to the group?
ivan: we could resolve that this is the direction we want to take with the SSV, with language to decided upon
avneeshsingh: 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
<wendyreid> Proposed: Explore removing the epub:type vocabulary from the specification and into it's own note
<JF> +1
<BenSchroeter> +1
<ivan> +1
+1
<CharlesL> +1
<wendyreid> +1
<duga> +1
<MURATA> +1
<MasakazuKitahara> +1
<dauwhe> +1
<Aimee> +1
<avneeshsingh> +1
Resolution: Explore removing the epub:type vocabulary from the specification and into it's own note
<dlazin> +1
Custom Attributes
<ivan> scribejs, pr 1756
dauwhe: 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
dlazin: can we get some documentation on what exists in terms of custom attributes? So people can make use of them in their books?
dauwhe: we can see about including some examples
<wendyreid> Proposed: Merge PR 1756
<dauwhe> +1
<wendyreid> +1
<dlazin> +1
+1
<ivan> +1
<CharlesL> +1
<BenSchroeter> +1
<duga> +1
<MasakazuKitahara> +1
Resolution: Merge PR 1756
dauwhe: okay, thanks everyone!