Can a JSON package file function as a navigation document?

[dauwhe]

Since EPUB BFF can provide the equivalent of a table of contents with a single level of depth (no nesting), is it still a requirement to have a Navigation Document? Should the Navigation Document become optional, for example to provide a more complex structure or provide things that only an HTML text node can do?

"links": [{
"href": "c001.html",
"media-type": "text/html",
"title": "Loomings"
}]

[rdeltour]

It is absolutely essential to provide a way to navigate deep in the content, like with a heavily nested toc. Could you do that with the BFF JSON?

If not, then I'm afraid that allowing BFF to be used as a single-level nav alternative may entice authors into not caring about providing a more detailed nav doc, which would be an issue notably for accessibility.

Also, consider the i18n issues also raised in #16.

[dauwhe]

I agree that a JSON manifest should not function as a navigation document. Navigation is often human-facing, and we need the expressiveness of HTML for that. And I think the existing solution of nav is a good one.

[HadrienGardeur]

I never suggested that it would fully replace the Navigation Document, and I think that the spine and ToC are potentially two different structures (that's something I really disliked in the HTML serialization proposal).

That said, for a good number of publications, a single level of depth and not being able to do i18n/Ruby/MathML is not a concern at all, and having to create an additional Navigation Document is a burden that we could avoid.

I do find it quite amusing that you're concerned about nesting slightly more the JSON document, but forcing a short story or basic novel to duplicate information and create another document is considered to be fine.
This says a lot about what this community is used to (EPUB) and what it's not used to work with (JSON).

[rdeltour]

I do find it quite amusing that you're concerned about nesting slightly more the JSON document, but forcing a short story or basic novel to duplicate information and create another document is considered to be fine.

I'm not sure who you're replying to in this paragraph, as I think neither Dave nor I talked about having concerns with nested JSON here.

My concern is rather about duplication of functionality. What you propose is basically an alternative way to provide navigation functionality to simple publications (short novel, comics, etc). I understand the use case is appealing, but then there is a huge risk IMO that people start using it in the general case and just ignore the more advanced option, resulting in lower-quality navigation in the general case.

So basically, my point is that there should be one and only one way to add navigation to a publication. If you want to propose a JSON syntax for it, go for it (although personally I think HTML is just fine in this context), but in that case it should entirely replace the Nav Doc, not just partially.

[iherman]

On 10 Mar 2016, at 20:38, Romain Deltour [email protected] wrote:

It is absolutely essential to provide a way to navigate deep in the content, like with a heavily nested toc. Could you do that with the BFF JSON?

If not, then I'm afraid that allowing BFF to be used as a single-level nav alternative may entice authors into not caring about providing a more details nav doc, which would be an issue notably for accessibility.

Also, consider the i18n issues also raised in #16 #16.

This is of course correct. However, I believe the original issue was whether the nav document could become optional. Ie, if the document is simple, if a one level TOC is enough, then there is indeed a duplication of content.

A typical example is to distribute a short document (e.g., a scientific article) in EPUB, much as it is done using PDF today. In such a situation creating a nav document becomes an unnecessary chore…

[HadrienGardeur]

Right, as @iherman just said the whole point here is to make it optional when it's an unnecessary burden to author/host a Navigation Document.

I strongly believe that right now EPUB is mostly designed with fairly large publications (books) in mind, but that's not the end goal for EPUB as a publication format.

[rdeltour]

I strongly believe that right now EPUB is mostly designed with fairly large publications (books) in mind, but that's not the end goal for EPUB as a publication format.

I won't argue with that!

But if the whole point is to make the Nav Doc optional, why try and allow a half-baked version of it in the JSON BFF in the first place?

[HadrienGardeur]

I don't really think we're trying to build a half-baked version, we get it as a bonus since a title on a link is useful for other reasons anyway.