EPUB 3 Working Group Telco — Minutes

Date: 2021-05-07

See also the Agenda and the IRC Log

Attendees

Present: Dave Cramer, Wendy Reid, Toshiaki Koike, Ivan Herman, Masakazu Kitahara, Matthew Chan, George Kerscher, Ben Schroeter, Tzviya Siegman, Gregorio Pellegrino, Dan Lazin, Laurent Le Meur, Ken Jones, Bill Kasdorf

Regrets: Matt Garrish

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

1. Update on FXL and Locators TFs

Wendy Reid: FXL and Locators met as usual
… FXL TF gave updates, we now have best practices doc on github
… you should start seeing PRs updating that document
… also talked about how we are going to update Daisy KB
… and some epub experiments
… we also talked about possible change to spec, possible proposal of what we could do to help FXL be more accessible (esp. in light of EUAA)
… will post explainer doc soon
… Locators TF was trying to refine use-cases this week, in terms of what we can do with CFIs, vs where a simple locator scheme might work

Ivan Herman: can you elaborate on change to which spec?

Wendy Reid: there’s a lot of discussion yet to come

Dave Cramer: essentially alternative stylesheet to provide a reflowable version of FXL content
… RS could then provide UI to switch to this alternative stylesheet
… similar to darkmode, reduced media use mode, etc.

2. is our scripting requirement normative?

See github issue #1659.

Dave Cramer: right now RS spec has non-normative section on security and privacy
… in here is where we have the statement that RS must behave as though each epub is its own origin
… but this is the cornerstone of our security model
… so should it be normative?

Ivan Herman: yes
… the question is whether putting that as a normative requirement now would create backwards compat issues for existing RS

Laurent Le Meur: for Readium, no, there will be no problem
… for other RS, not sure at all, because there is extra effort to do this
… not sure that RMSDK for example has this possibility
… if we make this normative, could this invalidate existing readers (e.g. eINK readers)?

Dave Cramer: not sure if any RS is compliant to that extent

Ivan Herman: what we can do is declare as normative today, but put it as “at risk feature” when we go to CR
… so if it turns out to create huge problems that implementations cannot handle, then we can remove it from normative section (and keep it as informative)

Dave Cramer: we already have at least one implementation
… fairly confident we can get at least one more

Laurent Le Meur: usually user storage is the issue
… and for user storage there is a simple test we can do (i.e. if one epub can store something that another reads)

Tzviya Siegman: i think Ivan’s “at risk feature” is a good process solution
… maybe also add an informative note with it to explain the history (and why we’re marking it “at risk”)

Dave Cramer: if epub 3.3 becomes REC, and there are some RS that don’t separate epubs from each other, I don’t see how that’s any different from the last 20 years
… doesn’t affect validity of epubs
… this is about what RS do, and we know that they make their own choices about what to implement
… prefer not to call this out as “at risk”

Ivan Herman: agreed. Withdrawing my earlier proposal.
… is there any serious epub out there that will become unreadable if we change to normative status?

Dave Cramer: i see backwards compatibility issue, but if that book is doing something sketchy from security POV, we don’t have to maintain compatibility for it

Ivan Herman: right, so my question is about valid epubs only

Proposed resolution: Make statement in issue 1659 normative (Wendy Reid)

Ben Schroeter: +1

Ivan Herman: +1

Tzviya Siegman: +1

Toshiaki Koike: +1

Wendy Reid: +1

Masakazu Kitahara: +1

Dave Cramer: +1

Matthew Chan: +1

Bill Kasdorf: +1

Dan Lazin: +1

Gregorio Pellegrino: +1

Resolution #1: Make statement in issue 1659 normative

3. mimetypes for dc:description

See github issue #1650.

Dave Cramer: the use-case here is to provide rich formatting for epub metadata in the package file
… there were various proposals on how to do this (e.g. escaped markup, markdown)
… but I have concerns about all of these
… they increase burden on RS to parse info out of package file
… plus, we already have an alternative to this via linked metadata
… and few RS use metadata other than title and author, not overwhelming demand

Laurent Le Meur: Atom provides the ability to do this
… but the results are often poor

Ivan Herman: See Atom syndication format

Dave Cramer: book descriptions in our ONIX feed use escaped markup
… once found something that was nested 37 level deep, found javascript fragment, found OpenOffice XML fragments
… very messy

Bill Kasdorf: in the trade book side of things, its not comment to embed things in metadata
… although it does tend to happen in other areas of publishing
… perhaps we can leave this to a successor format to epub
… e.g. in educational publishing, Macmillan wasn’t even familiar with ONIX

Ivan Herman: for those areas of publishing, would linking to metadata be acceptable?
… that is what we have today

Bill Kasdorf: if that publisher’s ecosystem supports that, then yes

Ivan Herman: the only minor thing that came up is that if we say we prefer the linked element solution, then we may want to add ability to use link to more elements

Dave Cramer: i’m also not aware of a RS that supports linked metadata elements

George Kerscher: what about where the book is ingested and that link is used to provide information about that book
… its not the RS itself that is using that link, but the link is being used elsewhere in supply chain
… does that pass our implementation test?

Dave Cramer: I think so, but I’m not aware of this happening

Laurent Le Meur: from what i heard, epub metadata is not used in ingestion, they use mostly ONIX

Wendy Reid: some epub metadata is used on ingestion, e.g. epub 3 vs 2, FXL vs reflow
… generally identification and classification of the type of epub

