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
- Resolution #1: last minutes are fine
- Resolution #2: accept the PR and possibly create new issues around it into github
- Resolution #3: remove the privacy section