- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 14 Jun 2016 09:01:56 +0200
- To: Nicholas Taylor <ntay@stanford.edu>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Heather Flanagan <rse@rfc-editor.org>, Romain Deltour <rdeltour@gmail.com>
- Message-Id: <1F66965C-2996-4856-9C9F-45E79753964F@w3.org>
Sorry for the late answer… I like the use cases there. I am looking forward seeing them incorporated into the 'main' UCR document! Ivan > On 11 Jun 2016, at 00:58, Nicholas Taylor <ntay@stanford.edu> wrote: > > Hi Ivan, > > No problem; I added this as a use case here: https://github.com/w3c/dpub-pwp-ucr/issues/29. > > Please see also the other archival use cases here: http://w3c.github.io/dpub-pwp-arch/Archival-UCR.html. > > Thanks! > > ~Nicholas > > -----Original Message----- > From: Ivan Herman [mailto:ivan@w3.org] > Sent: Tuesday, June 07, 2016 3:50 AM > To: Nicholas Taylor <ntay@stanford.edu> > Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>; Heather Flanagan <rse@rfc-editor.org>; Romain Deltour <rdeltour@gmail.com> > Subject: Re: Notes about the Web App manifest document > > Nicholas, > > indeed. That is an aspect missing. > > I wonder whether you could submit an issue to the UCR document issue list: > > https://github.com/w3c/dpub-pwp-ucr/issues > > because I believe the requirement of knowing about changes is very relevant, and should be recorded there. > > The fact of having many different ways of accessing the manifest is also very relevant; we have discussed that for PWP and we indeed had the HTTP header and the HTML link as part of our options (we did not use .well-known). Again, the best would to have this as a separate issue, too, to be included in the UCR, eventually… > > Thanks! > > Ivan > > >> On 6 Jun 2016, at 23:08, Nicholas Taylor <ntay@stanford.edu> wrote: >> >> Hi all, >> >> Admittedly more relevant to archiving service providers like LOCKSS, it is unfortunate that the Web App Manifest currently lacks a mechanism for updating (https://www.w3.org/TR/appmanifest/#updating). This would mean that synchronization would require ongoing polling and comparison of the manifests of all PWP archiving candidates, resulting in many superfluous requests to publisher web servers, additional processing work by the archiving service provider, and higher latency in completion of synchronization. >> >> This use case would be better accommodated by something like ResourceSync's Change List (http://www.openarchives.org/rs/1.0.9/resourcesync#DesChanges), which provides a push mechanism for advertising changes. ResourceSync (http://www.openarchives.org/rs/toc) is an extension of the Sitemap protocol (http://www.sitemaps.org/protocol.html) and therefore functionally focused on advertising web-accessible resources without getting into the specific nature of the content. >> >> The specification also offers various possibilities for the discovery of manifests (http://www.openarchives.org/rs/1.0.9/resourcesync#Discovery), including by means of a well-known URI, HTML link, or HTTP Link header. >> >> ~Nicholas >> -- >> Nicholas Taylor | Web Archiving Service Manager | Stanford University Libraries DLSS >> >> -----Original Message----- >> From: Ivan Herman [mailto:ivan@w3.org] >> Sent: Thursday, May 26, 2016 3:24 AM >> To: W3C Digital Publishing IG <public-digipub-ig@w3.org> >> Subject: Notes about the Web App manifest document >> >> Dear all, >> >> As some sort of a followup from the discussion we had with Chaals… I have looked at the Web App Manifest doc (https://www.w3.org/TR/appmanifest/) to see whether it could work for us as a basis for the manifest in PWP. These are just my (slightly unstructured) notes. >> >> The document defines a JSON structure/set of terms, and some processing steps to find and consume those manifests. This general approach is identical to what we considered as PWP (or BFM…) manifests, and that is the reason why considering the specification for our purposes is actually important. It includes a number of terms that may be very relevant (e.g., I18N consideration for manifest members like title and descriptions, the concept of display mode which may have a direct relevance for PWP, the concept of a scope, that may define a ‘subset’ of possible URIs to identify PWP resources). It also defines an extension mechanism, i.e., it is possible to define application specific terms (“members”, as they are referred to in the spec), i.e., it is possible to include anything we want for PWP. >> >> However: the Web App Manifest is, well, Web **App** Manifest. It is geared at Web Applications as far as many of the chosen set of terms are concerned. Its main goal is to define terms needed for the download and installation of Web Applications, i.e., active entities. Although, with a bit of a stretch of imagination, one could consider a PWP an active entity in case the PWP Processor is a downloadable application for that specific content, I am not sure this is the prevalent view. Ie, a PWP is a “passive” thing (regardless of whether it has internal javascript based interactivity) that is downloaded as a set of resources by a general processor. What this means is that the current Web App Manifest contains a bunch of irrelevant terms (related application, start url, icons, platform). >> >> There are also terms that, though may look relevant, would probably more appropriate in a CSS file or some other files within the PWP (eg, theme color). The processing/linking is simpler than what we discussed: the only source of a manifest is what can be accessed via a <link> element in HTML, there is no provision for HTTP Return Link Header, or embedded JSON content within an HTML file. >> >> I am not sure where to go from here. My ideal would be to have a “general” manifest file that would include whatever is generally useful or necessary, a (slightly more general) way of finding a manifest, general processing steps (which are part of the document) and then some clearer extension points/facilities for specific application areas, like Web Apps or PWP. >> >> Feedbacks? Ideally, we should have some discussion in the IG, ending a more solid, and common view that we could put in as an issue/comment to the current document. With the hope that, via some joint work, we can get somewhere… >> >> WDYT? >> >> Ivan >> >> ---- >> Ivan Herman, W3C >> Digital Publishing 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 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 Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Tuesday, 14 June 2016 07:02:13 UTC