Actually... your example violates another restriction in the current spec:

The URLs expressed in the reading order MUST NOT include fragment identifiers.

(I presume you would use a fragment identifier to point to stanzas...)

To be honest, I do not know where these restrictions come from.

(I presume you would use a fragment identifier to point to stanzas...)

Not necessarily. If the repetition were hundreds of lines it might be a separate file. But now we are asking authors to divide up their content only in certain ways.

Once again we hit a fundamental philosophical difference between EPUB and the web. With EPUB we help authors avoid errors. The web allows authors immense freedom to make mistakes.

Should web publications be like EPUB, or be like the web?

But how would you reuse the exact same file in a sequence of pages on the web and still direct the user to the correct previous/next page? Hope you get a meaningful referrer?

I believe the problem is the same for reading systems, as where exactly is the reader if the same file is defined at multiple positions? There will be pathways and situations (resumption) that will complicate knowing the context of the file.

That's my recollection of how we came to this restriction, although I haven't been able to track down where it was discussed.

Note that a particular resource's URL MUST NOT appear in more than one of these lists

This part I can get behind reducing to a should, or even dropping. What does it matter if a resource is listed in both when you have to get a union to find the unique list of resources? What breaks by having a resource declared in both lists? It's convenient not to have to list in both, but that shouldn't prevent someone from being super detailed...

Or, put differently, why bother saying it's a union when by definition you should only have to join the lists if you can't repeat resources (doing a union would only matter for error checking).

What does it matter if a resource is listed in both when you have to get a union to find the unique list of resources? What breaks by having a resource declared in both lists?

Yes. It feels like we're focusing a bit on theoretical purity, rather than being as minimally restrictive as possible while still creating a spec that's implementable.

I think this statement is a bit worthless as far as normative statements go, too:

The completeness of the resource list can affect the usability of a digital publication in certain reading scenarios (e.g., the ability to read it offline). For this reason, it is strongly RECOMMENDED to provide a comprehensive list of all of the publication's constituent resources beyond those listed in the default reading order.

"strongly advised", yes, but otherwise what sort of checking is this supposed to entail? I'm not writing an algorithm to hunt for possible missed "comprehensive" resources... :)

To try and address all the issues, how about this as a resolution:

• we delete the requirements that a URL not appear more than once in a list (this seems problematic for the links section) and not in more than list
• for the reading order:
  • to avoid rendering ambiguities, resources should not be listed more than once in the default reading order (i.e., we warn but don't strip duplicates)
  • fragment identifiers should not be included in the default reading order, but if they are we warn about them and strip them during processing
  • fragment identifiers may be included, but are regulated at the profile level
• for the resource list:
  • to avoid conflicting information, resources should not be listed more than once -if they are, only the first instance is retained during processing
  • fragment identifiers should not be included, warn and strip
• if a resource has already been declared in the reading order, any subsequent declaration(s) in the resource list are quietly ignored when compiling the list of resources in the bounds
• it is only advised to include a comprehensive list of resources
• it is not necessary to include a reference to the manifest (not a "must not")
• the restriction against using a fragment identifier for toc/pagelist/cover is removed since there is no longer a conflict with the readingOrder/resources rules - if a fragment isn't used, the first instance found in the file is used as per the existing rules
• add that cover must not be specified in the links list to match the other structural properties

Also:

• if a resource has already been declared in the reading order, any subsequent declaration(s) in the resource list are quietly ignored when compiling the list of resources in the bounds

That works for me.

From a UA perspective:

• duplicated resources in the resource list is sub-optimal but not a major issue
• duplicated resources in the reading order would cause major headaches

Let's say that a resource is present twice in the reading order. The first time at 20% of the book, the second time at 80% of the book.
When I follow a link to that resource, should I consider that this is for the first or second resource?

When I follow a link to that resource, should I consider that this is for the first or second resource?

Yes, I'm personally more comfortable leaving that particular restriction in place. Even in an audio format it seems flawed, as links from a table of contents could introduce this confusion. I'm going to un-strike that and see where the discussion Monday leads on this.

Yes, I'm personally more comfortable leaving that particular restriction in place. Even in an audio format it seems flawed, as links from a table of contents could introduce this confusion. I'm going to un-strike that and see where the discussion Monday leads on this.

I think the TOC case is solvable, with some programming, but the arbitrary link problem is more difficult. I'm OK with keeping the restriction.

I think the TOC case is solvable, with some programming, but the arbitrary link problem is more difficult.

It's the pathway to EPUB CFI to make both reliable, but let's not go there...

This issue was discussed in a meeting.

• No actions or resolutions

@mattgarrish can this be closed now?

(The corresponding PR, i.e. #131, has been merged...)