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

I completely agree with Dave.

El 21 sept. 2016 10:38 a. m., "Cramer, Dave" <Dave.Cramer@hbgusa.com>
escribió:

> 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.
>
>