Are fragment identifiers allowed in manifest?

[dauwhe]

See w3c/epubcheck#1085

It appears that href attributes anywhere in the package file must be IRIs.

Each item element in the manifest identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute. The IRI MAY be absolute or relative. In the case of relative IRIs, Reading Systems MUST use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI MUST be unique within the manifest scope.

But we don't appear to forbid fragment identifiers. All we say about href is

An absolute or relative IRI reference [RFC3987] to a resource.

EPUBCheck complains loudly about fragment identifiers, I think because it misinterprets them as incorrect file extensions.

I'm not sure if we need to do anything here.

[mattgarrish]

They should be allowed as they're needed for refines, links, previews, and probably other things.

There's just no defined reading system support for them, even for refines, I believe.

[mattgarrish]

I didn't realize we had an open issue for this, but I've tried to address this in the PR #1670 for the URL standard.

The URL standard differentiates "relative-URL string" from "relative-URL-with-fragment string". For manifest items (and media overlay audio elements) I've replaced the general requirement for IRI references with the stricter non-fragment URL strings.

Is there any case where a manifest resource can be a fragment of another?

Allowing link elements to reference fragments is fine, though, and we have an example of doing just that (linking to a metadata record embedded in an html doc).

[iherman]

The issue was discussed in a meeting on 2021-05-13

List of resolutions:

• Resolution No. 2: Merge PR 1670, close issue 1303, forbidding fragment identifiers in hrefs for items

View the transcript

4. Are fragment identifiers allowed in manifest?

See github issue #1303.

Dave Cramer: i made an epub that had fragment identifier in href
… epubcheck threw an error
… but not sure which section of the spec this requirement came from
… so something to think about, especially as we're rewriting the spec to refer to WHATWG URL spec

Ben Schroeter: would we need to do some epubcheck work if we were to decide to allow these fragment identifiers?

Dave Cramer: yes, but that shouldn't be an obstacle, not big code change

Ben Schroeter: any downside? could it be abused?

Matt Garrish: just curious what the expectation is for RS if it is a fragment? What is RS supposed to do?
… load then scroll to fragment?
… and what about only having each resource listed once?

Dave Cramer: i think this is the same as activating a link in toc, i.e., yes to scroll
… but not suppress any of the document before the fragment

Brady Duga: how would that work in the spine? So chapter 1 is beginning of chapter, but chapter 2 is link to middle of the book?

Dave Cramer: yes, but we could have a note to say not to do that

Ben Schroeter: is there a legitimate reason to do this?
… or is this just to fix the epubcheck thing?

Matt Garrish: suspect this has something to do with the requirement to point to a resource, not a fragment of that resource

Brady Duga: maybe if you want to skip some kind of chapter heading for each chapter, so that you start with the first paragraph of the chapter?

Wendy Reid: we've had some cases where the entire book is in a single HTML file
… so this would allow you to actually navigate to the inside chapters?

Ben Schroeter: what about the fact that fragments need to be allowed for refines and stuff like that?

Matt Garrish: that's not in the manifest

Dave Cramer: a valid reason for changing the spec is to make it match reality, and given that we already enforce this, allowing a fragment here would vastly complicate the responsibilities of an RS
… i think we just say hrefs in items shouldn't have fragments

Matt Garrish: and the URL spec has a type that specifically can't have fragments
… so easy to do in spec

Wendy Reid: is that the current test in the PR that you have out?

Matt Garrish: yeah (I didn't know we had an issue out for this at the time)

Proposed resolution: Merge PR 1670, close issue 1303 (Wendy Reid)

Shinya Takami (高見真也): +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Proposed resolution: Merge PR 1670, close issue 1303, forbidding fragment identifiers in hrefs for items (Wendy Reid)

Dave Cramer: +1

Matt Garrish: +1

Ben Schroeter: +1

Brady Duga: +1

Matthew Chan: +1

Wendy Reid: +1

Fred Chasen: +1

Shinya Takami (高見真也): +1

Resolution #2: Merge PR 1670, close issue 1303, forbidding fragment identifiers in hrefs for items

[iherman]

@mattgarrish I did not close the issue until #1670 is open; we shouldn't forget to do it.

[mattgarrish]

I did not close the issue until #1670 is open; we shouldn't forget to do it.

Right, and I have this issue linked from the PR so it should close automatically with it.