Publishing Working Group Telco — Minutes

Date: 2018-04-16

See also the Agenda and the IRC Log

Attendees

Present: Wolfgang Schindler, Avneesh Singh, Jeff Buehler, Ric Wright, Ivan Herman, Rachel Comerford, Gregorio Pellegrino, Luc Audrain, Tzviya Siegman, Laura Brady, Dave Cramer, Romain Deltour, Deborah Kaplan, George Kerscher, Peter Krautzberger, Nick Ruffilo, Franco Alvarado, Joshua Pyle, Mustapha Lazrek, Ben Walters, Garth Conboy, Bill Kasdorf, Benjamin Young, Ben Dugas, Ben Schroeter, Laurent Le Meur, Brady Duga, Lillian Sullam, Hadrien Gardeur, Reinaldo Ferraz, Marisa DeMeglio, Adam Sisco, Chris Maden, Tim Cole, David Stroup, Heather Flanagan

Regrets: Evan Owens, Vladimir Levantovsky, Jasmine Mulliken, Mateus Teixeira, Teenya Franklin

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo, Dave Cramer

Content:

• 1. Goals and Next Steps
• 2. Resolutions

Tzviya Siegman: Any new members today?

Tzviya Siegman: Minutes from last week? … Approved

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

Resolution #1: last week’s minutes approved

1. Goals and Next Steps

Tzviya Siegman: https://lists.w3.org/Archives/Public/public-publ-wg/2018Apr/0012.html

Tzviya Siegman: Let’s reiterate some of the key points of our goals and focus.
… We’ve had lots of confusion over the direction. Some of us aren’t all on the same page. There are some gaps in the understanding which has prevented us from moving on other items. After much discussion, Garth, Ivan and I put together what we wanted to say was the goal of the group as a whole. We’re open to discussion but we need to be working on the same goals and vision.
… Epub is our history in the publishing industry - we’re working with the influence of epub. We aren’t duplicating it, but we need to use the learning lessons from epub. We can look at it as a cleanup of epub to make it web compatible. This is going to be similar to that. We need to make sure anything that can be done on the web can be done in epub and back…

Romain Deltour: in case anyone doesn’t know: BFF = browser-friendly format (for EPUB)

Tzviya Siegman: That sounds like a huge task but we’re pretty far along there. We need to make sure we’re taking a careful eye on our normative work and non-normative work. Some non-normative work - such as what is required of browsers. We need to do that, but it’s not something we specify.
… So we want to be able to assign things to groups or task forces.

Garth Conboy: Agree with Goals bullets, but would add “Bring EPUB capabilities to the Web in an OWP-compatible fashion.” (as you just said, Tzviya)

Garth Conboy: you added in bringing epub capabilities to the web

George Kerscher: I know we don’t want to tell browsers how to do things
… but there are expectations about certain behaviors

Wolfgang Schindler: +1 to George

George Kerscher: I know we don’t want to specify that, but we do need browsers/reading apps do certain things–the affordances

Benjamin Young: also +1 to George

George Kerscher: am I right?

Tzviya Siegman: maybe. It depends on what we ask of them
… search is a good example of an affordance
… we could say we want the user agent to afford this
… but we might not define user agent conformance
… we do need to think about user agents interact with publications

Garth Conboy: historically, we have tried to limit our reading system behavior; search is an excellent example
… we want to be a content standard, we don’t want to make requirements around affordances

Hadrien Gardeur: I have a bunch of questions and comments. You mentioned epub and BFF - I’m wondering if that new direction/take has any difference on the infoset. Or maybe the infoset represents a subset of what is in epub? It could change quite a lot. The 2nd point is that readium and readium 2 - we’ve been continuing the work on epub BFF - so instead of starting with a new infoset, our work has been to take any version of epub and making it available on the web. It’s very similar to what we’ve been doing in that group. We’re dealing with a much larger infoset.

Garth Conboy: The comment about the infoset is relevant. The first item on the F2F agenda is looking at what is in epub and how those capabilities would be represented in OWP solution. The complete epub infoset may not be there (but should be there, I think)…

