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

Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

From: Ric Wright <rkwright@geofx.com>
Date: Fri, 09 Feb 2018 11:32:14 -0600
To: Ivan Herman <ivan@w3.org>
CC: "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>, Dave Cramer <dauwhe@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-ID: <D6A3332B.614535%rkwright@geofx.com>

I think one of the keys here is the phrase ³put it on my website².  What
does that mean?  Presumably FTP or some other means to put it in the correct
folder of your website where users will somehow see the book be able to
select it.  Then the ³browser² will detect the selection open the book and
the user begins reading.

With Readium it is similar. One has to deploy the CloudReader on the website
(come back to that in a minute), upload the book to a specified location
and the CloudReader sees the book, displays the cover and when they user
clicks on the book, it opens and youıre off reading.

So, yes, you need to CloudReader installed on your server.  Or if you have
the latest Edge, some of that is built-in.  Readium would be happy work with
any or all of the browsers to get the CloudReader capabilities present as a
part of the browser. Not trivial, but no unknowns either.

But is that what weıre trying to do? Lay out a blueprint for the browsers
how to display EPUBs (zipped or unzipped)?  That seems to be to conflate two
very different pieces:  the document to display and how to display it.  The
former (letıs call it EPUB) is a document specification/implementation.  The
latter seems to me to be software engineering and not really amenable to
specification at all ­ which maybe is the problem Iım having.


From:  Ivan Herman <ivan@w3.org>
Date:  Friday, February 9, 2018 at 11:10 AM
To:  Ric Wright <rkwright@geofx.com>
Cc:  "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>, Dave Cramer
<dauwhe@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, Daniel Glazman
<daniel.glazman@disruptive-innovations.com>, W3C Publishing Working Group
Subject:  Re: Pursuing the wrong goal? (was Re: A followup/writeup on our
Monday discussions (was Re: Continuing discussion on Polyfills))
Resent-From:  <public-publ-wg@w3.org>
Resent-Date:  Fri, 09 Feb 2018 17:11:07 +0000


thanks for your examples, they are great. But I have a question: how do I
get there? Where is the EPUB file? Do I have to start up a separate
application, "load" that EPUB file into it before I can see/read it? The
same questions if I unzip the content?

Put it another way: I would like to "just" create the content, put it on my
web site, and click on it from any web browser to get it displayed, eg, via
that readium app. Just as I can do it with a simple HTML file. How do we get


