Re: Feedback on WP Spec from Kobo

Hi everyone, 

I would like to comment Kobo's contribution but will start with Leonard's comment, which may help understand our views:

- It's a fact that EPUB has been traditionally developed for the trade publishing market, and is only known in this context; but nothing will hinder EPUB4 to be used in a broader context (i.e. the market currently addressed by PDF) if we manage to get it right. What I mean is that PWP is still for me a non-sense at the marketing level, and should be kept as a nickname for the packaging mechanism used for EPUB4. But this is only my perception and I know that Adobe prefers to see it differently, so that the "next PDF" can be "PWP compliant". ISBN etc. are metadata that MAY be embedded in EPUB files, but it's not a requirement. 

- WPs are a way to "stream" publications, and I'm pretty certain that we'll end with a simple equation: EPUB 4  = package(WP). The main issue is related to absolute/relative URLs and the security model of the Web, but we'll find a way.  

Now, about Kobo's feeback: 

> If this discussion can't be done in WebPub can we table the discussion for EPUB4?

The infoset of a WP (https://www.w3.org/TR/wpub/images/WP-diagram.svg <https://www.w3.org/TR/wpub/images/WP-diagram.svg>, https://www.w3.org/TR/wpub/#infoset <https://www.w3.org/TR/wpub/#infoset>) specifies exactly what you want to see: a way to tell the reading system which resources make the publication, in which order they should be presented and which items should appear in the TOC. I don't see how discussing this in the scope of EPUB4 would change anything.

> ...backlog of legacy EPUB2 content. This content needs to be easily converted to WP by publishers, and supported by us

More, the Readium Web Publication Manifest (https://github.com/readium/webpub-manifest <https://github.com/readium/webpub-manifest>, aka RWPM) is a proposal for a simple serialization of a similar infoset (they are some minor differences, currently) that is the result of a projection of EPUB 3 XML structures to JSON (JSON-LD  to be precise). The conversion from EPUB2/3 to RWPM is in action is every Readium-2 based SDK and application today, on iOS, Android, Windows, OSX or Linux. Compatibility is a therefore a fact, not a dream. Note that the reverse conversion (RWPM to EPUB 2/3) is not developed today but is easy also. 

> The major concern for us in the current spec is around the proposals for the navigation documents adding a new separate navigation model on top of existing ones (NCX, nav, OPF).

NCX is an XML document (structure only) and the EPUB 3 nav doc is an XHTML/CSS document (structure + presentation). There is an open discussion about if mixing structure and presentation for navigation objects (TOC, page-list, image-list) dedicated to reading apps is a good of bad idea. Whatever the result is, the NCX structure can be easily transformed to a JSON structure is we go this way; and XHTML will still be supported in WP/EPUB4 as-is: this only issue will be the existence of epub:type as currently used in EPUB 3 nav docs. 

>  If WP diverges too far from EPUB2/EPUB3 models it could complicate the creation process.

This is true if you speak about the conceptual model, and this is why we must carefully think about it. But converting serializations (e.g. from XML to JSON), if it is can automatic, is not a big deal.  

> Our belief at Kobo is that we want our customers to be able to read their content however and wherever they choose. WP presents a challenge for us in supporting that.
> As a retailer and reading system provider, it's apparent to us that we will need to produce web applications to support WP (or extend existing ones)

This is why the support of reading system developers is a must. We now see that browser vendors will not "jump" on WP and EPUB4 very quickly (the exception may be Microsoft). Web Applications will be developed by ... reading system developers, including Kobo. Grouping forces around open-source would be smart.  

> do we as a working group believe WP needs to be markedly different from EPUB?

Very good question: from what we see around us, WP will be mainly used in scholary publishing and for exposing extracts of trade books. But is it a very different market from traditional trade publishing? And I said earlier, why would trade publishing be the only market interested by EPUB4? 

> We need to remember, as a group of technically inclined publishers, retailers, and developers, that not all people affected by this are as comfortable with standards and change as we are. If we develop a spec that disadvantages smaller publishers or less technical publishers that do not have the resources to update, then we are not doing our jobs properly.  
You are underling the importance of authoring tools, conversion tools from EPUB 2/3 to WP and EPUB4 and good marketing / documentation / communication. I 100% agree.

Cordialement, 

Laurent Le Meur
EDRLab


> Le 4 mai 2018 à 13:00, Leonard Rosenthol <lrosenth@adobe.com> a écrit :
> 
> Thanks for that feedback from your perspective at Kobo – and it all makes complete sense with that lens on.
>  
> One thing that might help you (and others that have come in later) is why WP and PWP are not the same as EPUB4.  The reason that the committee chose to go that direction is to enable publications on the web that aren’t traditional publications found in EPUBs today, but are commonly found in other formats such as PDF.  Consider the desire to see memos, white papers, scientific publications, brochures, etc. all available both on and off the web using the same underlying framework that EPUB4 would.  But they can’t be EPUBs because EPUB requires many other things that those publications do not – ISBNs, rich metadata, etc. – and so we can’t have a single “end game” but can share a common foundation.   And that’s why WP/PWP is what it is…
>  
> So my recommendation to you is to ensure that when we begin the work on EPUB4, your compatibility, translation, etc. requirements are met – because that’s where it matters!
>  
> Leonard
>  
> From: Reid, Wendy <wendy.reid@rakuten.com> 
> Sent: Thursday, May 3, 2018 2:55 PM
> To: W3C Publishing Working Group <public-publ-wg@w3.org>
> Cc: Dugas, Ben <ben.dugas@rakuten.com>; Xu, Zheng | KGB <zheng.xu@rakuten.com>
> Subject: Feedback on WP Spec from Kobo
>  
> Hi everyone,
>  
> Thank you for the opportunity to contribute. I apologise for the delay, in constructing this feedback we gathered opinions from a number of people within the company, and it look a long time to compile it all into one coherent document. 
>  
> W3C Feedback for Web Publications
>  
> In response to the specifications proposed for Web Publications, we (Kobo) would like to highlight a few areas of feedback we hope to see the group address in future drafts. We don't think development of navigation in WebPub has gone off the rails but we would like to take a step back and consider one format and location that tells a reading system what's in the content, what order it should be presented in and and which items should appear in the TOC instead of spreading this information out across multiple files. If this discussion can't be done in WebPub can we table the discussion for EPUB4?
>  
> Compatibility and Production
> As a retailer that deals primarily with publishers and their content, we know the challenges of both accepting a new specification and adopting it. Within our system, the expectation for most content is it's compatibility with as many devices and platforms as we can support. Our expectation for WP is that it is as compatible and convertible to other formats as possible. This is specifically important for our and our publishers' huge backlog of legacy EPUB2 content. This content needs to be easily converted to WP by publishers, and supported by us. The major concern for us in the current spec is around the proposals for the navigation documents adding a new separate navigation model on top of existing ones (NCX, nav, OPF).
> WP presents a new challenge in publisher workflows and content creation. If WP diverges too far from EPUB2/EPUB3 models it could complicate the creation process. Additionally, it would present a new content type for conversion houses to offer, potentially increasing costs of production for ebooks.
>  
> Implementation
> In considering a new content type, as mentioned before, we need to consider what we will need to support and what platforms can do so. Our belief at Kobo is that we want our customers to be able to read their content however and wherever they choose. WP presents a challenge for us in supporting that. As a retailer and reading system provider, it's apparent to us that we will need to produce web applications to support WP (or extend existing ones), additionally, whatever features the WP spec requires of reading systems. These requirements may be such that our applications will need to override existing browser behaviour (for example, Firefox's reading mode currently disables some features for web content like highlighting). 
>  
> WebPub and EPUB4
> In our participation, we have noticed that the group has yet to have one conversation we feel is important to have, do we as a working group believe WP needs to be markedly different from EPUB? Can it potentially be a subsection of the requirements we introduce for EPUB4? That’s not to say we have a strong argument that WebPub should be a subsection of ePub4 but that we might not have yet proven through our use cases that a new format is required.
> There seems to be an argument for introducing things to EPUB that would bring it in line with web standards, and we fully support advancing the spec to support technical standards today. There's value in an EPUB standard that works on a variety of platforms and reading systems.
> There's additional value in modernizing the EPUB spec to support web, while still maintaining a standard publishers are already comfortable and familiar with. We need to remember, as a group of technically inclined publishers, retailers, and developers, that not all people affected by this are as comfortable with standards and change as we are. If we develop a spec that disadvantages smaller publishers or less technical publishers that do not have the resources to update, then we are not doing our jobs properly.  
>  
>  
> Please feel free to reach out to any of us with questions or concerns, and we’re looking forward to meeting everyone in May and discussing these things further!
>  
> Cheers,
>  
> The Kobo team (Wendy, Ben, and Jeff)