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

> On 27 Sep 2016, at 13:35, marcos@marcosc.com wrote:
> 
> 
> 
> On 27 Sep. 2016, at 7:56 pm, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
> 
>> 
>>> On 27 Sep 2016, at 11:08, Bill Kasdorf <bkasdorf@apexcovantage.com <mailto: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.

Ivan



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