EPUB 3 Working Group Telco — Minutes

Date: 2021-01-07

See also the Agenda and the IRC Log

Attendees

Present: Toshiaki Koike, Wendy Reid, Matthew Chan, Masakazu Kitahara, Marisa DeMeglio, Shinya Takami (高見真也), Ben Schroeter, Karen Myers, Garth Conboy, Brady Duga

Regrets:

Guests:

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

Wendy Reid: welcome back everyone.
… today we have 3 open issues that weren’t finished during the last meeting.
… these are either older, or ones which came up during testing.

1. Clarify language tag values.

See github issue #1325.

Wendy Reid: there’s an open issue in epubcheck repo re. dc:language, specifically, whether it has to be well formed or valid.
… currently we require one conforming dc:language value in the OPF.
… some earlier discussion resulted in conclusion that well formed dc:language value wasn’t of great use.
… this is in line with other specs.
… by well formedness, we are referring to bcp47.

Garth Conboy: is there a specific proposal?.

Wendy Reid: Matt didn’t come up with new language.
… but the gist, i think, was to drop the MUST to a SHOULD.

Ben Schroeter: is it a should in LTLI?.

Wendy Reid: yes, and the idea is to align with that language.

Ben Schroeter: there are a11y implications to this change….

Wendy Reid: currently epubcheck doesn’t check the value of dc:language, only that you have one.

Ben Schroeter: and under a SHOULD, epubcheck functionality would remain the same.

Garth Conboy: I thought that a SHOULD meant that epubcheck would only throw a warning?.

Wendy Reid: acknowledge point about a11y, but the a11y guideline could be updated to require a valid bcp47 language declaration.
… RS also has some part to play in this, as it may or may not honor the language attribute value, vs preferring what the ONIX says, etc..
… clarifying the issue in epubcheck, the open issue is that epubcheck does not validate the content of the dc:language, only that it is present and is well formed.
… and making this a SHOULD in our spec would not change that behaviour in epubcheck.

Brady Duga: reviewing what the spec actually says.

Wendy Reid: so the spec actually doesn’t make a reference to “well formedness”, only “valid”.

Marisa DeMeglio: reviewing Matt’s comments on this issue.
… reviewing the epubcheck codebase, there are checks for both MUST assertions and SHOULD assertions.
… so I think Garth_ is right about the epubcheck warning.
… so if we change the spec to say SHOULD, epubcheck would be expected to throw a warning, not an error; but really it doesn’t change the amount of work required for epubcheck, so even a SHOULD could be unrealistic..

Wendy Reid: as opposed to the current behaviour, where it throws an error only if dc:language is missing completely.
… and does nothing otherwise.

Ben Schroeter: we should clarify what Matt is advocating here: either 1) downgrading from MUST to SHOULD, or 2) removing it completely.

Wendy Reid: I think we should give authors something to work with, rather than being silent, but maybe Matt should come up with the specific revision to the spec.

2. Missing conformance criteria around item properties.

See github issue #1422.

Wendy Reid: essentially, the content side of the spec says that authors must set the scripted property on items, but there’s no equivalent language in the RS side of the spec.
… no prescribed behaviour for what RS should do if the property is missing.
… applies to other properties, but scripting is a good example of this discrepancy.
… can either leave the RS spec as is, or we can add some language to prescribe behaviour if this is important.

Garth Conboy: in another discussion, about I believe MathML, I think we ended up saying that these properties are useful to RS, but not something they can absolutely rely on.

Wendy Reid: there was a suggestion in the issue that if the property is absent, the RS could in theory choose not to enable the script, but this goes against the expectations of authors is seems counter productive.

Brady Duga: i can see how RS could use the presence or absence of these properties to modify RS behaviour.
… it is not trivial to ask an RS to just look at a document and determine for itself whether it has scripts or not.
… so that’s a point in favor of leaving it.

Ben Schroeter: reviewing the differing positions as presented in the issue.
… i think the rub is whether we should require the authoring requirements have a 1-to-1 correspondence to the RS requirements.
… and i don’t think we’ve done that.

Wendy Reid: leaning towards leaving it as is.
… with the proviso that we can come back to this after we have the larger discussion about scripting.

Proposed resolution: Close #1422, leaving the language in the content document as is. (Wendy Reid)

Shinya Takami (高見真也): +1 to leave it as is.

Ben Schroeter: +1.

Garth Conboy: +1.

Ben Schroeter: +1.

Brady Duga: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

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

Wendy Reid: +1.

Masakazu Kitahara: +1.

Resolution #1: Close #1422, leaving the language in the content document as is.

3. The default value of rendition:flow.

See github issue #1313.

Wendy Reid: this came up during testing.
… rendition:flow is a property by which an author can determine if pagination style is scrolled, paginated, or auto.
… if the RS supports it.
… the issue is that the spec says that the default value is auto, and that the RS may choose to support only the default.
… since auto means that its basically the RS’s choice, does this make the assertion untestable?.

Brady Duga: i think this is solved by saying that the default is auto, period..
… with the understanding that if authors are not explicit, then they get default functionality.

Wendy Reid: to clarify, W3C says any time we make a MUST statement, the assertion must be accompanied by a test.
… or, the statement shouldn’t be MUST.
… if this results in something untestable, we’re going to run into issues later.

Ben Schroeter: or change MUST to SHOULD?.

Garth Conboy: that would only mean that the RS SHOULD do whatever it wants. It works around the W3C’s testability requirement, but doesn’t make much of a functional difference.

Proposed resolution: Change the language for rendition:flow to define the default is auto, but remove the MUST statement/ untestable assertion. (Wendy Reid)

Garth Conboy: +1.

Matthew Chan: +1.

Ben Schroeter: +1.

Toshiaki Koike: +1.

Brady Duga: +1.

Wendy Reid: +1.

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

Masakazu Kitahara: +1.

Resolution #2: Change the language for rendition:flow to define the default is auto, but remove the MUST statement/ untestable assertion.

4. FXL Accessibility.

Wendy Reid: how do we want to tackle this? There are options. We could form a taskforce that meets separately. Or we can continue to just open issues and log PRs. Or dedicate upcoming meeting time to talk about this..
… I’m leaning towards task force, though this would place additional scheduling burden on task force members to meet on their own.

Ben Schroeter: even if we do open issues and PRs, at some point we’ll have to talk about those issues as a group.
… especially regarding the more hotly debated issues.

Wendy Reid: right now there are three main approaches to a11y.
… explore the extent of svg.
… clearer language about implementing multiple modalities.
… the most pie in the sky option, some kind of overlay that creates a layer specifically for a11y technologies, maybe involving audio.
… people could explore these options on their own, and report their findings back to the main group.

Ben Schroeter: maybe we could start running these discussions in the main group, and then breaking out to a task force once we’ve decided on a more concrete direction?.
… or after we decide that we need a compromise of the 3 directions.

Wendy Reid: yeah, perhaps the a11y approach might depend on the type of content.

Ben Schroeter: aside there was a very interesting accessible ebook example presented at AHG recently.
… maybe some ideas for directions to explore there.

5. AOB?.

6. Resolutions