W3C home > Mailing lists > Public > public-publ-wg@w3.org > December 2017

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

From: Ivan Herman <ivan@w3.org>
Date: Thu, 14 Dec 2017 09:47:29 +0100
Cc: Baldur Bjarnason <baldur@rebus.foundation>, Tzviya Siegman <tsiegman@wiley.com>, Benjamin Young <byoung@bigbluehat.com>, Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-Id: <82D20475-0279-4715-AD16-04069D97D1D4@w3.org>
To: Tim Cole <t-cole3@illinois.edu>
Tim,

I agree with your comments. I believe we may have an agreement for the near future (leaving open the issue of a PWP Media type). Thanks for the offer for making a PR with the changes.

Ivan


> On 13 Dec 2017, at 21:05, Timothy Cole <t-cole3@illinois.edu> wrote:
> 
> With regard to "4.1.1 Embedded Resource Selector serialized as a fragment identifier" - the current editor's note says that if we do not define a new media type for Web Publications and we do not define a new media type for Packaged Web Publications, then this section goes away. We seem to have consensus that no new media type will be registered for Web Publications (because Web Publication address must always resolve to an HTML representation). 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.
> 
> I'm happy to post this exact wording as an issue and then create a PR which when accepted closes the issue. Just want to be certain we have no plans to register a media type for PWP. I am not yet convinced of this just by the fact that the PWP may live offline of may even be created offline. A PWP could still be associated with  a media type - assuming it remains possible to put it online at some point in time. One reason section 4.1.1 exists is to facilitate addressing components within a PWP.
> 
> But even if the issue of media type for PWP remains open, we should eliminate all references to frag ids for WP and revert the example to pwpub as it was previously.
> 
> Thanks,
> Tim Cole
> 
> 
> -----Original Message-----
> From: Ivan Herman [mailto:ivan@w3.org]
> Sent: Wednesday, December 13, 2017 2:51 AM
> To: Baldur Bjarnason <baldur@rebus.foundation>
> Cc: Tzviya Siegman <tsiegman@wiley.com>; Benjamin Young <byoung@bigbluehat.com>; Hadrien Gardeur <hadrien.gardeur@feedbooks.com>; Daniel Glazman <daniel.glazman@disruptive-innovations.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
> Subject: Re: Comments on "Locators for Web Publications"
> 
> Reflecting on one technical issue:
> 
> <snip>
>> 
>>> The discussions we had about fragment ids om WP resolved around using the existing fragids for the media types in use in the publications, such as HTML [3].  If  you disagree with this, please comment on the issue, but we did discuss it at length.
>> 
>> That issue (#27) only mentions fragments _once_ and I’m not even sure whether it meant fragment ids in that context. A fragment identifier is a separate topic from identifier, locator, or address for web publications. Identifying a resource is an entirely different issue from using a fragment identifier to identify a part of that resource.
>> 
>> My argument is that we only have a remit to define a fragment identifier that identifies a part of the document returned (not other linked resources) when you fetch the web publication (or manifest) URL, provided that the file returned is a new media type.
>> 
>> If fetching the web publication URL returns an HTML file as has been discussed[1], then defining a fragment identifier for the web publication URL in any way shape or form is outside of our remit. Defining fragment IDs for HTML files is, realistically, only going to be done by the WHATWG. Defining a fragment identifier for web publication URLs is not compatible with the idea of having those URLs return an HTML file.
> 
> That is a fair technical point: I must admit I did not realize the contradiction between the fragid as defined in the locator spec and the separate discussion on 'what should I get back when dereferencing the WP address'. If the latter defines (as it does) the the return is HTML, then the current definition is indeed wrong.
> 
> The fragid in the locator document has always been a topic of discussion, and we were never sure that we should do that in the first place (as witnessed by the open issue). Thanks for pointing this error out.
> 
> I am happy removing the corresponding section from the document even before FPWD, although it would help if that specific technical point was added, crisply, to the issue as a comment.
> 
> Thanks
> 
> Ivan
> 
> ----
> 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
> 
> 


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


Received on Thursday, 14 December 2017 08:47:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:19 UTC