Publishing WG Telco, 2019-07-01: Future of WPUB, shape of audiobooks

See minutes online for a more detailed record of the discussions.

The meeting concentrated on a single issue: what exactly is the future of the work in the Working group. The essence of the question was part of the agenda, and is simply reproduced here:

Proposed Changes to PWG

The chairs of the Publishing Working Group (PWG) and the EPUB 3 Community Group have been discussing how best to move forward with Web Publications. As the specification exists today, there is little chance of it being adopted by publishers, as it does not reflect current business needs. In spite of our best intentions, we did not gain the support of the browser vendors or the larger web community. We attempted standardization before experimentation and incubation. Clear business needs have been hard to find.

We feel the best course of action is to suspend work on web publications for now, and focus on areas where we have clearly-expressed and widely-supported business needs, such as audiobooks. We would consider resuming work on web publications, but we would need more clearly-articulated business needs, and broader participation from the web community as well as the publishing world.

So what should we do? We have a proposal:

  • Publish the existing full Web Publications spec as a Working Group Note, with the message that “there is insufficient business interest to proceed today, but we can revisit in the future.”
  • Move forward with audiobooks. But we need to decide on an approach:
    1. Most of the chairs favor using the existing audiobook spec as a foundation, incorporating the manifest and associated vocabulary from Web Publications, and possibly integrating the packaging spec. By de-emphasising the WP aspect of audiobooks, specifying the processing of the manifest could become much simpler, avoiding the complications of fetch, CORS, and so on. But this still leaves open the possibility to better integrate with existing web technologies, and perhaps even evolve to support podcasts. And if the synced media proposal for audiobooks gains traction, it could be a boon to the larger web. This could open the door to future profiles as well.
    2. EPUB could become a packaged audio format by defining audio formats as core content types, allowing them to be referenced directly from the spine without fallbacks. This provides a natural way to incorporate navigation and non-audio content in audiobooks, and takes advantage of EPUB’s existing media overlays. But there may be little interest from the industry.
  • Work with the publishing community to focus on the future of EPUB. Perhaps instead of inventing something new, we can bring EPUB closer to the web. Some of the ambitious proposals made for EPUB 3.1 could form the foundation of the EPUB 4 of the future, including the browser-friendly format, the HTML serialization, and more progress on scripting in EPUB. If the industry indeed sees a business need for a new version of EPUB, We do not yet know where that work might happen, but logistics will come later.
  • Follow the advice that we’ve received from the larger web community about incubation, about identifying gaps in the web platform and advocating for filling them rather than trying to create a grand vision from scratch.

We will spend Monday’s meeting discussing these issues. We hope to hear your thoughts about these questions in particular:

  1. Would you prefer to move forward with audiobooks as is (in a Web Context) or audiobooks in an EPUB context? We would like to hear about implementation interest from both “listening system” vendors and content creators.
  2. What are the next steps for EPUB? What comes after EPUB 3.2? Going forward, we will ask you to identify particular gaps in the EPUB specification.

The discussion was complicated (see the minutes) and questions were raised. As for the question on audiobooks, the group’s decision is to use the WP formalism (as opposed to EPUB) for the audiobook line.

About Ivan Herman

Ivan Herman is the Technical Lead for Publishing@W3C. For more details, see http://www.w3.org/People/Ivan/

One Response to Publishing WG Telco, 2019-07-01: Future of WPUB, shape of audiobooks

  1. It is no surprise that this situation has arisen, but the path to a solution is not thru tri- or quadfurcation (EPUB 3, EPUB 4, WP, PWP, PDF…). This is “taking the cart before the horse”.

    W3C, together with the IETF, need to address the shortcomings of existing standards.

    The simple problem is:
    W3C NEEDS AN ANSWER TO PDF
    W3C NEEDS OFFLINE HTML
    W3C NEEDED AN ANSWER YEARS AGO!

    There are zillions of PDFs out there. The idea that “there is little chance of it [PWP] being adopted by publishers” is ludicrous. This is exactly the type of “market research” that Steve Jobs ridiculed and discredited. The discussion has been turned upside down.

    W3C mission is universal web and the vision puts consumers first, not content owners.

    W3C needs Offline HTML or, as I call it, Browser Document Format (BDF). Most of the worlds’ content is delivered in HTML. For much of this content, if it works in a browser online then it should be able to work in a browser offline.

    As many of you might remember, several years ago I produced samples demonstrating several use cases (UC from POV of consumers). I built an authoring system in WordPress (the CMS used by the W3C) that demonstrated creating offline HTML on the fly. Offline HTML can be done now!

    The W3C and IETF need to urgently address the need to deliver secure and validated HTML from the file system. While this entails looking at single and multi file solutions, in order to get the ball rolling, I suggest starting with the simplest single file cases – replace saving content as a PDF with tools to generate a single file HTML – as I demonstrated already.

    I suggest converting LPF to BDF that will define a single web page and all the extras in one file, with no need for any modified structure or manifest. Instead, I propose focusing on creating an optional file integrity check along with compression and maybe encryption.

    And I suggest, if the browsers are not ready to assist in this, the W3C encourage the development of browser extensions to address security and validation issues.