tcole3
commented
6 years ago Rationale:
-
We have consensus that the address of a WPub will resolve to HTML. Registering a new fragment identifier scheme for HTML is neither feasible, nor is it within our remit. So I have a pull request removing any suggestion from [1] that 4.1.1 "Embedded Resource Selection as Fragment Id" could be applicable for constructing a link to a component of a WPub.
-
The question of whether PWPub will use one of the several existing packaging formats or define a new one remains open (cf. [2] Editor's Note). To be clear in my earlier email I did not mean to suggest overriding an existing media type. I agree that this would not be feasible. However, an entirely new packaging format (which for now remains on the table) would imply a new media type registration, which then could include a new fragment identifier scheme.
Alternatively, should we settle on an existing packaging format that is designed exclusively for publishing - e.g., should we choose to reuse the EPUB Open Container Format (OCF), application/epub+zip - an argument could be made that the current WG could consider augmenting the fragment identifier scheme associated with this media type, though personally I would be hesitant to do so. Currently the IANA registration for application/epub+zip references [3] with regard to fragment identifier considerations which from its wording certainly seems to contemplate fragment identifier schemes in addition to CFI.
For these reasons my PR leaves section 4.1.1 in [1], pending the resolution of the packaging format question in [2].
[1] - https://w3c.github.io/publ-loc/#ErsFragmentId_def
[2] - https://w3c.github.io/pwpub/#packaging
[3] - http://www.idpf.org/epub/linking/
A few small updates to make clear that the ERS frag id section is only being considered if we end up using a new or existing publishing-dedicated packaging format (with publishing-dedicated media type). If we decide not to do this, then we remove this section.
Preview | Diff