Publishing Working Group Telco — Minutes

Date: 2018-08-20

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Avneesh Singh, Jeff Buehler, Tzviya Siegman, Gregorio Pellegrino, Wendy Reid, Jasmine Mulliken, Dave Cramer, Chris Maden, Rachel Comerford, Murata Makoto, Romain Deltour, Vladimir Levantovsky, George Kerscher, Luc Audrain, Zheng Xu, Benjamin Young, Deborah Kaplan, Bill Kasdorf, Franco Alvarado, Joshua Pyle, Evan Owens, Charles LaPierre, Ric Wright, Brady Duga, Marisa DeMeglio, Hadrien Gardeur, Derek Jackson, Jun Gamou, Jean Kaplansky, Tim Cole, Ben Schroeter, Caitlin Gebhard, Laurent Le Meur

Regrets: Garth Conboy, Teenya Franklin, Wolfgang Schindler

Guests:

Chair: Tzviya Siegman

Scribe(s): Rachel Comerford

Content:

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-07-30-pwg.html

Tzviya Siegman: approving minutes
… minutes approved

Resolution #1: minutes of July 30 accepted

1. Update on new draft

Ivan Herman: we have updated the webIDL to the new version
… while doing this there were some issues that came up
… some led to minor changes to make contents more precise
… some issues are still open (ie table of contents)

Tzviya Siegman: comments?

Tzviya Siegman: so everyone is happy?

2. Implementations

Tzviya Siegman: several of you offered to begin work on implementations
… any feedback or code samples to share?

2.1. JSON schema, JS conversion

Ivan Herman: 2 things i know about
… Hadrien worked on a JSON schema for the manifest
… someof the issues around the webidl came from the JSON schema
… the other one I know about is from me, which is a look at what it means to turn the manuscript into something a js library can use
… anyone is welcome to pick this up and use it, it was meant to cross check the webIDL

Hadrien Gardeur: https://github.com/w3c/wpub/tree/master/schema

Hadrien Gardeur: I linked the JSON schema; I think it will be useful for implementations and validations
… but I still need to work on “accessibilityModeSufficient”

2.2. Problems around “accessModeSufficient”

Tzviya Siegman: any questions on accessModeSufficient?

Hadrien Gardeur: initially I had something a bit too complex; I think if I look at the WebIDL I should be able to adapt the schema

Ivan Herman: https://github.com/w3c/wpub/pull/310

Ivan Herman: we had a discussion with several people and there is a pull request which I believe implements what I understood the syntax should be
… I would like to merge this ASAP

Hadrien Gardeur: there is one difference in the IDL and the schema in the type of validation

Ivan Herman: can I merge this pull request?

Tzviya Siegman: not enough people on the call are familiar with this to decide if we can merge

Avneesh Singh: the main issue was comma separated strings in the epub world (to fit in epub opf structure)
… the final example had a nested list structure
… and we should propose this list to schema.org as well

Ivan Herman: who proposes this to schema.org?

Tzviya Siegman: so there is an existing definition in schema.org
… what are we doing in our spec?

Ivan Herman: there was a long discussion in the schema.org github issue about what would be the final representation. The JSON examples posted to schema.org don’t actually align with what was agreed to in that description

Ivan Herman: it is an array of text, with a comma separated texts each, in WP

Ivan Herman: what I put in WP is in line with what schema.org agreed to, but schema.org has not yet corrected their samples

Ivan Herman: https://pr-preview.s3.amazonaws.com/w3c/wpub/pull/310.html#accessibility

Tzviya Siegman: any other comments about this pull request?
… are we ok to merge?

Rachel Comerford: +1

Tim Cole: +1

Luc Audrain: +1

Jeff Buehler: +1

Ivan Herman: +1

Joshua Pyle: +1

Gregorio Pellegrino: +1

Resolution #2: merge PR #310

Tzviya Siegman: ivan, go ahead and merge

Avneesh Singh: Regarding previous topic, the link to original schema.org discussion about accessModeSufficient

Avneesh Singh: https://github.com/schemaorg/schemaorg/issues/1100

2.3. other implementations?

Franco Alvarado: we’re doing a ‘frankenepub’ based WP

Rachel Comerford: frankenepub is a collection of textbook content

Hadrien Gardeur: Comment about our work from an audiobook distributor: https://twitter.com/Luisterhuis/status/1030776054665895936

Tzviya Siegman: friends from Kobo?

Rachel Comerford: Wendy Reid, I did talk to people here about what work it would take to implement. They thought it would be easy to implement with FXL and DRM as potential issues.

Tzviya Siegman: DRM is specifically out of scope

Tzviya Siegman: Josh what about atypon?

Joshua Pyle: I focused primarily on what will be discussed next month in Japan - FXL
… we’ve had some discussions about author and publisher hints for systems to use
… I’ve written a set of user stories around this as well
… it’s a delicate line to say on one hand we want to give authors and publishers freedom to layout however they want to but also give reading system freedom for how they want to display to users

Tzviya Siegman: we do have a spot in github for posting code
… can someone post the link?

Ivan Herman: https://github.com/w3c/wpub/tree/master/experiments

3. Updates on Use Cases and integrating into spec

Tzviya Siegman: Josh, how are yours coming

