Publishing Working Group Telco — Minutes

Date: 2018-07-30

See also the Agenda and the IRC Log


Present: Wolfgang Schindler, Matt Garrish, Zheng Xu, Tzviya Siegman, Dave Cramer, Ivan Herman, Nick Ruffilo, Luc Audrain, Jasmine Mulliken, Ric Wright, Rachel Comerford, Gregorio Pellegrino, Joshua Pyle, Garth Conboy, Franco Alvarado, Ben Walters, Hadrien Gardeur, Ben Schroeter, Marisa DeMeglio, Tim Cole, Laurent Le Meur, Brady Duga, Mustapha Lazrek, Adam Sisco, Bill Kasdorf, Jun Gamou

Regrets: George Kerscher, Evan Owens, Jean Kaplansky, Chris Maden, Juan Corona, Jeff Buehler, Derek Jackson, Benjamin Young


Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo


Tzviya Siegman: There’s an agenda…

Tzviya Siegman:

Tzviya Siegman: Comments on the meeting from last week?

Dave Cramer: I’m sorry we didn’t get to all agenda items.

Tzviya Siegman: OK - minutes approved

Resolution #1: last week’s minutes accepted

1. Publishing status

Ivan Herman: Latest version:

Tzviya Siegman:

Tzviya Siegman: There was a flurry of activity on github. We have made available a more current version - what is on github can be considered a relatively stable version, so we can consider this a current ‘publication’ - a ‘second public working draft’ although it is not formally that. It’s being reviewed by a few different groups
… Please read, review, add comments. We talked about the changes last week. We are also hoping for some implementations now

Ivan Herman: for future versions, I would prefer if we had publications more frequently. This one took 4-5 months. A lot has happened in that time. In future - because we can do it easier - we should publish more frequently. Matt and I can do it relatively easily now. For example, if the web IDL part becomes more stable, then I would propose that when it’s accepted and done we consider it good and publish without any further ado. It’s better because we can ask external groups to review, we can announce it to the business group…
… I have sent a separate request to the internationalization group. Hopefully they will comment. So having a stable version to share and be proud of is good.

2. Implementations

Rachel Comerford: This is one of the few circumstances where I ask the newbie question - what does “implementations” actually involve?

Tzviya Siegman: We’re looking for user agents to build a tool that can support web publications. And also someone to build content as well.

Zheng Xu: Do we need to open source the sample implementation for WPUB? Or do we let the user upload and try out their web publication content?

Ivan Herman: there is no requirement that the implementation has to be open source. If it is usable, that is fine.

Zheng Xu: Ok - so you just may need a link to the results of a given WP content?

Ivan Herman: Ideally, if you put it in a piece of software where I can upload a book or URL and then you do something with it, that’s fine as well.

Zheng Xu: so user could possibly upload the content and see the result. Is there any sample content to use in the beginning?

Tzviya Siegman: We have the audio file. We have Moby Dick. I also have a sample journal that I need to make sure it fits, but I’ll be preparing it in a week or two.

Garth Conboy: I wanted to chime in a bit on implementation - creating content partially counts, conformant with the spec. Any tools that creates content conformant with the spec is the other side of the spectrum. And anything capable of processing a WP is most interesting. Back to Rachel’s question - something that can hunt down and parse a manifest is a long way through an implementation.

Rachel Comerford: We should be able to take some epub3 content and represent it as a web pub.

Luc Audrain: I would also like to produce a very small novel in web pub as well.

Tzviya Siegman: We already have the audiobook that Hadrien prepared. And Moby Dick…

Luc Audrain: One more question - where do we put this sample content?

Tzviya Siegman: Some are already in github, but we have a location where we can put this

3. Use cases update

Tzviya Siegman: Josh, I put you on the agenda for updates to the use case repo - but its status quo?

Joshua Pyle: I want to make one final appeal to the group for additional use cases. I didn’t get any last week. Then we have 2 weeks off soon. I spent a few hours last week adding more.

Tzviya Siegman: When affordances was meeting, there were lots of people on the call - this is a new spin on affordances. If that work interests you, channel your efforts into helping Josh. It’s not much work with many hands.

Jasmine Mulliken: I can help.

Joshua Pyle: You won’t be expected to write, I just need topics and use-cases to write. So if you think something is missing, or affordances that are not represented as use-cases, that’s what I’m hunting

Tzviya Siegman: The next time we meet, hopefully we’ll have some more use cases.

4. Start thinking about EPUB4…

