[PWG] Reflections after two months

Dear Friends,


We have been working on WPUB for two months. It seems an appropriate time to take a step back and reflect on what we have and have not accomplished. Thank you to everyone for the considerable time and effort you have already contributed. Let’s remind ourselves of our charter [1], which talks about why our group exists and should serve as a guide for the direction of our group.


“The WG will specify Web Publications and identify what they need the underlying Web platform to provide. It will build upon existing platform technologies specified by other groups, where available, seeking to fill gaps by assuring that the unique requirements of Web Publications are addressed by features (including optional features) or extension points in those specifications.”


In our charter, we also provide a definition of Web Publications, including information about origin, offline, packaging, identity, and metadata. After discussions with many members, it seems to us that we have gotten a little bit lost in the minutiae of some of the items that we need to specify without paying any attention to other items. We have revisited many of the issues that were addressed in the chartering process. We have opened many issues on GitHub, and we will need to dive into the details of all of these issues. However, we have somewhat lost sight of the big picture.


Since June, we have been talking about getting to First Public Working Draft for both WP and PWP in time for TPAC. Our main goal is to provide for ourselves, as well as others who may not be  as familiar with the world of publishing, a strong idea of where we’re headed with this specs. We are NOT trying to write a specification in this time. We are also NOT trying to change the Web or Publishing in this time. We are trying to offer a broad brushstrokes outline of the two specifications. We got off to a good start at our face to face meeting in June. We even drafted a robust outline [2] for both documents. After that, we started to focus on too many details. We have spent an inordinate amount of time discussing things like the very exact definition of secondary resources and NO time on the vast majority of the specification. As a result, the Editors’ Draft [3] that we have now is rather detailed at the beginning and shockingly empty beyond section 4.


We propose, at this point, to put a temporary freeze on issues related to manifest and the information set. We will leave these issues open, but we will not address them until we have a more balanced draft document, probably after FPWD. Instead, let’s focus our energies on the rest of the spec. We have a great need to write the sections on security, privacy, and reading enhancements (including offlining, navigation, search, and pagination). Several people have volunteered for these sections, but we have seen little movement in these areas.


Note that the latest Editors’ Draft includes an outline (thanks to Matt) which may be used to direct our discussions. The discussion in issue #52[4] adds some new thoughts that can be used to refine that outline, and direct us to the first set of broad topics that should be addressed.


We will need the details. We will actually need even more details, grounded in real-world examples. As our charter states, we “build upon existing platform technologies specified by other groups, where available”. When we approach the Web Platforms WG to discuss the Web App Manifest, Service Workers, Web Packaging, or any other topics, it will not be sufficient to talk about conceptual examples or testing that we’ve done behind closed doors. We will need to provide actual examples. We have begun collecting samples at [5]. Similar pages can easily be set up for other types of samples. We therefore urge you to provide and document such detailed examples coming from your practice.


Concentrating on large brushstrokes at the moment is also vital to get a community into our Working Group that is currently largely missing, namely the browser and Web application developers. That community will not join our group until it has a better overall view on what exactly we want to achieve (this became very clear during the chartering discussions) and we believe their participation in the group is crucial if we do not want to define some sort of a publishing silo on the Web.


We are getting the testing efforts off the ground now, but we know from experience with other WGs that this is one of the most important things to do to make a Working Group operate well. If you are able to contribute to the testing effort, even just as the person who labels items in the spec as “testable,” please be in touch.


Unfortunately, there is one other issue we need to address. We have received comments from numerous members of our group expressing concern about the way we communicate with one another on the phone, on GitHub, and on email. One person expressed the point that it often feels that the assumption is that every comment made is wrong. Often people make comments, and the questions on the calls or in GitHub can be reduced to, “I disagree. You are wrong. Tell me why I should believe you are correct.”  Aside from this being a terribly uncomfortable mode of operation, it will lead us nowhere. We cannot be creative if we always assume others are wrong. Our goal is to create a new approach to publishing on the Web – this is a big goal, and one that demands teamwork and creativity.


We do not think that any individual intends to make another feel uncomfortable, but passions run high. We ask you to please pay careful attention to your words and how they will be perceived by others. Pay attention to how often you speak in meetings. Pay attention to the way people respond to your comments. Perhaps your tone has been a little harsher than intended? Perhaps you’ve been writing at great length, which makes it somewhat challenging for people, especially newcomers, to sort through the issues? Perhaps you’ve made the assumption that a solution that you’ve suggested is THE answer?  Perhaps you’re overly focused on your particular expertise or experimental implementation?


We truly believe that we have a wonderful group of people who are seeking to make a big difference in the way that publishing works. We look forward to your ongoing cooperation.


Best,

Garth, Ivan. and Tzviya



[1] https://www.w3.org/2017/04/publ-wg-charter/

Publishing Working Group Charter - w3.org<https://www.w3.org/2017/04/publ-wg-charter/>
www.w3.org
Publications, from magazine articles to product documentation, from electronic books to scholarly journal articles, are increasingly present on the Web. While ...



[2] https://docs.google.com/document/d/1sXM51YzrfahFmkJBL-rt69Jvo0LGbOesleuEgwRWvP0/edit?usp=sharing

[https://lh6.googleusercontent.com/0S6AB5ETk0zzzNU0ksOFyeLERLUqnqNzjHE1qYNvNYL3Igv9jGYYpFO_zhGlRiqwW3MBKA=w1200-h630-p]<https://docs.google.com/document/d/1sXM51YzrfahFmkJBL-rt69Jvo0LGbOesleuEgwRWvP0/edit?usp=sharing>

WP Outline<https://docs.google.com/document/d/1sXM51YzrfahFmkJBL-rt69Jvo0LGbOesleuEgwRWvP0/edit?usp=sharing>
docs.google.com
WP [Editor-in-chief, Matt] Introduction [Matt] <Some incoming from IG docs> What is a Web Publication? “The web works, start there” Terminology Conformance Content UA / Reading system Identifiers (of collection) [Takeshi (if joins) & BillK] Locators [Benjamin Young & Tim Cole?] Relationship to We...



[3] https://w3c.github.io/wpub

Web Publications - w3c.github.io<https://w3c.github.io/wpub>
w3c.github.io
This specification defines digital publishing based on a fully native representation of publications within the Open Web Platform. This first public working draft ...



[4] https://github.com/w3c/wpub/issues/52

[5] https://github.com/w3c/wpub/wiki/ToC-Samples

[https://avatars3.githubusercontent.com/u/379216?v=4&s=400]<https://github.com/w3c/wpub/wiki/ToC-Samples>

w3c/wpub<https://github.com/w3c/wpub/wiki/ToC-Samples>
github.com
wpub - W3C Web Publications






Tzviya Siegman

Information Standards Lead

Wiley

201-748-6884

tsiegman@wiley.com<mailto:tsiegman@wiley.com>