George Kerscher: VitalSource uses epub metadata, RedShelf uses it, CG is working on ways to expose epub metadata, we’re working with libraries (EBSCO, Proquest) to expose it

Tzviya Siegman: our research showed that the field that was used most was the identifier, and that was used to correlate to ONIX, for example
… covers were extracted, sometimes the author field
… as far as linked metadata, I was proponent, but we’re not seeing that used in real world right now, even in scholarly

Bill Kasdorf: all GCA certified publishers are putting accessibility metadata in their epubs

Dave Cramer: agreed that metadata in epubs are useful, but not sure that we should complicate that metadata

Tzviya Siegman: +1 dauwhe

George Kerscher: Micah Bowers is working on a way to create citations and bibliographic references, and that work depends on the metadata in epubs

Ivan Herman: so it seems the WG is not in favour of complicating the way we do metadata in epubs, with the exception of maybe adding a new relationship

Wendy Reid: the new relationship piece can be a new issue or PR, i think

Proposed resolution: Close issue 1650, add new property to linked relationship (Wendy Reid)

Ivan Herman: +1

Ben Schroeter: 0

George Kerscher: +1 add the relationship, then close

Laurent Le Meur: +1 to close, 0 for a new link

Toshiaki Koike: 0

Dan Lazin: 0

Bill Kasdorf: 0

Masakazu Kitahara: 0

Tzviya Siegman: can we clarify what we are adding?

Dave Cramer: https://w3c.github.io/epub-specs/epub33/core/#app-link-vocab

Tzviya Siegman: +1

Dave Cramer: little afraid that this will open a can of worms with other people wanting their own vocab added

Dave Cramer: +1 to close issue, -1 on new link relation

Proposed resolution: Close issue 1650 (Wendy Reid)

Wendy Reid: +1

Dave Cramer: +1

Matthew Chan: +1

Laurent Le Meur: +1

Ivan Herman: +1

Ben Schroeter: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Gregorio Pellegrino: +1

Bill Kasdorf: +1

Resolution #2: Close issue 1650

Ivan Herman: should I come up with separate PR about the new relationship?

Dave Cramer: a new issue, i think, where we can further discuss it

4. Validation of SVG

See github issue #1323.

Dave Cramer: this is the question of how to validate SVG, given that there are so many kinds of SVG
… DTDs in SVGs interact poorly with existing validation tools

Ivan Herman: first, the DTD problem has been settled
… second, currently what we do, like with HTML, is that our references in the spec are to SVG2
… which is what validator.nu validates against
… so it seems like events may have dictated the way that we go

Dave Cramer: perhaps we should postpone this issue to a later call, we are missing some members today

Ivan Herman: +1

Gregorio Pellegrino: +1

5. OCF Document: RFC3986 or RFC3987?

See github issue #808.

Dave Cramer: basically the question is generally how we define URLs in our spec
… essentially how URLs work on the web is determined by the WHAT-WG

Ivan Herman: +1

Dave Cramer: if we change our spec to refer to that instead of these RFCs then we are better off

George Kerscher: Agree to getting closer to the current web

Proposed resolution: Use the WHATWG URL specification instead of the RFCs (Wendy Reid)

Ivan Herman: +1

Wendy Reid: +1

Matthew Chan: +1

Toshiaki Koike: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

George Kerscher: +1

Ben Schroeter: +1

Dave Cramer: +1

Tzviya Siegman: +1

Dan Lazin: +1

Gregorio Pellegrino: +1

Resolution #3: Use the WHATWG URL specification instead of the RFCs

6. AOB?

Ivan Herman: i was looking at the list of changes on epub 3.3, and i think the spec is way way better today than it was in 3.2
… but nobody in the community knows about this spec at the moment
… wonder if there is a way to draw epub community to our work
… ask them to pay attention to what we’ve produced so far

Tzviya Siegman: https://docs.google.com/spreadsheets/d/1Jx5VvkMTQ4EL0Xfb3pDMDUiccq79mmIPHetSRfbziFM/edit?usp=sharing

Tzviya Siegman: i sent an email the other day about videos for the community
… we’re looking for people to do short presentations
… maybe one video could be able our changes to the spec

Dave Cramer: i’m wondering if now is the time for a communication like this vs when we reach CR
… we could then fold in some of the testing work
… we’re going to need participation on running the tests
… we could then explain difference between what happened before between IDPF and CG, vs what is now happening with the WG

George Kerscher: i’m doing presentations soon (IMS, etc.) and can include references to this spec work if the group wants

Ivan Herman: yes, agree to inclusion in the upcoming conferences
… i don’t think communication now excludes future communication at CR stage
… CR stage is for when the spec design is done, in that regard, having communication earlier may avoid issues at that late stage
… although I don’t expect major issues to be raised

Dave Cramer: we’ve also made tremendous strides in recent weeks on closing issues

George Kerscher: i don’t know how to explain to someone that they should embrace epub 3 now, but also tell them that the epub 3.3 spec is much clearer
… can i say that there is complete backwards compatibility?

Ivan Herman: yes

Bill Kasdorf: another reason for having people outside the group reading the spec is to surface things that they don’t understand

Ben Schroeter: the transition from IDPF to W3C is a significant thing to mention to outside parties, even if we don’t get into the specifics of how the spec has changed

Dave Cramer: okay, thank you everyone, we’ll see you next week!

7. Resolutions