table of contents in resources?

[mattgarrish]

Is this example correct: https://w3c.github.io/wpub/#table-of-contents ?

I'm a bit confused how the resource list can refer to a fragment of a resource. Does the file have to be listed again without the fragment to be valid?

[dauwhe]

I'm a bit confused how the resource list can refer to a fragment of a resource. Does the file have to be listed again without the fragment to be valid?

I just did a little experiment:

curl https://w3c.github.io/wpub/#table-of-contents 

As expected, it returned the entire resource. I think we can say that for caching, publication boundaries, etc. that we ignore fragments.

[mattgarrish]

Not questioning whether you get a resource, but what are the implications when referencing a fragment. What if the resource containing the table of contents is already in the default reading order, for example, does this also override the statement that says to only list resources that aren't in the default reading order? So the same document reference does occur in two places?

I'm not sure I see what benefit we gain over just having a separate property that references the toc. It seems like just another piece of potential confusion to add to all these lists and how to use them.

[HadrienGardeur]

Yeah, I think that this looks weird as well. No resource listed in "readingOrder" or "resources" should include a fragment. I would restrict the use of fragments to "links" (and the "toc" in our WebIDL).

[iherman]

Hm. It was one of the changes we agreed to a few weeks ago to remove the separate property references the ToC and, instead, fold the ToC into the general way of handling external links: #234 and we resolved to merge the corresponding PR.

There were good arguments in #234 for a unified approach, I do not think we should go "back" on that.

A possibility to move forward is to say the following:

1. Indeed, there should be no duplication of resources in the combined set of readingOrder, resources, and links.
2. if a resource is also labeled as contents in the corresponding rel value (we were careful enough to specify that rel is an array of possible values, thanks @HadrienGardeur :-) then the user agent should find an element with role=doc-toc in that resource, much like it does with the primary entry page in case no reference to a toc is given in the manifest.

I actually believe this makes much cleaner.

[mattgarrish]

I actually believe this makes much cleaner.

That's better in terms of getting rid of the fragment identifier, yes, but doesn't that also mean you have to look in either the default reading order or the resource list to find the table of contents? I don't have a problem with that, but we should specify it, as well.

[iherman]

You are right, that should be specified as well.

[BigBlueHat]

What is the key reason we're avoiding the Table of Contents being required to be expressed in the entry page directly?

If the table of contents is not included in the entry page, then how is the human reader to find it (since they can't consult the manifest)? (reworded from #223 (comment))

[iherman]

@BigBlueHat can we try to avoid coming back to issues that have been closed? This issue was discussed and a resolution in favor of the current draft has been accepted, see:

https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-06-25-pwg.html#resolution2

Actually, this issue should also be closed in light of that resolution.

[mattgarrish]

Closing this since I opened it and I'm fine with the changes and resolution.