Joshua Pyle: there’s been some discussions about fixed layout as an issue
… I merged locally, should I make pull requests to the master or merge every time?

Ivan Herman: I do branches on my local clone when I have a bigger topic, and make a PR from there directly in the repo. You are the editor, you dictate the granularity…

Tzviya Siegman: call for new use cases

4. Canonical Manifest

Tzviya Siegman: https://pr-preview.s3.amazonaws.com/w3c/wpub/pull/306.html#canonical-manifest

Tzviya Siegman: ivan, can I ask you to give an overview

Ivan Herman: this is a relatively major thing
… we are looking for the next logical step in the spec which is the lifecycle section
… this is out of sync
… how do I describe and specify the elements
… we inherited great flexibility from schema.org and the need to make authoring easier the manifest in JSONLD
… I can have a name but the value of the name can be an array (ie, the name in many languages), strings instead of, e.g., Person objects, simple strings instead of language-marked localizable strings, etc.
… the goal is to make this simple for the authors.
… But it makes implementations a bit more complex. What we propose is a canonical version of the JSON manifest, and a precise procedure to convert a manifest into it, that relieves all ambiguities. This increases interoperability of implementations.

Ivan Herman: the PR defines the transformation steps to generate a canonical manifest
… I have an implementation that uses the transformation as a proof-of-concepts

Tzviya Siegman: I think anything written in this algorithmic style is confusing

Deborah Kaplan: tzviya ++

Tzviya Siegman: are we creating this algorithm so we have data that can be useable by systems? I am confused about the why and how of this.

Ivan Herman: we could specify exactly what the canonical manifest looks like - make it explicit that you can have a string, an object…
… this is already there as part of the manifest definition
… what the algorithm does is to define the steps to generate the canonical version of the manifest
… if you want to implement this - take the manifest of a user and digest it in your environment - this must be done somewhere
… this makes it easier to produce the wpub to the specification with explicit directions and increased interoperability

Luc Audrain: +1 to interoperability

Juan Corona: +1 I like what i’m hearing

Benjamin Young: thanks ivan, I’m guessing this is a pre-req to any implementation?

Ivan Herman: yes

Benjamin Young: and this is a reflection of the way we shaped the manifest?

Ivan Herman: we made the manifest flexible, this gives shape to the requirement

Ivan Herman: one more thing not in the PR; there are some diagrams in the spec that I made because Rachel made me do it
… these need to be updated at some point

Zheng Xu: can any provide an example of the result of the transformation or JSON data structure example that could give us a more clear image about what Canonical Manifest looks like?

Ivan Herman: I will add references to examples

Zheng Xu: +1

Tzviya Siegman: shall we merge?

Luc Audrain: +1

Gregorio Pellegrino: +1

Joshua Pyle: +1

Tim Cole: +1

Rachel Comerford: 0 but only because I need pictures

Rachel Comerford: lol

Tzviya Siegman: consensus to merge

Resolution #3: merge PR #306

Ivan Herman: I will merge this then add examples

5. Issue 291 - TOC issues

Tzviya Siegman: https://github.com/w3c/wpub/issues/291

Tzviya Siegman: do we need a more detailed TOC description? In EPUB the nav document was the structured machine readable TOC as well as the visual.
… some people used it as the visual but others would create a standalone TOC as well
… should the machine-readable TOC be more stylized?
… will that hamper accessibility? machine readability?

Dave Cramer: do you have examples of the external TOC structure?

Laurent Le Meur: exemple of a graphical ToC : https://about.canva.com/wp-content/uploads/sites/3/2016/11/table-of-contents-.png

Dave Cramer: are we conflating brief TOC and actual content?
… are we basically going back to epub2 with an NCX
… I’m concerned we’re undoing work from epub3

Tzviya Siegman: +1 to dave’s concerns

Ivan Herman: the current spec is silent on this

Luc Audrain: -1 to Dave’s concern, sorry

Ivan Herman: my feeling is that WP does not need to make any additional statement about this

Brady Duga: Garth isn’t here, so I’m going to speak for him
… everyone gives us an NCX and NAV
… I don’t think it would be impossible for those books to make a machine readable TOC

Tzviya Siegman: the navigation is what makes the WP more accessible

Hadrien Gardeur: let’s agree to disagree then, I don’t think EPUB3 truly succeeded in creating something that’s good for both rendering and machine readable use cases

Bill Kasdorf: +1 to rachel: complex navigation is part of the content (it actually often has text, explanation, enrichment) that would not be in a <nav>

Ivan Herman: the manifest contains the reference to the resource where the TOC is but it doesn’t require any structure
… it doesn’t even require TOC presence
… do what you want with what you find there

Tzviya Siegman: let’s continue this discussion next week

Tzviya Siegman: we should also discuss Issue 276 (Can TOC refer to items outside of default reading order)

6. TPAC F2F

Tzviya Siegman: remember it is also time to talk about TPAC
… ivan has opened a google doc for suggestions

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

George Kerscher: I signed up and there are several other meetings (like MathML) - should we make a plan about how to represent publishing in these relevant meetings?

Ric Wright: Tzviya can’t be in two places at once? How disappointing…

Tzviya Siegman: thanks all
… read github!

Rachel Comerford: Bye!

7. Resolutions