Re: Notes about the Web App manifest document

And, taking this up a level of abstraction from a11y concerns, the linear
order and outline of <body> works perfectly well in the case where the
entire publication is comprised of a single HTML file and it could be
argued that in that base case no additional <nav> is necessary. But the
more general case of Web content is composite publications in which more
than one resource comprises the content. Resources can be strung together
with rel=next but that does not enable random-access navigation to the
whole from any point (unless the whole be pre-fetched and pre-digested). In
effect a Publication (in my proposed abstract definition as well as
concretely in EPUB) is analogous to a Web site / microsite more than it is
to a Web page. The term "weblet" was once coined to cover this [1]  but it
didn't stick. So HTML5 is the key building block but a single HTML5
document is not necessarily the whole thing.

Conversely not all web pages with a head and body are publications. Where
the body is just an empty div that javascript populates on the fly that is
not something that has a canonical order or reliable navigation into it.
When a web page is the equivalent of an X window session it is not a
publication even though it is still HTML5.

--Bill

[1] http://alglobus.net/NASAwork/papers/RNR-94-017/RNR-94-017.html


On Thu, Jun 2, 2016 at 10:44 AM, Siegman, Tzviya - Hoboken <
tsiegman@wiley.com> wrote:

> https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms.html
>
>
>
> *Tzviya Siegman*
>
> Information Standards Lead
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com
>
>
>
> *From:* Mike Perlman [mailto:perlmanm@me.com]
> *Sent:* Thursday, June 02, 2016 1:43 PM
> *To:* Bill McCoy
> *Cc:* Ivan Herman; Leonard Rosenthol; Siegman, Tzviya - Hoboken; W3C
> Digital Publishing IG
> *Subject:* Re: Notes about the Web App manifest document
>
>
>
> Hi all
>
>
>
> I think I have seen the suggestion about <nav> previously.
>
>
>
> What is the importance of <nav> to PWP?
>
>
>
> Why not just html, head, body as in HTML5?
>
>
>
> Cheers
>
> Mike
>
>
>
>
>
> On 02 Jun 2016, at 07:34, Bill McCoy <bmccoy@idpf.org> wrote:
>
>
>
> Ivan, my bad I didn't notice that Leonard was quoting you in his email and
> thus when you were disagreeing with his detailed suggestion  you obviously
> didn't have to clarify that you agreed with the higher-level point... since
> it was yours. That's what I get for dropping in midway on a long thread,
> sorry.
>
>
>
> --Bill
>
>
>
> P.S. I do still have a quibble about the broad/vague definition of "Web
> Publication" in the current PWP manifesto, that probably corresponds to a
> broad/vague definition of "Web App" by that group... I think some of the
> issue is that both efforts are really trying to solve broader problems but
> yet may feel that they have  "rope" only to solve problems for a narrower
> set of use cases leading among other things to unclear terminology.
>
>
>
>
>
> On Thu, Jun 2, 2016 at 10:27 AM, Ivan Herman <ivan@w3.org> wrote:
>
> Bill,
>
>
>
> just a quick note from my below. TL;DR: We actually don't disagree...
>
> ---
>
> Ivan Herman
>
> Tel:+31 641044153
>
> http://www.ivan-herman.net
>
>
>
> (Written on mobile, sorry for brevity and misspellings...)
>
>
>
>
>
>
> On 2 Jun 2016, at 18:00, Bill McCoy <bmccoy@idpf.org> wrote:
>
> 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".
>
>
>
> Isn't it what I said? In any case that was my intention to say: the
> problem I see with the current manifest document is that it is a Web App
> Manifest instead of a generic manifest that can be "subclassed" to a Web
> App or a Web Publication manifest.
>
>
>
> Ivan
>
>
>
> 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
>
>
>
>
>
>
>
> --
>
>
>
> Bill McCoy
>
> Executive Director
>
> International Digital Publishing Forum (IDPF)
>
> email: bmccoy@idpf.org
>
> mobile: +1 206 353 0233
>
>
>
>
>



-- 

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

Received on Thursday, 2 June 2016 18:04:32 UTC