Re: Rough sketch for WP, was Re: Dereferencing, was Re: Jotting down some discussion topics

Hi Marcos,

Apologies for top-posting, but it seemed to be the format that suited my
content :)

First of all, I wanted to thank you for your contributions to this
discussion. This is exactly what the publishing community (or at least
me!) has hoped for over the last three years‹full engagement from the web
community. This is awesome!

For quite a few years, some of us have been kicking around a set of ideas
which I've called ³EPUB Zero². Having worked with ebooks for fifteen
years, the complexity and insane duplication of content in EPUB have
driven me mad. So Iıve been wondering what the simplest possible ebook
format might look like. The goal was to use only HTML, instead of all the
custom XML vocabularies in EPUB.

A publication is, at its core, a bounded sequence of content documents.
How could we express such an idea in HTML? Itıs almost like we need an
ordered list of links to documents. Hmmm. If only there were an HTML
structure that was an ordered list of linksŠ wait, there is!

EPUB has always required a navigation document, as it was deemed to be
critical for accessibility, and EPUB (to the benefit of all of us) has
always been very focused on accessibility. And so a table of contents, in
the form of a HTML document with a nav element, could serve to define the
sequence of content documents. And it would have major advantages over a
TOC generated from content (a subject for another email).

Such a nav doc could contain the link to the web app manifest. It could be
used as a TOC in a browser reading mode optimized for publications (as
defined in the manifest). It could be the container for metadata that
applies to the publication as a whole. It would allow easy access to any
part of the publication, even in the absence of any more sophisticated
code in the browser, manifest, or service worker. Itıs the ultimate
fallback.

Dave


On 9/21/16, 6:18 AM, "Marcos Caceres" <marcos@marcosc.com> wrote:

>On September 21, 2016 at 1:37:59 PM, Ivan Herman (ivan@w3.org) wrote:
>> Terminology issues, I guessŠ (I hope!). We still have to define what
>>response the server
>> would return on a URL for a WP, right (in terms of mime type, etc).
>
>We don't. It's just HTML. We don't need to define anything else. WP
>are not a concrete thing: they are just web applications that want to
>be displayed inside browsers in some particular way (i.e., the webview
>has a slightly different set of UI buttons... but it's still just a
>browser). Some WPs will just want the standard browser toolbar...
>others may request full screen, and maybe an orientation lock, etc.
>It's up to the publication/application - and this would be done via
>web manifest (or the appropriate low-level API).
>
>Also, there are two classes of web applications that we need to cater for:
>
> 1. Libraries: like Safari Books, an academic journal website, or a
>magazine (current and back issues, like the Economist) - those are
>applications that allow access to 1 to many "publications". The
>solution must cater for switching in and out of the particular display
>mode.
>
> 2. Standalone publication: a website that is itself "a book" or
>similar that wants this special UI (which the user selects and has
>full control switching in and out of!).
>
>>  If I use a URL for a HTML
>> or an SVG page, and I issue a HTTP GET, the server would return the
>>corresponding mime type.
>> The same should be known for the WP case.
>
>That's handled by fetch. We don't need to do or define anything.
>
>(Also, it's not even worth talking about SVG being served as an
>application: No one does that, so let's not even bother talking about
>it. Let's focus on the 99.999% case, which is HTML - SVG is an image
>format embedded in HTML.)
>
>> (What I would probably expect is that the return would be something
>>like an (extended)
>> Web Manifest, or a (HTML) page with a reference to a manifest
>>somewhere. But that is to
>> be defined.)
>
>It would be a HTML page with a link rel manifest in it. The manifest
>need not be "extended" - if we, the web community, work together, we
>can get everything standardized.
>
>It would NOT be a manifest: that would break the web for users and
>would not degrade gracefully (e.g., in a non-supporting user agent).
>Thus, we should never pass around URLs that dereference to some form a
>user can't work with. We, humans, only share URLs that dereference to
>HTML. A supporting user agent would then pick up the link rel=manifest
>and do the right thing.
>
>> I seem to be absolutely old skool here, but what would be, in your
>>view, the right terminology?
>
>Don't fret about terminology (I have no idea about it either, so let's
>try to avoid fancy jargon and focus on simple concepts)... I think we
>are all still all percolating what this will look like, but my **very
>rough** sketch:
>
>1. A WP is a web app whose manifest optionally has its "display" mode
>set to "publication". This allows the browser to offer a
>publication-specific set of UI controls to the end-user (the ones we
>know and love from ebook readers: page numbers, switch between
>dark/night mode, maybe the browser also changes the dimming timeout,
>etc). The user would switch into this mode, as they do today in, for
>example, Safari's reader mode - or by "installing" these
>"publications" into the browser (similar to bookmarking, but purpose
>built for publications)... see also how "progressive web apps" are
>installed, same thing.
>
>2. A WP optionally includes metadata that users would want to find
>these things on... this set would be extremely limited at first and
>there would need to be precedence for this, so maybe only author and
>category would make the cut! Though category is dubious because it
>doesn't internationalize well (so it's pretty garbage). I'm still
>somewhat skeptical if "id" would make the cut (e.g., {type: "ISBN",
>id: "..."}), as ISBN, etc. can be included into the actual HTML of the
>publication.
>
>3. A WP would have a (likely) Service Worker API that allows the apps
>to optionally say, "this object hierarchy represents the related
>documents - and how each should be represented in the ToC".
>
>4. A WP would have a (likely) Service Worker API to indicate which
>resources are searchable - probably as part of 4, to create the book
>search index.
>
>5. A WP can be sync'ed across multiple devices via the forthcoming
>manifest "service_worker" member. This is just a normal service worker
>that handles all the synchronization of offline content, d/ls
>annotations to put into IndexedDB, etc. and whatever other things need
>to happen to get everything into the right synchronized state (e.g.,
>matching document location).
>
>That's it for now - what am I missing? I'd love to see other short
>rough sketches of what people are thinking...
>

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.

Received on Wednesday, 21 September 2016 09:36:38 UTC