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

> On 14 Dec 2017, at 20:35, Timothy Cole <t-cole3@illinois.edu> wrote:
> 
> Aside: Probably would be easier to track this as an issue rather than in an email chain,

+1

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

At this point, we should accept the PR and go with the FPWD with it (also in accordance with the votes on our calls). The new formulation of the editorial note makes it clear, in my view, that the whole section on fragid has a limited and highly conditional target anyway.

Note that we are one week away from the XMas vacations, and we need an approval for the FPWD-s (which takes some time).

Ivan



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


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704