Should the manifest be an implicit TOC?

[TzviyaSiegman]

Should the TOC be a separate HTML file or is the listing of primary resources in the manifest an implicit TOC?
See #2

[GarthConboy]

Admittedly without enough thought... but, seem possible that an implicit "machine readable" TOC could be created from the listing/order of primary resources and then pawing through for HTML header elements or elements with desired ARIA roles. This doesn't achieve the "both for display and machine processing" that is, at least somewhat, accomplished with the EPUB3 Nav file -- but perhaps that's okay. Be interested for the A11Y folks to chime in on this issue.

[dauwhe]

I think the answer depends a lot on the nature of the manifest, and its serialization. A manifest could be expressed in HTML as an ordered list of links, and serve as a lovely, human- and machine-readable TOC, understandable by AT, which everyone in the web world already knows how to author.

[mattgarrish]

I'm not sure what to make of this.

Having the UA parse an outline is interesting. With EPUB, a periodic thought was to introduce a structured spine that would aid in generating one (i.e., parent/child relationships to deal with funky chunking).

But what is a "primary resource" these days. Is it any top-level document, or only ones in the default reading order? If it's the former, how do you organize the ones that aren't in the default reading order? If it's the latter, what happens for publications that omit some primary resources.

@BillKasdorf mentioned on the last accessibility that a magazine doesn't have a concept of a reading order, so do they get a table of contents?

If the table of contents is just a listing of file labels, I think the value of that has already been questioned:

• what does it represent when content isn't chunked in completely logical ways?
• how much value are top-level file descriptions as a table of contents?
• with no way to author the table of contents differently, what hacking could it lead to?

I still would prefer a toc that provides author control, in a format that is easily authored, and is available to everyone by default.

[dauwhe]

@BillKasdorf mentioned on the last accessibility that a magazine doesn't have a concept of a reading order, so do they get a table of contents?

Most magazines, even online, do seem to have a table of contents, and thus an implicit order. I think of this as a consequence of deciding to be a publication. Maybe they can use ul in their nav 😎

[mattgarrish]

Most magazines, even online, do seem to have a table of contents, and thus an implicit order.

I know, I'm just positing a hypothetical. If publishers only put one document in the default reading order and rely on users following a sequence of hyperlinks through the content, which a magazine could do, then ordering of resources in the manifest seems to become important.

Correlating reading order or primary resources with automatic table of contents generation comes with its own set of problems and limitations.

[lrosenthol]

On Thu, Aug 10, 2017 at 7:27 PM, Dave Cramer ***@***.***> wrote: @BillKasdorf <https://github.com/billkasdorf> mentioned on the last accessibility that a magazine doesn't have a concept of a reading order, so do they get a table of contents? Most magazines, even online, do seem to have a table of contents <http://www.pointofdeparture.org/Content.html>, and thus an implicit order. I think of this as a consequence of deciding to be a publication. Maybe they can use ul in their nav 😎

Yes, but documents like memos, reports, spreadsheets, etc. do not.

[BigBlueHat]

@lrosenthol I'd reckon one can envision a ToC with a single entry. If you wanted to make that document a Web Publication, then you'd need to do that simple action. Otherwise, it's just a Web Page or Resource--which may also be entirely fine depending on the use case you're envisioning.

[pkra]

I'm struggling to understand the original question.

Should the manifest be an implicit TOC?

What would an implicit TOC be for? Who would this provide with a benefit / burden? Is it meant as specifying a fallback mechanism if no "explicit" TOC is given?

(I'm assuming there will be some optional way of specifying an explicit TOC?)

[baldurbjarnason]

I made the following comment over in #36 which I think is relevant here:

The manifest, once it exists as a concrete structure in an application, absolutely needs reading order, table of contents, and secondary resources as separate structures. If the format we create does not specify these structures as separate pieces of data, we are going to have issues with both interoperability and with our support for diverse publication forms and genres.

So the manifest format absolutely does need to specify these as separate structures in the format from the start. This is something that the html-first proposal does not do and is the root cause for why it is problematic in general (IMO).

Now, I do think that if the reading order is absent, the UA should use the ToC to generate it, and if the ToC is absent, the UA should use the reading order to generate that. And if a list of secondary resources is missing, a UA may want to try to generate that list through some other means. I think these are important features we should at least try to support to help authors do their job.

But we need to start off by specifying a format that supports these as independent structures before we specify how you'd use one type of structure to generate another. And we should be explicit in the specification that these conversions can fail for a variety of reasons.

[TzviyaSiegman]

This issue is resolved with #51

[iherman]

See telco discussion on closure.