Publishing Working Group Telco — Minutes

Date: 2018-05-21

See also the Agenda and the IRC Log

Attendees

Present: Chris Maden, Jeff Buehler, Deborah Kaplan, Ivan Herman, Rachel Comerford, Murata Makoto, Avneesh Singh, Garth Conboy, Romain Deltour, Benjamin Young, Dave Cramer, George Kerscher, Nick Ruffilo, Franco Alvarado, Joshua Pyle, Luc Audrain, Derek Jackson, Jun Gamou, Bill Kasdorf, Adam Sisco, Gregorio Pellegrino, Hadrien Gardeur, Brady Duga, Reinaldo Ferraz, Tim Cole, Evan Owens, Mateus Teixeira, Ric Wright, David Stroup

Regrets: Tzviya Siegman, Peter Krautzberger, Teenya Franklin, Laurent Le Meur, Jasmine Mulliken, Marisa DeMeglio, Matt Garrish, Caitlin Gebhard, Vladimir Levantovsky

Guests:

Chair: Garth Conboy

Scribe(s): Dave Cramer

Content:

Garth Conboy: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-05-07-pwg.html

Benjamin Young: +1 to minutes

Dave Cramer: minutes approved

Resolution #1: last meeting’s minutes approved

1. F2F Practicalities

Garth Conboy: Link to the F2F meeting page

Garth Conboy: we won’t have a call next Monday
… holiday in the US
… reach out to the chairs if you have changes for the agenda

Garth Conboy: http://hotelocho.com/food.html

Garth Conboy: Linke to the dinner participation list

garth>Dietar: restriction form: https://goo.gl/forms/UZ0yv8EBXBujTePw1

Garth Conboy: there will be a dinner on Wednesday night (link above)
… there’s a signup sheet in google docs
… ^
… and there’s a dietary restrictions form
… please fill it out even if you’re not going to the dinner, as it covers lunch and snacks at the F2F

Ivan Herman: the same goto meeting channel is open during the F2F, thanks to Laurent

2. closing some pending issues

Garth Conboy: what I wanted to try to do at this juncture
… we have a handful of issues where there’s been a lot of discussion
… I talked to Ivan in Berlin
… we grabbed a few of these that we want agreement on before the F2F
… the first one is, what is the browsing context (104)

2.1. what is the browsing context?

Garth Conboy: https://github.com/w3c/wpub/issues/104

Garth Conboy: we want to lose the term publication context because it’s not relevant, and I don’t think it’s in scope for this group
… the proposal we came up with is
… I’ll read this and then we can discuss
… if there happens to be a WAM a publication can be a progressive web app, but we don’t have to define it so

Proposed resolution: “A WP definition does not specify whether the content is rendered in a Progressive Web App, in the browser directly or via an extension, or in a separate app (or whatever else). Therefore we propose to close this issue with the answer to the original question (i.e., “What is the Browsing Context of a Web Publication?”) by saying “whatever the implementation chooses it to be.” Which is, by default, just the context of the “entry point”. Further propose to alter the current draft to remove the reference to “Publication Context.” (Garth Conboy)

Dave Cramer: we should be clear about where script runs in web publications
… but I’m ok with this language

Benjamin Young: my take is similar to dauwhe
… we’re not stating where stuff happens, so we don’t need to declare a browsing context

Garth Conboy: dauwhe is correct that scripts are involved

Benjamin Young: there are other concerns about the audience of the specification being unclear
… I’m not sure who recognizes themselves as an implementor

Garth Conboy: I don’t hesitate to take silence as consent

Jeff Buehler: +1 to the last two comments

Deborah Kaplan: I’m going to consent +0 :)
… we’ve talked before about the complications of requiring scripts
… I understand the reality we live in, but we should be wary…
… define scripts very carefully so they don’t create more problems than they solve

Garth Conboy: let’s say we resolve 104 with the above language

Resolution #2: A WP definition does not specify whether the content is rendered in a Progressive Web App, in the browser directly or via an extension, or in a separate app (or whatever else). Therefore we propose to close this issue with the answer to the original question (i.e., “What is the Browsing Context of a Web Publication?”) by saying “whatever the implementation chooses it to be.” Which is, by default, just the context of the “entry point”. Further propose to alter the current draft to remove the reference to “Publication Context.”