Benjamin Young: I wanted to clear up one thing about User Agents and affordances. The UA provides a feature, the content descriptions afford the ability to instantiate that feature. In-as-much-as we talk about search a lot as an affordance. We actually afford for the feature of search by limiting the scope of what is a document. Web applications as built with javascript do not afford search because they do not descriptively tell the browser what to search across - besides the current HTML page. The browser will let you ctrl-f and search a DOM and possible embedded iframes, but it will not let you search for things outside of the document (besides open search) there’s no way to tell of documents external to the loaded page.
… But these are things we want to provide as an affordance so that the browser can provide that functionality. I hope that clears things up.

Garth Conboy: The content affords the UA/Reading System the ability to perform features. My comment is that we don’t want to litigate that UAs/RSs MUST implement those features.

Benjamin Young: my +1 to George is that we are clear about the scope of what we define. So that browsers/UAs can develop a feature around that.

Bill Kasdorf: I’m concerned about the ambiguity around User Agent, Browser, and Reading System. People have used those terms at different times. What do we mean?

Tzviya Siegman: I’ll answer - in our formal documents we use User Agent exclusively - it includes browsers and reading systems.
… I wanted to make sure we’re covering approach and not nitty gritty details.

Garth Conboy: And from a historical perspective I do tend to use UA and RS as equivalent.

Dave Cramer: The term User Agent to mean Browsers & reading systems - that’s critical to the discussions we’re having now. It feels to me like we’ve been working on epub this whole time. We’re talking about this content format that’s going to need a large amount of scaffolding before it can be provided to a user - something like readium. While it’s all happening on the web, there’s tons of technology between the content and the user. When I think of web publications, I think of something more lightweight - where there isn’t a 3rd party required to show content to the user. Rather than the charter saying epub 4 - packaged web publications would come out of that, or maybe we make epub 4 and figure out what we learn from that and figure out when we make web publications.

Garth Conboy: Hallelujah to Dave’s!

Ivan Herman: Two things: I’m always worried about using the term epub 4 - maybe not for us that are deep in it. For most people, epub 4 and epub is very intimately related to packaging. we are focused on the content, and the packaging is separate. using the term epub 4 could be misleading in this context. we want to have content that is equivalent, but the package could be separate. I don’t want to say that web publication is practically the same as BFF. It is a good model, but different. My other point: we have simplicity VS non-simplicity. My dream is to make readium unnecessary :-) In a sense, the goal is that all the complexity that the readium people are putting in their system would be covered by browsers. However, I have the impression that I will be retired before that is true. For a time being, there is a need for an extra layer. In the long term, we hope that some browsers will pick that up.
… In the meantime, the other part of it is - if I put a web publication on the web, with all the bells and whistles but I use only the browser, we have to accept that some of the affordances will not manifest themselves. We have to accept that most of the content is available and consumable, but it may not be a complete publication as we know it. What happens if we just unpackage an epub 3 document and give it to a browser. Tzviya did say that in many cases, that would not work.

Benjamin Young: +1 to ivan’s ever clarifying clarifications

Hadrien Gardeur: I think dave and Ivan have an outdated look on readium. Readium 1 was very heavy - but readium 2 is very difficult. The goal is to do as little as we need on the browser side. Most of the work we need to do is the streamer - which takes files in a zip and allows access through HTTP.

Tzviya Siegman: That’s great news - you’ll be the first implementors :)

Hadrien Gardeur: In terms of BFF-ability - what was mentioned that epub3 wouldn’t work in the browser. The first is package, the last is navigation. Most epubs couldn’t navigate with the content as is, but if you solve those two problems then you have something that works - so we should focus our efforts there.

Romain Deltour: I had a first comment on what we mean by User Agent. I saw in comments that it includes browsers and web-apps and extensions and reading systems. I am having trouble putting a web-app on the same level as a reading system. A browser and a web-app are very different. If a web-app is a potential user agent it has consequences on the technical approach.

