16:49:50 RRSAgent has joined #pwg 16:49:50 logging to https://www.w3.org/2017/11/13-pwg-irc 16:49:51 rrsagent, set log public 16:49:51 Meeting: Publishing Working Group Telco 16:49:51 Chair: tzviya 16:49:51 Date: 2017-11-13 16:49:51 Regrets+ ReinaldoFerraz 16:49:51 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2017Nov/0009.htmll 16:49:51 ivan has changed the topic to: Meeting Agenda 2017-11-13: https://lists.w3.org/Archives/Public/public-publ-wg/2017Nov/0009.html 16:50:04 Regrets+ George 16:55:13 as our IT seems to have messed sth up with my business phone, I may only join the "call" via IRC. 16:55:45 typically at this time of the day I won't get any assistance on this issue today. 16:56:21 laudrain has joined #pwg 16:56:44 leonardr has joined #pwg 16:56:50 present+ Leonard 16:57:37 present+ 16:58:06 mateus has joined #pwg 16:58:15 mattg has joined #pwg 16:58:22 present+ 16:58:26 present+ wolfgang (IRC-only) 16:58:48 Present+ 16:58:59 josh has joined #pwg 16:59:02 *@tzviya: I'll keep my fingers crossed for you 16:59:05 present+ 16:59:26 present+ 16:59:56 JunGamo has joined #pwg 17:00:21 present+ 17:00:34 rdeltour has joined #pwg 17:00:35 present+ dauwhe 17:00:41 NickRuffilo has joined #pwg 17:00:45 timCole has joined #pwg 17:00:46 dwood has joined #pwg 17:00:54 present+ 17:00:56 present+ 17:00:56 scribenick: nickruffilo 17:01:00 present+ 17:01:03 present+ 17:01:03 present+ Tim_Cole 17:01:08 present+ 17:01:41 rkwright has joined #pwg 17:01:44 garth has joined #pwg 17:01:53 present+ Garth 17:02:14 present + 17:02:27 toshiakikoike has joined #pwg 17:03:02 present+ 17:03:32 Bill_Kasdorf has joined #pwg 17:03:39 Ivan, Tzviya, you on? 17:03:40 present+ 17:03:51 Audio is pretty silent! 17:04:04 marisa has joined #pwg 17:04:05 present+ 17:04:11 :-) 17:04:27 Regrets+ clapierre 17:04:33 chair: tzviya 17:04:37 Interesting… we’ll try to dial back in! 17:04:52 Vlad has joined #pwg 17:04:55 Tzviya: lets get started. Welcome back to all who was at TPAC. Those who didn't attend were missed. Garth, would you prefer to chair this session? 17:05:00 present+ 17:05:07 ...: Seems there is some issues with callin. 17:05:18 pkrautzberger has joined #pwg 17:05:25 present+ pkra 17:05:30 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-10-23-minutes 17:05:35 present+ 17:06:04 ...: we have october 23rd minutes. Approval? 17:06:21 pkrautzberger has left #pwg 17:07:09 duga has joined #pwg 17:08:00 david_stroup has joined #pwg 17:08:26 ...: Oct 23rd minutes - any comments? 17:08:36 RESOLVED: meeting for oct 23 are accepted 17:08:41 *@NickRuffilo: especially when it's working ;) 17:09:03 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-06-minutes.html 17:09:11 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-07-minutes.html 17:09:13 s/*@NickRuffilo: especially when it's working ;)// 17:09:23 pkra has joined #pwg 17:09:28 ...: Minutes approved. We did talk about archiving - which is not resolved yet. That belongs in the PWP section. I assume everyon 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 17:09:29 present+ pkra 17:09:50 Ivan: Lets give people a chance to review and read these - let's approve next week. 17:10:03 present+ Avneesh 17:10:06 Tzviya: Avneesh, do you have meeting minutes from your meetings? 17:10:09 BDugas has joined #pwg 17:10:18 Avneesh: I can get the link from Nina. 17:11:12 Regrets+ DanielWeck 17:11:18 present+ 17:11:33 I'm still in CA, so I'm on the call. 17:11:42 Yay :) 17:11:46 Tzviya: 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... 17:11:50 present+ dwood 17:11:54 s/Nina/Janina 17:12:16 Correction for minutes: We will get APA meeting minutes from Janina 17:12:22 q? 17:12:27 q+ 17:12:31 Ivan: We had a separate get together with Jake and others about offlining - that was interesting, I am not sure how to summarize. 17:13:21 q- 17:13:49 q+ 17:14:05 q+ 17:14:18 ack bigbluehat 17:14:21 Garth: It was a crowded breakout - with Jake Archibold 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 17:14:21 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. 17:14:51 BenSchroeter has joined #pwg 17:14:58 present+ 17:15:30 q+ 17:15:47 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 17:15:47 system or a store or a search engine. there was alot of implications that "this isn't the browser's job" so we need to figure out what we expect the browser to be. 17:15:50 q? 17:16:05 ack tz 17:16:19 leslie has joined #pwg 17:17:16 ack ivan 17:17:18 q+ 17:17:18 Tzviya: 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 17:17:18 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 17:17:22 q? 17:17:30 Hadrien has joined #pwg 17:17:52 Ivan: I am not a twitter user - and I'm not alone. Is there a way to collect the tweet feed for sharing? 17:19:07 q+ 17:19:29 even without Storify, a simple link to the tweet provides the whole discussion: https://twitter.com/marcosc/status/928708608832835584 17:19:54 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. 17:20:19 ack rdeltour 17:20:22 Ivan: 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 imeplemented, demonstrated, and proven that it can work. They need to show users... If 17:20:22 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. 17:20:23 After the first working draft is out, hopefully Microsofot might join the group. It would be welcomed. 17:20:45 s/Microsofot/Microsoft 17:21:38 +1 to rdeltour - we need a written gap analysis between a Web page and a book 17:21:38 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? 17:21:50 ack Bill_Kasdorf 17:22:02 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. 17:22:17 q? 17:22:21 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 17:22:39 +1 to baldur 17:23:23 q? 17:23:25 q+ 17:23:30 Tzviya: 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. 17:23:33 Ivan: What is PWA? 17:23:34 PWA = Progressive Web Apps 17:23:38 ack bigbluehat 17:23:39 Tzviya: Progressive Web Apps 17:25:49 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 17:25:49 those things. If we are talking about features that would span multiple features - search, annottaion, 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... 17:25:50 q? 17:25:51 q+ 17:25:53 +1 to bigbluehat 17:25:57 ack iv 17:26:26 Ivan: 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' 17:26:32 https://developers.google.com/web/progressive-web-apps/ 17:26:49 q+ 17:26:52 https://developers.google.com/web/progressive-web-apps/checklist 17:26:53 ack rdeltour 17:26:58 https://en.wikipedia.org/wiki/Progressive_web_app 17:27:26 laurentlemeur has joined #pwg 17:27:31 present+ 17:27:40 https://developer.mozilla.org/en-US/Apps/Progressive 17:27:41 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. 17:28:03 q+ 17:28:08 q+ 17:28:12 "PWA" was coined by Frances Berriman 17:28:29 Tzviya: 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' 17:28:45 q+ 17:28:48 q+ 17:28:49 ...: What is it - from a technical terms - that makes a PWP unique. 17:28:57 We know how we think about books, and they aren't like Web pages, but we need to write it down. 17:28:58 q- 17:29:23 a publication is an explicitly defined collection of resources, not an implicit one (PWA) 17:29:27 The feel of a paper book is important UX :) 17:29:37 q- 17:29:46 ack iv 17:30:33 Ivan: 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. 17:30:34 ack pkra 17:31:57 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 17:31:57 connection to that path... Just a general question. 17:32:08 q+ 17:32:13 ack NickRuffilo 17:33:08 q+ 17:33:20 q+ 17:33:27 q- 17:33:58 q+ 17:34:19 ack timCole 17:34:20 Tzviya: If I visit a website that looks like a publication, but it's a web publication - what is different? Why is it differnet? What is it really missing. 17:34:22 PRIVACY, offline reading, navigation, search, annotation 17:34:49 An edited collection 17:34:54 The “collection” and metadata 17:35:15 ...its the guarantee of those things--as all of them are provide-able via a PWA 17:35:37 q+ 17:35:46 +1 to guarantee 17:35:47 ack Hadrien 17:35:48 Tim: 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. 17:36:29 boundaries, authors rights 17:37:19 q? 17:37:20 q+ 17:37:24 ack bigbluehat 17:37:28 Hadrien: 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 insite 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 17:37:28 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 starndard web page but it doesn't go as far as to provide an explicit set 17:37:46 +1 17:38:46 q? 17:38:47 +1 bigbluehat 17:38:56 +1 bigbluehat 17:39:04 q? 17:39:22 ack ivan 17:39:23 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 17:39:23 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 17:40:16 PWA + guarantees of ___? (maybe?) 17:40:30 Ivan: 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 - but service workers, manifest - sure, but we have additional needs. Lets not try to make it a difference, but what we need further 17:40:38 +1 ivan 17:41:31 Tzviya: 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? 17:41:51 q+ 17:41:53 Tzviya: The concept of packaging came up more than I expected - even in other groups. 17:42:05 Ivan: but we are not wiser on the packaging. 17:42:24 ack bigbluehat 17:43:33 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 17:43:33 still part of the app. Withing WP and PWP we need to think through this. 17:43:49 +1 17:43:50 Tzviya: we mention the concept of archiving, but we've discussed it being an issue not just for us but for the larger web. 17:43:54 s/+1// 17:44:00 +1 17:44:12 Tzviya: Dave, do you want to say anything about the PWP document and how you want to move forward? 17:44:20 Can you hear me? 17:44:27 No :) 17:44:36 OK 17:44:46 https://github.com/w3c/wpub/issues/94 17:44:50 Tzviya: Pull request #94 17:44:59 Topic: Issue/PR #94 17:45:45 ...: 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 concesus on this, but there was some discussion on this that might not have - there might be further discussion on it... 17:45:49 q+ 17:45:54 ack laurentlemeur 17:46:47 (not necessarily "inside" the publication - we haven't decided that yet) 17:46:59 q+ 17:48:14 Laurent: What we want a landing page for? there is a sort of conesus 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 17:48:14 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 17:48:57 q+ to ask about spine 17:48:59 ...: 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. 17:49:01 ack dwood 17:49:08 q+ 17:51:25 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 17:51:25 - 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 17:51:26 don't want to confuse older clients. 17:51:42 Karen has joined #pwg 17:52:17 q+ 17:52:19 ...: 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? 17:52:33 ack tzviya 17:52:33 tzviya, you wanted to ask about spine 17:53:00 ack garth 17:53:02 Tzviya: Leaurent, some of the terms - such as a spine - are epub terms, so lets not assume we're pulling things in from EPUB world 17:54:21 +1 to garth - confusion is bad and hard to implement 17:54:26 s/Leaurent/Laurent/ 17:54:50 Garth: 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 17:54:50 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 17:54:52 ack Hadrien 17:55:57 q+ 17:56:06 q+ 17:56:25 Hadrien: 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 17:56:25 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... 17:56:29 ack garth 17:56:56 ack ivan 17:57:01 Garth: 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. 17:57:37 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. 17:57:42 q+ 17:58:52 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). 17:59:31 I'm fine with the landing page being optionally inside the WP, but this shouldn't be a requirement. 17:59:44 ack bigbluehat 17:59:48 Ivan: 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 17:59:48 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 17:59:49 integral part of the web page. We don't want to get involved in the HTTP 14 discussion that lasted 2 years 18:00:13 s/HTTP 14/HTTPRange-14/ 18:00:34 Tzviya: Next steps with this - we have not met concensus... 18:00:59 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. 18:01:03 Ivan: Binding? 18:01:17 Benjamin: encompass the edges of the collection - 'here are the resources that make up this thing' 18:01:47 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. 18:01:50 +1 to benjamin 18:02:00 Tzviya: It seems we need to hash this out a bit more on GitHub and come to consensus 18:02:14 I personally be okay with the the “landing page” being a page that contians a