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

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

Received on Wednesday, 21 September 2016 05:19:17 UTC