Tzviya Siegman: +1 to rdeltour

Romain Deltour: The other comment is about approach of the high-level. It makes it clear that epub is our history - so we can adapt a content-centric approach. We base our approach on the history of epub, then define publications in terms of it’s content - the infoset. I don’t think there is a lot of precedent for this type of content on the web. Are we limiting/constraining ourselves to a specific context/usecase? Are we trying to get the publishing industry using web-technologies for what they currently do? But aren’t necessarily trying to open ourselves to the larger world, but to move the publishing industry to the web. The way I feel about that - it’s more a business question than technical - to summary - by taking a content-centric approach, who is the constituency we’re trying to

Nick Ruffilo: target. Maybe it’s easier to look at epub 4 first, then later try to look at the lessons

George Kerscher: I’m in a strong agreement with Ivan - the way I Envision our success is that if we can create published content, and I can open it in a browser and read it - albeit maybe clunky - like having to go to a table of contents and move to the next file, press enter, rather than seamlessly looking at the next chapter - as long as I can read it successfully in a ‘dumb’ browser, we’re doing well. From there, other reading systems will develop additional affordances. As for search - i could search one page at a time, but it’s still search. And if we can achieve that, thats good.

Bill Kasdorf: I think a fundamental issue you’re raising is - what exactly are we doing. Are we creating a spec that works with today’s platform, or are we creating a spec that notes items that should be developed. What George was talking about is a spec that works with what we have now - or are we trying to determine what we really want even if not available. But we need to be clear.

Ric Wright: When Ivan was talking earlier about a convergence between what we are doing and what the web is doing - if we wait, the browsers will catch up and adopt what we’re doing. I’ve been through this mill so many times. By the time the browsers are starting to implement, things may have already changed and uses/implementations will be different.

Avneesh Singh: What business need are we solving? Epub 3 was released in 2012, still a huge number of publishers using epub 2. We are working on WP, PWP, why would people jump? We can keep creating specs, but what are the business needs?
… Is it to bring web designers to publishing? or to take publishing to the web? Lets make that our goal

Ric Wright: +1 Avneesh

Tzviya Siegman: https://w3c.github.io/dpub-pwp-ucr/

Bill Kasdorf: +1 to Tzviya about scholarly publishing

Tzviya Siegman: One thing we’re ignoring is the use cases created by the web publishing interest group. Link above. One thing we must go forward is that the use cases are what we are spec’ing for, and that the use cases we are working towards. Romain referenced the unicorn browser - we could create a crazy spec, but we need something reasonable. Scholarly publishing would use WP - but would never use epub.

Ben Dugas: +1 on regular review of use cases as well

Garth Conboy: Business cases and the BG are nicely driving the EPUB 3.2 momentum.

Ivan Herman: Two things - Avneesh - huge plus 1. One problem we’ve had and are still having is our relationship to the business group is not strong enough. We have been carried away by all types of technical issues. Myself as a technical person who is not part of the publishing business… One major thing is to create a bridge between the epub world and the scholarly publishing world - and that is something that needs extra work and a presence on the web. Those publishers do not care about packaging (and why they don’t care about epub). The web developer community that is out there and huge, but disconnected with those working on epub, and those working on epub is very small. Having an environment where XHTML and epub:type is used - this is just not working as a long-term solution and we need to let it disappear.
… We should work on affordances - but the huge difference is that it’s not normative. We can and should - make very clear - in the book world, these features are expected by the user community and what it means. In some cases, we may even outline what the missing technical features and APIs that are necessary. I think we should go at least as far as that. It becomes an important starting point. Whether it’s part of the document or a working group note is besides the point.

Deborah Kaplan: +1 to connecting regularly to the use cases

Deborah Kaplan: +1000 to Ivan on how we get wrapped on tech implementation and forget business cases.

Joshua Pyle: As one of the people who volunteered to help with the use cases - I did want to - mostly I think there are some camps developing. I align with the camp that is a little frustrating that we are constantly surrendering to the fact that browsers - I was kinda hoping that as part of the W3C we could make browsers less stupid…

