EPUB 3 Working Group Telco — Minutes

Date: 2020-10-09

See also the Agenda and the IRC Log

Attendees

Present: Dave Cramer, Gregorio Pellegrino, Avneesh Singh, Laura Brady, Ivan Herman, Matthew Chan, Wendy Reid, Masakazu Kitahara, Tzviya Siegman, Ben Schroeter, Laurent Le Meur, Brady Duga, Charles LaPierre, George Kerscher, Matt Garrish, Bill Kasdorf, Hadrien Gardeur, Yu-Wei Chang (Yanni), Garth Conboy

Regrets: Zheng Xu (徐征), Daihei Shiohama (塩濱大平), Jun’Ichi Yoshii, Toshiaki Koike

Guests:

Chair: Wendy Reid

Scribe(s): Dave Cramer, Wendy Reid

Content:

Wendy Reid: let’s get started
… welcome to this week’s episode of EPUB 3 WG
… we have a couple of new members

1. introduction of new members

laura: Laura Brady from House of Anansi
… I want to work on FXL a11y
… I’ve been working on EPUB forever
… I organized ebookcraft

Bill Kasdorf: You just got GCA certification from Benetech!

Laurent Le Meur: this is my first WG meeting
… I’m CTO of EDRLab
… we are implementing EPUB everywhere

Wendy Reid: we’re gonna deal with some open issues today

2. #645, adding OPUS as core media type

Wendy Reid: https://github.com/w3c/publ-epub-revision/issues/645

Wendy Reid: we’ll talk about a few media types issues
… this is related to Ogg and Vorbis
… it’s supported in browsers
… so we hope adding it for reading systems is not difficult
… but we do want to get feedback from implementors

George Kerscher: Any issues with seeking in opus? going to a particular place?

Wendy Reid: a good question

Hadrien Gardeur: not that i’m aware of. We use it for streaming

George Kerscher: that’s been one of the difficult problems with other codecs

Garth Conboy: as long as we’re not on a slippery slope of adding core media types… this one is really useful for a11y community

Wendy Reid: any other comments? Experience with opus?

Brady Duga: what is the actual proposal? A general OPUS proposal? or specifically OGG?

Wendy Reid: looking…

Brady Duga: opus is the codec, ogg is the container
… my recollection is that ogg is not supported on iOS

Hadrien Gardeur: you are asking for feedback about opus in general
… we’ve been using it as our default codec, with ogg, for streaming
… it works well
… you can target file size and bitrate
… it
… but we have to fallback to AAC or MP3 for iOS
… which is a shame
… they fixed webp in iOS14, but not OGG

Wendy Reid: checking caniuse…

Avneesh Singh: https://caniuse.com/opus

Wendy Reid: widely supported with the exception of iOS
… needs to be packaged for iOS

Ivan Herman: from a formal w3c sense
… it is perfectly possible to add now ogg as a media type
… and if during the CR phase, we can mark “at risk” and possibly remove if there’s not enough support
… CR is not for a year at least
… we can add a note to the spec warning the reader about this issue

Avneesh Singh: I was thinking the same as Ivan
… Opus is used so much in webrtc
… it’s hard to imagine safari will not support soon
… we had the same issue in 3.2
… so +1 to add now

Brady Duga: I’m impressed by Avneesh’s optimism
… I’m fine adding this with an explicit note
… we’ll just transcode in our implementation

Charles LaPierre: I thought that we only required two implementation for REC

Brady Duga: “at least 2”, “not only 2”

Tzviya Siegman: +1 dauwhe_

Wendy Reid: dauwhe_: If we are going to make a change it needs to be universally usable, 2 implementations is the W3C minimum, but we have a higher requirement to meet

Wendy Reid: … we would be fragmenting EPUB

Matt Garrish: the core media types are a higher bar than w3c’s rec process
… core media types are meant to be relied on by publishers
… it’s OK as long as we have a note saying we need better support

Avneesh Singh: In EPUB 3.1 even android support was an issue.

Hadrien Gardeur: you can support OPUS in iOS, but you don’t get it for free
… you’ll just have to jump through some additional hoops
… it’s still easier than pagination

Wendy Reid: there are ways around this

