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

Hi Tim,

I agree with your thoughts and comments. We do not have consensus whether a
PWP will have its own media type. I certainly agree that the statement that
a PWP may never be online is insufficient to judge whether it should have a
media type.

Thanks for offering to make an issue for this. Much appreciated.

Regards,
Dave

On 14 December 2017 at 06: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
>
>
>
>