Re: Thoughts on rechartering and the future of publications on the web

Agree with Dave, and more information about ISO and Asian publishers' thoughts.

Taiwan, Republic of China, is not member of United Nation since 1971. That means we cannot join ISO/IEC activities. Government may be happy to subsidy trade association like TDPF join W3C to participate pre-ISO process. But for members of TDPF, the publishers, they just think same thing as publishers concerned: 

- When will the validator come out?
- Is EPUB file in 3.2 standard accepted by major vendors?
- Current authoring tools support 3.2 standard or not yet?

They do not care about ISO standard, but daily authoring process.

It might be easy to test EPUB 3.2 standard on reading system developed by global vendor. But  it's not easy for local vendor those who developed their own reading system to support EPUB 3.2 without a reasonable road map. In Japan, EBPAJ's template and authoring guide do not cover "HTML based Fixed Layout" and media overlay function. In Taiwan, I'm working on a project followed EBPAJ's template to let publisher raise the bar of quality of digital publications. 

I'll try to get publishers' feedback with TDPF in Taiwan on a conference next month.

It may not easy to get consensus within Japanese publishers and ebook vendors, I'd like to know Murata-san's comment on this.

Regards

Bobby Tung

> Dave Cramer <dauwhe@gmail.com> 於 2018年11月6日 下午11:31 寫道：
> 
> Hi Everyone,
> 
> Hachette Book Group is a rather large company, as publishers go. A very significant fraction of our revenue comes from EPUB, which makes EPUB really important to us. Of course we’re interested in a future where we can do more with our digital books than is currently enabled by EPUB. How do we get there without going broke, alienating our customers, and destroying our business relationships? That's a tough question for web publications to answer. But this is what we need to figure out before we change direction, before we recharter, before we decide whether to move EPUB 3.X to REC track. What should the future of EPUB be? How does EPUB relate to the web? Is the “convergence” we dream of possible, or desirable?
>  
> From the point of view of trade publishing, the fundamental thing about an ebook is that it is a thing, it is a single object that can be bought and sold and transmitted. That allows us to sell digital books while still maintaining relationships with our authors. For us, packaging is the major difference between the web and EPUB. This means that WPUB is of little use to us unless it’s packaged. For other segments of publishing, the answers may be different. Scholarly publishing has different needs, as does education. 
>  
> We also need to think about what will encourage publishers to move to new formats. The original EPUB had a fairly compelling message: Use EPUB and you can stop making all the other incompatible ebook formats that were out there: Palm, LIT, PDF, Sony, etc. EPUB 3 had a far less compelling message. My CEO doesn’t care that I can use <aside> rather than <div class="sidebar">. Almost no one cares that you can put video in an ebook. And the result is that we are still working on convincing publishers to move from EPUB 2 to EPUB 3 after seven years. 
>  
> What will convince publishers to move to web publications? Being a “first-class citizen of the web” is not an answer. What can WPs do that EPUB can’t? What new content? What new business models? What new user experiences? This is the story we need to tell. We also need to tell the story of what happens to our existing content if everything changes. PRH has something like 80,000 EPUBs; we’re lucky to only have 30,000. 
>  
> We also need a story that works for the TAG, the AC, and the browsers. I’ve heard the word “shit’ used by the TAG to describe EPUB. How can we move closer to the web without wrecking our businesses? Part of that is being clear about what we want. Publications on the web are possible today. Nothing is stopping us. So what are we asking for? What problems are we trying to solve?
> 
> And whose problems are we trying to solve? We spend so much time thinking about technology and business and the politics of working groups that we forget who we’re doing all this for: actual human beings who want to read publications. Readers don’t care about EPUB or WPUB or anything we spend our days arguing about. Readers care that their books are too often full of mistakes. Readers care that their books are hard to navigate. Readers care that their books might just go away. 
> 
> We also need to figure out what EPUB means. What makes an EPUB an EPUB? Does an EPUB have to use OPF and OCF? Is a publication with a JSON-LD manifest and packaged with a bundle of signed exchanges an EPUB? Is there room for EPUB to evolve? EPUB that uses HTML, that kills off all the things we tried to get rid of in 3.1. Does anything we call EPUB have to be strictly backward compatible with EPUB 3.0.1? 
> 
> And where do audio books fit into this picture? We have a business need (although not documented as well as I would like), and a certain amount of urgency.  But do we adapt existing EPUB for audio, or try to build the new world from scratch with audio books as guinea pigs?
> 
> We have lots of questions. 
> 
> ***
> 
> What might the answers look like? I think we need a path that starts from where EPUB is today. I’ve written at length elsewhere about the problems we have with EPUB. 
> 
> The EPUB specification represents a contract between authors and reading systems. Follow the rules when making books, and the books will be rendered faithfully. But that contract is being broken far too often today. Reading systems don't implement parts of the spec. Implementations are buggy. We can describe this as a lack of interoperability, but that hides the actual damage: Readers have bad experiences, where content may be hard to understand or even missing. Publishers create suboptimal books, avoiding features that don't work everywhere. I think this a problem worth solving. But to solve it we need information. What features aren’t supported? What are the bugs? How can authors work around these problems? To find out, we need tests. Tests are little EPUB files that tell us what works and what doesn't. And what’s a best practice but a test that passes everywhere? With this information, we can encourage reading systems to fix bugs and support features. We can discover if the spec itself needs clarifications or changes. And we can document what works today for authors. Interestingly enough, these are the same actions required to bring EPUB 3.X to REC. I think this is a useful, if immensely challenging, step.
> Publications exist on the web today. We need to be very clear about what they are missing, what needs to change to make them viable for our industry. Instead of creating something called “Web Publications,” let’s look at what pieces are missing from the web platform. We have lots of use cases and requirements, but our requirements are very vague. Can these requirements be recast into more concrete, actionable statements, so that we can evaluate whether today’s web can meet these requirements, and then clearly identify the gaps? We need an explainer for our requirements. 
> When we’ve explained what we need, we should document all our proposed solutions, whether or not they are currently in the WPUB draft (one example: we should document why we rejected WAM). And we should bring that to the TAG, and enlist their help in finding architectural principles to guide our work. 
> Similarly, we should write an explainer for audio books. What exact problems of authoring, distribution, and consumption are we trying to solve? What does the industry do today? Who is asking for change? Who will be working on solving these problems?
> Once we have clarity about where we are starting from, what we need from the web platform, and how we want to do our work, we are in a good position to start writing a new charter that will get the support of the publishing industry and the browser community. But I don’t think we can write a charter until some of the above questions are answered. 
> 
> 
> Dave
> 
> 
> 
> 
> 
>