Re: Feedback on FPWD from Chrome team

“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.”

The response is at:
https://github.com/w3c/wpub/issues/154

With regards
Avneesh
From: Brady Duga 
Sent: Friday, February 23, 2018 02:45
To: W3C Publishing Working Group 
Subject: 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.
  a.. 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. 
  b.. 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.

  c.. 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? 
  d.. 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.

  e.. Creators needs to say what information constitutes a creator. Are these free-form strings, x.500 Distinguished Names, mappings with specified keys, etc.?

  f.. The dates should define a format, either RFC3339 date-times (yyyy-mm-ddTHH:MM:SSZ) or posix integral times.

  g.. The Privacy Policy should say whether it's expected to be human-(, lawyer-?), or machine-readable. 
  h.. 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.

  i.. 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? 
  j.. 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?