2.2. Infoset and JSON

Garth Conboy: https://github.com/w3c/wpub/issues/193

Garth Conboy: I’m in the “put everything in one place” camp
… the proposal that Ivan and I came up with in Berlin I’m pasting in
… it may not be consensus, but I hope it’s in the “can live with it”

Proposed resolution: “The infoset mostly resides within a JSON manifest (WP manifest). That JSON may optionally be embedded in the entry page rather than a standalone file referenced by <link> from the entry page. It may be supported to allow some infoset items to reside in HTML of the entry page, if information duplication issues can be sufficiently avoided.” (Garth Conboy)

Garth Conboy: (reads proposed spec language above)
… the only html info we’ve talked about is using nav to define primary reading order in HTML, so this leaves that as a possibility

Rachel Comerford: Hello!
… the question I have is about language
… I don’t understand “mostly”
… do you mean “primarily”?

Garth Conboy: that “mostly” was letting my religion show
… it means primarily
… there is a wp manifest, and it is a json thing, and most stuff should live there unless we find exceptions (like the nav thing)

Ivan Herman: +1 for primarily instead of mostly

Garth Conboy: does that answer the question?

Rachel Comerford: can we change mostly to primarily, and qualify that language with what you just said?

Garth Conboy: we can switch out the words in the resolution
… and we can assign to Matt to make it clearer
… if everyone’s in the ‘can live with it” or “likes it” camp, I’m gonna assume consensus

Garth Conboy: this one I view as less controversial; we’re not deviating from the existing draft much

Resolution #3: The infoset primarily resides within a JSON manifest (WP manifest). That JSON may optionally be embedded in the entry page rather than a standalone file referenced by <link> from the entry page.  It may be supported to allow some infoset items to reside in HTML of the entry page, if information duplication issues can be sufficiently avoided.

2.3. WAM or not

Proposed resolution: “Publications, as specified here, are not necessarily Progressive Web Applications. On the other hand, WAM is tightly coupled to a Progressive Web Applications, thus,, we will not require the usage of the WAM and our specification should not be dependent on it. The WP Manifest should be specified independently of the WAM. Of course, a particular WP may be rendered via a PWA, and therefore use a WAM, but that is orthogonal to this specification.” (Garth Conboy)

Garth Conboy: this isn’t really an issue resolution, unless we can find the issue
… there’s been a lot of discussion

Garth Conboy: (reads above proposed resolution)

Garth Conboy: how can a proposed resolution that uses orthogonal not be a good resolution? ;)

Garth Conboy: this is where I hoped we’d end up

Benjamin Young: +1 to the text as is; this was the takeaway of the task force

Hadrien Gardeur: +1 as well

Dave Cramer: +1.

Joshua Pyle: +1

Jeff Buehler: +1 for me as well

Tim Cole: I’m a little concerned with the wishy-washy language at the end… it seems gratuitous.
… another concern I have is that there will be people in the browser community who will say if some WPs can be specified by WAM, let’s only worry about those WPs.

Garth Conboy: this was not in my mind proposed spec language, this is what is in our understanding of the issue
… don’t disagree with your comment

Proposed resolution: Publications, as specified here, are not necessarily Progressive Web Applications. On the other hand, WAM is tightly coupled to a Progressive Web Applications, thus we will not require the usage of the WAM and our specification should not be dependent on it. The WP Manifest should be specified independently of the WAM. (Ivan Herman)

Garth Conboy: I think what Ivan just posted is addressing your comment, Tim
… I think Matt will resolve this

Garth Conboy: OK. Let’s count that as a resolution.

Resolution #4: Publications, as specified here, are not necessarily Progressive Web Applications. On the other hand, WAM is tightly coupled to a Progressive Web Applications, thus we will not require the usage of the WAM and our specification should not be dependent on it. The WP Manifest should be specified independently of the WAM.

Garth Conboy: I didn’t think we could get through these issues in an hour
… I did put one more thing on the agenda, but it is quite relevant to an issue that came up this morning

