RE: new frag id - RE: Comments on "Locators for Web Publications"

Aside: Probably would be easier to track this as an issue rather than in an email chain, but I think we have a short-term approach for FPWD and can open issue(s) on this as needed after FPWD. I would ask the WG to consider the following logic for FPWD with regard to a possible new fragment identifier scheme:

1. 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. 

2. 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/ 

This text has been added as a comment on the PR. 

-Tim Cole


-----Original Message-----
From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com] 
Sent: Thursday, December 14, 2017 4:19 AM
To: public-publ-wg@w3.org
Subject: Re: new frag id - RE: Comments on "Locators for Web Publications"

Le 13/12/2017 à 21:05, Timothy Cole a écrit :

> Do we also have consensus that there will be no new media type registered for Packaged Web Publications? If so, we must delete section 4.1.1 and 4.1.1.1. 


FWIW, everything already has a media type: html documents, text files, EPUB packages. Unregistered files fall back to application/octet-stream or text/plain. Our problem is that fragment identifiers are meaningful for a given media type, at best for a group of media types (eg. an area into an image/* resource). Even on a local filesystem, the media type is (sometimes incorrectly) inferred from the file extension, more rarely from file contents' sniffing (think /usr/bin/file).

I think it's out of question to override the existing media types with a new one. Example: is a EPUB package a PWP? If yes and if we give PWP a media type, that new media type will "hide" application/epub+zip, a probable no-go. Similarly, I doubt publishers will change the file extension of their packages to allow mime type sniffing server-side; so EPUB packages will remain *.epub and then application/epub+zip.

So my take on this topic is the following: we don't need to waste time discussing something that is impossible.

</Daniel>

Received on Thursday, 14 December 2017 19:35:39 UTC