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

Hi Marcos,

There has been a long-standing disagreement (some would say 'confusion', or
even worse) in the library community about the value of a 'work'. One way
to look at a book (or any other form of work) is that only the contents
matter. The other common way to look at a work is to say that the physical
form itself (the 'container') is the important part.

Sometimes both perspectives are valid. The physical object may be of
important historical value if it is an original first addition, or the only
original source material. The more common case is that it is only the
contents that matter; they may be places in many forms.

Your message has me wondering whether a variation on this age-old argument
also pervades the publishing industry. If so, this may be why we are
stumbling over terminology.

Your description of a WP seems to come from the perspective that a WP is an
application (a container that includes content). You call it an
application. Is that right?

I, and most Webby folk, have been presuming that a WP is just a bunch of
contents. Those contents may be acted upon by any of a number different
containers, such as a browser or an ebook reader. It is those containers
that would 'turn the pages', create the table of contents, manage hyperlink
clicking, etc.

Am I on the right track? If so, I would hope that we can surface the
perspectives so we can come to agreement. I would personally hope that a WP
becomes just the contents.

On Wednesday, 21 September 2016, 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...
>
>