Information content of the abstract manifest

[dauwhe]

From @dauwhe on June 27, 2017 14:33

What information is required for an abstract manifest? [edited to add items from comments]

1. An identifier for the web publication, which should be a URL
2. Some way of saying that this URL represents a web publication.
3. Some way of identifying the constituent resources of the web publication.
4. Some way of providing a preferred order of (some of) the constituent resources in case there is more than one
5. Some way of being able to add more complex metadata to a publication. (Not clear to my mind whether we would define a minimally required set of metadata, but the slot should be there.)
6. Locating table of contents or other navigation structure

What else? I think we should distinguish required information from "nice to have" information.

Copied from original issue: w3c/publ-wg#12

[dauwhe]

From @GarthConboy on June 27, 2017 14:56

I'd also throw in:

-- Reading order -- Basic metadata (yes, a can of worms we'll need to open)

Re the #1 and #2 just above in Dave's original issue, it seems they may want to be pre-manifest -- defined before the manifest is found, or be the actual path to the manifest (or to a "first file" that can be rendered, but also somehow points to the manifest).

[dauwhe]

From @iherman on June 27, 2017 14:56

4. Some way of providing a preferred order of (some of) the constituent resources in case there is more than one
5. Some way of being able to add more complex metadata to a publication. (Not clear to my mind whether we would define a minimally required set of metadata, but the slot should be there.)

[dauwhe]

From @iherman on June 27, 2017 14:56

(Wow. I just said the same thing as Garth just in other words. I swear we did not conspire...)

[dauwhe]

From @mattgarrish on June 27, 2017 15:54

What is meant by required here? Must always be present or must be accounted for in the design? This is why I wasn't sure at the f2f if navigation constituted a top-level or lower-level consideration.

A standardized means of locating the table of contents seems critical to me, even if it's optional to define and there are no epub-like rules on its construction.

[dauwhe]

From @GarthConboy on June 28, 2017 16:2

The updated #6 in the first panel says "Locating table of contents or other navigation structure", we should also consider:

-- Do we need such a Nav file (likely yes for A11Y) -- Should it be in the Manifest or pointed-to by the Manifest (I could see an argument for all eggs in one basket -- though the machine readable or renderable discussion will arise)

[dauwhe]

Do we need such a Nav file (likely yes for A11Y)

See #14

Should it be in the Manifest or pointed-to by the Manifest

Interesting question. I know Hadrien has proposed including section titles in a JSON manifest, but I have major concerns about possible reader-facing text in JSON (especially given that there's a standard html way to do this stuff).

[dauwhe]

From @HadrienGardeur on July 2, 2017 20:27

I know Hadrien has proposed including section titles in a JSON manifest, but I have major concerns about possible reader-facing text in JSON (especially given that there's a standard html way to do this stuff).

IMO the Navigation Document in EPUB 3 is a failed experiment. Most EPUB 3 documents that I've seen end up including at least two HTML table of contents:

• a nice looking one, included in the spine and not marked as being a Navigation Document
• a basic one, used as the Navigation Document

Most EPUB 3 reading systems do not render these Navigation Documents either, they simply parse them, extract the info and display things using their own UI.

This is a typical example of "spec purity" (the beauty of the Navigation Document) vs real world usage (no one is rendering these documents and we end up with more redundancy instead of less).

Readium (1, JS and 2) ended up parsing the info in the Navigation Document and providing a JSON output instead, which is much easier for developers to work with.

In the Readium Web Publication Manifest:

• there is absolutely zero requirement for a table of contents (I strongly believe that we shouldn't force a ToC on single resource publications that won't need one)
• all the different ToC types that exist in EPUB are parsed (NCX, landmarks in OPF and Navigation Document) and exposed in a consistent way (collections) in the manifest
• we also keep links to the Navigation Document in spine or resources and identify them as such using a rel value

[dauwhe]

From @HadrienGardeur on July 2, 2017 20:35

To go back to the initial question, in Readium we separate clearly the abstract model with the minimal requirements for a manifest.

The abstract model has three core concepts:

• metadata (based on JSON-LD)
• links
• collections (identified by a role, can aggregate metadata, links and other collections)

For each core concept, we make sure that:

• the requirements are very basic
• the model is flexible and powerful enough to allow the expression of complex use cases
• a number of extensibility points are available and clearly identified

The basic requirements for a manifest are then based on that model:

• a manifest should at least contain a title in its metadata
• it should at least contain a link to itself, identified by the self relation
• it should contain at least one resource in its spine collection, which contains the key resources for a publication in reading order

[dauwhe]

From @llemeurfr on July 3, 2017 12:43

An identifier for the web publication, which should be a URL

Better, an IRI because a) may be a urn (up to the publisher to choose, the Web doesn't care) and b) i18n is important. A URL to the origin is also important but should be another property.

[dauwhe]

From @WSchindler on July 3, 2017 14:47

I would like to add:

7. language(s) used in the WP - the plural is due to the fact that we will have publications such as parallel texts (original + one or more translations), bilingual dictionaries which contain 1-n languages . The language used has also implications for rendering (e.g. "ltr" vs "rtl", vertical layout)

[dauwhe]

From @HadrienGardeur on July 3, 2017 14:50

Language and direction (ltr vs rtl) should be two separate metadata. Agree that we need to allow more than one language.

[dauwhe]

From @lrosenthol on July 3, 2017 22:5

If we plan to use anything other than a URL (as defined by the HTML spec - https://www.w3.org/TR/WD-html40-970917/htmlweb.html), then we are going to need to be willing to jump into the current battle between the W3C and the IETF on the definition of URL/URI/IRI etc. Here is an old blog entry about it - http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI

On Mon, Jul 3, 2017 at 8:43 AM, L. Le Meur notifications@github.com wrote:

An identifier for the web publication, which should be a URL Better, an IRI because a) may be a urn (up to the publisher to choose, the Web doesn't care) and b) i18n is important. A URL to the origin is also important but should be another property.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-wg/issues/12#issuecomment-312635676, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNUBV20dmP2MLDyjT0lS3eVlEeU8gks5sKOHjgaJpZM4OGuBw .

[dauwhe]

From @llemeurfr on July 5, 2017 10:22

Re. URL vs IRI, after reading https://www.w3.org/International/wiki/IRIStatus, I must admit that this seems like a can of dirty warms. Apart from trying to allow for an extended i18n of publication identifiers, there is still the question of URNs allowed or not as global identifiers. For instance, I spotted that most @HadrienGardeur's Manifest samples use isbn urns as identifiers.

[dauwhe]

From @HadrienGardeur on July 5, 2017 12:47

@llemeurfr you're mixing up two different concept regarding the Readium Web Publication Manifest.

Keep in mind that we started this work in the context of BFF and that for Readium-2 we mostly ingest EPUB files.

The only requirement in the draft document for the Readium WebPub Manifest is to always provide a self link. In the context of a Web Publication it makes perfect sense: if a publications lives on the Web, we need a URL that can point to its manifest.

Here's a basic example using the Readium WebPub Manifest model:

"@context": "http://readium.org/webpub/default.jsonld",
"metadata": {
  "title": "The Master and Margarita"
},
"links": [
  {"rel": "self", "href": "http://example.com/manifest.json", "type": "application/webpub+json"}
],
"spine": [
  {"href": "http://example.com/chapter1", "type": "text/html"}
]

If the publication has an additional identifier, this can be provided in its metadata:

"metadata": {
  "title": "The Master and Margarita",
  "identifier": "urn:isbn:9780141180144"
}

That second identifier is not a requirement in the Readium model, and we can't expect all Web Publications to have such an identifier either.

The reason why most of our current samples have URNs (mostly for ISBNs or UUIDs) is because we ingest EPUB files or provide samples for books where ISBNs are very common.

[dauwhe]

I would like to add:

7. language(s) used in the WP - the plural is due to the fact that we will have publications such as parallel texts (original + one or more translations), bilingual dictionaries which contain 1-n languages . The language used has also implications for rendering (e.g. "ltr" vs "rtl", vertical layout)

My only concern is that HTML already has mechanisms for describing the language(s) of content. What happens when a user agent opens an HTML page declared with language A, finds a rel=manifest link, follows it, and sees language B declared?

[dauwhe]

From @HadrienGardeur on July 5, 2017 13:11

My only concern is that HTML already has mechanisms for describing the language(s) of content. What happens when a user agent opens an HTML page declared with language A, finds a rel=manifest link, follows it, and sees language B declared?

The manifest declares the language for the publication, while HTML is meant to declare the language for that resource. The UA would simply set the default to language B but override that option with language A as it displays or interacts with that HTML page.

[dauwhe]

From @llemeurfr on July 5, 2017 14:4

you're mixing up two different concept regarding the Readium Web Publication Manifest.

That's right. If a Web publication is copied to another website, this value will not be modified. Therefore a possible definition of the self link is "The original location of the Web Publication", which can be aligned with Requirement 8 for Web Publications: "There should be a way to uniquely identify a Web Publication."

[dauwhe]

From @HadrienGardeur on July 5, 2017 14:10

From RFC5988:

o Relation Name: self o Description: Conveys an identifier for the link's context. o Reference: [RFC4287]

[dauwhe]

From @WSchindler on July 5, 2017 15:36

It's of course true that via @lang or @xml:lang, you may define the language(s) used in your HTML. I still think that the point of entry for a UA consuming a WP would be the manifest where it would be helpful to find an information on the languages used in the WP. If you have a Chinese-English dictionary, it is IMO no trivial task to prepare the rendering.

[dauwhe]

From @lrosenthol on July 5, 2017 16:15

Actually, I would expect the UA to completely ignore the language settings (A, in this case) in the manifest - and only concern itself with the actual resource being processed/rendered (B, in this case). The language (or languages) in the manifest have no bearing on the actual content - they are (IMO) informational only.

On Wed, Jul 5, 2017 at 9:11 AM, Hadrien Gardeur notifications@github.com wrote:

My only concern is that HTML already has mechanisms for describing the language(s) of content. What happens when a user agent opens an HTML page declared with language A, finds a rel=manifest link, follows it, and sees language B declared?

The manifest declares the language for the publication, while HTML is meant to declare the language for that resource. The UA would simply set the default to language B but override that option with language A as it displays or interacts with that HTML page.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-wg/issues/12#issuecomment-313098532, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNbw7uxWapNOfZZN7r09Gmn2AxeqPks5sK4uKgaJpZM4OGuBw .

[dauwhe]

From @lrosenthol on July 5, 2017 16:16

If a Web publication is copied to another website, this value will not be modified

That's not necessary true. The new site may well change the link(s) in the manifest. There is nothing about it that is "off limits" - certainly not in a WP, and possibly not even in a PWP.

On Wed, Jul 5, 2017 at 10:04 AM, L. Le Meur notifications@github.com wrote:

you're mixing up two different concept regarding the Readium Web Publication Manifest.

That's right. If a Web publication is copied to another website, this value will not be modified. Therefore a possible definition of the self link is "The original location of the Web Publication", which can be aligned with Requirement 8 for Web Publications: "There should be a way to uniquely identify a Web Publication."

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-wg/issues/12#issuecomment-313112802, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNRbejRAPPpj2OsrzKSZptKCwspLPks5sK5gCgaJpZM4OGuBw .

[dauwhe]

From @HadrienGardeur on July 5, 2017 16:21

Actually, I would expect the UA to completely ignore the language settings (A, in this case) in the manifest - and only concern itself with the actual resource being processed/rendered (B, in this case). The language (or languages) in the manifest have no bearing on the actual content - they are (IMO) informational only.

While rendering content, sure I fully agree. But a UA can provide additional services on top of it, for example dictionaries or search. The publication metadata can be useful in that regard.

[dauwhe]

From @mattgarrish on July 5, 2017 16:21

I would expect the UA to completely ignore the language settings (A, in this case) in the manifest

I agree it's informative and must not be used for rendering content (or metadata), but the same question about value has been raised in epub revisions and the case has been made that it does have uses (e.g., pre-loading tts languages, offering access to dictionaries, etc.).

[dauwhe]

From @lrosenthol on July 5, 2017 16:23

On Wed, Jul 5, 2017 at 12:21 PM, Hadrien Gardeur notifications@github.com wrote:

But a UA can provide additional services on top of it, for example dictionaries or search. The publication metadata can be useful in that regard.

It could indeed be useful - and whether a UA chooses to use it for that or not is (IMO) out of scope for our work.

[dauwhe]

From @HadrienGardeur on July 5, 2017 16:24

It could indeed be useful - and whether a UA chooses to use it for that or not is (IMO) out of scope for our work.

Defining the UA behavior is out of scope, but making sure that it has relevant info needed is definitely within scope.

[dauwhe]

IMO the Navigation Document in EPUB 3 is a failed experiment. Most EPUB 3 documents that I've seen end up including at least two HTML table of contents:

a nice looking one, included in the spine and not marked as being a Navigation Document a basic one, used as the Navigation Document

I'm only responsible for around 25,000 EPUBs, but I've never seen an EPUB with two HTML tables of contents.

1. Do other publishers here commonly do this?

2. If so, why? I know that some reading systems don't support things like the hidden attribute, or list-style-type: none.

3. Do others consider the nav document to be a failure?

[GarthConboy]

Well, our reading system, FWIW, builds its in-UX TOC from the Nav document (or NCX, in the old days) -- only very rarely is this sufficiently "basic" as to not be the one the user expects to use for actual navigation.

And, I'd suspect our A11Y community would not consider a global navigation document as a failed experiment.

(and I'm certainly willing to admit that there are numerous things we invented from whole cloth in EPUB-land that would deserve the "failed experiment" moniker, but I don't think Nav docs would be one of them)

[HadrienGardeur]

Well, our reading system, FWIW, builds its in-UX TOC from the Nav document (or NCX, in the old days)

I'm not saying that the Navigation Document is useless but IMO it has essentially replaced NCX and nothing more. I've seen multiple examples where the NavDoc is strictly included in the manifest (<item>) without being included in the spine (<itemref>). Reading systems also tend to use the NavDoc like they used NCX: they extract the structural information from it without ever rendering the NavDoc.

IMO it's a failed experiment because:

• the NavDoc is strictly used for structural information, it's rarely rendered
• due to the limitations in reading systems (some of which you've listed above @dauwhe), content creators can be forced to create a separate HTML document that they include in the spine
• working with HTML for structured information is worse than working directly with XML/JSON, it's painful for developers. SDKs like Readium end up exposing these navigation docs as JSON or an in-memory structure instead of HTML.

I'm not in the same position as @GarthConboy but it would be interesting to run a large MapReduce job that estimates how often the NavDoc is included in the spine.

[TzviyaSiegman]

What I (and I think many other content providers) would like to see is the nav doc with a little bit more functionality. Yes, the current version is a replacement of the ncx. That is the intent. That is a reason that it's not included in the spine. The assumption is that the reading system will handle rendering. However, many publishers, myself included, provide users access to the Nav in more than one way via the spine. Especially in the world of educational publishing, there is interest in having the ability to stylize the nav. At a simpler level, sometimes it's important to display information such as subtitle or author names for individual chapters. This is not possible to do semantically in the current iteration of nav. Math in the nav can be a challenge as well. We also need to assess the accessibility of other options. @HadrienGardeur I don't think you can call this a failed experiment based on those criteria, nor do I especially care if we label it as such in order to move forward. It might be more beneficial to identify the requirements that we can learn from the way that people manipulate the nav and associated files. @GarthConboy might be able to provide actual data on how many EPUBs render the nav. 100% of the files I've published do.

[lrosenthol]

On Wed, Jul 5, 2017 at 6:47 PM, Tzviya notifications@github.com wrote:

What I (and I think many other content providers) would like to see is the nav doc with a little bit more functionality. Yes, the current version is a replacement of the ncx. That is the intent. That is a reason that it's not included in the spine. The assumption is that the reading system will handle rendering.

Though this is, as we have already discussed, not necessary the case. A publication may well want to have more control over the presentation and thus want the UA (we're trying not to use the RS verbiage, I thought) to do nothing.

However, many publishers, myself included, provide users access to the Nav in more than one way via the spine. Especially in the world of educational publishing, there is interest in having the ability to stylize the nav. At a simpler level, sometimes it's important to display information such as subtitle or author names for individual chapters. This is not possible to do semantically in the current iteration of nav. Math in the nav can be a challenge as well. We also need to assess the accessibility of other options.

All of which would be addressed by simply moving presentation and navigational control from the UA to the publication. It would also ensure that your publication looks and works the same in all UAs - which they certainly do not do now. (of course, it has the opposite effect of making your publications work differently than someone elses).

[HadrienGardeur]

At a simpler level, sometimes it's important to display information such as subtitle or author names for individual chapters. This is not possible to do semantically in the current iteration of nav.

These are interesting use cases, but why would you include such metadata (subtitle, author names) in the NavDoc instead of the documents themselves or a manifest? If there's a way this can be both semantically structured and accessible today, that would be a good argument but I'm not aware of a solution handling both together in HTML.

FYI, I'm not against the idea of rendering a NavDoc or its equivalent, I just have a hard time believing that we can achieve something that is good at replacing NCX and being rendered at the same time.

[dauwhe]

but it would be interesting to run a large MapReduce job that estimates how often the NavDoc is included in the spine.

I don't think this would tell us anything about the utility of the nav doc. 70% of the books we publish do not include a table of contents in the print edition. Whether a nav doc is included in the spine of an ebook is a design & content choice, not a description of the importance of having navigation available to the user.

[HadrienGardeur]

I'm not questioning the utility of the NavDoc, I'm questioning its design and its added value over what we had with NCX.

[mattgarrish]

There's a flawed assumption here that the navigation document was just the ncx with possible spine rendering. The NCX had to be replaced because it didn't handle i18n issues (ruby, bidi, etc.) or provide any flexibility for emphasis, etc. Reading systems may not utilize all those features, but HTML was the easier pick for how to address than going back to the drawing board on the NCX. That it could also be used in spine was an added bonus.

[HadrienGardeur]

My personal preference would be to let publications decide when:

• they want to use their own navigation as HTML (with a simple way to indicate that such a resource is meant for navigation, probably a link relation)
• and offer a different way to provide navigation that will be useful for the UA either internally (page-list) or in its UI (table of contents, landmarks, guided navigation)

Let HTML be HTML (with nice CSS sprinkles on top) without trying to cram structured information that it awkwardly attempts to contain.

[TzviyaSiegman]

The NCX had to be replaced because it didn't handle i18n issues (ruby, bidi, etc.) or provide any flexibility for emphasis,

This is very important to remember. The ncx was replaced for a reason, not just on a whim, HTML was chosen for a number of reasons. We would need a compelling reason to choose something other than HTML.

Let HTML be HTML (with nice CSS sprinkles on top) without trying to cram structured information that it awkwardly attempts to contain.

Well, HTML does a pretty good job of being structured information. Why should we invent mechanisms to replace existing structures? If <nav> serves the purpose we need, why change it.

However, this is not the topic of the thread. What is needed for the minimum viable abstract manifest? I will dig up the research we did for EPUB 3.1 on this. I have an anonymized survey of EPUB user agents and what they required.

[dauwhe]

The NCX had to be replaced because it didn't handle i18n issues (ruby, bidi, etc.) or provide any flexibility for emphasis, etc.

We still run into this nearly every day. Our editors ask us to make a word italic in ebook navigation. Easy with HTML. Impossible with NCX. Unlikely with JSON.

[GarthConboy]

I agree with a number of the comments above, clearly Matt's "added bonus" (as the Nav Doc replaced NCX) becoming renderable was a nice feature. Also, along the same lines, for the large number of publications (but likely well less than 50%) that do want a renderable/in-line TOC, the Nav Doc supports both features concurrently (machine processed Nav for the RS and renderable TOC) without duplication of data.

But, getting back to Tzviya's point -- "what do we need in a manifest?" I think a "publication" must support a mechanism such that machine-readable Nav information can be communicated to the "reading system" (or UA). This statement is true due to both RS functional requirements and A11Y ones, and doesn't presume to answer the HTML or JSON or XML format question or the in or out of manifest question. Just, that we must have a mechanism to support this functionality. I kinda hope this is not too arguable.

What certainly is arguable, is the details. I would propose the following: WP optional, PWP required, HTML format, referenced from manifest.

[lrosenthol]

I think a "publication" must support a mechanism such that machine-readable Nav information can be communicated to the "reading system" (or UA).

I think we can agree on that...though one caveat will be whether we believe that such "machine readable" information is declarative, programmatic or either...

On Thu, Jul 6, 2017 at 10:44 AM, GarthConboy notifications@github.com wrote:

I agree with a number of the comments above, clearly Matt's "added bonus" (as the Nav Doc replaced NCX) becoming renderable was a nice feature. Also, along the same lines, for the large number of publications (but likely well less than 50%) that do want a renderable/in-line TOC, the Nav Doc supports both features concurrently (machine processed Nav for the RS and renderable TOC) without duplication of data.

But, getting back to Tzviya's point -- "what do we need in a manifest?" I think a "publication" must support a mechanism such that machine-readable Nav information can be communicated to the "reading system" (or UA). This statement is true due to both RS functional requirements and A11Y ones, and doesn't presume to answer the HTML or JSON or XML format question or the in or out of manifest question. Just, that we must have a mechanism to support this functionality. I kinda hope this is not too arguable.

What certainly is arguable, is the details. I would propose the following: WP optional, PWP required, HTML format, referenced from manifest.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wpub/issues/6#issuecomment-313417458, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNcNPyRX2ISeKyCo8fl8tPgKbcw5Lks5sLPK8gaJpZM4OOnGN .

[HadrienGardeur]

Are we aware of any UA actually using the benefits from HTML in the NavDoc? Truly extracting bidi, ruby and all?

I'm not talking about rendering that content, but extracting the info to use it in its own UI.

[HadrienGardeur]

Well, HTML does a pretty good job of being structured information. Why should we invent mechanisms to replace existing structures? If

serves the purpose we need, why change it.

We're not "just" using <nav>. It would make things much easier if that was the case. There's a fairly long list of restrictions (http://www.idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-nav-def-model) and the hidden attribute isn't well supported.

HTML isn't that good at structured information, and after many attempts at injecting RDF one way or another into HTML, the current trend is to keep things separate using JSON-LD instead.

[lrosenthol]

HTML isn't that good at structured information,

That is very true, unfortunately.

and after many attempts at injecting RDF one way or another into HTML, the current trend is to keep things separate using JSON-LD instead.

For what use cases? For microdata/object-level-type operations, having the info directly on the node (ask RDFa, for example) is much better than having the data separate (and thus easier to get out of sync). Of course, for document level stuff, then sure, a blob of JSON(-LD) is fine.

On Thu, Jul 6, 2017 at 11:45 AM, Hadrien Gardeur notifications@github.com wrote:

Well, HTML does a pretty good job of being structured information. Why should we invent mechanisms to replace existing structures? If serves the purpose we need, why change it.

We're not "just" using

. It would make things much easier if that was the case. There's a fairly long list of restrictions ( http://www.idpf.org/epub/30/spec/epub30-contentdocs.html# sec-xhtml-nav-def-model) and the hidden attribute isn't well supported.

HTML isn't that good at structured information, and after many attempts at injecting RDF one way or another into HTML, the current trend is to keep things separate using JSON-LD instead.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wpub/issues/6#issuecomment-313436019, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNY8pISLQgG5qpZGt-K3l2P1mNkmKks5sLQEogaJpZM4OOnGN .

[HadrienGardeur]

What certainly is arguable, is the details. I would propose the following: WP optional, PWP required, HTML format, referenced from manifest.

@GarthConboy how do you create a PWP out of a WP if you require navigation that won't exist in the first place?

I agree that in general we should encourage the presence of navigation in PWP/EPUB 4, but if we want a seamless experience between WP and PWP, this will be difficult.

[HadrienGardeur]

We still run into this nearly every day. Our editors ask us to make a word italic in ebook navigation. Easy with HTML. Impossible with NCX. Unlikely with JSON.

@dauwhe did the NavDoc solved that issue? Do UA display the word in italic in their own UI now that HTML is used to provide navigation?

My guess is that most of the time, they don't. How can we expect UA to leverage bidi, ruby, mathml etc. when they don't even use basic HTML features?

IMO this group is overselling the usefulness of HTML for navigation handled natively by the UA. Very big gap between theory and real-world use case.

[lrosenthol]

I think it all depends on what we mean by "navigation", @HadrienGardeur, just like with what we mean for "manifest". Is it declarative or programmatic? What format(s) would it take? How (or if) do we expect the UA to process it? (not asking for answers now, just pointing out the questions)

On Thu, Jul 6, 2017 at 11:53 AM, Hadrien Gardeur notifications@github.com wrote:

What certainly is arguable, is the details. I would propose the following: WP optional, PWP required, HTML format, referenced from manifest.

@GarthConboy https://github.com/garthconboy how do you create a PWP out of a WP if you require navigation that won't exist in the first place?

I agree that in general we should encourage the presence of navigation in PWP/EPUB 4, but if we want a seamless experience between WP and PWP, this will be difficult.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wpub/issues/6#issuecomment-313438244, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNYuLHXfPSTSyqzTthWj9uISpddOlks5sLQLygaJpZM4OOnGN .

[hadrien]

Not the good hadrien @lrosenthol ;-) CC @HadrienGardeur

[HadrienGardeur]

@lrosenthol

The expectation for the NavDoc was that it would be used for:

• extracting structured information (which is what most if not all EPUB 3 UA do)
• rendering the document (which is not as common since you'd have to include the NavDoc in the spine for most UA)

I fully agree that if you render the document, we get all sorts of benefits from using HTML.

But when we extract structured information from the NavDoc, we end up with something that is equally as limited as NCX/XML/JSON regarding i18n.

[dauwhe]

But when we extract structured information from the NavDoc, we end up with something that is equally as limited as NCX/XML/JSON regarding i18n.

Seems like this is a limitation of the extraction process rather than the source format.

[lrosenthol]

And also makes me wonder what type of "structured information" is in there that wouldn't be in our manifest.... (thinking we might be able to have only a single document for all this instead of multiple)

As far as rendering, HTML is what gets rendered on the web by a UA - so I don't see why we would want anything else?!?

On Thu, Jul 6, 2017 at 12:11 PM, Dave Cramer notifications@github.com wrote:

But when we extract structured information from the NavDoc, we end up with something that is equally as limited as NCX/XML/JSON regarding i18n.

Seems like this is a limitation of the extraction process rather than the source format.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wpub/issues/6#issuecomment-313443573, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNXHZLWy04M2foGPuGzPB1gGKAPWpks5sLQc7gaJpZM4OOnGN .

[HadrienGardeur]

And also makes me wonder what type of "structured information" is in there that wouldn't be in our manifest.... (thinking we might be able to have only a single document for all this instead of multiple)

Fully agree.