Limiting reading order to the manifest

[HadrienGardeur]

Our current draft allows the reading order to be defined outside of the manifest:

The default reading order is either specified directly in the manifest or in an [html] nav element. In the latter case, the manifest MUST provide a link to the Web Publication resource that contains the nav element, with a fragment identifier that specifically identifies it.

This is IMO problematic on multiple levels.

First of all, as @iherman has recently summarized in a this Wiki:

The major technical contribution of Web Publication is to introduce a collection of resources as one conceptual resource on the Web, ie, identifiable by a URL. The collection consists of all kinds of Web resources, and has metadata assigned to the collection as a whole.

But our draft allows a manifest that would only include:

• a title
• and an address for the publication

The UA would have to extract the reading order somehow (I guess by fetching the document returned by the WP address).
This allows some even more bizarre examples, where a manifest contains a list of resources but no reading order, and you somehow have to guess which HTML resource might contain the reading order.

I don't think that such a manifest fits the description just listed above as it doesn't truly define a collection. In a collection, the items that are part of the collection (what we often call "the boundaries") are every bit as important as the associated metadata.

Having the reading order in a separate document also adds a lot of complexity to our lifecycle, as you can see in the current draft (keep in mind that a final version would have to be even longer than that since we need to expand the items that extract the nav and deduplicate items).

Limiting the reading order to the manifest would divide the steps in our lifecycle in half (if not more, since we might also drop the section about obtaining a manifest) and would be far more consistent with our stated goal.

Here's an alternate proposal to our current draft:

• the Web Publication Manifest infoset MUST contain a reading order
• the manifest itself SHOULD contain a reading order
• if a reading order is not declared in the manifest, the fallback behaviour is to use the WP address as the only item in the reading order

[llemeurfr]

It's worth noting again that the discussion about the reading order in the manifest must be treated separately from a discussion about the presence of a table of content in the manifest. The former is a way for the reading system to chain (prev/next) the constituants of the publication, where the latter is a way for the user to navigate in the publication.

[HadrienGardeur]

I'm posting the Microsoft and Edge team feedback relevant to this issue here (thanks @BCWalters):

We need to simplify what we expect user agents to do and reduce the flexibility and complexity of web publications. From our perspective, everything required to render the web publication should be included in a manifest. It should be the role of tools to be able to extract data from HTML, not reading systems.

[HadrienGardeur]

@BCWalters would the alternate proposal work for you and your team?

Here's an alternate proposal to our current draft:

• the Web Publication Manifest infoset MUST contain a reading order
• the manifest itself SHOULD contain a reading order
• if a reading order is not declared in the manifest, the fallback behaviour is to use the WP address as the only item in the reading order

[BCWalters]

That's much better, though I'd go even further. Reading order seems to be fundamental to web publications, so why not require the reading order in the manifest itself? User agents need to bail out if a manifest is completely invalid (invalid JSON, for example), and it's better for content/tool developers who accidentally leave out a reading order to flag that as a fatal error rather than let them find out after navigating to the end of the WP address.

[HadrienGardeur]

In the Readium Web Publication Manifest, we made the reading order a requirement.

The core difference with Web Publication though, is that WP already requires an address. As long as we have at least one URL, we can make things easier for single page publications by skipping the reading order entirely.

That said, this is all about balancing things out. If we think that a reading order for single resource publication is not too much of a burden, we could align WP with Readium WPM.

[iherman]

Charles will make a writeup for this affordance or propose closing, based on the discussion on 2018-05-31.

[HadrienGardeur]

This can be closed, we resolved this issue during the F2F in Toronto.