Publishing Working Group Telco — Minutes

Date: 2017-09-18

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Tzviya Siegman, Dave Cramer, Chris Maden, Avneesh Singh, Rachel Comerford, Deborah Kaplan, Luc Audrain, Ric Wright, Romain Deltour, Lillian Sullam, Garth Conboy, Marisa DeMeglio, Joshua Pyle, Tim Cole, Ben Schroeter, Bill Kasdorf, Brady Duga, josh, Jeff Printy, Charles LaPierre, Benjamin Young, Hadrien Gardeur, Leslie Hulse, David Stroup, Ben Dugas

Regrets: Vladimir Levantovsky, Peter Krautzberger, Matt Garrish, Baldur Bjarnason, Reinaldo Ferraz, Nick Ruffilo, George Kerscher

Guests: Gregorio Pellegrino

Chair: Tzviya Siegman

Scribe(s): Dave Cramer

Content:

Garth Conboy: (though largely lurking — over an hour traffic delay on bus to Ivrine this morning)

Tzviya Siegman: next week we may pre-assign scribes for TPAC

Tzviya Siegman: before we begin, we have at least one new member

ben-dugas: ben-dugas has joined #pwg

Joshua Pyle: My name is Josh Pyle, I work at atypon
… before that I founded metapress
… been in scholarly pub for two decades
… we’ve adopted an epub-first strategy, and are trying to kill PDF

Tzviya Siegman: welcome Josh
… anyone else new?

Ivan Herman: I heard Gregorio

Laurent Le Meur: Gregorio is from LIA in Italy

Ivan Herman: he’s not yet official member of the WG

Tzviya Siegman: welcome Gregorio!

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-09-11-minutes.html

Tzviya Siegman: minutes from last week’s meeting. Any comments?
… jyasskin talked about packaging

Resolution #1: last minutes are fine

Tzviya Siegman: we have a busy agenda
… will start with Marissa going over reqs for SMIL-lite

1. Requirement for SMIL Lite

Garth Conboy: “SMIL lite” == “grin”

Tzviya Siegman: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia

Marisa DeMeglio: link in GotoChat
… we’ve been looking at design reqs for syncronized multimedia

Rachel Comerford: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia

Marisa DeMeglio: allowing talking books to talk

Tzviya Siegman: can you give a quick overview?

Marisa DeMeglio: EPUB3 didn’t have a lot of problems with media overlays
… we can look at something lighter than SMIL
… we used a slim subset in EPUB3
… but SMIL adoption in the world at large hasn’t been huge
… so we can look at other formats
… we do need to link chunks of text with chunks of audio
… you still need structural semantics for navigation etc
… making video + text transcripts more accessible is a requirement
… and there are some things not included in media overlays
… I’ve been emailing with dweck
… like having multiple granularities of navigation–from para by para to word by word
… text + sign language
… video + descriptive audio
… all those are not covered by media overlays
… our next step is deciding what format to do

Garth Conboy: That multi-resolution MO approach was discussed some years ago, and I think prototyped in Readium, I think. It’s a cool idea.

Marisa DeMeglio: first question is about formats–XML or not XML

Dave Cramer: what’s the status of audio sync on the web at large?

Marisa DeMeglio: I don’t know of anything

Ivan Herman: I don’t know much more
… I love your understatement… SMIL adoption is terrible
… we will have to define a SMIL-lite which has any hope for implementation

Bill Kasdorf: is there an active SMIL WG?

Ivan Herman: we will also have to ensure there will be several implementations on top of browsers

Laurent Le Meur: I agree with Ivan when he says we’ll have to create polyfills
… if this is the case, if JS is the language that will use SMIL, then XML is not the best structure for that
… JSON has the lead, a structure JS loves
… SMIL is so complex, there are too many features
… we can track as JSON structure

Garth Conboy: Marisa is also correct, when saying MO/SMIL(lite) adoption in EPUB Reading Systems is pretty good.

Laurent Le Meur: as for the requirements, we should make sure the structure we define doesn’t prevent us from adding advanced features later

Ric Wright: one other area is where there is a SMIL implemenation is for animation of SVG
… this has been implemented by browsers

Avneesh Singh: the main objective of this work was lack of support of SMIL on the web
… and then additional things came up
… that were not covered in EPUB3 MO
… media fragments is the one thing in the web which is used
… if we can find out groups in web who are trying to solve similar problems
… we can try to do it together

Charles LaPierre: ETS and Mark Hakkinen has done lots of work with SMIL
… they might have some insight
… they use this for assessments

