Re: Notes about the Web App manifest document

Well, not to set precedent by agreeing with Leonard ;-) but Ivan I think
you missed part of his point (with which I do agree): we should have a more
general "Web Manifest" which could then be specialized as necessary for
"Web Apps" and "Web Publications", not trying to build on something already
specialized for "Apps". That seems worthwhile independently of debates
about e.g. JSON (I do agree with you on this and since EPUB already is
ZIP-based as is almost everything else under the sun I am not offended by
the idea of evolving towards a universal Web packaging that is ZIP+JSON
rather than ZIP+XML).

But back to Leonard's higher-level point: I still think with PWP we are a
bit too liberal about what we mean by "Web Publication" [1] at least as
regards the current scope of the IG. I could take this definition as
inclusive of for example a casual game written in JavaScript (so all its
essential functionality is there and it is usable offline). But of course
the Web Apps folks would consider that an "App", as they should. And the
Holy Grail that PWP seeks to solve (Web content that is seamlessly usable
online and offline and whether its constituent resources are packaged or
distributed) applies equally well to such apps (albeit not client-server
apps) as well as other types of content that might be argued to be beyond
the scope of our charter (such as videos). I think it's great if PWP solves
bigger problems that help OWP overall but let's call a spade a spade - if
we are solving the online/offline packaged/distributed seamlessness for web
content in general then it is  just "Web" not "Web Publications" or "Web
Apps".

And if we want a more crisp definition of what is really a "Publication"
that sits fully within the scope of the current IG charter and participants
(and I think we do) my candidate is that a publication is any Web content
that has a defined order for its essential content and provides
discoverable navigation into it. That is to me what makes EPUB EPUB, not
the details of *how* those things are defined in EPUB 3. And doing so could
be as simple as saying any Web content that designates a <nav> element that
provides these things qualifies as a "Publication".

--Bill

[1] http://w3c.github.io/dpub-pwp/#pwp_definition

On Mon, May 30, 2016 at 2:54 AM, Ivan Herman <ivan@w3.org> wrote:

>
> > On 29 May 2016, at 18:27, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> >
> >> Maybe we can agree in some sort of a 'core' set of term for a Web
> Manifest (and not Web *App* Manifest), which can then be adapted for
> different constituencies
> >>
> > Not just for constituencies but also potentially for grammars and/or
> serializations.  The plan to use JSON vs XML vs. ??? is still before us,
>
> Well… I have the impression that this boat has sailed, but that is my
> personal impression. The Web Community has voted with its feet, so to say,
> to move away from XML towards JSON. That may become HJSON, or some other
> evolution of JSON, but the direction is quite clear. What we heard from
> Chaals is the probably move of the Web App/Browser community is to towards
> a ZIP+JSON manifest combination when it comes to packaging.
>
>
> > yet figure out what we need in there in terms of concepts and values
> would be worthwhile regardless of the serialization.
> >
> > I also like the separation of core terms from publication terms – and
> possibly even specific publication terms (eg. “Edupub”).
> >
>
> +1.
>
> Ivan
>
>
> > Leonard
> >
> >
> > On 5/29/16, 4:43 AM, "Ivan Herman" <ivan@w3.org> wrote:
> >
> >>
> >>> On 27 May 2016, at 20:54, Siegman, Tzviya - Hoboken <
> tsiegman@wiley.com> wrote:
> >>>
> >>> Hi Ivan,
> >>>
> >>> Thanks for getting this started.
> >>>
> >>> What I was envisioning for PWP is something along the lines of
> exploiting the Navigation Scope [1]. This would mean, that, like an app, a
> PWP is a defined set of "scope members" [2]. Scope members have many of the
> same features that we've been discussing for PWP - identity, location, type
> - and I'm hoping that this can be a launch point for discussion of a
> customized/customizable equivalent to epub's spine or manifest.
> >>
> >> I agree. This is certainly one of the items in the manifest doc that we
> can re-use and keep compatibility. Display mode[1] is another area, for
> example.
> >>
> >> However, my problem with the document is more general. Chaals referred
> to this manifest doc as, possibly, the basis for some sort of a
> Zip+manifest packaging approach that browsers may favor. However, it is not
> clear in the document whether, to be a bona fide manifest, it MUST contain
> all the terms defined in this document (with possibly more via the
> extension point) or not. And, if not, is there a subset of the terms that
> is required or is it a completely open set. Because if everything that is
> in the document is required, then we may run into a problem.
> >>
> >> Maybe we can agree in some sort of a 'core' set of term for a Web
> Manifest (and not Web *App* Manifest), which can then be adapted for
> different constituencies, like Apps or publications, then we would be in a
> much better place imho.
> >>
> >> Ivan
> >>
> >>
> >> [1] https://www.w3.org/TR/appmanifest/#the-display-mode-media-feature
> >>
> >>>
> >>> We will have to figure out what to do about all the information, such
> as installation.
> >>>
> >>> [1] https://www.w3.org/TR/appmanifest/#navigation-scope
> >>> [2] https://www.w3.org/TR/appmanifest/#member-scope
> >>>
> >>> Tzviya Siegman
> >>> Information Standards Lead
> >>> Wiley
> >>> 201-748-6884
> >>> tsiegman@wiley.com
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Ivan Herman [mailto:ivan@w3.org]
> >>> Sent: Thursday, May 26, 2016 6:24 AM
> >>> To: W3C Digital Publishing IG
> >>> 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
>
>
>
>
>


-- 

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org
mobile: +1 206 353 0233