Proposed resolution: Add the media-type for OPUS/OGG to the core media types (address issue #645) (Wendy Reid)

Wendy Reid: I think we’re good as long as we supply some context

Bill Kasdorf: +1

Laura Brady: +1

Brady Duga: +1

Matt Garrish: +1

Hadrien Gardeur: +1

Matthew Chan: +1

Ivan Herman: adding to proposal that a note should be added to the doc

Masakazu Kitahara: +1

George Kerscher: +1

Avneesh Singh: +1

Ben Schroeter: +1

Proposed resolution: Add the media-type for OPUS/OGG to the core media types (address issue #645) with a note explaining the exception for Safari (Wendy Reid)

Gregorio Pellegrino: +1

Charles LaPierre: 0

Garth Conboy: +1

Ivan Herman: +1

Resolution #1: Add the media-type for OPUS/OGG to the core media types (address issue #645) with a note explaining the exception for Safari

Tzviya Siegman: +1

3. #1323, validation of SVG

Wendy Reid: https://github.com/w3c/publ-epub-revision/issues/1323

related: https://github.com/w3c/epubcheck/issues/1172

Wendy Reid: SVG documents with DTD declarations cannot pass EPUBCheck, which is problematic
… most people don’t hand-code SVG; tools insert the DTD

Ivan Herman: AFAIK, the same problem exists with MathML
… both MathML and SVG, the DTDs use modularization; the DTDs are full of entities; somewhere else we say DTDs are not to be used
… this is the point where these collide

Brady Duga: raises eyebrows expressively
… we’re talking about DTDs
… I don’t see a DTD in this failing SVG

Bill Kasdorf: is it just a DTD declaration?

Brady Duga: I think EPUBCheck is validating against some schema and failing
… I don’t think it’s only an issue of DTDs?

Ivan Herman: I don’t know what SVG you are looking at
… what I hit, and there is a trace in the EPUBcheck issue
… it complains about external entities being used
… so if SVG doesn’t have DTD, EPUBCheck ought to accept it (see also epubcheck issue)

Brady Duga: that’s the issue

Brady Duga: https://github.com/w3c/epubcheck/issues/1172

Garth Conboy: there are two failure cases in this world

Laurent Le Meur: EPUBCheck validates the HTML; was there a decision to validate SVG and MathML?
… is it a previous decision, or a grey area?

Ivan Herman: what they said is they do what’s in the standard

Matt Garrish: we got mixed up in issues
… the DTD issue is something else
… Garth opened an issue with epubcheck
… about the rel attribute on
… we take schemas from validator.nu
… and they don’t implement SVG2 validation
… so that raised the issue of SVG validation–should we do it at all?
… duga mentioned we lost a requirement when we gave up our own SVG reference
… there’s two parts: 1. what should epubcheck be doing? should we differ from validator.nu?
… should we say we support SVG2 in the same way the web does?

Garth Conboy: one could look to what we do with png and jpeg; we don’t validate those, and SVG is an image type
… we only had a hundred books with a problem, we could get rid of @rel
… but if this content keeps coming in… almost all SVGs are mechanically authored

Brady Duga: 1. Should we add back validity? 2. If yes, how do we phrase it? 3. If no, should epubcheck validate by default?

Garth Conboy: I’d like to hear other opinions. Is svg a black box?

Brady Duga: @rel is an interesting case
… there was a fill that works everywhere but isn’t allowed in SVG 1.1
… we don’t have validity in SVG right now
… how could we say we require validity while the spec evolves? Which schema? is it a live schema?
… should epubcheck be checking for validatity by default? I think no.
… it’s not required by the spec

Tzviya Siegman: I agree with brady that epubcheck shouldn’t check for things in the spec
… this is more like CSS than other image types
… EPUBcheck does little with CSS
… since there are tools that check svg, we have options whether to use them
… I don’t think we should build additional tools to check SVG
… and we have to pay for anything we do with EPUBCheck

Tzviya Siegman: https://inclusivepublishing.org/epubcheckdonate/

Tzviya Siegman: let’s not build an SVG validator

Avneesh Singh: tzviya read my mind :)
… EPUBCHeck maintenance is additional work
… the more we increase the demand on EPUBCheck, it becomes more difficult to maintain
… we can reduce overhead of HTML by migrating to the HTML validator in the future
… but if we have to keep updating schema inside EPUBCheck for each spec, that’s too much overhead.

George Kerscher: I want to emphasize the importance of SVG for people with low vision
… it’s an important issue; RSs need to deal with the spec properly
… we see interactive SVG applications, like exploration of chemical molecules
… it has to run the same way on various platforms
… I don’t know how images are validations; I think we use the same expectations

Ivan Herman: i wonder about one thing
… SVG is an image file, but it’s also an XML file
… I think we require XML validity for all our docs
… the DTD problem comes from that

Matt Garrish: the DTD problem comes from XML requirements that you can’t have an external entity set
… it comes up for NCX, for SVG…
… they get errors
… we look at this validity question. Is it just images, or XHTML?
… we’ll have SVG inside of HTML. Do we validate that?
… is there broader application of leniency?

Charles LaPierre: you could have SVG as an image file, brought in, vs. inline SVG in HTML
… would checker ignore both?

Brady Duga: if XHTML docs have to be valid, they have to be valid.
… if you have a base64png in the doc, it still has to be valid
… we don’t have a validity requirement anymore in EPUB. We deleted them.
… one could argue this is a step towards our Great HTML Future (tm)
… if we want validity checking, we have to put it in
… today we don’t actually require XML validity

Wendy Reid: should we put aside as we clarify some more of the HTML future?

Laurent Le Meur: I agree with brady
… when I see that reading systems are a non-validating processors
… I don’t know how EPUBCHeck validates HTML
… maybe we should just require well-formedness

Matt Garrish: it’s validator.nu schema; it constantly changes
… it’s not even fully integrated; we just take the schemas
… even for a11y, valid HTML isn’t a requirement
… WCAG doesn’t require it

Ivan Herman: I am just a go-between
… here is the reference I got from Romain: https://www.w3.org/publishing/epub3/epub-spec.html#confreq-xml-extmarkupdecl
… any publication resource that is an XML Media type… external entities must not appear in the DTD

Wendy Reid: External identifiers must not appear in DTD

Brady Duga: AFAIK this has nothing to do with DTDs; EPUBCheck is validating is against a 1.1 schema

Ivan Herman: the standard DTDs for SVG include external identifiers
… the problem is that SVG 1.1 defines a DTD which includes external identifiers
… therefore SVG 1.1 can’t pass EPUBCheck
… same for MathML. That’s the problem

Dave Cramer: To the general question of validation, we need to think about each language individually
… HTML validation is less critical because browser error handling is well-defined
… package file validation is more important because we haven’t defined errors
… a broken package file is something a reading system would struggle with
… I don’t know where svg would fall into this

Tzviya Siegman: not sure I have much more to add
… re: a11y and SVG
… we’re being caught up in what validation means, and confusing it with requirements
… and we should talk about this with Romain
… we try to have EPUBCheck match the specification
… let’s try to shift from EPUBCheck, and talk about the spec

Ivan Herman: what it means is that we cannot put a valid SVG 1.1 into EPUB per spec

Tzviya Siegman: that’s a problem with the spec

Ivan Herman: yes

Tzviya Siegman: talking about epubcheck is a distraction

Wendy Reid: as a group we control the spec but not EPUBCheck :)

