Feedback on FPWD from Chrome team

I reached out to the Chrome team for informal feedback on the FPWDs and
forwarded the invitation to join the WG. The response at a high level was
that the Chrome team does not review specs that they are not currently
implementing, as that can lead to poor design choices and is often a waste
of effort. As of now, the work being done in the PWG does not match any
ongoing Chrome development, so a detailed review or implementation is
unlikely. However, the more the WG focusses on incremental improvement of
mainstream web tech, the more likely it is they could invest some
resources, at least in experimental trials. This would have to target
specific improvements to existing features, which could be tested with real
customers.

That said, Jeffrey Yasskin did provide some detailed spec review for Web
Publications. He did not review PWP (placeholder), or web annotation
extensions. His comments on Web Publications:

===============================================

WPub is basically a statement of what information a publication needs to
contain. That's potentially helpful as a starting point, since it can let
the group point out what's hard to express using existing web features.
There's nothing here yet about how to serialize the information.

   - The accessibility section is woefully lacking in details. The
   schema.org metadata seems to be able to declare which features exist,
   but a publication spec needs to say how to find the accessible content. For
   example, accessibilityFeature="alternativeText" isn't useful--a spec
   needs to say where that alternative text lives. In this case, HTML handles
   it for you with the <img alt> attribute. WPub should point out places that
   HTML is insufficient (and propose additions) or explain which HTML features
   are especially relevant to publications.
   - Address is decent, although I'm not sure whether it differs from the
   App Manifest's start_url. Whether or not you decide that the App Manifest
   serialization format is right for WPubs, you should be clear about how the
   information models relate.
   - Language/Base direction: These resemble https://w3c.github.io
   /manifest/#lang-member but are less precise. I don't see a statement of
   how to handle translations here: is the idea (like with App Manifests) that
   a translation is an entirely different publication?
   - Canonical Identifier needs more detail about the format of the
   identifier. "it MUST be possible to make a one-to-one mapping to an
   address" should instead say how that mapping is made. If you intend it to
   "provide a measure of permanence above and beyond the Web Publication's
   address", you should forbid it from being that address, and require formats
   (URI schemes?) that do provide that permanence.
   - Creators needs to say what information constitutes a creator. Are
   these free-form strings, x.500 Distinguished Names, mappings with specified
   keys, etc.?
   - The dates should define a format, either RFC3339 date-times
   (yyyy-mm-ddTHH:MM:SSZ) or posix integral times.
   - The Privacy Policy should say whether it's expected to be human-(,
   lawyer-?), or machine-readable.
   - Default Reading Order should be specified to be, I think, an ordered
   sequence of URLs. Otherwise, good job sketching the algorithm for
   generating it from a <nav> element.
   - Does the Resource List need to describe the kind of thing each
   resource is? i.e. is it another flat list of URLs, or does it distinguish
   page content from images from indices?
   - Table of Contents should specify how a <nav> encodes the table of
   contents. The description makes it look like the ToC is an ordered sequence
   of (URL | ToC). Is that right? Are there semantics for which elements of
   the Reading Order are within each ToC entry?