Repository navigation
Clarify that resources must be present for relative paths #2024
Description
It appears in our rewrite of URL processing that we've lost the requirement for there to be a resource at the end of relative paths. In 3.2, we had this statement:
All relative IRI references MUST resolve to resources within the OCF Abstract Container (i.e., at or below the Root Directory).
This was meant to cover both that the URL not leak outside the container and that there must be a resource at the end of it.
Our new rewrite covers URLs not leaking outside the container better, but we no longer appear to have a requirement that there be a resource at the destination. Without that bit, someone could argue that missing resources in the container aren't really errors.
We should add back a statement about the need for a resource to be present so that we're consistent again with previous versions of EPUB 3.
Activity
OriKuttner commentedon Mar 2, 2022
rdeltour commentedon Mar 2, 2022
I'm wondering if a SHOULD wouldn't be enough here now. For instance if an image is missing, I'd like EPUBCheck to warn me, but my EPUB isn't critically unreadable either. 🤔
mattgarrish commentedon Mar 2, 2022
I get your point, but that can get highly subjective. If it's the cover or some decorative image, sure, but what if it's a key diagram in a science textbook?
Or, worse, a whole missing content document?
Do we start enumerating what elements a missing resource is an error from? That sounds brittle.
OriKuttner commentedon Mar 2, 2022
rdeltour commentedon Mar 2, 2022
For reference, a pointer to previous discussion about that in #1939 (comment) (starting with "Also, a side comment not specific to the current PR" and following comments).
OriKuttner commentedon Mar 2, 2022
iherman commentedon Mar 4, 2022
The issue was discussed in a meeting on 2022-03-03
List of resolutions:
View the transcript
3. Clarify that resources must be present for relative paths (issue epub-specs#2024)
See github issue epub-specs#2024.
Dave Cramer: Our other issue is similar. When we did this we lost a requirement that there be a resource at the end of the path.
… originally we had 1. not leak and 2. must exist.
See github pull request epub-specs#2028.
Dave Cramer: We lost part 2. We should put it back. There is already a PR.
Matt Garrish: We just need to put the existence text back.
Dave Cramer: Yes, and it sounds like the PR does just that.
… I am in favor of merging.
Dan Lazin: I don't know if it follows that there must always be a thing that is referenced.
… For instance a book on how to write epub that shows errors (eg this is what it looks like when a resource is missing).
… The cases are rare, but I can imagine some.
… and there are plenty of ways to create bad content.
Wendy Reid: Going with must on this, because nothing stops people from ignoring epubcheck.
… In general epubcheck is heavily relied on by publishers to tell them of problems.
… and this will more often than not help those publishers find problems.
Matt Garrish: I basically agree with wendyreid.
… epubcheck does look for this now.
… There are other things epubcheck will flag.
… This seems like a can of worms to change, and error has worked really well to date.
Dan Lazin: Those are persuasive arguments.
… I thought epubcheck gave warnings on shoulds, isn't that good enough?.
Wendy Reid: Errors scare them more.
Dan Lazin: I am ok with must, but odd that epubcheck is preflight and a conformance checker.
Dave Cramer: Propose merging 2028.
Dave Cramer: AOB?.