Deborah Kaplan: +1 million to “make browsers less stupid”

Joshua Pyle: As someone who is representing a corporate interest - without standards, we get all these corporate e-readers, which all seem great, but the W3C is bigger than that, and it would be great if ever web browser used the same standards. It’s also frustrating for developers to do their job, then figure out what technology playforms do. I want us to surrender less to the notion that it takes browsers a while.

Nick Ruffilo: Publishing is big and lots of different sections and we need to consider that

Romain Deltour: When we say we need to clarify the business case - it makes us think about the business group. I want to note that we also have to keep in mind that there is a bias in the business group around specific types of publishing, so if we want our group to have a broader group of users, we need to think a bit bigger. As Tzviya was saying - knowing about groups waiting on web publications and people who wouldn’t use epub right now - why? Maybe do some analysis on who use cases are not solved in epub but would be solved on epub.

Ben Dugas: There was a few weeks ago and we talked about some of the standards in general - maybe in the past with the IDPF - we think in the past there was a lack of emphasis on use cases and implementations - we couldn’t demonstrate a need for a new format. The other thing I was going to say was at kobo we’ve been trying to stay up to date - so if we want to get data and feedback from other types of publishers - smaller pubs, etc. I’m not sure how we’d go about that but keep us in mind.

Jeff Buehler: In my opinion is - less is more. Whatever we adopt, not matter how rich, clients and corporations will break the spec. They will do what we didn’t consider and pursue implementations in their best interest. From my context, addressing the basic set of what we’re trying to pursue - then moving ahead with a richer set of features and affordances, but regardless of what we do, the people I work with will want to do things we haven’t covered.

Ivan Herman: Not taking away the job oF Tzviya - when talking to scholarly publishers, but epub may not work for them because it might be as stupid as what I said before - that for people, epub is “packaged stuff” and they don’t think in those terms. The fact of separating the content and the packaging is already half of the way.
… It’s come up before with the browsers - that they are slow and do not understand. That’s not very constructive manor. We are in a chicken and egg situation. Browsers will implement things that they see as having a massive importance for the web. Less and less they work on things that are in the future - they work on things that are already available but want to make it faster, better, and more secure. That is what standardization does. This is certainly a way of looking at things they prefer. It is chicken and egg, but the only way the browsers would think of implementing is if there was content on the web that was a publication. That’s the issue. Having a format that works - someway or another with browsers - that needs some software but it’s there and usable, that’s the important point. If there is content out there, they will implement. If it’s not out there, they will tell you to implement it yourself.
… We have to accept that - and W3C is not the buddy that gives orders to browsers. Another point: I don’t think what Nick is referring to is forking - but I don’t think we should decide on that, but we could decide to issue several versions of web publications, so we could start with a simple version and then build from there. We have had many version based standards.

Ben Walters: Mustapha and I have obviously been quiet here for this relatively lively conversation. We don’t have a short response, but at a high level, Ivan described fairly accurately the considerations of browsers choosing new features and technologies to implement.

Tzviya Siegman: there are 2 main issues - we have the affordances task force, which we still need. The WAM task force will still - there was a bulleted approach on processing the document. Other items we need to work on. Luc - do you need help reviewing the infoset?

Luc Audrain: I will raise some issues when I’m done, but not done yet…
… There are some interesting questions that need to be raised, but for the rest, it’s going well, but we have to look deeply into the issues about being practical - it’s a work in progress.

Tzviya Siegman: Would anyone like to volunteer to help Luc look through the infoset as to what is needed and complete?

Tzviya Siegman: Is there anyone who would like to look at the existing use cases. Prioritize, etc.

Tzviya Siegman: Nick, Josh, Rachel, and Josh will review the use cases

Ben Dugas: I’ll get involved in some capacity ;)

Tzviya Siegman: Ben, i see you’re volunteering - thank you

2. Resolutions

• Resolution #1: last week’s minutes approved