Tzviya Siegman: the larger group should comment about requirements
… this is not part of our charter… so what should we do with these requirements? What are next steps?

Ivan Herman: as usual, this was the topic I wanted to put on the queue
… that’s an admin problem
… this whole issue of SMIL lite is not in our charter, but is a necessary thing
… this would be rec-track work
… the traditional way to do something like this would be to form a separate CG
… that would look at an initial spec plus one or two polyfills, showing it is possible
… once the CG says we have this, it solves these requirements, it’s polyfilled, it has users
… the most obvious way would be to then form a new WG

Garth Conboy: From charter: “This specification should generally be a functional superset of EPUB 3.1. Functional round-tripping to/from EPUB 3.1 considered highly desirable.” So, would could argue it’s kinda in our charter, as it’s in EPUB 3.1.

Ivan Herman: I still believe something like SMIL is still necessary for the web, and not only for WP
… even if WP is driving this here
… the web in general would benefit
… we then could get experts from other places for a CG
… I have some colleagues in Amsterdam who worked on original SMIL
… some of them are still around; I can approach them
… but a WG would be too much for them

Tzviya Siegman: the next steps are to clean up requirements and share them
… we should pass this on to APA, and share with Janina

Ivan Herman: there are some other media-related groups, like a video group
… they might have feedback
… and outside w3c there are other groups

Marisa DeMeglio: to comment on SMIL
… DAISY was in smil WG
… we used SMIL more than anyone else, but used less of it
… our use case was really different from everyone else’s
… they used it for short presos, annotations, etc.
… we used for entire books
… I’m not sure that reawakening the SMIL group would be good
… we might look elsewhere for overlap

Ivan Herman: it’s going to be very light, very concentrated

Tzviya Siegman: it might come down to how you position it
… I can help with that

Avneesh Singh: that’s a valid point from marisa_demeglio
… we need more strength to make it an implementable standard
… we need to strike a balance for something useful for our requirements as well as for others
… that IPTV was looking for something like SMIL
… Hiroshi can be a liason
… and Mark H can also help

Tzviya Siegman: we have people volunteering to be liasons
… joanie might know who to talk about at the browsers

Avneesh Singh: I will contact Mark Hakkinen and Hiroshi Kawamura

Bill Kasdorf: I was going to ask Marisa if there is a link she can share that documents the subset of SMIL that is actually used by DAISY

Marisa DeMeglio: bill_kasdorf: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-overlays-def

Bill Kasdorf: marisa: thanks, I didn’t realize that the MO spec in EPUB 3.1 was the subset you were talking about. That’s great to know because that is what folks are actually using in the publishing world.

2. Metadata PR

Tzviya Siegman: let’s move on to the metadata pull request

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

Tzviya Siegman: Luc, could you give us an overview

Luc Audrain: just back from holiday, so I can’t give an update; I need to read some emails first :)

Tzviya Siegman: has anyone had a chance to read it

Ivan Herman: I did read it, had some discussion with Baldur
… some of us did read it
… my overall opinion is we should merge this
… this doc 1. defines some additional terms that could go into the infoset
… some are more “mays” than “shoulds”–authors publishers editors
… and 2. there’s a small section that says whatever we do, we should link out to other vocabularies (like ONIX)
… and they are external to the manifest/infoset
… merging the PR and turning some Qs into issues is good

Tim Cole: I agree with Ivan about merging to get something in there
… one Q I haven’t yet added
… are we going to have a WPUB namespace, or will be borrow things from existing standards?

Ivan Herman: can you give an example

Tim Cole: author, do we use DC or do we have our own concept of author?
… that wasn’t clear from current language

Ivan Herman: I don’t know the answer

Luc Audrain: reading the comments in the PR
… this job that Baldur did is very accurate with what we discussed
… some terms may be need more precision between may and should / must
… but it reflects our ideas

Tzviya Siegman: sounds like we should accept the PR

Garth Conboy: +1

Ivan Herman: and add some github issues

Avneesh Singh: if they need something from a11y task force, please let us know

Tzviya Siegman: I think the a11y metadata can fit right in

Luc Audrain: we created a slot for a11y metadata, but it needs to be more precise

Avneesh Singh: this is OK
… normally we talk about discovery metadata, but metadata is also good for user agent to invoke special features
… in those cases it might be a “must”

Tzviya Siegman: we can adjust after the first draft

Resolution #2: accept the PR and possibly create new issues around it into github

Luc Audrain: +1

3. Identifiers

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