3. Is an exhaustive “resource list” required to create a Web Publication?

Garth Conboy: https://github.com/w3c/wpub/issues/198

Garth Conboy: there’s a primary reading order, but what about the rest of the issues. Must they specified fully?
… there are some comments in there that I like, from Ivan
… the list of secondary resources should be those needed for offlining
… the Q is whether that list of secondary resources is required. MUST all web pubs be offlinable/packageable?
… so the secondary list is author-optional?

Garth Conboy: https://w3c.github.io/wpub/#wp-resource-list

Garth Conboy: it does have the statement that it is strongly recommended to supply a list of all resources
… that’s a may, not a must.
… if that’s really what we mean that drives the issue

Brady Duga: we can discuss this again, but this exact question has been asked

Hadrien Gardeur: I think the current draft is fine

Brady Duga: the very clear answer from the group is that not all publications can be cached/offlined

Garth Conboy: I don’t love it, I can live with it

Brady Duga: I’m not necessarily in the camp, but I asked the question and the answer was clear

Joshua Pyle: I’m not entirely clear how the requirement for a resource list factors into packagability
… even a non-offlineable publication could have a list of constituent pieces
… but I wanted to weigh in that I feel strongly that WP ‘may” be packageable
… there are a lot of publications where it would be impractical to package
… and we don’t want things to be automatically packageable
… we want to tag things as unpackageable, possibly with a license
… in terms of offlinable, I feel less strongly
… it might be a worthwhile challenge to say they must be offlinable
… . what that means to me is that they are designed so that if you have minimal bandwidth, then a minimal amount of data to start the publication, and it doesn’t lock up if you go into the proverbial train tunnel
… perhaps without videos etc
… but at least it doesn’t “lock up” when it loses connection

Garth Conboy: let me answer the first thing
… my view is that the exhaustive list of secondary resources is required to make things offlinable
… or packaged
… if that list is missing
… then you’re going thru the list of primary, then web browsers do know how to get the associated resources

Hadrien Gardeur: the current spec language is fine
… I don’t agree with what you said
… it’s possible to have publications with everything in html
… with CSS inline, images as base64
… so I don’t think we should tie ability to offline to a list of resources

Garth Conboy: then you don’t need a list of secondary resources
… I agree

Hadrien Gardeur: basically the list of resources is not what is going to indicate if a WP is packageable
… you can always package or cache the primary resources
… but if your WP depends on JS, css, etc, and you don’t include those in the list of resources, than this can affect the quality of the experience
… this is not similar for all publications
… some will heavily rely on JS, and if you don’t include JS they will break

Deborah Kaplan: I want to say a variant
… this is a controversial thing
… we shouldn’t just say let’s agree
… we are conflating too many things
… it’s hard to differentiate between packaging and offlining
… packaging is not the same as rights management
… packaging and piracy are separate
… it’s important to understand what secondary resources are
… in some cases ALL CSS and JS are necessary for the publication
… if they are necessary they’re not secondary
… if the publication is not usable without the resource, then there’s an argument that it’s not secondary

Ivan Herman: we have to be careful to distinguish between offline and packaging
… these are two different things
… we may have to have yet another entry in our infoset which says does the author allow offlining or packaging
… if we decide there are non-offlinable WPs, we must state this, we cannot deduce this from magic
… I would prefer we say every WP is at the minimum offlineable
… and the author should say this explicitly
… the list controls what goes into the offline version

Deborah Kaplan: so to clarify:

Deborah Kaplan: 1. Let’s have an up/down vote on language if we’re deciding today, not a quick silence = consent

Deborah Kaplan: 2. Packaging != offlining != rights management

Deborah Kaplan: 3. If a resource is necessary, it’s not secondary. If it’s necessary, it needs to be listed. If it’s not necessary, it doesn’t need to be listed.

Deborah Kaplan: I agree with Ivan, re: offlineable. +1

Bill Kasdorf: Note that there is a difference between “allowing” offlining and “enabling” offlining.

Ivan Herman: I think every web publication is offlineable, but it’s up to the author to say what’s in the offline version

Garth Conboy: I think with the language that the full list is recommended but not required
… that means the pub may or not be fully offlineable