> On 9 Feb 2018, at 17:57, Ric Wright <rkwright@geofx.com> wrote:
> I guess I am very much in agreement with Nick and Dave here ­ what ARE we
> trying to do in this WG?  If we look at what the WG is chartered for and is
> apparently trying to do, one has to wonderŠ why?  If we were a proposed
> startup and came up with all this (e.g. FPWD) etc.  and went before a bunch of
> venture capitalists and said ³hereıs what we propose spending your money on²
> they might very well come back with the question:  "What is the value
> proposition?  What are you proposing spending a lot of time and money on that
> EPUB and the existing Web donıt provide?²
> Personally, I would have a hard time answering that question, but that may
> just reflect my limitations (which are legend).  But I come from a  long line
> of ³show me the bits² type of engineering and product development.  For
> example, consider two examples, both based on a fully deployed, production
> version of the Readium CloudReader:
> https://readium.firebaseapp.com/?epub=epub_content%2FHales-Motivic-Measure&got
> o=epubcfi(/6/8!/0)
> <https://readium.firebaseapp.com/?epub=epub_content/Hales-Motivic-Measure&goto
> =epubcfi(/6/8!/0)>
> https://readium.firebaseapp.com/?epub=epub_content%2FNeHe-EPUB-17-32&goto=epub
> cfi(/6/2!/4/2/2) 
> The first is an EPUB with a LOT of math in it (which is why it is a bit slow).
> The second has a lot of WebGL in it (ditto).  Note that the CloudReader also
> supports shared annotations via the Hypothes.is <http://hypothes.is/>  plugin.
> So one has a full EPUB 3 compliant reading experience (including
> media-overlays), annotations, even WebGL.  These same publications can be
> unzipped onto a server as-is and would work.  As Hadrien pointed out, the work
> on Readium 2 has developed a ³better OPF² (Web Pub Manifest) but is that what
> weıre trying to achieve? If so, are we done?
> Iım probably way over-simplifying this but it seems like weıre making this far
> more complicated than it needs to be, but I am probably just misunderstanding
> what it IS we are trying to achieve.  But if so, then to echo Baldur, I donıt
> think I am alone.
> Thanks
> Ric
> From: "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>
> Date: Friday, February 9, 2018 at 8:56 AM
> To: Dave Cramer <dauwhe@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>
> Cc: "daniel.glazman@disruptive-innovations.com"
> <daniel.glazman@disruptive-innovations.com>, "public-publ-wg@w3.org"
> <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))
> Resent-From: <public-publ-wg@w3.org>
> Resent-Date: Fri, 09 Feb 2018 14:57:14 +0000
> Dave,
> This was beautifully put.  Along with Baldurıs amazing comments earlier ­ this
> sums up how I feel as well.  My perspective coming into this is as an
> entrepreneur, and an author.  I worked at Vook putting audio/video into
> ebooks, and worked on experimental features that only worked in ibooks.  I
> worked with Aerbook, creating award winning book-apps as well as
> javascript-powered ebooks that ­ again ­ only worked in iBooks.  I built an
> interactive ebook creation tool that would output apps, epubs and interactive
> webpages.  
> After 5 years of developing bleeding-edge things and hacking the ibooks
> platform to create content (only to later have ibooks Œpatchı out and prevent
> the use of that) I checked the #eprdctn hashtag only to see people still
> complaining that dropcaps still donıt display correctlyŠ
> Thatıs why I joined this group ­ because I feel like the web is a really good
> solution to publisherıs needs, but it just needs a bit extra.  Beyond the
> display issue, having run an ebook retail website, the amount of customer
> service Iıve had to deal with to try to help people read an epub file is
> insane.  Some people are just not tech savvy, some refuse to install apps,
> some are on work PCs and donıt have admin rights, so they canıt install apps.
> There is a business solution around this ­ to provide a web-based reading
> platform like Readium JS, so I guess there is a solution.
> I think about the basic use-case of people who are buying ebooks from my
> service.  (We sell e-textbooks, trade, and pretty much anything else).  At
> itıs core, they want to read the content.  Literally, they want to just open
> the book, and read itıs content in the order it would be presented in a
> printed book while being able to jump around easily from chapter-to-chapter.
> If the web were able to deliver those basics ­ and I was able to offer some
> sort of reading app solution that provided all the bells-and-whistles ­ my
> customer service requests would fall by nearly 80%!
> But I struggle (now more than every) with where the line draws.  I currently
> unzip epubs that are distributed to my system, then sort the files into
> directories (for security reasons) and serve them up with a custom UI that
> provides basic user needs for the purpose of sampling.  Thereıs only time
> stopping me from being able to make that a reading experience and solving my
> own problems without needing standards or expecting browsers to change.  What
> if epub is good enough ­ because it is HTML/CSS inside, and any service like
> mine can simply do what it needs fairly easily to make the ebook a web-based
> citizenŠ
> Part of the exercise Iım going through with my code right now is to create
> something I can share (sadly code I do for work must remain private) and
> provide as an example to help me answer that question ­ what is the real
> problem weıre needing to solve?  Maybe all we need to do is push for better
> display of math, better support for accessibility within a multi-document
> structure, and better handling of annotations.  Maybe all the rest is up to
> the industry to solveŠ
> -Nick
> From: Dave Cramer <dauwhe@gmail.com>
> Date: Friday, February 9, 2018 at 9:06 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: "daniel.glazman@disruptive-innovations.com"
> <daniel.glazman@disruptive-innovations.com>, "public-publ-wg@w3.org"
> <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))
> Resent-From: <public-publ-wg@w3.org>
> Resent-Date: Friday, February 9, 2018 at 9:07 AM
> (Note: written for a different email chain, but this rant describes some of my
> concerns with WP)
> At least this is the conversation we should have been having for the last four
> years!
> What problems are we trying to solve?
> EPUB works, more or less. My company has sold a billion dollars' worth of
> ebooks. Our industry gets people to pay for digital content‹we make HTML
> without advertisements. It's a miracle. At the most basic level, EPUB does
> what it needs to do‹it gets (some kinds of) books to the people, and they can
> read them without worrying too much about technology.
> Books are not apps. Books are not websites. Oh, we can do both of those
> things. We have done both of those things, and it didn't work‹nobody cared.
> Web Application Manifest solves a particular problem‹being able to save a web
> site to the home screen of your mobile device. WAM is for making web apps more
> like native apps. But our problem is not that web books are lacking
> capabilities of native book apps.
> I think the fundamental issue is that books are a separate category of media,
> their own thing. Our expectations of user interface and affordances is very
> specific to books, not generally shared with other web stuff, and much closer
> to how we think about other specialized media, like music and movies. I don't
> have five thousand separate album apps on my computer or my phone. I have one
> app, which accepts a certain kind of content and provides an identical
> interface for each discrete creative work. That's what reading systems are,
> too. That's how people think about books.
> What problems are we trying to solve?
> We want a web publications spec. Are web publications actually a thing we
> need? What do we actually mean by web publications? I share Garth and
> Benjamin's concern about providing the interface along with the content. The
> strength of the web stack is separation of concerns, although the script
> kiddies seem to be forgetting that. Content is HTML. Design is CSS.
> Interaction is JS. And what we forget is that browser itself provides much of
> the user experience, handling links, bookmarks, history, search,
> personalization, and so on.
> What are some real problems? Nothing works everywhere‹some things work
> nowhere. We mostly can't make books with scripting. We can't link from book to
> book. We don't know what the heck to do with math. ebooks still look like crap
> compared to print, or most websites. Making and editing EPUBs is a bitch.
> Everybody complains about walled gardens, but the gardens are more like vacant
> lots with broken glass and burned-out cars. The ebook ecosystem is more like
> gang territories‹don't try to bring your Kindle books to Google Play or you
> might get beat up. What we need more than anything else is interoperability.
> Does the road we're going down in PWG get us closer to that, or further? I
> don't know.
> I think the very nature of how we relate to books means that packaging is our
> key concept. Maybe we need PWP without WP. Maybe the trouble we're having with
> WP is not accidental, but intrinsic. Books are more permanent than web sites,
> we feel more ownership of them, they are more a "thing". We don't travel
> through the intertubes to visit the one copy of a book on a server somewhere.
> We each have our own copy, so the book has to travel, has to be a thing, has
> to be packaged. Maybe the packaging itself can provide the structure we're
> struggling with. 
> Dave
> On Fri, Feb 9, 2018 at 7:41 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> Daniel - I think you hit the nail on the head there, but perhaps not in the
>> way that you meant.
>> I believe that this group - for obvious reasons - is too focused about
>> finding a replacement for EPUB and *not* focused on building the future of
>> publications for the web.  And yes, I very strongly believe those are two
>> completely different things.  As you have said so well in other threads -
>> let's go ahead and fix EPUB and address the concerns of *that* industry...but
>> do that completely separately from solving what is needed to enhance the web
>> for publications (of all types).
>> I believe that it can be accomplished - even with our current charter - but
>> it will require everyone to *want* to work in this fashion....
>> Leonard
>> On 2/9/18, 1:05 AM, "Daniel Glazman"
>> <daniel.glazman@disruptive-innovations.com> wrote:
>>     Le 08/02/2018 à 22:15, Romain Deltour a écrit :
>>>     > +1000. Can't agree more.
>>     I wish I had Baldur's eloquence (I'm serious) but I'm only a frog.
>>     I could not have written this better, and I am in full agreement
>>     with everything Baldur said. With all my tech background, I wonder
>>     where this WG is heading at and, worse, why... And the WG is voting
>>     on that.
>>     We're still in the "Deep concerns about the future of EPUB" that were,
>>     after all the denials, apparently spot-on.
>>     </Daniel>

Ivan Herman, W3C 
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Friday, 9 February 2018 17:33:49 UTC

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