06:38:02 RRSAgent has joined #pwg 06:38:02 logging to https://www.w3.org/2018/10/22-pwg-irc 06:38:07 Zakim has joined #pwg 06:38:10 present+ 06:38:13 rrsagent, set log public 06:38:17 agenda: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit 06:38:35 Meeting: Publishing F2F, 1st day 06:38:41 date: 2018-10=22 06:38:52 ivan has changed the topic to: agenda 2018-10-22: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit 06:39:06 chairs: Tzviya, Wendy, Garth 06:39:48 present+ 06:39:53 present+ 06:41:57 tzviya has joined #pwg 06:42:18 George has joined #pwg 06:42:50 present+ George 06:42:56 duga has joined #pwg 06:42:58 Avneesh has joined #pwg 06:43:32 present+ 06:43:32 present+ 06:43:38 marisa has joined #pwg 06:43:41 toshiakikoike has joined #pwg 06:43:42 Hadrien has joined #pwg 06:43:42 JunGamo has joined #pwg 06:43:46 present+ 06:43:47 present+ 06:43:50 clapierre has joined #pwg 06:43:50 present+ 06:43:51 laudrain has joined #pwg 06:43:52 gpellegrino has joined #pwg 06:43:53 present+ 06:43:56 garth has joined #pwg 06:43:56 present+ 06:43:57 present+ 06:43:59 laurentlemeur has joined #pwg 06:44:03 present+ bigbluehat 06:44:05 present+ 06:44:08 present+ Garth 06:44:09 present+ 06:44:24 scribenick: bigbluehat 06:44:27 present+ 06:44:50 Topic: Introductions 06:44:58 leonardr has joined #pwg 06:45:04 present+ Leonard 06:45:12 Cristina has joined #pwg 06:45:24 present+ Rachel 06:45:35 present+ marisa 06:45:57 +cristina 06:46:01 ...lots of wonderful people greet each other with their name and titles. 06:46:11 present+ Cristina 06:46:45 present+ DanielWeck 06:47:27 zakim, who is here? 06:47:27 Present: wendyreid, romain, ivan, George, duga, tzviya, marisa, Hadrien, Rachel, toshiakikoike, clapierre, laudrain, bigbluehat, gpellegrino, Garth, laurentlemeur, Avneesh, 06:47:31 ... Leonard, cristina, DanielWeck 06:47:31 On IRC I see Cristina, leonardr, laurentlemeur, garth, laudrain, clapierre, JunGamo, Hadrien, toshiakikoike, marisa, Avneesh, duga, George, tzviya, Zakim, RRSAgent, Karen, romain, 06:47:31 ... ivan, josh, Rachel, wendyreid, rachel_, github-bot, plinss, astearns, bigbluehat, jyasskin, dmitry 06:47:45 gkellogg has joined #pwg 06:48:30 Bobbytung has joined #pwg 06:49:04 present+: dauwhe 06:49:07 Ralph has joined #pwg 06:49:09 present: liisa 06:49:10 gpellegrino has joined #pwg 06:49:24 present+ liisa 06:49:25 tzviya: anyone on the phone who would like to introduce themselves? 06:49:36 present+ 06:49:40 present+ Gregg_Kellogg 06:49:43 ivan: please everyone around the table please present+ yourself in IRC 06:49:58 tzviya: if you're not familiar with IRC, please let us know 06:50:00 present+ bobbytung 06:50:01 present+ Ralph_Swick 06:50:04 Topic: Dinner 06:50:21 https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit?usp=sharing 06:50:27 tzviya: please RSVP for dinner on the Google Doc 06:50:41 ivan: also please add your appetizer and desert choice before noon today 06:51:12 DanielWeck has joined #pwg 06:51:12 Topic: Now Let's Talk About Publishing 06:51:16 present+ 06:51:40 JuanCorona has joined #pwg 06:51:47 present+ 06:52:03 tzviya: I'll start with an overview to hopefully catch everyone up 06:52:06 s/present: liisa/present+ liisa/ 06:52:09 ...here's our current position 06:52:25 ...the content in a Web Publication is anything the Web can have: SVG, images, audio, HTML, etc. 06:52:39 ...the big questions still pivot around the manifest and the content and how those interact 06:52:52 ...we still talk about the abstract concept of the infoset 06:53:02 ...and we also continue to explore metadata 06:53:10 ...as well as the exact structure 06:53:21 ...especially with regard to internationallization 06:53:30 ...there is a lot of interplay between the pieces 06:53:39 ...and we often get hung up on some of these questions 06:53:44 ...the details of which are rather important 06:54:04 ...but we need to be careful not to debate these at too much length, as we have more to accomplish 06:54:33 ...so. what we have right now is: 06:54:37 ...the content - html, css, etc. 06:54:46 ...the abstract infoset 06:54:47 ...the manifest 06:54:50 ...the webidl 06:54:55 ...and the JSON-LD context 06:54:58 q? 06:55:02 ...and we'll be discussing how those all interact 06:55:09 Karen has joined #pwg 06:55:14 ...if there's anyone who's new to this, please ask questions! 06:55:29 ...k. I think we'll move on to the next agenda item 06:55:51 ivan: um. I think the whole infoset debate/question should be discussed 06:55:53 gpellegrino1 has joined #pwg 06:56:02 ...when we started the work, the abstraction was valuable 06:56:11 liisamk_ has joined #pwg 06:56:18 ...if I were comparing it to something else, it would be numbers or numerals 06:56:40 ...numbers are the abstract concept, and numerals are the real tangibles...hexidecimal, etc. 06:56:47 q? 06:56:56 ...because I'm a mathematician this abstraction helps me a lot 06:57:13 ...and currently the whole document is written around this construction 06:57:16 q+ 06:57:28 ...but we need to determine if it would be better to focus on the just the manifest 06:57:42 q+ 06:57:43 q+ 06:57:46 ...which we did consider may happen when we introduced the manifest concept 06:57:48 ack garth 06:57:59 garth: I would have said the info set is really the content of the manifest 06:58:05 q+ 06:58:07 +1 to removing the infoset 06:58:10 ...I don't really see them as separate 06:58:29 ivan: so let's not forget that your statement is not quite correct 06:58:37 ...the manifest may be incomplete by itself 06:58:45 ...and it will need to take information from the surrounding HTML itself 06:58:55 ...so it's much clearer to think about the infoset 06:59:02 ...which may be filled from many different sources 06:59:05 ack romain 06:59:13 ...the infoset then is important 06:59:21 romain: I feel it's mostly a communication issue 06:59:24 q? 06:59:28 q+ 06:59:30 q+ 06:59:33 ...and fear we'll drive people way with the "abstract infoset" language 06:59:55 ...for instance, if we talk about "publication title" it seems obvious this is the abstract concept, and not the specific serialization 06:59:57 q? 07:00:00 +1 to what Romain said 07:00:01 ack Avneesh 07:00:04 +1 07:00:06 ...so I'm not sure continuing to distinguish this is helpful 07:00:08 ack Avneesh 07:00:08 +1 to romain 07:00:30 Avneesh: is there a possibility that the infoset at the abstract level includes beyond the manifest? 07:00:39 q? 07:00:41 ...so I guess we may need to have both of them 07:00:42 ack Rachel 07:00:45 ack Rachel 07:01:00 Rachel: what is the problem that the infoset was attempting to solve in the first place? 07:01:16 q+ 07:01:25 ivan: I think at the moment, when we began to discuss this things went all over the place 07:01:37 q+ 07:01:40 ...what are the things we need, and then we very quickly went into how we expressed them in JSON 07:02:01 ...so we introduced the infoset terminology, to avoid always pushing things into JSON 07:02:18 q 07:02:21 q+ 07:02:22 q? 07:02:33 ...so we were then focused on what the things we needed abstractly without demanding we determine the format/expression 07:02:46 ...do we still need that now? does it help the reader? that's really the question for today 07:03:04 Rachel: I'm still struggling to understand what the infoset is actually solving for us 07:03:18 tzviya: we built up this list of metadata and called it the "infoset" for abstraction purposes 07:03:24 q+ 07:03:35 ...then when we got to the JSON-LD discussion, we started adding MUSTs and SHOULDs 07:03:59 ...but we still have the infoset, because things like `title` may be expressed in either HTML or JSON-LD 07:04:08 ...and therefore the abstraction may be helpful 07:04:30 q? 07:04:32 Rachel: the problem, then that we have is that we need to determine the location of this information 07:04:38 ack duga 07:04:39 ack duga 07:04:47 tzviya: so one idea is to focus on the origins of the metadata rather than their abstractions 07:05:08 duga: I'm trying to think of specs that do something like this, and CSS 2.1's box model spec takes this approach 07:05:22 https://www.w3.org/TR/CSS2/box.html 07:05:25 ...there are abstract ideas explained, and then details of their expressions 07:05:34 ...I'm not sure, though, that our spec is that complex 07:05:42 q? 07:05:52 ...however, it still might be useful to keep some expression of abstractions 07:06:05 ack leonardr 07:06:07 ack leonardr 07:06:07 ...but for things like title, I'm not sure it needs it's own abstraction as people understand those already 07:06:33 leonardr: I would agree with duga and think ivan's history that we defined the infoset before we serialized it is correct 07:06:41 ...and that the abstraction may no longer be necessary 07:06:52 q+ 07:06:53 ...and hopefully we can remove the abstraction 07:06:58 acl laudrain 07:07:02 ack laudrain 07:07:02 ...and fill in the missing pieces that it dealt with 07:07:13 s/acl laudrain// 07:07:17 laudrain: so in our intro we say that a Web Publication is "pure Web" 07:07:35 ...so the abstractions begin to explain perhaps how a Web Publication differs from a Web Site or a Web App 07:07:36 q? 07:08:02 ...it could be very technical and expressed in something like JSON-LD 07:08:05 ack gkellogg 07:08:13 ...but we really should explain how Web Publications differ 07:08:23 glazou has joined #pwg 07:08:24 present+ gkellogg 07:08:26 gkellogg: we ran into this on the JSON-LD specifications 07:08:58 dauwhe has joined #pwg 07:09:05 ack laurentlemeur 07:09:16 ...we currently discuss things in strings, arrays, and dictionaries 07:09:31 ...abstract enough that it can be implemented in something like YAML, but concrete enough for it's focus on JSON 07:09:46 q+ to explain that duplication is the problem 07:10:02 laurentlemeur: perhaps we could remove the abstract infoset, and instead focus on the WebIDL or some other expression of the properties 07:10:02 +1 Laurent. Infoset is not so well understood 07:10:15 florian has joined #pwg 07:10:19 ...also the infoset is scattered throughout the document, and perhaps moving it back together into one place could be helpful 07:10:32 q+ 07:10:34 ack Hadrien 07:10:53 ...the options for placing the title, are encoding expressions 07:11:03 Hadrien: we are working with something conceptual 07:11:05 +1 07:11:10 ...but I do think the infoset term is confusing 07:11:22 ...but this concept of a Web Publication is what we're selling to the world 07:11:43 q? 07:11:43 ack Rachel 07:11:46 ...perhaps one of the issues is that keeping things at the abstract, is that we don't divide well between what actually ends up in the manifest and what doesn't 07:11:46 +1 07:11:50 ack tzviya 07:11:52 tzviya, you wanted to explain that duplication is the problem 07:11:53 +1 07:12:09 tzviya: one concern we've had in the past is duplication 07:12:45 ...the requirements on the abstract infoset can be confusing 07:12:48 q- 07:12:55 ...and using properties of a publication might be more clarifying 07:13:06 ivan: k. I don't think we should go on with this discussion to much longer 07:13:20 ...I propose that Matt, I, and perhaps the chairs look through the document 07:13:27 ...and take these comments into account 07:13:38 ...and essentially remove the term...which I realize may frighten some here 07:13:56 ...but I don't think having telcos on this longer makes sense 07:14:00 q? 07:14:13 ...so we will work up a pull request to address this 07:14:14 ack ivan 07:14:36 PROPOSED: edit the infoset and properties section, and introduce a PR to the group 07:15:12 Avneesh: should we express that this is a non-operative section? 07:15:15 clapierre has joined #pwg 07:15:21 tzviya: I think that is part of the intent, but as yet it's not that concrete 07:15:28 +1 07:15:40 ivan: we hope to have continued discussion around the specific text once it's sent as a pull request 07:15:50 RESOLVED: edit the infoset and properties section, and introduce a PR to the group 07:16:01 q? 07:16:24 topic: use case, affordances 07:16:47 tzviya: since we have 10 extra minutes, does anyone have other questions around the interactions of the different pieces, manifest, infoset, webidl, etc? 07:17:13 George: are web browsers today looking for this manifest? 07:17:28 q? 07:17:33 +1 07:17:38 ivan: no. and it remains to be seen if/when that will happen 07:17:46 George: so that is why we begin with an HTML document? 07:17:47 ReinaldoFerraz has joined #pwg 07:17:48 tzviya: correct. 07:18:07 laudrain: so, these are at this point very similar to Web Apps. 07:18:27 ...but that will be hard for publishers to make something like that consistently and as a standard 07:18:41 tzviya: I believe this is issue #271...and we've discussed this frequently 07:18:54 ...what does it mean to be "WP-aware"? 07:19:10 ...I don't want to derail things, but we have yet to define what it means to open a WP 07:19:19 -> https://github.com/w3c/wpub/issues/271 #271 : WP rendering in non WP aware browsers 07:19:37 https://w3c.github.io/dpub-pwp-ucr/ 07:19:40 ...Franco has done an amazing amount of work on the use cases and requirements document 07:20:03 tzviya: hi Josh! 07:20:12 ...are you on IRC? 07:20:20 josh: yes! 07:20:33 ...the changes I've made were checked in on Friday 07:20:39 present+ josh 07:20:41 ...and I've noticed some have been merged 07:20:48 dauwhe has joined #pwg 07:20:51 https://w3c.github.io/dpub-pwp-ucr/ 07:20:57 ...they're good. Franco did some great work identifying areas that weren't covered 07:21:07 q? 07:21:10 q+ 07:21:11 ...so the status feels like it has what it needs and just needs some editing and then publishing 07:21:29 present+ ReinaldoFerraz 07:21:35 ...there may, however, need to be some trimming of requirements that I've not understood when I started editing the document 07:21:36 ack leonardr 07:21:44 leonardr: can you give us any sort of general overview about the changes? 07:21:44 q+ 07:22:04 ...were these clean up changes? new use cases? can you generalize these into a summary for us? 07:22:17 josh: sure. there were no new use cases. 07:22:41 ...Franco has submitted some that tzviya and I have yet to review 07:22:48 ...it was about a two year old document 07:22:59 ...so it's been tidied up a bit, and in the last 48 hours there's some new content 07:23:05 q+ 07:23:09 ...but we've also done some general clean up 07:23:21 ...however, i think this group has bigger fish to fry than more use cases 07:23:37 ...I don't know how in depth tzviya wants to go 07:23:50 ...there's one huge one, what does the UA want to do? 07:23:54 ...and that one could take a while 07:24:04 ...for most of these, we'd all agree easily with about 90% of these 07:24:24 ...but 10% of the ones related to user experience--layout, user movement through the document, etc 07:24:38 ...they sound simple, but they have frequently been hard to discuss 07:24:46 q+ 07:24:51 ...I don't know how much of these are practical for the first version 07:24:53 ack tzviya 07:25:06 tzviya: so, since I merged many of Franco's PRs, I can give a brief overview 07:25:16 ...he did add more use cases based on what's gone into the spec 07:25:33 ...he also added comments, so you'll see comments like "I did not see these fields, help wanted" 07:25:45 ...this is where the request of the working group to review/contribute 07:26:05 ...the intent was to make the URC document match the WPUB document's current reality 07:26:26 ...when heather was the editor, she'd started a pattern of adding requirements at the end of the document 07:26:40 ...Franco's continued that with the intent of making UCR and WPUB match 07:26:44 s/URC/UCR 07:27:05 q+ 07:27:07 ...we have a WebIDL and we have metadata, but what does that mean if I open the web publication? 07:27:14 ...we keep getting hung up here 07:27:27 ...and if I want to understand that with the UCR, I open section 2.2.1 07:27:41 JunGamo_ has joined #pwg 07:27:43 ...and it explains more about what could be done with that metadata 07:27:54 ack ivan 07:28:04 ...so, today, we can talk about what can be done 07:28:17 ivan: the most important thing is to link the UCR with WPUB...from both sides 07:28:23 ...right now, we have the "affordances" section 07:28:29 ...and also with the specific metadata 07:28:38 Vlad_ has joined #pwg 07:28:38 ...and those refer to their use cases 07:28:44 ...and for many it's obvious, but for some it's not 07:28:57 present+ 07:29:01 ...we also want to do the same from the UCR document 07:29:07 (irc only for now) 07:29:20 ...we can or can not do the use case described with what's expressed in WPUB with links back to how to make that happen in reality 07:29:27 s/(irc only for now)// 07:29:31 q? 07:29:58 q? 07:30:02 ack Hadrien 07:30:09 Hadrien: the document is very useful, but I'm concerned that whenever we talk about a UCR or when we talk about what a non-WP does or does not 07:30:26 ...we still don't determine what the minimum of what a WP-aware reader must do 07:30:47 ...there are some things that are not minimum, like offlining, that we talk about as if they were 07:30:48 q+ to talk about focal use cases 07:30:58 q+ 07:30:59 ack leonardr 07:31:01 ...and I fear that by trying to solve them all at once we solve none of them 07:31:09 leonardr: I think that what I'm hearing is two different things 07:31:26 ...I completely agree with the desire to map WPUB requirements to the UCR document 07:31:44 ...what I have a problem with is using the UCR document to put requirements on UAs 07:32:01 q? 07:32:01 ...in PDF specs for example, we talk about format requirements vs. process requirements 07:32:17 ...we have format requirements in WPUB, but we lack process requirements 07:32:27 wolfgang has joined #pwg 07:32:32 ...that seems like a very normative core to our spec which we should add 07:32:52 ...we're describing not only what they're expressing, but what they expect to have happen when they do it 07:33:02 +1 Leonard 07:33:07 present+ wolfgang 07:33:11 ...the UCR, however, is not normative, and has no "Thou Shalt Do X" in it 07:33:19 yanni has joined #pwg 07:33:37 tzviya: typically, it depends on the spec, but usually that sort of thing does't appear in W3C specifications 07:33:51 ...I'd spoken with Josh about creating three or so "focal" use cases 07:33:56 ...one might be offlining 07:34:04 ...it's a lot complicated 07:34:12 ...but it seems essential 07:34:31 ...so we write some focal use cases around that and other core requirements 07:34:33 ack garth 07:34:41 ack tzviya 07:34:41 tzviya, you wanted to talk about focal use cases 07:34:43 ack George 07:34:48 garth: how do you see the UCR? is it just augmenting the WPUB spec? 07:34:52 tzviya: yes. I agree with that 07:35:12 George: I agree with garth and Hadrien. That we should reference and describe the things in our UCR document 07:35:18 ...and point to them from the WPUB spec 07:35:29 q+ 07:35:36 ...but we shouldn't go from the UCR document and then figure out how to modify the WPUB spec to match 07:35:36 ack ivan 07:35:46 ...we should focus on implementable WPUB 07:35:56 ivan: I'm in agreement with a minimum viable approach to WPUB 07:36:10 ...but the hard part if determining what is normative and what is non-normative 07:36:33 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html Ralph 07:36:37 ...if we put it as normative, then we MUST have (per W3C process) several implementations for everyone one of those MUSTs 07:36:44 ...if it's informative, then we can just leave it there 07:37:07 q? 07:37:21 ...so, for this MVP approach, those things should be normative, but we should be careful here 07:37:29 q? 07:37:29 ...because we have to test and verify all these things 07:37:34 present+ Karen_Myers 07:37:39 q+ 07:37:39 ...so if it goes into WPUB as normative, we should be very careful 07:37:59 tzviya: so, coming back to the UCR, what things should we add to this MVP for WPUB? 07:38:08 garth: all MUSTs but some SHOULDs? 07:38:19 ack josh 07:38:20 tzviya: do we even have that language in the UCR? 07:38:32 garth: yeah, we do have that in the UCR currently 07:38:37 josh: I love the MVP idea 07:39:06 ...I've been going through the UCR document for weeks 07:39:32 ...for instance, showing the TOC while you're anywhere within the document 07:39:52 present+ Leonard_Rosenthol 07:39:55 The TOC must be omnipresent 07:39:58 q+ 07:40:27 q- 07:40:28 q? 07:40:53 q+ 07:41:08 q+ 07:41:25 PROPOSE: the table of contents must be accessible from anywhere in the publication 07:41:56 scribenick: duga 07:41:56 present+ Cristina_Mussinelli 07:42:07 +1 to bigbluehat on TOC 07:42:20 bigbluehat: All for clarifying stuff, but really need a testing champion 07:42:28 tzviya: We have one! Chris 07:42:37 bigbluehat: Need another 07:42:57 ... Need to figure out how to make this omnipresence testable 07:43:08 ack ivan 07:43:13 ack bigbluehat 07:43:19 scribenick: bigbluehat 07:43:42 q? 07:43:43 ivan: we've discussed the toc issue several times 07:43:45 q+ 07:43:51 ...there are many more of these though 07:43:56 q+ 07:43:58 ...like search should be across all the things in the publication 07:44:07 q+ 07:44:08 ...and figure numbering, etc, should be across all the things in the publication 07:44:33 ack Hadrien 07:44:35 laudrain_ has joined #pwg 07:44:36 ...these seem like sensible and unique-to-publications features and capabilities 07:44:43 Hadrien: I don't think these are MVP 07:44:52 ...frankly, I only see two things as MVP 07:44:58 q? 07:45:00 ...going through the reading order, and accessing the ToC 07:45:01 ack leonardr 07:45:02 ack leonardr 07:45:05 q? 07:45:10 leonardr: I was going the same place as Hadrien. 07:45:18 ...what ivan listed require many more discussions 07:45:28 ...and I'd not consider them MVP 07:45:29 q+ 07:45:43 ack garth 07:46:05 garth: I'm very hesitant to put requirements on UAs. 07:46:32 ...things like search, etc, seem likely to be added by UAs, but not likely to be an MVP 07:46:51 ivan: searching across multiple documents is something unique to publications 07:46:56 q+ 07:47:09 q+ 07:47:24 garth: I'm generally agreeing. The top two (toc access and directional progression through the document) do state an MVP 07:47:43 ...but then what can happen in non-WP aware UAs is also a consideration 07:47:53 ...well, the actual one is understanding the manifest 07:48:15 q? 07:48:16 ...so, perhaps this is a great discussion for us to determine these things and build up from there 07:48:24 q+ 07:48:25 ack laurentlemeur 07:48:32 ack laurentlemeur 07:48:32 q- 07:48:37 tzviya: josh perhaps you can think through what's MVP and what's WP-aware and add these things to the UCR 07:48:46 q+ 07:48:54 laurentlemeur: so, we can do some of these things by going back and forward in a current browser 07:49:08 q+ 07:49:13 ...or is this a directional progression from point a to point b to point c without back and forth? 07:49:29 q? 07:49:30 ack Avneesh 07:49:39 garth: I'd say directional from resource to resource without back and forth 07:50:09 Avneesh: this sounds like determining the bounds of a publication 07:50:14 ack laudrain_ 07:50:17 q? 07:50:22 laudrain_: about WP-aware UAs 07:50:35 ...is it possible to speak about a UA that understands at least JS and CSS? 07:50:41 ...what kind of engine are we speaking about? 07:50:48 ...what must it support? 07:50:56 ...what if it can't do CSS or JavaScript? 07:51:01 q+ 07:51:04 ...what does it mean in that moment? 07:51:19 q- 07:51:23 ...I would like to propose that we're talking about UAs that can do JavaScript and CSS as a minimum 07:51:29 ack Avneesh 07:51:42 Avneesh: as far as I understand, WP-aware vs. non-WP-aware, the keyword is "WP" 07:51:46 ...not JavaScript support, etc. 07:51:59 ...there should be points where we say "this is a WP aware UA feature" 07:52:11 ...the JavaScript and CSS are not part of those requirements 07:52:53 laudrain_: but that is my point by not determining whether we have these things or not, we do not have a foundation to build upon 07:53:01 q? 07:53:13 q+ to say that we can't redefine UA for W3C 07:53:27 ...I feel like we speak about engines that are too small and lack features, such that we can't build a WP experience in a non-WP-aware browser 07:53:59 q? 07:54:03 q+ 07:54:07 RickJ asked me to forward his greetings to everyone around 07:54:07 [I suggest that we can describe what it means to be "WP Aware"; what it means to conform to the WP specification but it is not practical to say what a non-"WP Aware" agent does with a WP. We can design WP such that non-aware clients are more likely than not to do something helpful.] 07:54:12 ack Hadrien 07:54:26 Avneesh: just one note to say that if JavaScript is provided via a non-WP-aware but uses JavaScript to create a WP like experience, than that non-WP-aware UA becomes WP-aware 07:54:56 ack tzviya 07:54:56 tzviya, you wanted to say that we can't redefine UA for W3C 07:54:57 Hadrien: this is back to the discussion earlier, but I think going back and forth to a ToC is not an MVP feature 07:55:19 tzviya: I think we need to be careful with defining User Agent 07:55:27 ...we can define WP-aware 07:55:32 ack garth 07:55:35 ...but we need to be careful to determine the meaning of UA 07:55:59 garth: I keep thinking Reading System, and I'm not sure if that's a UA. I think it is, but it has been confusing 07:56:04 q+ 07:56:24 ...I think what laudrain_ and Avneesh are saying is that if you can build the reading experience and distribute that with your publication than you get a WP-aware UA with your publication 07:56:53 ...and in as much as WP's are distributed on the open web platform, then a WP can be distributed with such a built-in WP-aware UA 07:56:53 q? 07:56:58 ack George 07:57:03 q? 07:57:04 ...the publication itself causes the WP to be WP-aware 07:57:16 :) 07:57:30 George: Hadrien I like to be able to move through the document without going back and forth 07:57:55 ...but I also want to be able to collapse a collection of 1000+ documents, and get to just part of that 07:58:00 Hadrien: yes. I want that too. 07:58:04 s/Hal/Dave/ 07:58:07 George: then we're in agreement. great :) 07:58:20 sidenote: in HTML, "user agent" are defined as a conformance class (in 2.1.8: https://html.spec.whatwg.org/#conformance-classes) 07:58:34 tzviya: let's come back to the MVP for WP-aware 07:58:42 q? 07:58:59 Hadrien: there's no concept of this now 07:59:06 ...if you build something like this now, it would be a Web App 07:59:12 q+ 07:59:19 ...and those lack an understanding of scope 07:59:40 ...especially with search...so I think that should not be an MVP 07:59:52 ...also offline-ability is hard to achieve consistently 08:00:08 ...things like comics, etc, don't have space available usually 08:00:19 ack leonardr 08:00:24 q+ 08:00:25 ...and are therefore not good MVPs 08:00:41 q+ 08:00:46 leonardr: and this brings us back to the discussion of boundedness 08:00:48 Perhaps: MVP == (get to TOC | move through reading order); MGP == search within bounds of WP 08:00:56 ...do we list all resources? do we list just some resources? 08:01:08 ...do we allow them all to be searched? offlined? etc. 08:01:27 q? 08:01:38 ack ivan 08:01:45 ...then we'll need to determine per resource what's possible for search, offline, etc. per resource 08:01:53 ivan: so we have some MVP thoughts 08:02:00 q+ 08:02:03 ...but if we stop there, then we have this minimal thing 08:02:12 ...and a huge blob of features in the UCR 08:02:20 ...and then UA developers pick just what she wants 08:02:24 q+ 08:02:39 ...and then there are some of these affordances, however hard they may be, should be considered fundamental to a publication 08:02:54 ...it perhaps is a difference between MUSTs and SHOULDs, but they should still be expressed 08:03:03 q? 08:03:17 q- 08:03:19 ack wendyreid 08:03:38 wendyreid: the product creation folks understand this 08:03:42 ...and ivan is reading my mind 08:03:50 ...what we probably have to do is create tiers 08:03:50 q+ 08:03:54 ...MVP comes from product design 08:04:05 ...one of the core product design concepts is iterative improvement 08:04:06 q? 08:04:21 ack duga 08:04:22 q+ 08:04:23 ...and we could benefit here from a list of iterative improvements up from an MVP 08:04:37 duga: so I have an unhelpful comment, but I'm also going to be generally agreeable 08:05:01 ...I don't think search is an MVP because it'd be possible to ship something that can be searched, but without expectation that it will be searched 08:05:12 q+ 08:05:26 ...if a large group says, it's hard to implement and hard to create then is it an MVP feature? 08:05:26 ack marisa 08:05:44 marisa: can someone remind me what MVP means in relation to our stack? 08:05:48 q+ 08:06:05 ...when I think of our spec, then I could see many browsers to do most of these 08:06:10 ...what does it give our spec to define mvp? 08:06:40 garth: I'd think of them as just the MUSTs 08:07:12 ...and I'll agree with duga 08:07:22 ...searching across the bounds of the publication is probably not a MUST 08:07:24 q? 08:07:34 ack George 08:07:35 marisa: I don't think we have to split so many hairs here 08:07:44 q+ 08:08:05 q+ 08:08:08 George: the minimum viable reading experience is probably something beyond what we've discussed so far as MVP 08:08:10 +1 08:08:11 q? 08:08:12 ack Hadrien 08:08:16 Ariel has joined #pwg 08:08:25 ...and I'm concerned that if we only spec an MVP, that it won't result in a good reading experience 08:08:37 Hadrien: we should focus on MUSTs, SHOULDs, and MAYs 08:08:51 ...there's been a lot of discussion of search and offline 08:08:52 q+ 08:08:58 ...I think those are intertwined 08:09:07 ...once they're offline you could index them 08:09:21 ack bigbluehat 08:09:26 scribenick: duga 08:09:40 bigbluehat: The web is trending offline 08:09:55 ... service workers, new stuff 08:10:18 ... New indexing stuff is coming for searching large documents 08:10:27 q? 08:10:29 ack romain 08:10:32 ... Currently be explored in other groups, let's talk to them 08:10:34 scribenick: bigbluehat 08:10:46 romain: I had a quick look for UAs in the HTML spec 08:10:51 ...and they use conformance classes 08:10:59 ...interactive browsers do one set of things 08:11:06 ...non-interactive ones get a slightly different list 08:11:13 ...things like validators, etc. 08:11:14 q+ 08:11:17 q- 08:11:20 https://html.spec.whatwg.org/#conformance-classes 08:11:31 q+ 08:11:32 ack Avneesh 08:11:41 ...we could build up from these 08:12:07 ack liisamk_ 08:12:17 Avneesh: I believe everyone generally agrees, but perhaps MVP is a confusing term 08:12:29 ...and in fact we're looking for the core affordances that should be provided 08:12:31 tzviya: I agree 08:12:35 q? 08:12:48 liisamk_: I don't think search is MVP, and I don't think changing font size is necessarily MVP 08:12:56 ack ivan 08:12:58 ...but I do think internal and external linking experience is MVP 08:13:27 +1 to Romain, to also consider html classification 08:13:31 ivan: I was happy to hear what bigbluehat was saying. We should use the MUST, SHOULD, and MAY, etc. 08:13:52 ...if it's hard today, we should put it as a SHOULD 08:14:09 ...but we should have a clear idea of what is being built for the future 08:14:11 q+ 08:14:44 ack bigbluehat 08:14:45 q+ 08:14:48 scribenick: bigbluehat 08:14:59 q+ to propose a way forward 08:15:06 [more tests are always better; even SHOULD and MAY] 08:15:09 bigbluehat: You do have to write tests for SHIOULD but don't need to pass them (maybe?) 08:15:33 ... There is an assumption we are on a desktop browser given our title with "Web" 08:15:49 ... Can we assume this for conformance tests? 08:15:50 s/SHIOULD/SHOULD/ 08:16:32 q+ 08:16:42 ... If we don't assume a proper browser, we end up in a bad place 08:16:45 scribenick: bigbluehat 08:16:57 dauwhe has joined #pwg 08:17:16 present+ 08:17:20 q+ 08:17:41 George: is it possible for a WP aware browser, to not process JavaScript embedded affordances that it already provides 08:17:44 q+ 08:17:51 ivan: the answer is yes 08:18:03 ack liisamk_ 08:18:05 tzviya: we've got 13 minutes 08:18:09 ...just fyi 08:18:38 ack tzviya 08:18:38 tzviya, you wanted to propose a way forward 08:18:39 liisamk_: from a general mapping perspective, MVP is MUSTs, SHOULDs are next level up, and MAY is super awesome product 08:18:40 q? 08:19:04 s/the answer is yes/the answer is yes: that's what polyfills are designed to do 08:19:14 tzviya: so. I'm going to propose that josh and franco with the UCR and affordances, etc, go through the existing WPUB document 08:19:18 ...and go through the MUSTs 08:19:23 must = minimal, should = desirable, may = optimal 08:19:27 ...and next time we meet we look at the MVP/MUSTs 08:19:33 ...and start listing them in some section of the document 08:19:36 or may = sexy 08:19:42 ...and then we'll see if that's something we can live with 08:19:47 ...does that sound like a good plan? 08:19:54 q? 08:19:56 ack ivan 08:20:24 ivan: I would also welcome if someone else took on editorial jobs related to this minimal stuff 08:20:37 ...so that we have a text that might actually replace the current section we have on affordances, etc. 08:20:40 q? 08:20:54 ...matt will have quite a lot of work already to deal with our infoset choices 08:21:01 ...so I think it's unfair to expect matt to do this also 08:21:05 ...so help wanted! 08:21:27 ack gpellegrino 08:21:28 scribenick: duga 08:21:54 gpellegrino1: Reply to George: JS should check if browser is WP aware 08:22:00 ... like JQuery does 08:22:14 ... Allows polyfill of specific features 08:22:30 George: That means each affordance can be uniquely identified 08:22:47 q? 08:22:50 ack Hadrien 08:22:51 ... Ran into this with footnotes, with JS footnotes vs RS finding them 08:23:12 Hadrien: We have been talking about MVP, but in terms of JS don't want to test if WP aware 08:23:20 ... Instead want to test for features 08:23:39 q+ 08:23:50 ... Transition from non-WP aware to WP aware is also important 08:23:59 zakim, close the queue 08:23:59 ok, tzviya, the speaker queue is closed 08:24:05 ... We haven't discussed it but there is a UX issue 08:24:11 ack marisa 08:24:42 tzviya: Josh and Franco to find the MUSTs for MVP 08:24:52 ... in the future we will do the same with SHOULD 08:25:08 ... Need volunteers and an editor for Affordances section 08:25:29 garth: Wanting to define a minimal list of musts 08:25:40 ... currently we have 2 and third, is that enough? 08:25:43 tzviya: No 08:26:18 tzviya: Break! 08:26:35 zakim, open the queue 08:26:35 ok, tzviya, the speaker queue is open 08:28:02 marisa: Does WebIDL have a way to query if a specific affordance is available? 08:28:09 Ivan: No 08:29:26 GuillaumeSire has joined #pwg 08:29:43 present+ Guillaume_Sire(observer) 08:33:35 marisa has joined #pwg 08:34:23 marisa has joined #pwg 08:37:01 marisa has joined #pwg 08:40:22 glazou has joined #pwg 08:47:59 marisa has joined #pwg 08:51:52 Vlad has joined #pwg 08:52:58 toshiakikoike has joined #pwg 08:53:01 garth has joined #pwg 08:53:49 marisa has joined #pwg 09:01:46 leonardr has joined #pwg 09:08:22 romain has joined #pwg 09:08:43 GuillaumeSire has joined #pwg 09:09:45 Avneesh has joined #pwg 09:10:31 Karen has joined #pwg 09:10:44 scribenick: duga 09:11:04 tzviya: Reminder about dinner stuff 09:11:10 gpellegrino has joined #pwg 09:11:11 ReinaldoFerraz has joined #pwg 09:11:24 romain_ has joined #pwg 09:11:46 garth: Google covering dinner 09:11:59 marisa has joined #pwg 09:12:27 topic: Boundaries 09:12:35 Hadrien has joined #pwg 09:12:36 q+ 09:12:47 ack dauwhe 09:12:50 tzviya: Reading from the agenda 09:12:56 Bobbytung has joined #pwg 09:13:09 dauwhe: Need to put some effort into describing this in an operational way 09:13:09 https://github.com/w3c/wpub/issues/194#issuecomment-428662128 09:13:29 ... Say I am in a WP context and click a link to another WP? 09:13:34 q+ 09:13:36 ... what happens then? 09:13:44 ... How do we discard a manifest? 09:13:52 q+ 09:14:08 q+ 09:14:18 ... Easy to talk about boundaries are, but what do they mean? 09:14:21 ack leonardr 09:14:29 leonardr: The concept I agree with 09:14:52 liisamk has joined #pwg 09:14:56 ... Thinking about boundaries from UX perspective 09:15:03 marisa has joined #pwg 09:15:19 ... eg my goal is to search this publication - what is a WP to accomplish that 09:15:44 ack bigbluehat 09:15:47 ... Look at use cases as they relate to boundaries 09:16:07 bigbluehat: Dave mentioned UX. We talked about constraints on UAs 09:16:16 laurentlemeur has joined #pwg 09:16:23 q? 09:16:24 ... Biggest one we have to consider is what happens when you cross the boundary 09:16:28 present+ 09:16:52 ... There is some precedent in the web, eg web manifest 09:17:07 ... inverse is iFrames, you pull things into your scope 09:17:26 ... third is target:blank which insists you leave the publication 09:17:56 q+ to make sure we define rules and UX separately 09:18:06 ack Hadrien 09:18:09 ... Anything out of scope takes you to a browser context 09:18:37 Hadrien: Glad to hear this example, we had inter document linking discussions at epub 09:18:54 ... Nice to finally be able to link between pubs 09:19:12 ... Earlier we didn't have the right terminology to discuss the boundaries 09:19:23 ... No longer true. The scope is now expressed. 09:19:47 ... Agree we have established patterns for what happens 09:19:53 ... no need to reinvent the wheel 09:20:11 ... When you are no longer in the bounds of the pub, the affordances are no longer available 09:20:15 JunGamo has joined #pwg 09:20:24 tzviya: We seem to be agreeing 09:20:29 q? 09:20:38 ... Goal is to address issue 205 09:20:40 hober has joined #pwg 09:20:57 ... Maybe we are done with this? 09:21:14 q+ 09:21:31 ack tzviya 09:21:31 tzviya, you wanted to make sure we define rules and UX separately 09:21:33 ... maybe we just need to more specific about what happens and the UX for when we leave the pub 09:22:12 garth: Searching - maybe that is a should, clearly you need bounds for that 09:22:13 s/need to more/need to be more/ 09:22:23 q+ 09:22:23 ... Are we comfortable saying we are now done? 09:22:29 q+ 09:22:31 ack leonardr 09:22:36 q+ 09:22:48 leonardr: Concerned we are talking about 2 different things regarding bounds 09:22:54 q? 09:23:02 ... 1 is what the UA understands are the bounds (eg for search) 09:23:10 ... Seems clear why we need that 09:23:27 ... Issues around exiting and entering is a completely different issue 09:23:36 Karen has joined #pwg 09:23:40 ... Nothing to do with the actual bounds 09:23:50 ... Just a UX issue, which is still important 09:23:56 q? 09:23:57 q? 09:23:57 ack romain 09:23:58 ... Look at both, but do not combine 09:24:01 q? 09:24:11 q- 09:24:24 romain: Security issues - what happens when you move between origins 09:24:34 ... Origin historically undefined in epub world 09:24:46 ... Pubs can share local storage, etc 09:25:03 q+ 09:25:07 ... Bounds is an opportunity for use to tackle this issue 09:25:17 q+ 09:25:24 s/use/us/ 09:25:26 ack ivan 09:25:28 ... Do you have to examine every resource to determine origins 09:25:31 ... ? 09:25:41 -> https://github.com/w3c/wpub/issues/205 205 - We need a section of the document that explicitly defines the bounds of a publication 09:25:46 ivan: Issue of bounds depends on what we discussed before the break 09:25:53 q+ 09:26:09 ... May be ok to say search is only for things in the resource lists 09:26:18 ... but may not be true for offlining 09:26:31 Hadrien: But those are the same bounds? 09:26:31 q? 09:26:44 ack dauwhe 09:26:49 ivan: But do we need to list eg CSS 09:27:13 marisa has joined #pwg 09:27:16 dauwhe: case 194 talks about links to items in multiple pubs? 09:27:33 q? 09:27:33 ... Do you need to define the various combinations of navigation actions? 09:27:37 ack bigbluehat 09:27:37 ack bigbluehat 09:27:57 bigbluehat: How ready are we to decide things like experiential actions like 09:28:13 ... clicking on something outside of bounds is different than inside? 09:28:16 q? 09:28:20 ... Are we at a place to deal with that now? 09:28:29 q+ 09:28:30 ack liisamk 09:28:35 liisamk: Yes, we are! 09:28:47 ... If you are in the bounds you should know that 09:29:22 ack dauwhe 09:29:26 ... There should be some experiential way of knowing I am navigating to something I "own" to something I don't 09:29:28 q? 09:29:29 DanielWeck has joined #pwg 09:29:37 present+ 09:29:48 dauwhe: Important web principal - how can a user trust their content (or not)? 09:29:57 +1 to experience mapping to user trust 09:30:07 ... web app manifest has a lot on this, about indicating to user they are in some special mode 09:30:08 q+ 09:30:12 ack bigbluehat 09:30:30 bigbluehat: There was a mention about web apps be similar but non standard 09:30:31 q+ 09:30:32 q+ 09:30:40 ... There is no consistency promies 09:31:02 s/promies/promise/ 09:31:02 ... Web pubs should have more trust - clear you are in the pub 09:31:15 q+ 09:31:40 ... Adding that expression of trust is valuable to publishing 09:31:58 tzviya: We are revisiting why we need boundaries 09:32:02 ack tzviya 09:32:06 ... But we have already discussed that 09:32:31 ... Need for security, offlining, wayfinding, etc 09:32:35 q+ 09:32:40 q- 09:32:41 ... Need to focus on how not why, people! 09:32:45 ack laurentlemeur 09:32:50 ack laudrain_ 09:32:55 q+ 09:33:00 laudrain_: User trust is fine, but also need to consider author trust 09:33:10 ... Something has been "published" 09:33:17 ... Bounds are important to verify that 09:33:21 ack Hadrien 09:33:40 q+ to suggest we write some UA reqs based on these bounds :) 09:33:44 Hadrien: In the case of web apps, it is similar to how epub RS often work 09:34:02 ... You have a context, when you go out if it, may open a browser or web view 09:34:11 ... so you are now in a different UX context 09:34:34 ... Compared to web once I have switched, I don't have the same expectation of how I get back 09:34:37 q+ 09:34:43 s/go out if it/go out of it/ 09:34:45 ... Web apps often don't really support back 09:35:11 ack leonardr 09:35:17 q+ 09:35:23 ... From a UX stanpoint fairly common way of handling bounds 09:35:27 q- 09:35:34 leonardr: Take a use case, say offlining 09:35:36 s/stanpoint/standpoint/ 09:35:51 ... Use as an example to figure out what we need 09:36:15 ... Have default reading, resource list, etc 09:36:22 ... [reading from spec] 09:36:56 q? 09:36:58 ... The bounds are defined as the union of resource list and default reading order 09:37:00 ack bigbluehat 09:37:00 bigbluehat, you wanted to suggest we write some UA reqs based on these bounds :) 09:37:03 bigbluehat: Before we go there 09:37:12 ... We have avoided UA requirement so far 09:37:16 ack bigbluehat 09:37:21 ... Should we define those now? 09:37:47 ... Things like leaving the pub, etc 09:37:56 ack duga 09:37:58 ack dauwhe 09:37:58 ack dauwhe 09:38:01 ... Should we just file issues and make Josh do them? 09:38:04 tzviya: Yes 09:38:17 dauwhe: Can we define expectations? 09:38:18 q+ 09:38:24 guests+ Tess_O'Connor 09:38:33 ... Eg if you do search, these are the ones you should search 09:38:51 ... Those can be tested 09:38:53 q+ 09:39:16 ... Have an operational definition instead of saying "this is a boundary" 09:39:35 ... Breaking the back button is really bad 09:39:54 Hadrien: I was just pointing out how web apps work 09:40:06 ack josh 09:40:07 dauwhe: I would be unhappy with pubs that did that 09:40:08 q? 09:40:28 josh: Is it possible you have something in bounds that is not in the reading order? 09:40:45 chorus_of_voices: yes 09:40:53 q? 09:41:17 https://w3c.github.io/wpub/#resource-list 09:41:21 josh: Does that mean what Leonard says was wrong? 09:41:26 ack ivan 09:41:31 ivan: No, you had it wrong, it is the union 09:41:50 ivan: I am fine putting this into a resolution 09:41:53 q+ 09:42:00 q+ 09:42:01 ... and then we can close an issue 09:42:27 ... it puts responsibility in the authors that if they expect eg offline to work 09:42:38 ... then they better put the CSS in the resources 09:42:53 ... Which is fine, but we need to decide 09:42:57 ack garth 09:43:05 ... I propose we do it now! 09:43:10 garth: Agree 09:43:23 ... Better flesh out your resources 09:43:28 ack leonardr 09:43:29 leonardr: I support that 09:43:54 ... The things we need to iterate on are various things we have discussed 09:44:24 tzviya: Proposal: leave language as is, change from a note to text, close the issue 09:44:35 q+ 09:44:44 leonardr: Change the language to "this defines the bounds of the publication" 09:44:44 q? 09:44:49 ack dauwhe 09:45:08 q+ 09:45:16 dauwhe: What happens if you have a resource that links to CSS outside the bounds 09:45:54 q+ 09:45:58 ivan: What happens today if you have something in the cache that refers to an external file? 09:46:04 ... That is totes the same 09:46:17 dauwhe: I am ok with not required 09:46:20 q? 09:46:23 q+ 09:46:46 tzviya: Objections? 09:47:15 q+ 09:47:29 romain: Need to understand what happens when there are multiple origins 09:47:39 ivan: Need extra constraints on resources 09:48:19 q? 09:48:24 ack leonardr 09:48:28 Hadrien: If we decide defining bounds is more convenient as one resource, then [something] 09:48:41 leonardr: You are viewing the bounds wrong 09:49:03 ... The fact that you can reference external CSS is irrelevant 09:49:14 ... Bounds are what the list says, not where they are 09:49:34 ... How we deal with bounds is another question 09:49:40 ack bigbluehat 09:49:49 bigbluehat: There is some prior art that is painful 09:49:55 ... eg app manifest 09:50:04 ... which is being replaced by service workers 09:50:25 ... No master list, it just puts referenced things in the cache 09:50:31 q? 09:50:31 ... No need for boundaries 09:50:33 q- 09:50:39 ... Further constrains a service worker 09:50:50 ack duga 09:50:52 scribenick: bigbluehat 09:51:06 duga: these lists of resources are all great 09:51:17 ...once upon a time there was a thing called epub 09:51:20 ...we had a manifest 09:51:24 ...then we had a package 09:51:33 ...which also had a list of files within the zip format 09:51:40 ...and the only thing that we got from the manifest 09:51:44 ...was errors 09:51:52 ...when you're not considering packaging, manifest sound great 09:52:03 ...but when you get to packing, you probably will hate the manifest 09:52:08 q? 09:52:18 q+ 09:52:19 tzviya: do you want these to be the same in WPUB and EPUB4? 09:52:22 duga: probably not 09:52:27 scribenick: duga 09:52:42 garth: A wp doesn't need to be packaged 09:52:43 q+ 09:52:59 ... but we could make a rule that the list is expunged by the time we package 09:53:25 ... I thought we were sort of close to agreeing that the bounds was the union 09:53:32 leonardr: Didn't we agree 09:53:35 ... ? 09:53:39 ack liisamk 09:53:40 q? 09:53:56 liisamk: We did have call for objections 09:54:18 ... I disagree with duga, I think it was very useful to have a list of resources 09:54:25 ack dauwhe 09:54:28 ... and am not opposed to it in WP 09:54:50 dauwhe: Does the current web packaging spec have [side chatter]? 09:55:05 ... Is there something there that [side chatter]? 09:55:25 dauwhe++ 09:55:35 ... Having some alignment with web packaging would be a lovely alignment 09:55:48 ... Hope we can coordinate with them 09:55:57 cristina has joined #pwg 09:55:58 +1 09:56:22 The union of the resource list and default reading order represents the definitive list of resources that belong to the Web Publication. All other resources are external to the Web Publication. 09:56:24 +1 09:56:25 s/have [side chatter]/have features that support WP? 09:56:29 tzviya: Can we agree with the statement in the spec now [reading from spec]? 09:56:35 The union of the resource list and default reading order represents the definitive list of resources that belong to the Web Publication. All other resources are external to the Web Publication. 09:56:50 ... Do we agree? 09:56:51 +1 09:56:52 +1 09:56:56 +1 09:57:00 s/that [side chatter]?/that we should pay attention to? 09:57:00 +1 09:57:08 ivan: Do we close 205 with this? 09:57:19 tzviya: Yes? 09:57:25 q? 09:57:32 +1 in that this statement is necessary, but not sufficient. There is more work to be done with boundaries and user experiences 09:57:42 +1 09:57:49 Resolved: The union of the resource list and default reading order represents the definitive list of resources that belong to the Web Publication. All other resources are external to the Web Publication & close #205 09:57:54 tzviya: Objections? 09:57:55 also +1 dauwhe 09:58:02 +q 09:58:04 q- 09:58:05 bigbluehat: Not -1 09:58:05 +1 09:58:17 ... Don't want to be the only negative one 09:58:28 ... also discussed a CG for exploring this 09:58:40 ... and kind of concerned about this 09:58:53 q? 09:59:00 ... Opposed because it is underexplored, has security ramifications, etc 09:59:19 ... We are pushing ahead due to time, but we need an outlet to properly vet these things 09:59:30 +1 to what @bigbluehat said 09:59:40 wendyreid: Dave said something like that in his +1 09:59:55 +1 09:59:56 ivan: If new problems come up, it is in our right to reopen 10:00:07 ... but don't want to keep issues open forever 10:00:10 +1 10:00:15 +1 10:00:21 +1 10:00:25 q? 10:00:28 ... at this moment uncertainty is bad 10:01:00 tzviya: Now proposing the PCG! 10:01:01 +1 to Ivan. We have to study implication of this definition of boundaries but can use it as a ground. 10:01:14 ... lunch time! 10:03:28 rrsagent, draft minutes 10:03:28 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html ivan 10:04:38 laurentlemeur has joined #pwg 10:08:03 Travis has joined #pwg 10:10:46 dauwhe has joined #pwg 10:36:27 Karen has joined #pwg 10:41:33 yanni has joined #pwg 11:04:40 dauwhe has joined #pwg 11:05:32 toshiakikoike has joined #pwg 11:08:06 r12a has joined #pwg 11:09:05 romain has joined #pwg 11:09:55 George has joined #pwg 11:10:12 addison has joined #pwg 11:10:24 romain_ has joined #pwg 11:10:30 leonardr has joined #pwg 11:12:08 david_clarke has joined #pwg 11:14:52 George has joined #pwg 11:15:05 liisamk has joined #pwg 11:15:39 ivan has joined #pwg 11:15:39 scribejs, set danbri Dan Brickley 11:15:44 marisa has joined #pwg 11:15:49 gkellogg has joined #pwg 11:15:53 garth has joined #pwg 11:16:13 scribejs, set addison Addison Philips 11:16:24 yanni has joined #pwg 11:16:24 laurentlemeur has joined #pwg 11:16:36 https://www.w3.org/community/blog/2018/10/22/proposed-group-publishing-community-group/ 11:16:37 scribenick: leonardr 11:16:38 yanni has joined #pwg 11:16:39 scribenick leonardr 11:16:39 scribejs, set r12a Richard Ishida 11:16:56 guests+ danbri, r12a, addison 11:17:00 tzviya : quick introductions 11:18:08 tzviya some technical issues + please use mike 11:18:33 https://w3c.github.io/wpub/#language-and-dir 11:18:37 tzviya three github issues 11:18:49 Avneesh has joined #pwg 11:18:53 Topic: language and base direction in JSON-LD 11:19:04 q+ 11:19:07 q- 11:19:27 ivan long running discussion that we've had with you folks in the past, about the need to represent 11:19:53 laudrain has joined #pwg 11:19:56 ...the language of content as well as multi-lingual 11:20:05 Ariel has joined #pwg 11:20:17 ivan schema.org also needs to be able to understand and address whatever "standard" is used 11:20:26 JunGamo has joined #pwg 11:20:29 ...base direction of a publication is not well defined in schema.org 11:21:00 ...(page) progression direction also needs to be reflected/described 11:21:30 DanielWeck has joined #pwg 11:21:32 present+ 11:21:34 ...in the cse of the WP, the UA needs to know which is "next" 11:21:38 q? 11:21:45 q+ 11:21:50 addison this also applies to J books for vertical orders 11:22:03 Bobbytung has joined #pwg 11:22:06 ...its not the same thing as base direction (for bidi) 11:22:21 ivan we do have them separately 11:22:36 https://github.com/w3c/wpub/labels/topic%3Ainternationalization 11:22:48 danbri has joined #pwg 11:22:57 ack liisamk 11:23:00 Hadrien has joined #pwg 11:23:22 gpellegrino has joined #pwg 11:23:37 liisamk are we also going to address mixed direction in a block? specifically in JSON, such as the title 11:23:58 JunGamo has joined #pwg 11:24:26 ivan : lets start with the trandition lang and dir issues 11:24:45 ...what we did there is to have two separate items (lang + dir) 11:24:51 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html Ralph 11:24:55 ...but there is gossip to change that 11:25:09 addison : what is the context, as there may be the case. 11:25:20 ...metadata about the publication, yes? 11:25:34 ivan : we don't do anything with the content (that' HTML). this is indeed abotu metadata 11:25:41 s/ivan long running/ivan: long running/ 11:26:02 s/ivan schema.org also/ivan: schema.org also/ 11:26:04 ...we set a global language via existing schema.org 11:26:21 s/addison this also applies/addison: this also applies/ 11:26:23 ...inLanguage? 11:26:39 s/ivan we do have/ivan: we do have/ 11:26:43 tzviya : clearing up some issues here... 11:26:53 cristina has joined #pwg 11:26:54 s/liisamk are we also/liisamk: are we also/ 11:27:05 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html Ralph 11:27:19 ...we are talking about specifc tags in JSON-LD and possibly schema.org, which danbri may have input into 11:28:12 ...we are particularly talking about how to express the language and/or direction of some tags. For example, the title or author of a document. 11:28:42 addison : the problem that you are encountering is similar to those of other groups. 11:29:11 ...if we have a piece of natural lang text, we need to be able to apply language and the base dir of that text. 11:29:24 here is our base reference: https://w3c.github.io/string-meta/ 11:29:30 ...(sometimes you may not need one or the other, but you want to be able to set them when important) 11:29:48 ...there are presentation cases where you need to know the proper things to do (eg. font selection) 11:30:45 ...we recommend that each tag have its own set of values for this. Our string-meta doc tries to address this 11:31:06 ...we agree that you need to transport both 11:31:29 ivan : in the current draft, we have a global setting, but we also want to enable overridding for specific items. 11:31:56 ...inLanguage from schema.org but they don't have an "inDirection" tag, so we added our own 11:32:36 ...but this is an issue because we had to introduce our own. However, there is a bigger issue 11:33:35 ...the individual override. Using @value language in JSON-LD 11:33:56 ....but we don't believe that schema.org understand this 11:34:12 ...(see gkellogg who wrote that spec) 11:34:25 ...the online tool for schema.org wasn't happy about it 11:34:27 Guillaume has joined #pwg 11:34:58 ..but direction is even more complicated, because JSON-LD doesn't have this natively. 11:35:17 q? 11:35:26 gkellogg : because JSON-LD is just RDF, then the language is coming from base. but RDF has no direction concept, tehre is nothing to come from 11:35:40 ...but if a future RDF had it, then JSON-LD would get it. (but not in the plans right now) 11:36:35 romain_ has joined #pwg 11:36:56 https://w3c.github.io/string-meta/#script_subtag 11:37:00 ivan : going back a bit, the gossip says that for this restrictive usage we could "get away" with just the Lang tag. 11:37:08 q+q? 11:37:12 q?- 11:37:24 ack q? 11:37:42 q+ 11:37:46 r12a : if there is no other way to do it, then you could assume direction from language tag, if you had script info as well. 11:38:19 Bert has joined #pwg 11:38:21 ...or could reliably guess. Hebrew, for example, might include info about the cdirection 11:38:38 script - ISO 15927 11:39:21 addison : inferencing the direction is not the same as actually having one 11:39:33 are there cases where a single script could be written several ways (eg. maybe japanese sometimes vertical etc?) 11:39:50 ...esp if you are counting on all downstream processing to do the same (right?) thing 11:40:20 ...the challenge is to think of cases where the title is in a lang but non-standard direction 11:40:30 tzviya : I can give you lots of examples! 11:41:35 addison: you can imagine a doc where infering direction would cause things in the wrong direction. 11:41:54 q? 11:41:58 ivan : the reason why I would like to avoid the direction tag is that it gets rid of a headache. 11:42:20 r12a : our preference is to have a separate label for each string. 11:42:36 ack gkellogg 11:42:42 ...but there could be any number of strings and each one needs the same treatment 11:42:55 gkellogg : using HTML literals as string values? 11:43:03 ivan : we considered by punted on that for other reasons 11:43:05 q+ 11:43:34 gkellogg : there is another level of indirection also possible but also mnot used commonly 11:44:01 ivan : setting the lang for each literal is not a problem, we know how to do that from JSON-LD perspective 11:44:11 ...but also having the direction is the problem 11:44:34 addison : we get that its a problem but you need that info if that the dstring is ever going to be displayed 11:44:41 q+ 11:45:06 ...otherwise, things may not actually line up properly in display. This is avoidable. 11:45:30 ...we do, however, consider this as a major flaw/limitation in RDF/JSON/JSON=LD 11:45:39 ivan : yes, but we are at the end of the stick 11:46:10 ...the only thing we can set today in JSON-LD is lang 11:46:10 ack bigbluehat 11:46:19 q+ 11:46:43 q+ bigbluehat 11:46:55 danbri : there are several dynamics happening here... 11:46:59 ack danbri 11:47:16 ...while I am happy to put stuff into schema.org, it may not be the right place 11:47:37 ...this group seems to be doing application modelling as well and I can help you do that too 11:47:44 ...let's not confuse the two 11:47:56 ivan : I don't see a proper solution here 11:48:18 danbri : cleanup issues in early 2000's lead to the current state and we're not going back there 11:48:33 tzviya : I like getting people angry 11:48:38 ack Hadrien 11:49:11 Hadrien : what we have right now is similar to your proposal but it woudln't be undestandable by generic processors 11:49:37 ...and that is a big part of our concern. we don't necessarily want to go out on our own, we'd rather use general stuff 11:49:51 q+ to discourage notion of a "Schema.org processor". There are applications (and families of application that share infrastructure) which use Schema.org terms and patterns. 11:49:59 ....esp. if it causes failures by general processors 11:50:01 ack bigbluehat 11:50:54 bigbluehat : concerning the suggestion of using HTML syntax for the strings, ivan is not a fan. 11:51:12 ...I'd like to understand why we don't want to go down that path. 11:51:17 ack danbri 11:51:17 danbri, you wanted to discourage notion of a "Schema.org processor". There are applications (and families of application that share infrastructure) which use Schema.org terms and 11:51:20 ... patterns. 11:51:26 q+ 11:51:39 +1 to bigbluehat 11:51:58 q+ 11:52:07 danbri : there is no such thing as a "schema.org processor". there are search engines, but that's not a general case 11:52:12 q+ 11:52:44 ivan : can we take the position that we can use any valid JSON-LD and have it handled? 11:52:59 danbri : no, not aware of a full JSON-LD processor in use today for schema.org 11:53:45 ...there are specific use cases where specific needs of JSON-LD are used (or not). 11:53:58 q+ 11:53:59 ...at Google, we picked a specific subset of things and Bing probably as well 11:55:14 ivan : what we have tried to do so far is to ensure that what we want to do is understood by an existing tool and if not... 11:55:33 q- 11:55:41 ack r12a 11:56:28 Hadrien : we have discussed the HTML route many times, we are concerned that many UAs that would ingest these literals would not know what to do with the HTML anyway 11:56:43 q+ to suggest this brings us back to our defining UA conversation 11:56:50 ...it would convert it down to a string and would end up dropping the useful bits 11:57:35 laurentlemeur : there is also an issues if improper elements are used 11:57:51 ...adding HTML elements de-simplifies JSON 11:57:51 glazou has joined #pwg 11:57:58 q- 11:58:31 r12a : there are three levels - global, per element, inter-element 11:58:54 ...HTML already knows how to do that and the Unicode controls aren't well supported by browsers 11:59:16 q+ to ask which strings we're needing this for 11:59:32 ivan : we don't use HTML for any strings 12:00:14 12:00:47 q? 12:00:48 addison : Ruby shouldn't be need for presentation of metadata but would be useful for sorting 12:01:06 ack add 12:01:27 q- 12:01:55 addison : yes, if you use HTML, you need to then have it parsed and understood. 12:02:04 ack bigbluehat 12:02:04 bigbluehat, you wanted to ask which strings we're needing this for 12:02:35 bigbluehat : it might be helpful which strings are thinking about here. What other data could be applied here? 12:02:45 addison : author, publisher, title 12:03:03 tzviya : let's look at the issues 12:03:14 ivan : they are all around the same issues 12:03:36 tzviya : proposal 1: going to HTML. (but that has been nixed by a few people) 12:04:00 ivan : do we think our UA/RS folks are willing to do deal with the HTML? 12:04:21 tzviya : would UAs rather see it as HTML or JSON/JSON-LD? what are common flows? 12:04:25 q+ to propose a narrower sub-set of HTML focused on language expression 12:04:44 addison : they have fields with the values and not HTML 12:04:48 q+ 12:05:41 you don't get anything for free from JSON-LD but it still works with those processors 12:05:49 re Google SDTT, consider an example like https://gist.github.com/danbri/010ee9afeb48806c857775d062caf3ed ... it is OK by the Google tester but effectively useless. SDTT is good for testing to see if specific data examples match the information needs of specific google tools, and it also catches some low-level errors. 12:05:56 ack bigbluehat 12:05:56 bigbluehat, you wanted to propose a narrower sub-set of HTML focused on language expression 12:06:31 bigbluehat : social web working group uses the HTML representation (or a subset thereof) 12:06:47 ...we should probably also set the set of valid values 12:06:56 q+ 12:07:18 ack leonardr 12:07:56 Leonard: Adobe's XDM handles some of these issues 12:08:12 ack danbri 12:08:20 leonardr: we follow script-meta recommendations 12:08:42 danbri : there seems to be nothing in between HTML and "plain text". 12:08:46 q+ 12:09:00 ivan : we are not in the position to make a new RDF datatype 12:09:41 q+ 12:09:56 ivan : we could define a subset of HTML but that would need to be validated during workflows 12:10:11 ack bigbluehat 12:10:29 q- 12:10:50 bigbluehat : in practice, *lots* of folks had the same issue that HTML is too big and scary and don't expect folks to use it 12:11:13 ...and ended up using a subset of HTML 12:11:29 tzviya : we need something robust but not as scary as HTML 12:11:35 q+ 12:11:56 garth : it having our special stuff ignored a bad thing? 12:12:04 tzviya : why can't we change JSON-LD? 12:12:20 bigbluehat : because JSON-LD is modelled on RDF which we can't change 12:12:51 q+ 12:12:52 bigbluehat : why is violating JSON-LD OK? 12:13:15 ivan : because implementors could just ignore the validation errors 12:13:24 q+ 12:13:54 ivan : the reason for JSON-LD was so that the metadata would be understood by search engines and other schema.org aware systems. So why violate it? 12:14:00 ack r12a 12:14:04 liisamk has joined #pwg 12:14:13 q? 12:14:13 bigbluehat : but maybe Google or bing will index it anyway 12:14:15 [ JSON punted on the lang/dir issue. RDF tried to punt on it as well, expecting the underlying serialization to handle it. When the first serialization was XML then the RDF punt nearly worked. An underlying serialization in HTML handles lang/dir as well as (potentially) markup for SVG, MathML, ... ] 12:14:23 q+ 12:14:54 r12a : HTML was one option. JSON-LD was another. but there is another possibility 12:14:58 ack gkellogg 12:16:17 gkellogg : the three options I heard. Inside a tag, you have to use HTML (or the like). For the entire tag, use a script as part of the language tag (as that is valid RDF). Or use a fully structured object with lang and direction, which is also valid JSON-LD/RDF 12:16:59 ivan : this means moving away from "simple literals" 12:17:04 ack bigbluehat 12:17:07 Guillaume has left #pwg 12:17:40 Guillaume has joined #pwg 12:18:08 bigbluehat : the situation of feeding search engines, I've tested things and Google seems to handle the HTML values in JSON-LD - for some definition of "handle" 12:18:16 q+ 12:18:42 the alternative, the complex objects, will not index by the search engine 12:19:14 ack liisamk 12:19:25 gkellogg : if there was a standard "indirect object" that would help 12:19:42 liisamk : doesn't onyx use HTML for thje strings? 12:19:56 s/onyx/ONIX 12:20:08 tzviya : its HTML and XML. (ONIX is a common vocab for books) 12:20:27 ??? : what are the cases where you can't determine the direction from the lang? 12:20:39 re JSON-LD, could we use a complex "datatype" to carry lang+direction together? (ugly and horrible and wrong...) 12:20:53 ONIX: https://www.editeur.org/83/Overview/ 12:20:55 s/???/Mathias/ 12:21:10 addison : writing mode is different. examples like azerbejan can go in both latin or arabic 12:21:12 q+ the hard case is the mixed language title 12:21:17