Ivan Herman: what do you mean?

Deborah Kaplan: I don’t agree with that, Garth.

Garth Conboy: if such a list of 2ndary resources isn’t there, then offline would get primary resources plus their direct links, which might not be enough

Brady Duga: I want to remind people that DRM is out of scope, and we shouldn’t worry about it

Joshua Pyle: +1 (please God, no DRM)

Ivan Herman: +1 to duga

Deborah Kaplan: duga++

Luc Audrain: +1

Tim Cole: we did have a conversation that relates to offlinability and caching

Tim Cole: https://github.com/w3c/wpub/issues/183

Tim Cole: that doesn’t get all the way to DRM, but in browsers you might say that something shouldn’t be cached because it changes too quickly
… we also haven’t defined what offlining means
… so I don’t agree with Ivan that everything should be technically offlinable, that might be too much

Garth Conboy: I’m gonna paste something in that Ivan might disagree with

Garth Conboy: “Is an exhaustive “resource list” required to create a Web Publication?

Garth Conboy: No. Such an an exhaustive list may be needed to make the WP fully offline-able or package-able. But, an exhaustive list of resources required (beyond the primary reading order) is not required, as it is up to the author whether a WP is fully offline-able or package-able.”

Garth Conboy: the issue: is an exhaustive list required? I’ll propose above as resolution

Ivan Herman: you said something that worries me, garth
… you said you take the primary resources offline, and the CSS and etc… that is pandora’s box
… there are things I didn’t mention explicitly that are offlined

Garth Conboy: I’m for requiring the list

Ivan Herman: I don’t think we need a decision today

Garth Conboy: the spec says the list isn’t required

Ivan Herman: let’s not go into linguistic analysis
… it just meant that the resource list may be a selective list that are used by WP but selected by what can go into a cache and what can’t
… this is not easy

Deborah Kaplan: i agree with ivan
… we are not stating about packaging and offline
… this is a Q about resource list
… offline and packaging aren’t in the scope of the next 11 min
… but it’s legitimate to say what that list of resources will enable
… what is in the resources defined what could be cached, what could be offlined, what could be packaged, what could be preloaded
… here are affordances provided by a such a list. if a resource isn’ tin the list, then these things aren’t possible
… this is just a minimum requirement

Brady Duga: +1 to understanding what this list is for
… if CSS is not listed in 2ndary list, am I forbidden from downloading it?
… one reason we didn’t require resources to be in this list is scripting

Jeff Buehler: +1 dauwhe beyond scope of next 10 min - I need to think about this more myself

Brady Duga: where it might not be possible to determine what resources are used by script

Hadrien Gardeur: a comment on terminology
… i think primary and secondary are confusing
… we’re talking about reading order and list of resources
… we need to be careful
… talking about offlining is confusing.
… there are many ways to do that.
… we should talking about caching and packaging
… packaging is a way of offlining, too
… I think default reading order and resources are two lists where we have expectation of user agents
… we expect UA to do something more, put them in package, to have a proxy to intercept requests
… this is what we should be discussing
… what the UA should be doing that the web doesn’t do now
… everything else should be like the web
… if we have image with cache-control headers, it might still work offline because of caching even when it isn’t in the list

Tim Cole: +1 Hadrien

Benjamin Young: the Q that came up as to what H said, why do we need the list…
… working out the scenarios for its use
… currently it’s recommended, but now we say that it has to include all the primary resources, and we’ve doubled everything
… we also need to define exhaustive
… and we haven’t repeated existing components
… it would be good to work thru the “why is this here” stuff

Garth Conboy: I’m giving up on my fantasy of closing this issue
… we do have agreement that the default reading order is required
… I would envision the resource list is stuff beyond the default the reading order, so we don’t restate stuff

Benjamin Young: +1 to not restating stuff

Benjamin Young: (as in not restating stuff in the resource list)

Hadrien Gardeur: +1 to avoid redundancy between default reading order and list of resources

Ivan Herman: +1, too

Luc Audrain: +1

Dave Cramer: github-bot: end topic

Ivan Herman: Safe travels for all who come!

Garth Conboy: thanks everyone
… no call on Memorial day

4. Resolutions