RE: Web Publications via HTML Imports

Thanks for the proposal Dave. This is a very interesting way of using existing tools to create a WP.

Laurent, it seem that you are proposing requirements. Is a method a validating the metadata a requirement for WP?  I have been tracking requirements at [1]. Please take a look.

Again, we are not debating serialization at this point. The PWG has not yet open the topic of serialization for metadata, let alone reached consensus on what format it will be in. As Dave points out, the metadata can be embedded in multiple formats. Let’s not confuse discussions on GitHub with consensus in the larger Working Group.

[1] https://docs.google.com/document/d/1NzYLURq4zqkeGoCJbY-5rlIUsfPt9Dy5S10BLOA-tGg/edit?usp=sharing


Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Laurent Le Meur [mailto:laurent.lemeur@edrlab.org]
Sent: Monday, July 24, 2017 5:57 AM
To: Dave Cramer <dauwhe@gmail.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Web Publications via HTML Imports

I see some drawbacks in such a prototype:

- a web publication must convey structured metadata. The html meta element is a poor solution for metadata exchange (e.g. no way to validate the model).
- this import mechanism, when supported by a browser, fetches the complete set of imported resources. This is not really the need expressed (-> to list the resources and enable selective fetch).
- a native reading system would spend more time parsing such html (tag soup) structure than a small JSON or XML structure.

One could easily create an equivalent prototype with an HTML document fetching a JSON structure (.eg via jQuery.getJSON). The HTML document could then be used as a "browser-friendly" start page.

Cordialement,

Laurent Le Meur
EDRLab

Le 24 juil. 2017 à 05:31, Dave Cramer <dauwhe@gmail.com<mailto:dauwhe@gmail.com>> a écrit :

I've been experimenting a bit with a different approach to creating web publications.

Our fundamental goal is figuring out how to treat a collection of web resources as a single entity. It's not hard to create a list of such resources--EPUB had the package, PWG has been talking about JSON manifests. But both those things just refer to the resources rather than including them, and both those things aren't HTML.

And it occured to me that this exact problem was solved twice in the XML document world, first with external entities and then with xinclude. And HTML has created just such a feature, in the form of HTML imports*.

A web publication can be represented by a single HTML document that includes other documents via html imports:

<link rel="import" href="chapter-1.html">
<link rel="import" href="chapter-2.html">

I've made a little example at:

 https://dauwhe.github.io/zero-labs/MobyDickImport/MobyDickImport.html

(see #2 below for why you should view using Chrome).

I see lots of advantages:

1. It's harder to argue about what the URL of the web publication is :)

2. It's easy to provide fallback behavior. If you view the above link in Chrome, you see the entire copy of the book, as Chrome supports HTML imports. If you view the link in Safari or Firefox, you see the book table of contents, so you can still access every resource. And yes, there's a polyfill for HTML imports.

3. The HTML file containing the imports provides a "canvas" for authors who wish to supply their own user interface, and also allows reading systems to just take the links.

4. Nested web publications become easy.
.
5. Resources can be shared between different web publications.

6. The master HTML file is a natural location for publication metadata, which can be expressed with all the richness and i18n support of HTML (and can also be embedded as JSON-LD, etc.

7. Web app manifests could still be used to provide save-to-homescreen, etc.


*Yes, HTML imports are controversial, and may evolve into a module system. Lots of interesting discussions at https://github.com/w3c/webcomponents/issues/645. Might be fun to talk to Web Platform WG folks about our use cases. Finally something fun to do on Friday at TPAC!

Dave