15:58:02 RRSAgent has joined #pwg 15:58:02 logging to https://www.w3.org/2018/04/23-pwg-irc 15:58:07 Zakim has joined #pwg 15:58:15 title: PWG 15:58:32 chair: Tzviya 15:58:44 rdeltour has joined #pwg 15:58:46 JunGamo has joined #pwg 15:58:56 jasminemulliken has joined #pwg 15:59:16 present+ 15:59:18 present+ 15:59:31 present+ 15:59:33 Nick_Brown has joined #pwg 15:59:39 laudrain has joined #pwg 15:59:51 bendugas has joined #pwg 15:59:56 josh has joined #pwg 15:59:58 present+ 16:00:09 present+ dauwhe 16:00:11 present+ 16:00:24 present+ wolfgang 16:00:32 adamsisco has joined #pwg 16:00:47 present+ 16:00:51 Present+ 16:00:57 present+ 16:01:03 Present+ 16:01:23 present+ 16:01:29 zakim, pick a victim 16:01:29 Not knowing who is chairing or who scribed recently, I propose Avneesh 16:01:30 NickRuffilo has joined #pwg 16:01:58 evan has joined #pwg 16:02:03 scribenick: nickruffilo 16:02:24 George has joined #pwg 16:02:25 regrets+ garth, ivan 16:02:44 Hadrien has joined #pwg 16:02:46 Vlad has joined #pwg 16:02:49 present+ 16:02:51 franco has joined #pwg 16:02:55 present+ 16:02:55 present+ 16:02:55 present+ George 16:02:59 present+ 16:03:09 present+ 16:03:19 present+ 16:03:21 wendyreid has joined #pwg 16:03:23 cmaden2 has joined #pwg 16:04:08 gpellegrino has joined #pwg 16:04:17 present+ Chris_Maden 16:04:26 present+ 16:04:36 Makoto: I have been involved in epub 3 and 3.2 but i'm also interested in what's happening in this group. I work for KO advanced double3 16:05:02 s/KO/Keio/ 16:05:14 Nick Brown: I'm Nick and i work for Vital Source - part of Ingram. I've been involved with IDPF before and mostly epub3 for the last few years. I work closely with Rick Jonson. 16:05:18 laurentlemeur has joined #pwg 16:05:19 Tzviya: Welcome. 16:05:23 Bill_Kasdorf has joined #pwg 16:05:29 present+ 16:05:30 present+ Benjamin_Young 16:05:32 present+ 16:05:50 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-04-16-pwg.html 16:05:58 Tzviya: First item - review minutes from last week. Comments? 16:06:04 topic: minutes 16:06:05 dave: They should be approved 16:06:57 topic: offlining 16:07:02 duga has joined #pwg 16:07:09 present+ 16:07:55 Tzviya: Approved. Main topic - something we haven't discussed yet - the concept of offlining. I hoped today we could come together on different approaches to offlining. There is a question of if we do it now or defer. Lets open up the floor. I want to start saying that offline is crucial to publications. I believe there is an important case to offline and it's extremely important. Especially 16:07:55 in scholarly publishing - if someone wishes to annotate an HTML document and they are on an airplane or other no-connectivity situations. 16:08:01 q+ 16:08:02 https://w3c.github.io/dpub-pwp-ucr/#onloffl 16:08:04 ack Hadrien 16:08:58 Hadrien: I think what we could be doing regarding offlining is rely on existing infoset items - if i offline a publication, should it be the default reading order? How do you deal with versions? How do I know there are updates? The technical details are going to be difficult, but explaining how various items in the infoset can be used is a good first step. 16:08:58 q+ 16:09:02 ack laurentlemeur 16:09:21 timCole has joined #pwg 16:09:37 q+ 16:09:38 mateus has joined #pwg 16:09:47 present+ 16:09:52 q+ to point out the difference between offline and package 16:10:11 ack dkaplan 16:10:14 Laurent: It occured to me that when we make a relationship with the video business - netflix doesn't try to offline movies for exactly the same stream. When you want to offline, you denote another version. There could be an alternate solution that there is a stream read where you annotate in the reader using a plugin, and if you want to read it offline, you download it and read it in a reading 16:10:14 system. This is what the video world is doing now. We could fallback to this solution. 16:10:15 q+ 16:10:16 present+ 16:10:34 s/denote/download 16:10:55 marisa has joined #pwg 16:11:10 ReinaldoFerraz has joined #pwg 16:11:49 Deborah: The question that will come up - and the big question is how to deal with remote resources. Such as an iframe with a quiz in it from a remote resource - will the publication say that certain items cannot be offlined - or do we need legal notation for what can be downloaded. We will need to accomodate the concept that things may not work with offline/download 16:11:50 ack tz 16:11:50 tzviya, you wanted to point out the difference between offline and package 16:13:08 q+ 16:13:37 pkra has joined #pwg 16:13:40 ack rdeltour 16:13:45 present+ 16:13:45 Tzviya: I want to explain/remind people why we've separated offline and packaging. There are a place where people know that PDF and Epub exist, but they aren't interested in it - such as the world of scholarly publishing. They have access to PDF or epub - but the act of downloading is not what they want. It's an extra step to have to download a file and share it. For scholarly publishing, the 16:13:45 only available format is PDF because epub did not catch on in the scholarly world. If we say the way to access is the complete package, it won't catch on in the scholarly world. So having it offline but not downloaded, that's attractive (in a package) 16:13:58 q+ 16:14:34 q+ 16:14:55 Romain: the other elephant in the room is service workers - so if we say that the web publication does not intend to use offline - we need to have a declaritive way for offlining, but it would require service workers - although they would live in the reading system not the document. The web has solved offlining in this way, so if we want to do something different, we have to explain why. 16:14:58 ack laudrain 16:15:14 q+ 16:15:52 q+ to discuss SW 16:16:05 q+ bigbluehat 16:16:35 ack Hadrien 16:16:35 Luc: in our first public working draft we have clearly associated offlining with the resource list - that means that there is a resource list and that means it should be available when you have no connection. We have something straightforward, as soon as we have the resource list and possibly the default reading order, we should enable access to the publication offline. Our first public working 16:16:35 draft states that a user agent should do this unless it cannot reach the item, in which case it becomes an external resource. With the resource list we have a good start with the question of offlining. 16:17:55 Hadrien: To react to service workers - i am not sure we can say the web has solved offline, but i would advice against this being the only solution. I'm not sure we should say we only have 1 way. There are some real technical issues regarding offlinability. The browser or dedicated reading app can trigger offlining a publication - which is very different than a service worker is designed. The 16:17:55 Service worker is normally allowing the web-app to determine what is offline. 16:17:58 ack dauwhe 16:19:05 dave: I have concerns with service workers as they exist today - especially where they store stuff and how it's handled. I don't want my book deleted by the browsers - so we have needs beyond what service workers are doing. It's a huge topic and I'm wondering if we can let this happen in the first version of the spec. Annotations while offline - that seems really complex and is that required 16:19:05 for version 1 of the spec? 16:19:07 q+ 16:19:25 ack Evan_Owens 16:19:29 q+ 16:19:34 +1 on the topic of "storage" or "persistence", which is one the limitation of today’s Web for publications 16:20:06 q+ 16:20:31 ack tzviya 16:20:31 tzviya, you wanted to discuss SW 16:20:35 Evan: There is an interesting practice in scholarly publishing where a user downloads a PDF - crossref has the functionality where there is a link in the PDF that the user can check to see if there is an update. That's a utility that lets the publisher know if content is updated. Updating is an important issue - the user needs to know if it's the latest version they are looking at. 16:21:11 Tzviya: i wanted to talk about storage VS persistent. We need to suss out how persistant something needs. If it's your ability to go offline for an hour - that's different than needing to persist for a long time.... 16:21:11 ack bigbluehat 16:21:16 david_stroup has joined #pwg 16:21:19 q+ 16:22:17 q+ 16:22:47 https://storage.spec.whatwg.org/#persistence 16:24:06 https://dauwhe.github.io/html-first/Moby-Dick/ 16:25:31 q? 16:25:35 Benjamin: It's come up a few times that: A) we need more nuanced language around 'offline' but there are many different states. Offline in the browser is currently temporal - there are quota limits, it's optimized for your storage, and it lumps it in with cookies. So it's possible to clear cache and get rid of your books. There is the storage spec at the WhatWG - does have some persistence 16:25:35 stuff. It is a way to ask the browser to keep something longer and be less volatile - but it's not currently spec'd and thought of. With things like web-apps, they are offline-first. That is not to say we can't pick up from where we are on the web. Service workers are a good way to process requests. Late last year I demo'd a link with an infoset reading order pulled from TOC - then pipes all 16:25:36 that through some iframes. the service worker watches those iframes and then keeps those items in a cache. Additionally, it has a manifest if you load in a phone that will signal you can install this thing - it will put an icon on your home screen and you can read offline. It uses the infoset to then read the items offline... 16:26:45 ack NickRuffilo 16:26:46 ...: It's saying the URLs, but it can still be worked with offline - but you're working with the cache - so you don't have strong persistence. Once we start looking at permanence, we are looking at versioning. So we need to signal that there are new copies... There are lots of issues to file. It can be done with current tech. 16:27:08 NickRuffilo: we need some use cases 16:27:15 ... for different types of publishers 16:27:32 ... when reading fiction/novel on the beach, while turning off wifi 16:27:38 ... is a different need for offline 16:27:47 ... you might want an update but you might not 16:28:05 ... in scholarly, a minor correction might be a major update 16:28:11 q+ 16:28:29 ... but downloading to a device might be out of scope 16:28:39 ... so the industry might want a different solution 16:28:47 ack Nick_Brown 16:29:34 q- 16:30:45 ack jasminemulliken 16:30:47 Nick Brown: i wanted to make a quick comment about versions, annotations, etc feeling big and scary. Some of our experience here. A significant portion of our reading system platform go towards supporting those things. The last few folks that have spoken have talked about descoping some of those aspects and focus on cache and persistence. That feels like the appropriate place to focus. It's 16:30:48 a nice primitive path to solve some of the complex packages. I have a hard time seeing how the complex ones could be solved simply and within spec. That seems like the right start - and it solves the cache and persistence issues. 16:31:35 +1 Hadrien - exactly right, and I wouldn't propose to standardize our solutions to those problems 16:31:40 Jasmine: Is there anything we can draw on what the web archiving group has been addressing? Is there something we can draw on? LIke a single work file we can draw on? 16:32:01 q+ 16:32:18 ack tzviya 16:34:17 ack dkaplan 16:34:23 tzviya: One thing garth and I talked about - is whether or not service workers are an option - if we're putting the opportunity on the author of a script - it should be optional - meaning that offlining, or other features could be optional. The reading system needs to support it, but we're saying that for those people who care about it - ok. If it's really important, put the script in, and great 16:34:23 it will work. The publisher/author need to determine if the users want to use it. Scholarly publishers incluse scripts for things like mathjax - but making it optional reduces the burden of what is required. 16:35:58 q+ to mention affording for offline vs. the actions to offline something 16:36:35 Deborah: As for web-archiving, tim is on the queue - Tim is probably best to answer. There are possible relations. I wanted to lean against the way Nick R framed the issue - that some things need or don't need offline. It doesn't gain us anything to say "there is a scholarly publishing model that is different." I can think there are casees where you might need annotations while sitting on the 16:36:35 beach. I do like the idea of saying it's an optional thing. So a publication doesn't need to be offlinable, but if we define what it means, then a publication CAN be offlinable, so it's a better way of defining it. It lets publishers/content creators to second guess what the users are doing with the content, but that is acceptable in this case. 16:36:37 ack timCole 16:38:29 q? 16:38:37 we can't truly offline anything for good with today's technology, the best we can do is cache things and intercept some network requests for a limited period of time 16:38:38 ack bigbluehat 16:38:38 bigbluehat, you wanted to mention affording for offline vs. the actions to offline something 16:38:40 Tim: I put myself on the queue to talk about the importance of taking control of the timing of the cache. Publishers have the responsibility sometimes to make sure that content doesn't persist - like a library, where content could expire. So it could be useful to tell the UA how long the content should be around for. In terms of optional. In response to web archiving, the question always comes 16:38:40 when to take a snapshot - when does something change, and how do I mark the date and time of this change, and how many am I obligated to take. I'm not sure this group is going to solve those issues. but that's what they're working on. 16:40:39 Benjamin: I wanted to add one thing - the moby dick demo just expresses links to primary resources and covers the TOC. The script that should be considered a polyfill does the actual offlining. It takes the things afforded, and then adds the ability of offline it. There is nothing implicit in the state of the document that made it go offline or prevented it. It's just an HTML document - but 16:40:39 it was shaped in a way that was meant to be consistent, so that something else knowing intent could offline it. The script or the UA does the things required to offline, but the affordances were about linking to the required resources and having proper cache headers so that the service workers were allowed to do that. Affording for it was just the descriptive bits. 16:40:50 Tzviya: We need some technical meat and need to go beyond affordances. 16:41:01 ...: lets come away with some action items. Some need to work on use-cases. 16:41:32 ...: Anyone interested with some use-cases for offlining? 16:41:36 q+ 16:42:09 ack NickRuffilo 16:42:23 q+ 16:42:52 ack bigbluehat 16:42:59 ...: We need to build this out a bit more - and flesh out a bit more in what we're looking for - possibly make it optional. Tim talked about making it a timed expiration. 16:43:55 George has joined #pwg 16:44:29 present+ George 16:44:37 Benjamin: Related to the use-cases, alot that this affects. Versioning, annotation, and both of those relate to identification of the resource itself. The one thing that current caching/offlining gets us is that it's experiencable off the network without changing the identity. Nothing else has that at the moment. That lets you be away from the network while expericing the thing. This is 16:44:37 foundational - that the identity doesn't change. Such that all the things I do with the publication still have meaning when I transport them. Identity ties into all these concerns. 16:45:13 Tzviya: Can I ask Benjamin, Tim, and Nick Brown - who touched on some key points - can you work on a few github issues to capture some of what we've talked about in this meeting? 16:45:36 Tzviya: Lets move on to the infoset. Luc? 16:45:53 /join pwg 16:46:11 s/\/join pwg// 16:46:21 Phone line was cut off. 16:46:38 s/Phone line was cut off.// 16:46:59 topic: Infoset update 16:49:46 q+ 16:49:48 George back on phone 16:50:12 Luc: I think we - I need at least some more clarification about what is expected in our first public working draft. We had some discussions - long discussions - about what should we describe in the web publications - it should be very simple, the minimal that will allow people not coming from publishing/epub world to think about what could be a publication on the web. The pendulum went a bit 16:50:12 too far on "why not a single HTML page to be a publication." It seems to me that what we have in our first draft is a reflection of this movement towards a simple infoset to start with for people not coming from the epub world. Now I see a different move. We had these discussions in the interest group - and the 3.1 BFF (Browser friendly format) It looks like this info is coming again. In my 16:50:12 opinion, we should re-explain what we are expecting with this BFF. About the infoset, the other point of view - the extremeity of the pendulum - is what hadrien said in #176 where hadrien explained the GAP between what we have in epub and the needs. My question is, do you imagine - for web publication - do we need to have a description of all of what is in epub? Not in terms of implementation 16:50:12 but in terms of items. That is not clear to me. Reading the infoset as it is now, some items need to be more detailed, but I don't think we have to describe implementation. I thought until now that the spec we have to now cover everything we need for a first implementation. I'm not sure it's the good way to do it. 16:50:45 ... Do we need to have much more things - all or almost all of what we'll have in epub 4. Obviously it will be with MAY - for pwp and epub 4 then MAY will then becomes a should or possibly a MUST... 16:51:41 q+ 16:51:42 Tzviya: Is the question whether the infoset - which is rather minimal - is sufficient or if we need to incorporate all the details that came from the gap analysis between epub? 16:51:45 Luc: yes 16:51:46 ack bigbluehat 16:52:45 have to leave early. Sorry. 16:52:52 Benjamin: The things that I want to focus on are that the infoset affords things that we need. I would be concerned if we just inhereted epub 3.1 - for all the reasons it was trying to afford things - which may be some of our issues, but we have a web spec which has different concerns. I would want to really be careful that things were over there, so we'll move them over here. 16:53:06 ack tzviya 16:53:50 q+ 16:53:59 Tzviya: I think it's worth going through the functionality items that epub provided and see if that's available here. For example, the epub infoset includes a "link" element. The link item was there to afford external metadata - but that's available in PWP, just in a different way. 16:54:28 Luc: The gap analysis goes much further. I agree, we should not copy/paste, but we should redefine in web-language and technologies all the things that are in 3.1 that should be in 4.0 16:54:48 ack Hadrien 16:54:56 tzviya: I think that Hadrien's list is important to look at. Like what Benjamin said, we need to find ways to dupe the functionality, not the technology. 16:55:53 Hadrien: we had to start somewhere - i haven't looked at the satellite specs, just the core. We need to think carefully where each of the infoset items belong. They might not be important in epub 3 but might be in 4. The example used - link - it's not limited to extneral metadata, and we don't yet have a replacement for it's functionality. 16:56:08 Tzviya: OK, so we need to take a look at each item, think about it's functionality, and make sure it is covered. 16:56:09 s/extneral/external/ 16:56:47 Luc: Starting with hadrien's list, we should create an action item out of each. Would it come to WP and how it would be expressed in web technologies. In any case we need to understand how to rethink for an open web platform. 16:56:53 Tzviya: Anyone willing to volunteer? 16:57:25 Luc: For the infoset as it is now - for the minimal web publication - yes it is stable. 16:57:42 Tzviya: What I will do is take the issue hadrien raised and break it out into further issues and look into where it belongs going forward. 16:57:54 Luc: We should have an item on BFF - so it would be completely clear for everyone. 16:57:58 Tzviya: Exactly what do you mean? 16:58:11 Luc: Myself at least - I am not very comfortable with what BFF 16:58:34 Tzviya: BFF is something we did in the past - and it's used as reference, but we are not going to use it going forward. We have WP. 16:58:39 q+ 16:58:46 ack Hadrien 16:59:41 Hadrien: One thing - BFF isn't entirely in the past. The work done continues with Readium 2 and the web publication manifest. We did the work to transform infoset items. We make sure that it's round-tripable between epub and the readium manifest. It works well so far - when Luc mentions looking at BFF - i think he means looking at the work that was done. 16:59:46 Tzviya: Interesting, thank you. 17:00:14 ...: I will follow up with those who volunteered. 17:00:24 ...: Affordances task force later today 17:00:41 dkaplan3 has left #pwg 17:00:55 present+ 17:01:31 rrsagent, make logs public 17:01:36 rrsagent, make minutes 17:01:36 I have made the request to generate https://www.w3.org/2018/04/23-pwg-minutes.html tzviya 17:02:15 evan has left #pwg 17:06:24 Karen has joined #pwg 17:10:37 laurentlemeur has left #pwg 17:12:41 cmaden2 has left #pwg 17:13:16 bigbluehat has joined #pwg 19:05:36 Zakim has left #pwg 19:18:37 rrsagent, bye 19:18:37 I see no action items