W3C TPAC 2018

12:21:19 s/its HTML and XML/it's XML not HTML 12:21:24 q? 12:21:38 q+ to ask where we go from here? 12:22:01 ivan : what are the real practical cases that we would have in publishing if we *only* used the lang tag? 12:22:15 r12a: you would have to ensure a script tag! 12:22:20 xfq has joined #pwg 12:22:59 addison : the Unicode/ICU approach also has some options (???) 12:23:05 Hadrien has joined #pwg 12:23:19 s/Mathias/Matthias_Kovatsch 12:23:51 danbri : re JSON-LD, could we use a complex "datatype" to carry lang+direction together? (ugly and horrible and wrong...) 12:24:11 q? 12:24:42 ack leonardr 12:24:58 q+ to mention the hard case is the mixed language title 12:25:14 LeonardR: when you mention Unicode, you're not referring to the deprecated substring stuff, are you? 12:25:29 Addison: I'm referring to BCP47 12:25:54 ... separately, Unicode bidi control characters that could be used in plain strings outside of markup 12:26:08 ack tzviya 12:26:08 tzviya, you wanted to ask where we go from here? 12:26:13 ... modern changes on isolating controls are not yet widely in use, though that's what you'd really want to recommend 12:26:15 FWIW Google's JSON-LD parser doesn't complain if it sees "name": "Stan Dinkley", etc., but nothing in Schema.org says when/whether to treat '<' as markup vs part of the content. Most of our *applications* would strip or otherwise sanitize it. But that is an application-level decision. 12:26:27 xfq has joined #pwg 12:26:46 RichardIshida: we really need isolation control to make bidi work 12:27:00 tzviya : what happens next? 12:27:26 ...danbri suggested evaluating underused attrs like "role" 12:27:28 http://blog.schema.org/2014/06/introducing-role.html 12:27:37 danbri : we tried that, but it wasn't a success 12:28:20 danbri : nobody likes it 12:28:21 q? 12:28:26 q+ 12:28:37 ack bigbluehat 12:28:37 bigbluehat, you wanted to mention the hard case is the mixed language title 12:29:11 bigbluehat : I still feel the only way to handle this, esp with mixed language, is to use (a subset of) HTML 12:29:19 q+ 12:29:31 ack laurentlemeur 12:29:51 here's a real world json-ld schema.org mixed language name/title from MusicBrainz, https://search.google.com/structured-data/testing-tool?url=https://musicbrainz.org/work/e664139f-6fb5-4aaf-91f1-3c109753c7ea#url=https%3A%2F%2Fmusicbrainz.org%2Fwork%2Fe664139f-6fb5-4aaf-91f1-3c109753c7ea 12:29:56 laurentlemeur : I want to go the exact opposite way, to not use HTML but standard data elements 12:30:15 ....but that does not solve mixed language 12:30:20 q+ 12:30:23 ack leonardr 12:30:25 (currently {"name":"(Si Si) Je Suis un Rock Star") 12:31:01 glazou has joined #pwg 12:31:02 Leonard: do we actually know what was indexed (by Google) in Benjamin's experiments? 12:31:17 q+ 12:31:18 q+ to comment on the 'how google does it' bit 12:31:22 hehe 12:31:43 ack r12a 12:31:46 bigbluehat: removing the tags and keeping only the content gives the wrong result 12:32:23 r12a: if you did it using the HTML, you would have to do it all the time for each string 12:32:23 q- later 12:32:49 ack danbri 12:32:49 danbri, you wanted to comment on the 'how google does it' bit 12:33:17 danbri : I would move away from "how Google indexes things", but instead consider rthat stuff comes in and then out as a "triple" 12:33:39 ...and then sent downstream where some processors may strip out bit and others may not 12:33:44 q? 12:33:44 ack ivan 12:34:07 ivan : the perfect is enemy of good 12:34:15 ...so what is the 80/20 cut on this one? 12:34:25 Karen has joined #pwg 12:34:54 example of strings that need base direction: في HMTL5 يتم تحقيق ذلك بإضافة العنصر المضمن bdi. 12:35:05 ... are we willing to sacrifice some of these requirements (eg. mixed language) in favor of supporting the others more simply? 12:36:05 q+ 12:36:17 david_clarke : an example in titles such as my text book 12:36:32 ivan : this is where Unicode directionality might help 12:37:17 r12a : you are talking about a different issue. applying bidi inside a string with the Unicode dir chars is fine. *but* that doesn't address the base direction 12:37:42 ...my example earlier shows up the problem with missing base dir 12:38:02 David_Clarke_ has joined #pwg 12:38:41 rrsagent, pointer? 12:38:41 See https://www.w3.org/2018/10/22-pwg-irc#T12-38-41 12:38:45 addison: when passing data around, when you need the data, you need it! and once computed, you want it understood the same way in all cases 12:38:52 q? 12:39:10 q+ 12:39:30 ...the options discussed here are all valid ones but you need to decide which pain points you are willing accept 12:40:15 skk has joined #pwg 12:40:17 addison has joined #pwg 12:40:29 marisa : another example in arabic...numerals. you switch the directions with numerals 12:40:47 ack marisa 12:40:57 q+ to propose that we write a simple HTML subset for strings in JSON-LD 12:41:00 ack r12a 12:41:04 ivan : there is no ideal solution. "which finger should I bite?" 12:41:36 bigbluehat I have a starting point from PDF for that that we use for rich text string... 12:42:13 q+ to ask if you'd like a tentative/experimental (i.e. "pending" review) inDirection property in schema.org to help move things along? Is there a definition to use? 12:42:42 ack bigbluehat 12:42:42 bigbluehat, you wanted to propose that we write a simple HTML subset for strings in JSON-LD 12:42:53 bigbluehat : propose that we write a simple HTML subset for strings in JSON-LD 12:42:55 q+ 12:43:04 ack bigbluehat 12:43:08 ack DanielWeck 12:43:14 danbri: we'd use that if you come up with it! 12:43:31 ...alternatively, would you like us to add an inDirection property in schema.org to help move things along? 12:43:32 ack DanielWeck 12:43:39 q+ 12:43:42 ack danbri 12:43:42 danbri, you wanted to ask if you'd like a tentative/experimental (i.e. "pending" review) inDirection property in schema.org to help move things along? Is there a definition to use? 12:43:54 s/making proposals/writing down proposals/ 12:44:20 ack DanielWeck 12:44:22 ivan : will make sure to contact danbri with a formal propsal 12:45:14 proposed: we propose for schema.org to add an inDirection term alongside inLanguage, with value of "rtl", "ltr", "auto" 12:45:18 DanielWeck : if we were to carry the HTML in the string liternal, then the RS needs to process that? How would you know that it is HTML? 12:45:31 ivan : you would know that from the RDF/JSON-LD 12:46:02 gkellogg has joined #pwg 12:46:13 ivan: calling for objections for my proposal? 12:46:22 Crickets 12:46:22 q+ to ask that we also record the sub-set of HTML proposal 12:46:26 rrsagent, pointer? 12:46:26 See https://www.w3.org/2018/10/22-pwg-irc#T12-46-26 12:47:35 resolved: we propose for schema.org to add an inDirection term alongside inLanguage, with value of "rtl", "ltr", "auto" 12:48:33 [acknowledging that this resolution doesn't address multiple-direction literals] 12:48:57 DanielWeck : this is not just RS, but authoring, etc. all have to deal with whatever we proposed 12:49:13 thanks, noted in https://github.com/schemaorg/schemaorg/issues/2086 12:49:21 (entities, whitespace normalization, etc.) the HTML processing model 12:49:27 q+ 12:49:47 ack bigbluehat 12:49:47 bigbluehat, you wanted to ask that we also record the sub-set of HTML proposal 12:49:47 ivan : if we do a pure HTML datatype, then anything could be allowed 12:50:00 bigbluehat : which is why I want a specialized version 12:50:26 duga : there is a history here with EPUB that the Japanese couldn't represent some titles - let's not do that again 12:50:33 ack duga 12:52:02 [is it plausible to sanitize the HTML before putting it through a full HTML parser? Likely reading systems don't want to have to write a separate limited HTML parser?] 12:52:03 tzviya : we have a proposal to work up a small subset of HTML that could be used 12:52:04 q? 12:52:06 q+ 12:52:20 ack leonardr 12:52:49 q+ 12:52:50 Leonard: if someone is proposing to pursue a formal proposal, we should let them do it 12:53:06 q? 12:53:14 ack r12a 12:54:01 Benjamin: I'm writing it now 12:54:20 proposed: allow literals (title, publisher, creators) to be expressible using an HTML datatype, restricting the HTML to a subset 12:54:21 PROPOSED: to create a sub-set of HTML--narrowed to multiple language tags--to use within all text strings used within the infoset/manifest 12:54:22 romain has left #pwg 12:55:21 romain has joined #pwg 12:55:31 PROPOSED: to create a sub-set of HTML--narrowed to multiple language tags--to use within (a set of TBD) strings within the infoset/manifest 12:56:49 tzviya : any objections? 12:57:59 ivan : no one is saying that you *must* use the HTML. just that it would (possibly) be an option 12:58:28 q+ 12:58:43 addison : please make sure to include us in those discussions 12:58:54 ...we want solutions for the web at large 13:00:35 ack laurentlemeur 13:00:43 FWIW I asked in #tpac-chat, tantek noted WICG draft around sanitization, https://github.com/WICG/purification 13:01:28 tzviya : break time!@ 13:01:39 ...thanks to all our guests. 13:02:10 George : we also have a11y items outstanding as well. don't forget about them. 13:03:50 Bobbytung has joined #pwg 13:13:17 Karen_ has joined #pwg 13:16:31 ReinaldoFerraz2 has joined #pwg 13:21:52 gpellegrino has joined #pwg 13:23:54 plinss has joined #pwg 13:27:31 laurentlemeur has joined #pwg 13:27:40 Bert has left #pwg 13:32:04 romain has joined #pwg 13:32:35 Ariel has joined #pwg 13:35:05 Karen has joined #pwg 13:35:45 romain_ has joined #pwg 13:37:20 marisa has joined #pwg 13:38:18 marisa has joined #pwg 13:38:31 gpellegrino has joined #pwg 13:42:45 xfq has joined #pwg 13:43:38 xfq has left #pwg 13:43:46 laudrain has joined #pwg 13:44:28 Bobbytung has joined #pwg 13:46:10 JunGamo has joined #pwg 13:51:44 Karen has joined #pwg 13:52:10 toshiakikoike has joined #pwg 13:52:46 scribnick: Rachel 13:52:56 Topic: schema.org issues 13:53:01 scribenick: Rachel 13:53:08 https://github.com/w3c/wpub/wiki/Schema.org-issues 13:53:55 Bobbytung has joined #pwg 13:53:55 Ivan: we've started with some problems in which we started to define our own context and terms. 13:54:32 ...in publishing the order of authors, publishers, translator etc is deadly serious 13:54:43 ...currently, these terms are not ordered 13:55:00 Karen has joined #pwg 13:55:16 ... we put these in an ordered list to meet our needs - is this an acceptable solution for schema.org 13:56:23 danbri: lists have always been a pain in rdf... schema.org made an item list construction. 6 months ago we went through an exercise with json-ld. the end result was prettier and there was consensus that the result was prettier. 13:56:30 ...that's as far as we got 13:56:50 ...we would introduce new ones, not turn the current ones into lists 13:57:01 Karen_ has joined #pwg 13:57:41 ivan: so for the time being its fine to keep it as it is now 13:57:57 danbri: the most obvious one is recipe instructions 13:58:29 ivan: it will be a timing issue 13:59:01 re lists in schema.org, see https://github.com/schemaorg/schemaorg/issues/1910 13:59:11 ivan: we will skip over language setting 13:59:59 tzviya: accessibility issues go back to the first idpf proposals for tags that sit in a non-normative document about certification metadata 14:00:24 ...we have outlined what we want 14:00:36 ...it picks up conformance rules from dublincore 14:00:58 ...certified-by, certified-credential, certified-report 14:01:09 danbri: my concern would be overlap 14:01:33 Hadrien has joined #pwg 14:01:53 https://idpf.github.io/epub-vocabs/package/a11y/#sec-certifierCredential 14:02:44 danbri: This might overlap with the credential work (certifier) 14:02:53 Guillaume has joined #pwg 14:03:15 tzviya: we didn't add accessibility to purposefully keep it generic 14:03:43 wendyreid: certified-by points to the org, which is a recognized org 14:03:51 ...for accessibility 14:04:20 leonardr: it should be tied to accessibility 14:04:38 q+ 14:04:42 danbri: our preference is to say it's a relationship between two things 14:04:53 q+ 14:04:55 ack gpellegrino 14:04:58 Karen has joined #pwg 14:04:59 ...certified credential carries some of that work 14:05:17 gpellegrino: we also need a URL, because it is specific to that publication 14:05:19 ack leonardr 14:05:28 Ralph: certification should be a URL so that you can look up properties of the certifier; e.g. org, specifics about the certification 14:05:47 leonardr: if the document is certified to 2 purposes but you only have one set of metadata how do you address that 14:05:54 tzviya: have the field repeat 14:06:14 danbri: what is the purpose 14:06:41 tzviya: to clarify who is saying that something is accessible and what they are using to say it 14:06:45 q+ 14:07:12 danbri: if you have multiple things being investigated, you don't know which report is which 14:07:18 ack Rachel 14:07:19 ... you might need to hack something 14:07:23 [we should also look for overlap with Verifiable Claims work] 14:07:41 EOCred work --- https://www.w3.org/community/eocred-schema/ 14:07:54 Rachel: re: purpose -- in education this comes up repeatedly; we have two situations -- an actual certification program run by Benetech 14:08:12 ... Benetech will certify that a publisher is producing accessibly ebooks 14:08:45 ... and many campuses are requiring publishers to self-certify; accepting responsibility for fixing problems 14:09:03 danbri: it's about each particular published thing 14:09:07 ...rather than the publisher 14:09:26 ...we have this corner of schema.org where we can throw things and see if they work 14:09:37 have a look at this: http://pending.eocred-1779.appspot.com/EducationalOccupationalCredential 14:09:42 q? 14:09:50 tzviya: there is some potential overlap with verifiable claims and open badhes 14:09:56 s/badhes/badges 14:10:27 ...if a publisher is saying "I assert this is accessible" how do we verify this? 14:14:45 ivan: languages - in json-ld there is something easier to use, called language mapping, from an authoring point of view...??? 14:14:48 [Ivan is now discussing https://github.com/w3c/wpub/wiki/Schema.org-issues#language-indexing Language indexing ] 14:15:12 Hadrien: you need to be able to process the context 14:15:27 Bobbytung has joined #pwg 14:15:29 danbri: I'm not aware of anyone in the search industry doing complex processing 14:16:31 Ivan: can you find out if this is planned? is it a good idea to use this index? 14:16:44 Hadrien: are there plans to support json? 14:16:53 danbri: that would be company by company 14:16:58 q+ 14:17:10 ack bigbluehat 14:18:27 bigbluehat: [starts troubleshooting for the json working group even though he has his own meeting] 14:19:01 ivan: we need something close to the link role 14:19:02 -> https://github.com/w3c/wpub/wiki/Schema.org-issues#linkrole LinkRole 14:19:10 ...even though it's experimental 14:19:22 ...what we started to do is that we defined our own type 14:19:41 ...it is almost the same except linkrole cannot accept mime types 14:19:54 ...I raised an issue about this on schema.org 14:20:15 danbri: encoding format shouldn't be used on the link role 14:20:41 ivan: the real question is encoding format 14:20:54 danbri: linkrole is still pending? 14:21:09 ...I need to check on the mechanics... 14:21:27 ivan: It would be better for us to rely on schema.org vocabulary than inventing our own here 14:21:29 q+ 14:21:34 ivan: audio 14:21:38 -> https://github.com/w3c/wpub/wiki/Schema.org-issues#duration-values [audio] duration alues 14:22:14 ...the html equivalent is more relevant than schema.org 14:22:43 ack leonardr 14:22:43 wendyreid: duration in schema refers more to a CV - as in I was in a job from jan 2017 to feb 2018 14:23:07 q+ 14:23:22 see lower section of https://schema.org/Duration for properties whose value is datatyped schema.org/Duration, which does lean towards 8601 14:23:38 ivan: we should allow for the iso standard to be used 14:23:46 -> https://www.w3.org/TR/2018/WD-html53-20181018/infrastructure.html#durations [HTML 5.3] Durations 14:24:05 wendyreid: we would like to extend the iso standard to be used 14:24:08 ack wendyreid 14:24:08 whereas https://schema.org/temporalCoverage covers date ranges, and we had some issue about openended ranges 14:24:52 https://github.com/schemaorg/schemaorg/issues/2086 14:27:31 next step is to follow up https://pending.schema.org/duration and clarify whether it is a temporal quantity, versus a period (temporalCoverage); could be clarified 14:27:34 ivan: general question - there is a large vocabulary for publications in schema.org, but new types of publications are unavoidable 14:27:53 ...what steps should we take to add new types 14:28:03 -> https://github.com/w3c/wpub/wiki/Schema.org-issues#what-is-the-mechanism-this-community-should-follow-for-new-publication-types mechanisms for new publication types? 14:28:14 danbri: we generally push to wikidata to do the work 14:28:44 ivan: proceedings is a good example 14:28:45 glazou has joined #pwg 14:29:47 https://www.wikidata.org/wiki/Q1143604 14:30:44 danbri: you can use wikidata directly 14:30:45 Karen has joined #pwg 14:31:12 ivan: so in my json-ld, I would use Q1143604 instead of Proceedings? 14:31:17 danbri: yes 14:31:42 ivan: [suggests workaround Rachel doesn't understand] 14:31:46 danbri: that too 14:32:37 Bobbytung has joined #pwg 14:32:39 laurentlemeur has joined #pwg 14:33:20 Topic: Issues 14:33:22 workaround is "Proceedings" is a term in the surface syntax defined by a json-ld context, but maps to Q1234-style URLs 14:33:36 scribenick: Ralph 14:34:21 -> https://github.com/w3c/wpub/issues issues 14:34:46 Wendy: looking for things that could be closed ("propose closing") 14:34:52 Karen_ has joined #pwg 14:34:55 https://github.com/w3c/wpub/issues/261 14:35:28 ... #261: use of "cover image" 14:35:53 Ivan: 'cover' is a structural property in the manifest 14:36:32 Leonard: cover is optional? 14:36:34 Ivan: yes 14:36:47 Wendy: any objection to closing this? 14:37:03 [none expressed] 14:37:51 Garth: we have to update the editor's draft now to close it 14:37:57 Ivan: yes; that's the mechanics 14:38:08 resolved: close #261 14:38:27 Wendy: consider #54 14:38:28 https://github.com/w3c/wpub/issues/54 14:38:38 ... "Obtaining language from http headers" 14:39:16 Wendy: the issue is whether http headers can be fallback for determining the language of a publication 14:39:29 Tzviya: this is no longer relevant; it's from a long time ago 14:39:42 Rachel: let's add a comment saying this 14:39:57 Ivan: I'll clean the minutes then refer to them in a close comment 14:40:34 Wendy: #270 14:40:52 ... Conformance criterion for UA 14:41:03 Ivan: we should add a reference to this morning's discussion 14:41:14 ... and add a comment that it will be followed-up later 14:41:21 Wendy: not proposing to close this yet 14:41:37 Wendy: #291 14:41:48 https://github.com/w3c/wpub/issues/291 14:42:00 ... Do we need a more detailed definition for the HTML TOC format? 14:42:10 ... based on #385 14:42:14 s32 14:42:25 s/38/28 14:42:28 s/s32// 14:42:36 Ivan: and we now have pagelist 14:43:15 Garth: there's a reference to a transcript of a meeting, though it didn't resolve the issue 14:43:31 Ivan: the question is whether we want to define a structure in HTML for TOC 14:43:44 ... at the moment the spec doesn't say anything 14:43:53 q+ 14:44:04 ... we have two extremes: the EPUB model and no restriction (whatever you can express as HTML) 14:44:41 ... the discussion was that whatever we define should be machine processable; there should be a clear algorithm for extracting the TOC from the HTML 14:44:59 ... the current spec stops at describing an ARIA tag 14:45:18 ... it's relatively clear that an algorithm can be defined for what's in EPUB, or even for something more liberal 14:45:21 Bobbytung has joined #pwg 14:45:30 q+ 14:45:39 ... on the other hand, nobody so far has come up with an algorithm to get a reasonable TOC from arbitrary HTML 14:45:58 q- 14:46:00 ... if you think something more liberal should be permitted, provide an algorithm 14:46:04 q? 14:46:08 q+ 14:46:19 Juan: I've been thinking about an algorith 14:46:19 ack JuanCorona 14:46:31 s/rith/rithm 14:46:50 ... my thinking is to require UL/OL with LI and then require SPAN 14:47:24 ... I've been looking at the Category content model and have an idea about explicit/implicit P 14:47:39 liisamk has joined #pwg 14:47:46 q? 14:47:58 q+ 14:48:04 ... I think there's text there about runs of phrasing content that could be used to define a generic algorithm 14:48:25 ... I have a tree-walker algorithm that is very preliminary 14:48:25 q+ 14:48:42 q+ 14:48:44 ... would welcome comments 14:48:45 ack laudrain 14:48:52 Tzviya: sounds interesting; I'd love to see it 14:48:52 q+ laudrain 14:48:56 ack laurentlemeur 14:49:02 Laurent: we have to permit round-tripability 14:49:16 ... we must be careful 14:49:18 ack liisamk 14:49:27 Liisa: what problem are we trying to solve? 14:49:44 ... replacing the nav doc in some way that doesn't sound like addressing missing formatting in that doc 14:49:54 ... the inline TOC and the navigation are not a map of each other 14:50:04 ... often we include more in the nav that we include in the inline TOC 14:50:27 ... we've been thinking that we might not create an inline TOC where the printed version didn't have one 14:50:31 ... as a content item 14:51:02 ... a renderable TOC is often very heavily designed and that doesn't get put in the nav 14:51:27 ... as we're thinking about this, keep the option that they can be separate 14:51:48 Tzviya: nothing prevents you from creating an inline TOC 14:52:08 ... in my ideal world they would be the same thing 14:52:26 Liisa: I'd like to have the machine-readable with the option to have the pretty one 14:52:28 Karen has joined #pwg 14:52:36 q? 14:52:39 q+ 14:52:39 ... I don't necessarily want the pretty TOC to be the machine-readable TOC 14:52:47 Ivan: so you'll have two structure? 14:52:52 s/e?/es? 14:52:55 Liisa: yes 14:53:15 Ivan: that's still doable; you just have to identify via ARIA which one is the machine-readable one 14:53:40 q? 14:53:56 Wendy: the pretty one is the one users look at; as a RS, I'd love to offer all the information that's there 14:54:17 Liisa: two separate problems: the amount of information and the prettyfying of that 14:54:25 ack ivan 14:54:27 q+ 14:54:49 Karen__ has joined #pwg 14:54:50 Ivan: can you write down (later) the algorithm and the corresponding HTML structure? 14:55:19 ... if this can be written, and if it includes the usual structure in EPUB 3 and other possibilities, that's fine 14:55:37 Juan: I can do that 14:55:37 ack laudrain 14:56:01 Luc: this is important both for TOC and for accessibility issues with TOC 14:56:05 q+ 14:56:31 Juan: I'm thinking that there's one container, a DIV, and a text node 14:56:46 ... that text node becomes an H1 14:56:52 q- 14:57:15 ... I get lost with mixing H2, H3, ... 14:57:29 ... I saw a proposal for something that takes the level from the nesting 14:57:39 ... I don't yet know how to address this 14:57:57 ack Ralph 14:57:59 Tziya: others here might help in understanding the outline algorithm 14:58:21 Rachel: when we present a TOC in a textbook we generally have two of them: a detailed one and a brief one 14:58:28 ... in our ebooks we have a third for navigation 14:58:31 rrsagent, draft minutes 14:58:31 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html ivan 14:58:38 rrsagent, pointer? 14:58:38 See https://www.w3.org/2018/10/22-pwg-irc#T14-58-38 14:58:50 ... we present the nav TOC in the reader navigation and within that there are links to the brief and full TOC 14:59:01 ... the full TOC has additional links that are not in the nav 14:59:17 Hidden=“hidden” 14:59:28 q+ 14:59:29 q? 14:59:35 ack Rachel 14:59:40 ... we put these in the full TOC because students look for them while paging through a book 14:59:40 ack bigbluehat 15:00:05 Benjamin: there are use cases for several TOC presentations 15:00:25 ... is it a requirement that the machine version be extractable from the human-readable one? 15:00:44 ... perhaps it's an imagemap 15:00:47 a+ 15:00:49 q+ 15:01:00 q+ 15:01:10 q+ 15:01:14 ... are we trying really hard to make this possible without saying "the machine SHOULD ..."? 15:01:18 ack leonardr 15:01:40 Leonard: similar question; I'm not sure why we need a machine readable TOC in WP 15:01:43 q? 15:01:49 ... I understand the need for a human-presentable one 15:02:06 q+ 15:02:15 ... giving that reading order and resources are both handled elsewhere, why does a UA need in addition another TOC? 15:02:22 q+ 15:02:30 Tzviya: we've answered this over the course of several meetings 15:02:39 Brady: briefly, for accessibility 15:02:44 ack duga 15:02:47 ... George can explain in more detail 15:02:48 ack liisamk 15:03:02 Liisa: were we planning to be able to have the machine readable have extensible formatting? 15:03:12 ... embedding styling, images, ... 15:03:25 Tzviya: this ties back to the JSON-LD discussion 15:03:33 Wendy: audiobooks have an example 15:03:35 q- 15:03:42 ... and audiobook in a language that does not have a text form 15:03:49 ... the TOC might use voice prompts or images 15:03:52 q? 15:03:55 q+ 15:03:58 ack laudrain 15:04:04 ... we'd want a machine-readable TOC to be able to say "there's no text for this chapter" 15:04:28 Luc: I'm concerned with performance to compute a machine-readable TOC 15:04:54 ... as a publisher, I have no issue to prepare a machine readable and a presentable TOC 15:04:59 ... I don't care about duplication 15:05:08 ... I care about production and performance for the user experience 15:05:17 ... I have no issue with a complex presentaton TOC 15:05:40 ack laurentlemeur 15:06:08 Laurent: a good discussion would be what is the user experience in an RS if there is no machine-readable TOC only an HTML page 15:06:11 q+ 15:06:35 ... the TOC could still be accessible but it might take the whole screen because the RS wouldn't know how to make it smaller 15:06:37 q+ 15:06:43 ... would this be a good user experience? 15:06:57 ack Hadrien 15:07:07 Adrien: we're discussing two concepts 15:07:10 romain_ has joined #pwg 15:07:17 ... something nice, presented to the user in many ways 15:07:29 ... and something else meant for accessibility or [other] specific UI features 15:07:38 s/Adrien:/Hadrien:/ 15:07:42 ... in EPUB3 we tried to have something serve both and failed 15:07:55 ... I'm wondering if we shouldn't simply treat them as separate 15:07:59 q? 15:08:09 ... the machine-readable one may have some very specific information 15:08:28 ... I'm not hearing yet a step forward 15:08:32 q+ 15:08:33 ack ivan 15:09:00 Ivan: Juan might come up with a more general and usable solution 15:09:35 ... if JuansAlgorithm fails there can be a fallback for the UA to use it as is 15:09:54 q? 15:10:02 ... an imagemap can be marked as a TOC, JuansAlgorithm will fail, and Benjamin will get what he wants 15:10:16 Hadrien: @@ 15:10:55 Tzviya: we get into a tricky area if you're thinking that the accessible version is different 15:11:04 Hadrien: that's not what I'm suggesting 15:11:20 q? 15:11:20 s/@@/one can mark up the same element with two different doc-XXX to denote the two different navigations approaches in one element/ 15:11:36 ... I was thinking at the manifest level 15:11:54 Tzviya: I think people will be happier with Juan's approach if it works 15:12:13 Ivan: is there another ARIA element? 15:12:14 q? 15:12:17 Tzviya: not really 15:12:39 Dave: it's possible to be both smart and good looking :) 15:12:43 ack dauwhe 15:12:48 ack bigbluehat 15:12:52 https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/ 15:13:09 Benjamin: ^^ shows what one can do 15:13:19 ... it's an EPUB in which I renamed the nav file to index.html 15:13:37 ... Avnesh says this is sufficient for accessibility 15:13:48 ... next and previous are populated from what's underneath what you read 15:14:04 ... it's not using LI or anything magical; just finding the next anchor 15:14:07 ... keeps reading state 15:14:18 Tzviya: this is navigation, not the TOC 15:14:26 Benjamin: in this document those happen to be the same 15:14:39 ... I claim that navigation can be as simple as next anchor 15:14:53 Ivan: the JuansAlgoritm might cover this 15:15:00 Juan: yes; I think this idea could still work 15:15:24 Benjamin: tree order can be determined from the parentage of each link 15:15:26 +1 15:15:45 ... if this were structured in an HTML DOM tree they could be represented in a machine-readable navigatin 15:15:59 DanielWeck has joined #pwg 15:16:00 my proposal is to have two different rel values at a manifest level, if a resource can be both "good looking" and "machine readable", it would simply use both rels 15:16:01 ... I believe this suggests that the algorithm is not very hard 15:16:05 q? 15:16:15 ... the machine readable thing is calculable 15:16:29 ... this example calculates from the TOC 15:16:51 proposed CG https://www.w3.org/community/blog/2018/10/22/proposed-group-publishing-community-group/ 15:17:06 Tzviya: I think this discussion could proceed in the newly proposed ^^ CG 15:17:17 Garth: the TOC discussion belongs in this WG 15:17:40 ... the discussion of options might come from the CG? 15:17:43 Tzviya: yes 15:18:00 Benjamin: I think the WG can keep the discussion 15:18:14 Tzviya: Juan will work on JuansAlgorthm 15:18:26 ... Hadrien will work on a double TOC proposal 15:18:30 rrsagent, draft minutes 15:18:30 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html ivan 15:18:33 laurentlemeur has left #pwg 15:18:42 Garth: I'm skeptical that JuansAlgorithm can work 15:18:55 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html Ralph 15:19:03 DanielWeck has left #pwg 15:19:30 zakim, bye 15:19:30 leaving. As of this point the attendees have been liisa, JunGamo, Gregg_Kellogg, bobbytung, Ralph_Swick, DanielWeck, JuanCorona, gkellogg, josh, ReinaldoFerraz, Vlad_, wolfgang, 15:19:30 Zakim has left #pwg 15:19:33 ... Karen_Myers, Leonard_Rosenthol, Cristina_Mussinelli, dauwhe, Guillaume_Sire(observer), laurentlemeur 15:19:38 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html Ralph 15:20:35 rrsagent, draft minutes 15:20:35 I have made the request to generate https://www.w3.org/2018/10/22-pwg-minutes.html ivan