Brady Duga: I’m going to ignore ivan’s comments right now
… historical perspective on why we required XHTML validity
… in the early days of OEB, people would abuse tags to get style behaviour
… people would use <p> in <ul> to get indents
… it was a lovely way to get padding in paras, but it broke a11y
… so we required validity for that purpose
… I don’t know how much tag abuse happens because of styleing need

Bill Kasdorf: lots of people abuse tags to get stylistic behavior.

Brady Duga: but now we have CSS

Wendy Reid: all the abuse is in <span>

Matt Garrish: agreeing with brady…
… wcag has addressed a lot of those problems
… if we’re not going the validity route with SVG
… ivan’s problem is more complicated
… I don’t know why it’s a content requirement
… it’s more of an issue for reading systems

George Kerscher: to help me understand
… the external identity issue is because we don’t allow it because it’s not included in the package? And a reading system can’t get to it?

Brady Duga: yes

Matt Garrish: and there are security issues
… and you can create havoc

George Kerscher: so svg and mathml are important pieces
… could we look at what the core entity set is, and include them in the package?

Wendy Reid: george is reading my mind
… are there core external entities?
… that we trust?

Ivan Herman: the problem with the SVG DTD
… the entities that are used have nothing to do with funny characters
… it’s used for mimicking inclusion and exclusion of DTDs
… in practice, no SVG reader actually uses the DTD
… and XML processors are not obligated to read the DTD
… it’s more a way of identifying the XML vocab
… one possibility is to modify the thing… we do not accept external entities, but we just ignore the DTD
… processors are expected to ignore the DTD
… and then SVG and MathML work
… SMIL does not use this DTD modularization

Garth Conboy: what ivan said makes sense
… I think we’re OK with the spec now; that we are not requiring validation

Ivan Herman: it’s a problem with the spec

Wendy Reid: the validation of SVG is an EPUBCheck problem

Garth Conboy: the issue is that it is validating an SVG against a schema it dreamed up

Brady Duga: if we had a better SVG dtd, we would still have the same EPUBCheck problem, because @rel is not allowed on <a> in SVG 1.1.
… on top of that, we have the rule that external entities are not allowed in DTDs. But that’s a separate issue. It should be its own bug.
… if we fix your problem, my problem still exists

Ivan Herman: I’ll raise a new issue

Brady Duga: it does need to be fixed

Matt Garrish: validation of doctypes doesn’t occur
… the schema doesn’t validate the doctype

Wendy Reid: we can defer this

Brady Duga: wrapping up this issue… I don’t see an action item
… our plan is to close the spec issue, since we don’t require validity
… and request that EPUBCheck stop checking SVG docs for validity

Wendy Reid: and a new issue in EPUB about external entities

4. AOB

Wendy Reid: is there any other business for today? Questions? Comments?
… we’re working on the F2F agenda
… dealing with time zones, and how much time for each issue

Matt Garrish: can I close the ISO a11y issues?

Wendy Reid: +1

Brady Duga: +1

all: yes

Ivan Herman: +1

Matt Garrish: +1

Ivan Herman: we were discussing renaming the repo
… renaming to epub-specs

Dave Cramer: That was my concern, the repo has existed for a long time with the current name and I don’t want to break any links

Wendy Reid: I think this will help SEO

Matt Garrish: we did change the name before at the time of the merger

Ivan Herman: yea or nay?

Wendy Reid: I’ll put it to the list
… email filters are flawed creatures
… see you next week
… we have a joint meeting with APA next week 11AM Eastern next Thursday
… TPAC starts on Monday
… happy Canadian Thanksgiving

5. Resolutions