Tim Cole: our current draft has 3.5 and 3.6 about canonical identifier and identifier of doc as a whole
… but we also need to talk about fragments of a WP
… do we have any premises about our approach?
… we could use the CFI approach
… but what would replace package/spine?
… I think the stronger possibility is the selectors and states approach
… a WG note from the Web annotations group
… which allows an identifier for an arbitrary part of a web resource
… is the selector and state approach OK?

Tzviya Siegman: ?

Bill Kasdorf: +1 to the selectors and states approach

Tim Cole: also, do we need to tie together things back to the web pub itself?

Ivan Herman: my only problem is that you and I know what is in that document
… but I dont think the rest of the group knows the selector note
… perhaps you could give an overview at some time

Tim Cole: there are various ways you can provide a mechanism for locating within a file (text and graphics)
… here’s a point range, and it calls selectors
… and it can identify versions

Tzviya Siegman: when we worked on EPUB 3.1, we did away with part of EPUB CFI
… (the hyperlinking part) and it turns out no one used it

Garth Conboy: Yep — removed in content.

Tim Cole: ivan, we can proceed with a first draft PR that assumes the web anno approach in order to make it more concrete

Rachel Comerford: this one: http://www.idpf.org/epub/31/spec/epub-changes.html#sec-epub31-cfi?

Dave Cramer: +1

Tim Cole: because of the history with CFI, I think that’s the better approach
… if you’re talking about packaged web publications, taht might be different

Tzviya Siegman: is anyone able to talk about why CFI was so complicated

Rachel Comerford: we use CFI in order to create reading “chunks” to provide assignments for students in our LMS
… CFI must live within a single XHTML file, and couldn’t work across files

Luc Audrain: http://www.idpf.org/epub/31/spec/epub-changes.html#sec-epub31-cfi

Rachel Comerford: we usually chunk by a-head, but we couldn’t create a link that included two a-heads

Tim Cole: that’s an issue I raised

Ivan Herman: the current version of notes gives only a partial answer to Rachel’s problems
… that may be an issue here, too
… I”m fine putting it in the public draft

Bill Kasdorf: there appear to be two problems with CFI: 1) it’s too complicated, and 2) it’s not complicated enough

Ivan Herman: I would be pleased if any CFI users would have an early look
… to see if this is a realistic “path”

Tzviya Siegman: https://www.w3.org/TR/selectors-states/

Rachel Comerford: +1 to review, also nominating jeffp to review

Ivan Herman: the way the anno group worked, was not to create URLs, but to define JSON structures to anchor
… so the note talked about turning the JSON into a URL
… and this is not standardized, we’d need to go to IETF
… so early feedback is necessary

Tim Cole: another thing about the difference
… the web anno approach gives us some flexibility–there’s more than one way to do it
… you could use a phrase, or character/byte offset
… and there are range selectors across files
… but a limitation is that it assumes that every component has a URL
… which might not be true in a packaged doc

Brady Duga: CFI points at a thing; you just have to have a range to do it, you could specify a range that spans file
… its complicated because locatiing content that someone else wrote is intrinsically hard
… it’s easy to reference your own content–just put in an anchor
… but with content you can’t it’s hard.
… if you use byte offset, then change encoding then it’s hard
… CFI is hard to generate, but it’s hard to point into other people’s content

Ivan Herman: is the CFI specification usable with non-xml html? does it work wtih non-XML manifests?

Brady Duga: it probably doesn’t work
… it could probably be extended

Garth Conboy: CFI root is the EPUB manisest.

Ric Wright: I’m not volunteering
… we’ve experimented in readium, and we can get CFI to work with non-X HTML
… anyone on the systems side to look at web annos?

Brady Duga: I would, but I don’t have time in the next few times

Summary: people should look at the WA document, and prepare a PR on the topic (Ivan Herman)

Tzviya Siegman: there’s a lot of writing that needs to happen

4. writing assignments

Tzviya Siegman: we have a section on establishing a web pub; we’ll volunteer matt
… we hope dweck can work on offline
… leonard is working on security
… we have a section on privacy, can we move it?

Ivan Herman: florian has done a PR on pagination
… lots of relations to CSS

Tzviya Siegman: https://github.com/w3c/wpub/pull/65

Dave Cramer: OK to remove the privacy section?

Laurent Le Meur: ok

Garth Conboy: +1 (to privacy sec removal)

Luc Audrain: ok

Tim Cole: +1

Resolution #3: remove the privacy section

Tzviya Siegman: feel free to comment on issues and PRs in GitHub
… thanks all!

5. Resolutions