Tzviya Siegman: Next agenda item, lets start the discussion about epub4. It might sound preliminary, but one thing we need to keep in mind is that epub4 is an extension of web publications.. A specified, packaged version of the web publication. We have a todo about defining the boundaries and what distinguished epub4 from web publication. We are hoping people are reading through and seeing what is missing - what makes it a web publication, what makes it an epub file and what distinguishes them. We don’t need to determine the package mechanism, but what the boundaries are. We don’t need to answer today but we need to think.

Dave Cramer: I think it’s important - what is going - we have a long history of epub, so how is epub4 going to be in the lineage of previous epubs. If it’s utterly different in serialization, packaging, content, etc. I guess another way of putting it - is what will we be able to do with epub4 that we couldn’t do in epub 3…

Garth Conboy: the boundaries for epub4 is easy - the boundaries are what is in the package. I believe as Dave’s comment, that it ought to be in a zip package, like 3.2… I’ve always believed that you didn’t have to start with a WP to get to an epub4. If you’re starting with a WP to get to an epub4, then you need to set the boundaries on the WP. If you’re making the epub4 directly, that’s less of a challenge. One possible answer to Dave’s question is that an epub4 is conceptually similar to an epub 3.2 for the interchange of packaged content. Does a number of changes in the BFF timeframe - HTML instead of XHTML, manifest is JSON rather than XML - logical packaging of the same stuff. Tzviya said to think, and thats what I’m thinking

Luc Audrain: If I succeed in doing a small, simple, web publication, I’ll try to put it in a zip and that should be an epub4…

Garth Conboy: A WP uses web links, over a specific domain, to go from it’s various resources. If we’re encapsulating it in a zip - that would be one of the differences (between web packaging) - you’d have to fix up all the links to file system links. It’s not quite as trivial as saying “throw it all in a zip”

Ivan Herman: Additionally to what Garth said, there may be additional requirements - the media flag/type, we have to think about whether we want to adopt zip or some special version thereof… I would say - Luc - essentially the answer is yes, the content is the same as WP, but there might be on the edge something we have to clarify

Ivan Herman: One more thing that is relevant - by doing it this way, we have something that is fully compatible with something that is not packaged. Not all publications are meant to be packaged. The way we are building things now, the toolkit can be used both for epub4 and a non-packaged WP because the content is 100% compatible.

Tzviya Siegman: Matt probably knows this best - there are lots of nuances to epub when it comes to the packaging mechanism, but what goes into the container.xml but we need to figure out what that means in the future.

Dave Cramer:

Joshua Pyle: I tend to agree that there is significant differences between a packaged web publication and epub. I started looking into implementation. It does feel like we’re taking something completely incompatible with epub, packaging it, then putting the name epub on it. So there is some concern…. Zip is not what makes epub an epub. What we are doing is quite different. There could be messaging that epub4 is not based on epub3…
… We need to message that in the industry very well

Nick Ruffilo: think of doc vs. docx - the messaging is definitely important

Ivan Herman: Those are the differences we really have to understand. When you document the differences - it helps us, not only on the messaging, but also to track the technical points that we have to make the transition from WP to epub4
… I have the impression in the case of DOC vs DOCX - the main content became of a different format. Most of the work to be done when you produce a book is to produce the right content with the right CSS, the HTML, fonts, etc. I have the impression that the content is almost the same as in epub3 - except that the content is now fully compatible with the web. We are not bound to XML serialization. I would think that the content is really the same. I would be interested by the experience of Rachel and her people what it means to convert an epub3 into WP. That will be very interesting. Sure - we may change the OPF file and it will be simple, but the content will be the same if not better.

Tim Cole: One questions that I think is coming up - that we should all agree on - when we think of epub4 - is it a specialization of WP or is it the opportunity that give it some other differences from epub3 that are small. For example when we determine what can be packaged - we can give different types of packaging options. We could limit to just zip - or we could say thta packaged web publications can use different packages, but epub4 must use zip. Does epub4 have to be an exact specialization of packaged web publications?

Ivan Herman: That seems like it would be a possibility.

Joshua Pyle: I just wanted to follow Ivan’s comment that he hit on the right message. epub4 is epub + web compatibility. It’s true. If anyone questions the decisions, we can simply say: ‘we started with a webbier format’ and then packaged it.

Ivan Herman: Josh: “EPUB4 is EPUB3 + Web Compatibility”

Dave Cramer: I think selling epub4 is going to be hard. Why should a publisher spend hundreds of thousands to millions of dollars when there isn’t that much difference in the content. Having the metadata expressed in JSON is not convincing to the COO.

Tzviya Siegman: We’ve had this discussion before - for journals, it will be much easier than the books people. I can let Ivan speak to that.

