W3C home > Mailing lists > Public > public-publ-wg@w3.org > February 2018

RE: Let's get back on topic (was pursuing the wrong goal...)

From: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>
Date: Fri, 9 Feb 2018 15:52:51 +0000
To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Dave Cramer <dauwhe@gmail.com>
CC: Leonard Rosenthol <lrosenth@adobe.com>, "daniel.glazman@disruptive-innovations.com" <daniel.glazman@disruptive-innovations.com>, "public-publ-wg@w3.org" <public-publ-wg@w3.org>
Message-ID: <SN1PR0201MB1615B9B0D7449415BBE376C1D5F20@SN1PR0201MB1615.namprd02.prod.outlook.com>
Hi All,

Let’s take a step back. I think that we have gotten way off topic.

This thread started as a discussion that was fundamentally about whether we should move forward with an approach that is based on the Web App Manifest.

The underlying question is this: The User Agent accessed the starting page that includes a link to the manifest. What does it do with it? How do we get from the UA having information to the point where we have a User Agent implementing the basic affordances for WP?"

We seem to have some general constraints:
- A user agent that is aware of WP (what we have been calling WP-aware), including stand-alone Reading system apps, should not be bothered by any scripts/polyfills/whatever that are included in the WP
- Publishers of a WP should not be under the pressure to develop their own solution for WP-unaware browsers or other user agent

So, to everyone who has commented positively or negatively on this thread (and anyone else), what happens when a WP-aware UA encounters the link to the manifest? (This question is valid even if we choose not to use WAM, by the way.)


Tzviya Siegman
Information Standards Lead

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
Sent: Friday, February 9, 2018 10:16 AM
To: Dave Cramer <dauwhe@gmail.com>
Cc: Leonard Rosenthol <lrosenth@adobe.com>; daniel.glazman@disruptive-innovations.com; public-publ-wg@w3.org
Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

Well, since we're all sharing today, let me share the perspective from the Readium side.

When we started thinking about Readium-2 about a year and a half ago, we looked at what works and what doesn't work so well in Readium-1.
We quickly identified that:

  *   the server/client model is the only good solution for native apps as well, and that even for EPUB, we're better off using an HTTP server
  *   that Readium-1 lacked a good manifest format, we needed something more abstract that could work with any publication (not just EPUB) and that would be the bridge between the server component (the one that parses packaged publications and expose them using HTTP) and the client component (pretty much what we've been talking about in the previous thread, with all the publication specific affordances)
We extended and improved previous work that was started during the EPUB 3.1 BFF effort and very quickly built prototypes that worked very well and unified our vision as well. Thanks to this manifest we could easily:

  *   build native apps for reading publications
  *   build Web apps and browser extensions for reading as well
  *   stream remote publications in a native app or a web app (the business model or use case for that is IMO very obvious as well)
As we continued working on this manifest, we also discovered that:

  *   our manifest is also a good fit for audiobooks and made it easy to support streaming or caching for those (there's a desperate need to standardize audiobooks)
  *   it's a good fit for comics as well, which a WG within EDRLab is now working on
  *   it's also a good way of extending EPUB, since we can easily embed our manifest at a well-known location (manifest.json) and rely on it (instead of an OPF) for specialized use cases (like comics, where EPUB and FXL are super limited and get in the way of the reading system)
  *   the hypermedia nature of its design also made it a good fit for a new revision of OPDS (meant to distribute publications and browse/search a catalog) as well as a new generation of OPDS parsers
One thing that we never focused on where publications primarily distributed on the Web, because we didn't had a use case for them.

I think that the whole "EPUB vs the Web" thing is misguided. Instead of long discussions about polyfills we should focus on:

  *   affordances ("what we want to build in terms of UX")
  *   use cases ("why we're working on these specifications")
As we've seen with Readium-2 and the Readium Web Publication Manifest, sometime we accidentally find good solutions to problems that we never even considered in the first place.

Received on Friday, 9 February 2018 15:53:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:21 UTC