Re: "Show me the metadata!" :), was Re: Rough sketch for WP

On Tue, Sep 27, 2016 at 12:41 PM, Ivan Herman <ivan@w3.org> wrote:

>
> On 27 Sep 2016, at 13:35, marcos@marcosc.com wrote:
>
>
>
> On 27 Sep. 2016, at 7:56 pm, Ivan Herman <ivan@w3.org> wrote:
>
>
> On 27 Sep 2016, at 11:08, Bill Kasdorf <bkasdorf@apexcovantage.com> wrote:
>
> I agree, presuming that one possible choice is to put the metadata in the
> publication (though by far the more common and preferred practice would be
> to maintain it externally to the publication). This is consistent with
> current actual practice regarding metadata in most (but not all) sectors of
> publishing.
>
>
>
> We have to be careful what this means, specifically for metadata not
> embedded in the HTML content or part of the manifest.
>
> - If we consider a Web Publication only (ie, simply on the Web), this
> means that the metadata is a separate file somewhere on the Web, referring
> to from, say, the manifest. What has to be conveyed somehow is whether
> offline is applicable for it, ie, whether that file is one of those that is
> 'registered' by the service worker based layer that handles the publication.
> - If we consider a Packaged Web Publication, then the issue is whether the
> metadata should be part of the package or not.
>
> I think the choice should be (1) taken by the author/publisher and (2) it
> should be the same in both cases. By "the same" I mean if the Packaged Web
> Publication is 'unpacked', then the corresponding manifest should somehow
> list the metadata file as being candidate for offline handling, and vice
> versa: if a WP is packed, all files listed for offline handling must be
> present in the package.
>
>
> "Offline handling" by who? (And if you say "browser" you have buy everyone
> a drink at next TPAC). But seriously, we need to please avoid speaking in
> passive voice when it come to any processing or handling of things.
>
>
> Is this a prerequisite for a drink?
>
>
> As I've stated a few times already, browser engines are only interested in
> doing as little lifting as possible. We need to be super careful about
> assuming browser engines providing any support that can be done by authors
> using a js library.
>
>
> Right. At the moment, I try not to make the difference yet (do not eat me
> alive!:-): it is a combination of what the browser can do and what a JS
> layer on top of the browser will do (in form of some sort of an extension,
> or a dynamically downloaded JS library, for example). It is not clear to my
> mind at this point which functionality would be taken over by the browser
> directly and which would not; and I do understand that browsers must be
> conservative in this respect. That is also why I believe that, at this
> point, having the abstract notion of a 'WP processor' of some sort is
> useful. Obviously, the WP processor is a JS layer that makes a (heavy) use
> of service workers, manifests, etc.
>


Yes, but please let's not insist on too many implementation details in this
group. We should be focused on what more than how.

The danger is that we specify service workers, then some new technology
comes along that would be useful on the content, but non-compliant. It is
better to specify simply the contents of a WP/PWP, including a manifest if
needed, and let applications decide how to process that content.

For example, if I wanted to build Dave's Awesome eBook Reader, I shouldn't
need to write JS if I didn't want to.

Regards,
Dave
--
David Wood



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