Publishing Working Group Telco — Minutes
Date: 2017-11-13
See also the Agenda and the IRC Log
Attendees
Present: Leonard Rosenthol, Tzviya Siegman, Mateus Teixeira, Wolfgang Schindler, Luc Audrain, Avneesh Singh, Joshua Pyle, Hadrien Gardeur, Baldur Bjarnason, Dave Cramer, Romain Deltour, Ivan Herman, Nick Ruffilo, David Wood, Tim Cole, JunGamo, Garth Conboy, Ric Wright, Toshiaki Koike, Bill Kasdorf, Marisa DeMeglio, Matt Garrish, Vladimir Levantovsky, Peter Krautzberger, Brady Duga, Ben Schroeter, Laurent Le Meur
Regrets: Reinaldo Ferraz, George Kerscher, Charles LaPierre, Daniel Weck
Guests:
Chair: Tzviya Siegman
Scribe(s): Nick Ruffilo
Content:
Tzviya Siegman: lets get started. Welcome back to all who was at TPAC. Those who didn’t attend were missed.
1. Last minutes
Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-10-23-minutes
Tzviya Siegman: we have October 23rd minutes. Approval?
… Oct 23rd minutes - any comments?
Resolution #1: meeting for oct 23 are accepted
Tzviya Siegman: Minutes approved. We did talk about archiving - which is not resolved yet. That belongs in the PWP section. I assume everyone who was at TPAC read through the minutes. I will be writing a summary of TPAC this week, it will be almost like you were there. Even if you were there, it will take you back.
Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-06-minutes.html
Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-07-minutes.html
Ivan Herman: Lets give people a chance to review and read these - let’s approve next week.
Tzviya Siegman: Avneesh, do you have meeting minutes from your meetings?
Avneesh Singh: We will get APA meeting minutes from Janina
2. TPAC experiences
Tzviya Siegman: Moving along, most of the agenda is TPAC based. I can talk for a long time but if people want to share some thoughts… We had a very successful set of meetings. We should be publishing things soon. Matt will be working on the Web Publications draft. We will have work done from David on Packaged Web Publications…
Ivan Herman: We had a separate get-together with Jake and others about offlining - that was interesting, I am not sure how to summarize.
Garth Conboy: It was a crowded breakout - with Jake Archibald from google - the consensus from jake and possible Marcos, when we had the talk at the publishing summit - is that their theory is that browsers should not bake reading system functionality early - it should be done late after we define what WP is. Intelligent pollyfills or whatever - when there are sufficient of that, then maybe that is when browsers should natively take on - through experimentation. Finishing the definition of WP and get some experimental implementations, which will decouple it from the major browsers, which can be seen as a feature or a bug.
Benjamin: One thing we clarified was that there are certain things that cannot be shimmed - we cannot create a cross-domain service worker. We would have to use a browser extension to demo that - so there are things we could or could not polyfill - we would need to approach that in interesting ways. We don’t know exactly what we should be polyfilling or things they would see falling to a reading system or a store or a search engine. there was a lot of implications that “this isn’t the browser’s job” so we need to figure out what we expect the browser to be.
Tzviya Siegman: I wanted to add - there was a great discussion on twitter, started by Marcos, that started out saying “publishing doesn’t understand progressive web-apps” but ended saying: “we’ll work together to figure this out.” It’s an opening for us to sit down with people like Marcos (who works for Firefox) and some of the people in the TAG were also in the exchange. There is interest in what we’re doing, and interest in working things out. Some of the discussions were difficult, but I think the outcome was positive - so we can possibly figure out how to make this work in browser land
Ivan Herman: I am not a twitter user - and I’m not alone. Is there a way to collect the tweet feed for sharing?
Hadrien Gardeur: even without Storify, a simple link to the tweet provides the whole discussion: https://twitter.com/marcosc/status/928708608832835584
David Wood: Chrome and Firefox developers confuse books with Web pages. They see no difference. I see a lot of important differences. Not all of those differences are functional affordances; some have great social consequences, such as expectations of privacy. We will live in a much poorer world if the browser vendors don’t change their position.
Ivan Herman: The reason I originally queued myself is that there was one message that came up strongly in the various meetings from the browser vendors - essentially that we cannot count on the browsers to initially come and implement what we do - this is not their way of operation. they expect new features to be implemented, demonstrated, and proven that it can work. They need to show users… If all those things are put together, then they will consider implementation. This is how we should see things and operate. It’s important to find ways where the web publication should be displayed in a browser. Otherwise it will not work. One more things - Tzviya and I talked with two people from Microsoft about people who put epub into edge - so they see an interest in something like this. After the first working draft is out, hopefully Microsoft might join the group. It would be welcomed.
Romain: I am wondering if we should have another document or a gap analysis about why we thing the current web is not enough. Marcos said he read the current draft, but he thought the document wasn’t clear enough. What more information do we need to convey?
David Wood: +1 to rdeltour - we need a written gap analysis between a Web page and a book
Baldur Bjarnason: I’m with Marcos that the web does 99% of what web publications need so it isn’t just people outside of this WG who have that opinion.
Bill: I was not able to be at the F2F but at the summit - I thought the browser people were shockingly modest - instead of being arrogant. They were more saying that ‘if we just trudge ahead and do it, we’ll do it wrong, which is why we need guidelines
Peter Krautzberger: +1 to baldur
Tzviya Siegman: If people are reading our spec and saying ‘this isn’t telling me something I don’t already know’ then we need to analyze the spec. We need to figure out how to get a bookish experience and how that is different enough.
Benjamin Young: PWA = Progressive Web Apps
Benjamin: The PWA case works if you’re talking about a single book - and if you’re OK about unknown expectations when they get the ‘thing’ but a PWA has some requirements when installing on the homescreen - a manifest, a service-worker for offline, but from a publication expectation, they offer no guarantee about accessibility, or other things that are musts/shoulds. A PWA isn’t going to provide those things. If we are talking about features that would span multiple features - search, annotation, the browser hasn’t come close to thinking about those things. What are the affordances? That will find our points of clarification - or we’ll need to make an extension…
David Wood: +1 to bigbluehat
Ivan Herman: I saw Hadrien’s comment - and it’s close to what I wanted to ask. Is there a proper spec for PWA, or is it general “you know or you don’t”?
Peter Krautzberger: https://developers.google.com/web/progressive-web-apps/
Peter Krautzberger: https://developers.google.com/web/progressive-web-apps/checklist
David Wood: https://en.wikipedia.org/wiki/Progressive_web_app
David Wood: https://developer.mozilla.org/en-US/Apps/Progressive
Romain: PWA is a term - a set of best practices and a set of standards… So the service workers are an essential part of PWA and the manifest is as well, but how they fit together is a collection of best practices - but google docs and blog posts.
Romain Deltour: “PWA” was coined by Frances Berriman
Tzviya Siegman: Most of us agree that PWP should follow the mindset of PWA - which doesn’t conflict with the work we’re doing, but what we’re missing, and what people we’ve spoken to is trying to describe to us - ‘what makes publications unique’. What is it - from a technical terms - that makes a PWP unique.
David Wood: We know how we think about books, and they aren’t like Web pages, but we need to write it down.
Hadrien Gardeur: a publication is an explicitly defined collection of resources, not an implicit one (PWA)
David Wood: The feel of a paper book is important UX :)
Ivan Herman: I would go one step further than what you said - maybe we need - relatively quickly - a page somewhere that would try to make a quick comparison between what we describe as PWA and what we are. That might be a good thing to do because we will hit this question millions of times.
Peter: Sorry for missing TPAC - I wanted to go back to an early point that Ivan made - the input that anything has to happen by polyfilling and making a case that something is missing - how do we expect the transition from a spec to a polyfill? I feel like without thinking about how you can make those stages, we will not tackle the stages that are really holding things back. I don’t see any connection to that path… Just a general question.
Tzviya Siegman: If I visit a website that looks like a publication, but it’s a web publication - what is different? Why is it different? What is it really missing.
David Wood: PRIVACY, offline reading, navigation, search, annotation
David Wood: An edited collection
Garth Conboy: The “collection” and metadata
Benjamin Young: …its the guarantee of those things–as all of them are provide-able via a PWA
Luc Audrain: boundaries, authors rights
David Wood: +1 to guarantee
Tim Cole: To me, one way to explain is what makes web publication different from a website. Some is continuity - some is reading in a more structured way - ways that you cannot specify without additional requirements. I’m creating content that starts in this file, and ends in this file, then goes from A to B to C. That may begin to help if we can define the polyfills - making it more than that.
Hadrien Gardeur: Having an explicit collection is what makes it different from a website. I discover a page using a URL but from the URL I could browse anywhere - no start or stop. the explicit collection, you know what is inside and not inside - context. The web doesn’t have a way to provide metadata for that collection. I can provide metadata about a website, but not a collection. PWA doesn’t add to that. it’s about ‘here is where you start’ but not where things end. It provides metadata but it’s lacking. It does more than a standard web page but it doesn’t go as far as to provide an explicit set
Luc Audrain: +1
Avneesh Singh: +1 bigbluehat
Baldur Bjarnason: +1 bigbluehat
Benjamin: Browsers will continue to come back with ‘you can do this with a PWA’ The collection thing is one, but they would look at the different formats we’ve kicked around, so then as an industry, choose to list your documents one way and build your PWAs on top of that. But if we want braille readers to be able to guarantee, and perhaps for the short-term, we would then need to prove to the browsers that we can do this. It’s frustrating to hear this, but they are right - we need to narrow into what we can all JS together. The collection OM maybe comes close - but it might just be a new JS API and possibly no more. We need to be very clear. We now know the rules, so lets play the game
Benjamin Young: PWA + guarantees of ___? (maybe?)
Ivan Herman: Continuing down that line, maybe the right formulation is to say we are different from PWA - but to acknowledge to say we are a PWA++. Many things they do actually works for us - service workers, manifest - sure, but we have additional needs. Lets not try to make it a difference, but what we need further
Benjamin Young: +1 ivan
Tzviya Siegman: We cannot say different - because we aren’t that different. The conversation we had today was productive. Maybe Matt with his magic can help write it up. It maybe does belong in the document, maybe it’s a separate document. Any other TPAC comments?
Tzviya Siegman: The concept of packaging came up more than I expected - even in other groups.
Ivan Herman: but we are not wiser on the packaging.
Benjamin: One comment on packaging - one thing that came up in offline docs is that some clarification is needed in offlining something - so this thing might let you have a cached copy VS a keepable copy - and a packaged thing. PWAs talk about reinstating the app from a launch screen - but you don’t necessarily know if it’s been offlined. Packaging provides for that - but to what end, and is it still part of the app. Within WP and PWP we need to think through this.
Tzviya Siegman: we mention the concept of archiving, but we’ve discussed it being an issue not just for us but for the larger web.
Benjamin Young: +1
3. Pull Request #94
Tzviya Siegman: Issue #94 (Pull request #98)
Tzviya Siegman: https://github.com/w3c/wpub/issues/94
Tzviya Siegman: Very active discussion about the URL of a publication. The basic idea is that a web publication is identified as a URL - but what does it resolve to? We had almost consensus on this, but there was some discussion on this that might not have - there might be further discussion on it…
David Wood: (not necessarily “inside” the publication - we haven’t decided that yet)
Laurent Le Meur: What we want a landing page for? there is a sort of consensus for it to have a URL. One will be a URL that leads to an entry point within the publication. We know that when we talk about a book or an epub - there is an entry point - the first spine ID - usually the cover. On the web - to have a webpage with a cover is not a great thing - especially if this web page is processed by a web browser - it will not lead to the other parts of the web publication. The idea of the landing page is to show the users something that is an entry point to the publication. As they’ve said, in the summary, we can have a consensus that it’s an HTML page, because it can contain links, some content with images, and it should have a link to the JSON Manifest - so it could be found easily. Should it contain the TOC? On this - it MAY contain a TOC or the TOC could be something that is linked to from the spine of this landing page. we should not have a SHOULD for the TOC.
David: There was some confusion on the issue - i think some of the things that web people find utterly critical is that if we’re going to identify a publication on the web, that we need to have a URL that resolves to something. One thing that makes a web publication different than a general resource is that it’s going to have to resolve to something you expect. That’s why we’re writing a spec - so you know what you’re getting. We want to say this ‘thingie’ that we’re pointing to is a web publication and clients who access that URL can tell that it is a web publication when they resolve it - so they know how to handle it. When we resolve the URL - you can tell it’s a web publication. The 2nd metapoint of that issue is, when you resolve the URL and tell it’s a web publication, we don’t want to confuse older clients.
… From that basic foundation, some things fall out. We probably want it to be an HTML page, if it contains a TOC or is inside the package - these are ancillary. Doesn’t matter if they are inside or not, or has a TOC or not, just that a client can tell that it’s a web publication and knows how to handle it. Helpful to reset the conversation?
Tzviya Siegman: Laurent, some of the terms - such as a spine - are EPUB terms, so lets not assume we’re pulling things in from EPUB world
Garth Conboy: We did agree there is a default reading order - which epub world calls a spine… I found David’s comments useful. If we are in a position - if the TOC is the default reading order, and if we are going to require it - it makes me somewhat nervous that the landing page might contain this document or it might not. Seems to me we have to make a decision as to where all things that are required must live. I’m nervous about it being in two different places. Whatever we land on has to be identified as a web publication. For those who haven’t dug into this, there are beautiful GitHub graphics. We’re in the scenario 3 discussion - so focus on that
David Wood: +1 to garth - confusion is bad and hard to implement
Hadrien Gardeur: Compared to some other discussions in the issue - I agree more with what David said than the conclusion of that issue. What David said is that we need an HTML page, inside or outside, don’t care if it requires TOC or not… I still have one thing I’m still wondering about. You talked about having the current page a web publication. Do we want to know that the current page is the web publication, or that the landing page is part of the publication… I like that you’re not getting into too many details, such as a specific link or a link to a manifest…
Garth Conboy: I think Hadrien is hitting on something important. Is this landing page part of the web publication or is it just a pointer to the web publication. Either answer is OK, but that’s what we need to nail down.
David Wood: I’d vote for the landing page being “inside” or part of a WP, but am willing to take guidance from the publishers to find whether there are good arguments the other way.
Hadrien Gardeur: I would vote for the landing page to be outside the WP, and as a place that identifies where you can actually find the publication (similar to how RSS or PWA work). I’m fine with the landing page being optionally inside the WP, but this shouldn’t be a requirement.
Ivan Herman: Let’s not forget that one of the fundamental issues we had at the start - we agreed that a web publication, even if it’s abstract, it has a URL. If it has a URL, the first question you have to answer is what happens when I reference this stuff. From an architecture point of view, we should refer to the HTTP header… We played with various scenarios… That said, if we want to be practical and satisfy the current browsers/engines, this must have a very clear answer. We would have to go to something the browsers understand. For me, the scenario where this page - landing page or whatever - this page has a link to the publication - what does it mean to dereference the link? The only pragmatic answer I feel is taking from here - that yes, it is an HTML page that is an integral part of the WPUB. We don’t want to get involved in the HTTPRange-14 discussion that lasted years
Tzviya Siegman: Next steps with this - we have not met consensus…
Benjamin: The thing that comes back from the URL of the web publication - MUST contain it’s binding - it has to do the thing that does the binding - if it’s outside, it won’t be useful.
Ivan Herman: Binding?
Benjamin: encompass the edges of the collection - ‘here are the resources that make up this thing’
Hadrien Gardeur: I’d like to point that I can find a RSS feed on an HTML page, without considering that the current HTML document is part of the RSS feed.
Ivan Herman: +1 to benjamin
Tzviya Siegman: It seems we need to hash this out a bit more on GitHub and come to consensus
Garth Conboy: I personally be okay with the the “landing page” being a page that contains a
<nav>element, and contains the default reading order, and links to the JSON manifest (identifying it as a WP), and this landing page itself may, or may not, be in the contained default reading order.
Luc Audrain: +1 to Benjamin
Mateus Teixeira: +1 bigbluehat, garth
Tzviya Siegman: we have lots of work to do 2 drafts to come out soon
David Wood: Thanks all!
Benjamin Young: +1 garth
4. Resolutions
- Resolution #1: meeting for oct 23 are accepted