Bill Kasdorf: +1

Ivan Herman: That’s one - the way I look at it is maybe - on a slightly higher level - by doing the full web compatibility, what it also means for publishers is that they can rely on the huge number of companies and tech experts who are developing for the web of today. Those people find the market to develop content for publishers because they are working with the same content. This is not the argument that will help convince short-term, but long-term, a very important thing - the people who are using those technologies…

Ivan Herman: +1 to laurentlemeur

Laurent Le Meur: To complete these arguments, web technologies - there is a notion of conversion we need to push forward. Conversions of audiobooks, comics (the ability to make and package web comics) and magazines - scholarly publishing… Aspects of markets that have never used epub because it was too complex and now an option. We that is what we’ll need to market. We must be very careful about removing complexity to these formats. Convergence, Simplicity, web technologies

Luc Audrain: +1

Joshua Pyle: +1 to growing the market with EPUB4 rather than just converting it.

Luc Audrain: +1

Zheng Xu: First, I want to agree that the direction of epub and epub + web is closer to WP. At this moment we need to be careful about backwards compatibility of epub. Generally from what I’ve seen, many publishers cannot change - especially a small publisher. One example is that there are quite a bit of epub2 in the Europe and NA market. The highest rate of epub3 is Japan because digital publishing started with epub3. The workflow to provide new content is also a high cost. We should be careful about the compatibility with epub 3.2. What I want to do with epub4 is to look into what we still have not done and what we want to add to epub 3.2 and possibly even add an extension and keep in mind epub 4

Nick Ruffilo: EPUB2/3 will continue to exist - no motive for already successful EPUB publishers to change for EPUB4

Tzviya Siegman: I assume everyone will re-read the spec in the next few weeks. As you read through the document, these are some of the things we’re asking you to think about. epub4 will be building on this. We need authors/editors… Think about starting issues on epub4. if you see something that you would want/need, make an issue. Think about what you’d like to see in epub4. One thing we neglected to mention was offline ability. if you can’t create it, that’s OK but we’d love to see it in an implementation
… as we move to epub4 we’ll need to see the whole package, but we don’t have a good way to identify it. You can start writing spec language. Anything to add?

Zheng Xu: guess here

Garth Conboy: I think that’s good. From an agenda item - it said ‘start thinking about epub4’ Dealing with what is missing is important. One last comment to make was about backwards compatibility. Re-iterating our charter - functionality round-tripping is in, but not necessarily backwards-compatibility.

Hadrien Gardeur: I would need to slightly tweak it, but this example supports offlinability:

Tzviya Siegman: There is one agenda item about showing raw data in infoset…

5. Presenting Raw Data

Ivan Herman: Not sure now is a good time. I was playing with the IDL thing - where I tried to sync the IDL with what is in the document. I know why we do it and I agree, but I was a bit worried if IDL or WebIDL is good - as the spec is quite complicated. The WebIDL interface in javascript is extremely complicated. Do my frustration, the conversion tools are not easy to use. Having said that, having looked at it again, what we do and use for now (dictionaries and enumeration) those convert into javascript easily, but I was still wondering if this is a sledgehammer or if there were simple tools.

Hadrien Gardeur: IDL doesn’t necessarily has to be fully “synchronized” with our JSON
… We need to keep in mind that UAs will parse our manifest as pure JSON rather than JSON-LD

Ivan Herman: That is not a requirement - it depends. User agent MAY use pure JSON but maybe not. JSON-LD has powerful tools that implementations may want to use

Hadrien Gardeur: Not a requirement, but it’s by far the most likely scenario

Tzviya Siegman: Not sure what the next step is - we need to hear back from implementations if WebIDL is a challenge or helpful.

Hadrien Gardeur: How do we provide feedback from an implementor’s perspective?
… Not bug, feedback about what’s easy/hard/problematic

Tzviya Siegman: You can file a bug in Github - someone asked about providing implementation - we do have a place in github for experiments. Not sure that’s the best places to post an implementation, but you can post links. If you have other suggestions, we’re open to them.

6. Miscellaneous

Tzviya Siegman: TPAC reminder - if you’re coming, now is the time to book. We need to plan, but there’s discussions of having a joint meeting with the business group that we’ll figure out shortly. We’re taking the next 2 weeks off; Next meeting will be 20th August. Read the spec and open issues. If it’s about web pub, open it there, if it’s about epub4, open it there.

Ivan Herman: Bill McCoy has just announced that he leaves W3C. Thank you to Bill McCoy for all your hard work and efforts for epub and WP and the merger of organizations!

7. Resolutions