12:49:52 RRSAgent has joined #pwg 12:49:52 logging to https://www.w3.org/2018/05/30-pwg-irc 12:49:53 rrsagent, set log public 12:49:53 Meeting: Publishing Working Group F2F, Day 1 12:49:53 Chair: Tzviya, Garth 12:49:53 Date: 2018-05-30 12:49:53 Regrets+ 12:49:53 Agenda: https://tinyurl.com/y9g4fgat 12:49:53 ivan has changed the topic to: Meeting Agenda 2018-05-30: https://tinyurl.com/y9g4fgat 12:49:59 present+ 12:50:58 present+ 12:51:06 present+ dauwhe 12:52:20 RickJ has joined #pwg 12:52:31 present+ RickJ 12:52:55 josh has joined #pwg 12:53:32 duga has joined #pwg 12:53:43 present+ 12:53:45 For anyone remote, we are still working out room stuff 13:00:30 Deborah!!! <3 13:03:32 dauwhe has joined #pwg 13:04:36 RickJ has joined #pwg 13:05:28 ivan has joined #pwg 13:07:56 garth has joined #pwg 13:08:07 josh has joined #pwg 13:08:23 scribenick: dauwhe 13:08:25 present+ 13:08:25 present+ 13:08:26 present+ 13:08:32 present+ 13:08:34 marisa has joined #pwg 13:08:39 BenWaltersMS has joined #pwg 13:08:39 tzviya: people on the phone, please say hi 13:08:46 present+ 13:08:49 laudrain has joined #pwg 13:08:50 present+ 13:09:01 Phone introductions! 13:09:02 Jean_Kaplansky: I'm Jean Kaplansky, now I work for DQ (???) 13:09:13 ... I'm interested in a11y and web publishing 13:09:14 s/DQ/Deque 13:09:29 rdeltour_ has joined #pwg 13:09:30 laurent: I'm Laurent Le Meur from EDRLab 13:09:32 wendyreid has joined #pwg 13:09:37 ReinaldoFerraz has joined #pwg 13:09:52 ???: from voyager japan 13:09:57 q? 13:09:59 ???: from Japan 13:10:11 toshiaki koike ,voyger japan 13:10:20 Thanks, Tzviya. Yes. Deque Systems, Inc. 13:10:21 Jun Gamo and Toshiaki Koike from Voyager Japan 13:10:23 Rick Johnson, VitalSource 13:10:24 s/voyger/voyager/ 13:10:25 present+ Garth 13:10:31 clapierre has joined #pwg 13:10:32 Garth Conboy, Google 13:10:34 George has joined #pwg 13:10:40 Tzviya Siegman, Wiley 13:10:43 present+ JunGamo 13:10:47 Dave Cramer, Hachette 13:10:49 IVAN <3 13:10:57 laurentlemeur has joined #pwg 13:10:59 DavidWood has joined #pwg 13:11:03 Ben Walters from Microsoft 13:11:10 David Wood, ConsenSys 13:11:14 present+ laurent 13:11:22 present+ DavidWood , BenWaltersMS 13:11:25 present+ Charles_LaPierre 13:11:30 present+ avneesh 13:11:34 Marisa DeMeglio, DAISY Consortium 13:11:35 present+ george 13:11:39 From EDRLab, the European Digital Reading Lab 13:11:39 s/IVAN <3/ 13:11:42 present+ Luc Audrain, Hachette Livre 13:11:47 https://rakuten.webex.com/join/wendy.reidrakuten.com 13:11:51 present+ marisa, rachel 13:11:55 Rachel Comerford, Macmillan Learning 13:11:56 Brady Duga, Google 13:11:58 present+ wendyreid 13:11:58 +present ReinaldoFerraz 13:12:02 Thanks jean! 13:12:03 webex https://rakuten.webex.com/join/wendy.reidrakuten.com 13:12:04 zakim, who is here? 13:12:04 Present: ivan, dkaplan, dauwhe, RickJ, JunGamo, Rachel, tzviya, duga, josh, BenWaltersMS, marisa, Garth, laurent, DavidWood, Charles_LaPierre, avneesh, george, Luc, Audrain, 13:12:04 Wendy Reid, Kobo 13:12:07 Avneesh has joined #pwg 13:12:07 ... Hachette, Livre, wendyreid 13:12:07 On IRC I see DavidWood, laurentlemeur, George, clapierre, ReinaldoFerraz, wendyreid, rdeltour_, laudrain, BenWaltersMS, marisa, josh, garth, ivan, RickJ, dauwhe, duga, RRSAgent, 13:12:07 ... Zakim, Jean_Kaplansky, JunGamo, dkaplan3, toshiakikoike, tzviya, github-bot, Rachel, plinss, astearns, jyasskin, bigbluehat 13:12:09 present+ George Kerscher, DAISY and Benetech 13:12:29 present+ bigbluehat 13:12:30 present+ Kroner Guide Dogs for the Blind 13:12:36 Benjamin Young, Wiley 13:12:53 present+ Jean_Kaplansky 13:12:55 david_stroup has joined #pwg 13:13:08 tzviya: we did introductions 13:13:12 ... time for practicalities 13:13:18 Josh Pyle, Wiley (Atypon) 13:14:04 (not minuting minutiae of switching rooms) 13:14:08 present+ Avneesh Singh DAISY Consortium 13:14:20 rdeltour__ has joined #pwg 13:14:30 present+ david_stroup 13:14:43 zheng_xu has joined #pwg 13:14:43 present+ wendyreid 13:14:45 bendugas has joined #pwg 13:14:53 Topic: technical summary 13:14:54 present+ 13:15:00 tzviya: where are we? 13:15:01 it would be more intersting if the webex camera was spotting the attendees, not the windows :-) 13:15:06 ... we have a lot of open issues on WPUB 13:15:06 present+ rdeltour_ 13:15:14 Working on it! 13:15:17 ... our goal is to clean stuff up, so we can get to the next release 13:15:32 s/it would be more intersting if the webex camera was spotting the attendees, not the windows :-)/ 13:15:36 ... we want the spec to be more readable 13:15:45 s/Working on it!/ 13:15:49 ... we want to pull out of the weeds and get to the big picture 13:15:56 ... we need to agree on the direction 13:16:05 thanks 13:16:18 ... we want to formalize infoset and manifest 13:16:32 ... we need to resolve some bigger-picture ideas 13:16:46 ... like WPUB in isolation, the relationship with PWP, and EPUB4 13:16:53 q? 13:16:59 ... hopefully by the end of the meeting we can revise our spec and go to another draft 13:17:25 ivan: I would like to be able to go home in two days with a clear idea on what should be in the manifest in what format 13:17:41 ... we have had too many philosophical discussions over the months 13:17:47 ... and the clock is ticking 13:17:54 tzviya: we don't want to rewrite the charter 13:18:01 present+ 13:18:20 ... we also need to address the use cases and business requirements 13:18:29 ... Josh and Nick have been working on use cases 13:18:40 present+ zheng_xu 13:18:40 ... we have a session tomorrow on affordances and use cases 13:19:01 ... we need to think about who will use this specification 13:19:08 ... and the relationship with EPUB 3.2 13:20:00 ... if we do EPUB 3.2 next month, and EPUB 4 the month after that, it might be confusing to the market 13:20:19 ... there is stuff in EPUB that doesn't fit into the HTML world, like epub:type 13:20:48 marisa has joined #pwg 13:20:59 Topic: epub:type 13:21:04 tzviya: let's have a history lesson 13:21:20 ... epub:type derived from DAISY's Digital Talking Book (DTB) 13:21:25 ... there were terms like chapter 13:21:36 ... EPUB 3 incorporated these terms, to make epub more accessible 13:21:45 ... chapter, abstract, index, frontmater, backmatter 13:21:58 technically, DAISY DTB made books accessible to blind and VI people; DTB is not for all PWD. 13:22:06 ... the idea is that this would make books more accessible 13:22:09 epub:type vocab: https://idpf.github.io/epub-vocabs/structure/ 13:22:14 ... and provide publishers with structural semantics 13:22:20 ... but it didn't really help a11y 13:22:33 ... but assistive tech did not really pick this up 13:22:45 present+ Leonard 13:23:03 ... reading systems do pop-up footnotes based on epub:type 13:23:06 ... but that's about it 13:23:27 ... it helps publishers move from XML to EPUB 13:23:46 pagebreak gets used, in some reading systems, too. 13:23:50 ... every publisher wants to say this is frontmatter or this is a chapter 13:24:07 q? 13:24:10 ... they want to maintain this vocab 13:24:13 q? 13:24:25 dwood: that list you give... 13:24:37 ... these terms didn't come from DAISY, but from typesetting 13:25:04 ... Should these terms move into an e-reading environment? 13:25:35 ... with this lack of update, have there been discussions that these terms don't have value in digital formats? 13:25:48 s/dwood/DavidWood/ 13:25:55 tzviya: the original intent was for a11y 13:26:00 q? 13:26:03 q+ 13:26:18 ... then we joined w3c and we're trying to find out how to make this list useful 13:26:19 leonardr has joined #pwg 13:26:25 https://www.w3.org/TR/dpub-aria-1.0/ 13:26:28 ... so we worked with the ARIA WG to make this useful for AT 13:26:36 ... Matt and I found the most useful terms 13:26:43 ... they went into the DPUB-ARIA vocab 13:26:50 ... they map directly to a11y APIs 13:27:03 ... these are the most widely used 13:27:28 ... and I've asked what people wanted to add to the list, and there haven't been too many requests 13:27:36 ack lu 13:27:38 q+ 13:27:40 acl laudrain 13:27:41 laudrain: re: XML and publishing 13:27:53 ... publishers are using XML, but not for that 13:28:04 ... we have XML for cooking or gardening or dictionaries 13:28:14 ... that have semantics for those domains 13:28:19 q+ 13:28:26 ... the XML for epub:type is the "book" structure 13:28:33 ... we need that in EPUB 3 13:28:46 ... we need to use the EPUB 3 as an asset and not just a publication 13:28:49 Avneesh_ has joined #pwg 13:28:54 ... we can chunk an EPUB per chapter, for example 13:29:20 ... and you need the front matter to go with the chapter, so you need to know what all these things are 13:29:45 ... when we moved to EPUB3 at HL, we asked all our suppliers to use epub:type, so we can retrieve the book structure 13:30:03 q? 13:30:09 ack laudrain 13:30:09 ... it happens now that when we implemented ACE, the epub:type allowed us to easily implement the aria roles 13:30:16 ... so I'm glad we used epub:type 13:30:33 ... I hope that in WP we keep this mechanism, the structural description of the publication 13:30:41 q? 13:30:42 ... HTML5 will not add the book structure types 13:30:49 ... but we need this for our assets 13:30:50 ack George 13:30:55 present+ dkaplan3 13:31:32 George: there's a thing called ???? ???? ???? , an SGML vocab for publishing, which was adapted for HTML, and DAISY's vocab came from there 13:31:40 rkwright has joined #pwg 13:31:48 ... the importance of semantics is not only for a11y 13:31:57 ... but to create meaningful comments 13:32:12 s/???? ???? ????/ISO 12803 13:32:13 ack dkaplan3 13:32:24 ack dkaplan 13:32:31 dkaplan3: re dpub-aria 13:32:38 ... one thing that is still true 13:32:56 ... is that some of the ARIA documents imply that all aria roles should only be used for AT 13:33:15 ... strongly, strongly imply that @role is ONLY for AT 13:33:27 q+ 13:33:36 ... we would need to talk to ARIA about that 13:33:44 tzviya: dkaplan3, you have hit the nail on the head 13:33:47 ... I agree with you 13:33:52 +1 dkaplan3's comments. 13:33:54 ... based on my recent knowledge of ARIA 13:34:03 ... adding more roles increases confusion 13:34:08 ... and they won't add more roles 13:34:12 rdeltour has joined #pwg 13:34:15 ... or change their documentation 13:34:19 q+ 13:34:33 q+ 13:34:38 ... default semantics are often sufficient, and you risk overwriting default semantics 13:34:46 q+ 13:34:54 ... so aside role=chapter gets messy, and is often unintentional 13:35:04 AAP DTD ISO 12083 was created in the 80s. The first HTML elements were extracted from this DTD. Also, DAISY used the AAP DTD for the small vocabulary used in the DTD. Later Ansi/NISO z39.98 defined a vocabulary and the epub-type terms came from that work, i.e. Z39.98. 13:35:06 ... 1. what are our options for epub:type 13:35:30 ... 2. what do we need as standard? Is this a workflow thing? or a standard thing? a best practice? 13:35:44 ... 3. If we talk about standardizing, what are our options 13:35:46 ack leonardr 13:35:48 ack leonardr 13:36:01 leonardr: the ARIA group is not clear on what they're doing with @role 13:36:29 ... MS is talking about using commenting, the annotations into the content itself 13:36:37 ... they're using ARIA in a similar way 13:36:45 ... there's a need to enhance HTML semantics 13:36:50 ... but no one has a good way to do it 13:36:51 q+ 13:36:55 ... maybe our group should do that 13:37:10 tzviya: I've talked to anno people; they've nixed the idea of using role 13:37:28 ack laurentlemeur 13:37:30 ... if we proposed DPUB-ARIA today, it would be shot down in two minutes 13:37:34 present+ 13:37:49 laurentlemeur: if we try to use aria, we have conflict between semantics and a11y 13:37:59 ... we could use microdata 13:38:13 q+ 13:38:17 laurentlemeur: ++, with conflicts between semantics and aria 13:38:21 ... specific html atttributes 13:38:21 ack ivan 13:38:22 ack ivan 13:38:36 ivan: the alternatives we have from a technical point of view... 13:38:48 .. in html it is in theory possible to define another attribute 13:38:54 q+ 13:39:04 ... any HTLM parser would parse it, it would end up in the DOM, but the HTML would not be valid 13:39:11 s/HTLM/HTML 13:39:14 ... but we have extended HTML with new attributes 13:39:21 https://w3c.github.io/html-extensions/ 13:39:28 ... ARIA is one of those, there is another one for controlling translations 13:39:29 q? 13:39:38 ... I've started asking the team about how it might be done 13:39:47 q+ 13:39:54 ... we have to define an attribute, what are the possible values, and we have write conformance statements 13:40:02 ... on which elements are the attributes usable, etc 13:40:09 ... this is a possible route ahead 13:40:26 ...the question is, do we really need it 13:40:30 ... what are the usages today 13:40:39 ... which are not covered by DPUB-ARIA today 13:40:45 ... it's usable today 13:41:01 ... are there values that are not in DPUB-ARIA? THey will never be in DPUB-ARIA. 13:41:10 ... then we have to define a new attribute, with all that work 13:41:18 ack rdeltour 13:41:19 q? 13:41:29 romain: what's the use case? 13:41:29 q+ 13:41:35 ... we keep mentioning ARIA 13:41:39 ... aria is used for a11y 13:41:49 romain++ 13:41:58 ... aria doesn't need new stuff 13:42:12 ... I don't feel like there use cases for the readability of the publications 13:42:13 q+ 13:42:16 +1 13:42:22 ... there might be special affordances based on epub:type 13:42:36 + to affordances first 13:42:42 ... the primary use case for such a beast is a workflow one, to help with produciton 13:42:45 ack bigbluehat 13:42:50 ... I think it's orthogonal to what we're doing 13:43:14 bigbluehat: epub:type is partly data semantics, which is workflow 13:43:28 ... and partly interaction semantics, like footnotes--something happens experientially 13:43:39 q? 13:43:43 q? 13:43:45 ... and then look at tools 13:43:58 ... we might not want to map those different things into the same attribute 13:44:18 ... or there might be other tools for data semantics, like RDFa or microformats 13:44:30 q- 13:44:33 tzviya: the 2 questions 13:44:37 cmaden2 has joined #pwg 13:44:39 ... 1. how is epub-type used today 13:44:46 ... 2. what solutions are available 13:44:56 ack josh 13:44:56 ack josh 13:44:57 josh: I was mostly going to complain :) 13:45:03 ... looking at an epub right now 13:45:19 q+ to warn that implementation of interaction semantics have social consequences 13:45:19 ... I have doc-abstract, a zillion things that are tagged at least three ways 13:45:34 ... we shouldn't keep piling stuff into aria 13:45:42 q? 13:45:43 ... structural semantics are not necessarily a11y 13:45:49 ... what we're doing is bigger than WP 13:46:11 ... as I look at this HTML, it has epub:type everywhere, now I have an epub namespace in a WP 13:46:18 ... that's a problem 13:46:34 q? 13:46:42 ... it's weird to have epub tagging in something that might not be epub 13:47:01 tzviya: Luc gave an example of how epub:type is valuable to Hachette, separate from a11y 13:47:10 do we have that mapping of what exists in epub type and not in others? 13:47:25 ... at wiley we use data-* 13:47:39 garth: if wiley needs to use hachette's data, then we might need to do something 13:47:40 q+ 13:47:58 laudrain: I think semantics are more than workflow 13:48:20 garth: what we have from epub:type into aria is sufficient? 13:48:28 ack zheng_xu 13:48:34 q+ 13:48:38 very rough slides of options in HTML for expressing various epub:type-s https://usercontent.irccloud-cdn.com/file/ZS6lycM6/epub-type-alternatives-in-html.pptx 13:48:47 zheng_xu: we we use epub:type to improve the view, like footnote 13:48:54 q- 13:48:56 ... the semantic info for epub: type is necessary 13:49:14 ... we want avoid different types of semantic info from different publishers 13:49:31 ... but it might not need to be epub:type 13:49:40 josh: you can use dpub-aria 13:49:48 laudrain: it's not sufficient 13:50:01 duga: other than footnote, what do you use it for 13:50:07 zheng_xu: I'll find out later 13:50:29 RickJ: we see lots of it and ignore everything but page-breaks 13:50:37 ... there's no other way of getting info 13:50:42 tzviya: that's in aria 13:50:48 ivan: I want to hear a use case that 13:50:54 ... 's not in dpub-aria 13:50:57 laudrain: bodymatter 13:51:12 tzviya: it can be useful because kindle uses it in the deprecated guide 13:51:30 q? 13:51:38 ack RickJ 13:51:40 ack RickJ 13:51:48 ack dkaplan 13:51:55 dkaplan3: I have a mild issue with saying these things 13:52:13 ... I was going to bring up pagebreak, it's in aria but RSs use it 13:52:19 ... there are 3 use cases 13:52:30 q? 13:52:32 ... what is a production thing that someone uses in-house 13:52:36 q+ 13:52:38 ... and what is a11y semantics 13:52:44 +100 13:52:50 ... jamming them all together causes problems 13:53:25 ... putting semantics in aria roles has a bad affect on AT users 13:53:40 ... which is orthogonal to the queation of how much the vocabs overlap 13:53:53 s/queation/question 13:53:54 q? 13:54:03 ack Avneesh 13:54:04 q+ 13:54:05 ... it's important to realize that there's a reason to keep some of these things sepearate from AT 13:54:15 Avneesh: re: history, lots were in DAISY specs 13:54:31 * 13:54:32 q+ 13:54:39 ... we need to evaluate what can be used by screen readers 13:54:46 ... I'm ok with keeping aria the same 13:54:55 ... we want to implement epub:type in screen readers 13:55:13 ... when we talk about different vocabs from different publishers that worries me 13:55:17 ... we should be collaborative 13:55:27 ... if we come up with new universal semantics 13:55:33 ... then we can map it to aria roles 13:55:45 ... having a definite list of semantics is important 13:55:51 q+ 13:56:01 tzviya: we have five minutes and a queue 13:56:21 ... a11y aside, this is important, but once we have this is that we can map it to a11y 13:56:24 +1 13:56:26 ack George 13:56:31 George: having a common vocab is important 13:56:47 ... when publishers talk to authors, they need words that aren't in html like glossary 13:57:00 ... when a publisher talk to vendor, you need a common understanding of words 13:57:05 ... or when I'm teaching 13:57:13 ... I think it has value across domains 13:57:13 ack ivan 13:57:20 q- 13:57:22 ivan: i'm trying to see the way forward 13:58:02 ... tzviya and I, we have to find out what are the official ways to add new attribute to html whose values we partially control 13:58:34 This also parallels to personalization and we are struggling with this same problem. 13:58:34 ... we must have an attribute in html that expresses the "role" of the element without using @role, which was taken by a11y 13:58:47 no bikeshedding +1 :D 13:58:50 ... we might need to work with other groups 13:58:59 q? 13:59:14 ... there is a personalizatioin group that's also looking at new attributes 13:59:23 ... we should work with them 13:59:29 s/personalizatioin/personalization 13:59:55 bigbluehat: I posted slides on options 14:00:23 tzviya: ideas like webcomponents 14:00:35 bigbluehat: role= is in the list, itemtype and typeof, etc 14:00:38 BTW I am co-facilitator of the Personalization ARIA (soon to be APA) Task Force. 14:00:45 ... none of them define interaction semantics 14:01:04 ... but using them with a defined vocab could map into the workflow use cases, or stating what's a chapter 14:01:20 (describing slides) 14:01:40 https://usercontent.irccloud-cdn.com/file/ZS6lycM6/epub-type-alternatives-in-html.pptx 14:02:23 bigbluehat: (continues to describe slides) 14:02:33 q+ 14:05:32 q? 14:05:40 ack zheng_xu 14:05:48 tzviya: let's finish the queue 14:05:57 zheng_xu: we use toc, toc, and landmarks and cover 14:06:05 ack garth 14:06:05 q+ 14:06:15 garth: listening to deborah and then avneesh and george 14:06:19 q? 14:06:23 ... we don't want to screw up a11y with @role 14:06:39 ... and having common vocabs, so Ivan's proposal for figuring out where to put that stuff... 14:06:50 Karen has joined #pwg 14:06:57 @bigbluehat something really missing in your study = https://www.w3.org/TR/microdata/ 14:07:14 ... what I'm missing, I haven't heard of something that isn't in ARIA, is used in EPUB:type today, and isn't a workflow thing 14:07:25 laurentlemeur: slide 3; `itemtype` is Microdata 14:07:36 @bigbluehat, sorry I just spotted it ... 14:07:44 ivan: I would hate to use RDFa or microdata, because it's complicated 14:08:04 ack ivan 14:08:05 ... as a co-author of RDFa I can say that :) 14:08:22 ... if we need it, the only solution is to add one single attribute whose values we define 14:08:31 but itemtype should better be a URI in your sample 14:08:33 q+ 14:08:34 josh: or we can continue to use a namespace 14:08:52 ivan: namespaces in html5 are dead 14:08:57 ack david_stroup 14:09:34 david_stroup: I agree that the first question to be answered is what isn't already supported 14:09:42 q+ 14:09:45 ... if the use cases matches what already exists, we don't need anything 14:09:53 (long live namespaces... lots of publishers will need hand-holding to let go...) 14:09:57 ... so far all our exampoles have been internal to the content 14:10:08 ... the toc and reading order and such can be external data about the content 14:10:14 ... its context-sensitive 14:10:15 ... I 14:10:27 ... 'd want to loook at something external. Do we have a use case? 14:10:30 ack bigbluehat 14:10:38 q+ 14:10:42 bigbluehat: 1. we need to get back to affordances, and what we want out of the list 14:10:45 q? 14:11:03 zakim, close the queue 14:11:03 ok, tzviya, the speaker queue is closed 14:11:04 q? 14:11:05 ... 2. and what we expect to happen when the user does something 14:11:23 ... RDFa and microdata are defined for smalll bits, so they are conceptually different 14:11:25 q? 14:11:41 ack Avneesh 14:12:03 Avneesh: Is this someting in the charter? Do we need to deliver? We've discussed for two months, without having a solid addition 14:12:11 ... Luc proposed a few things 14:12:20 tzviya: only if we had a use case 14:12:26 ack DavidWood 14:12:32 garth: LET'S FIND problem before solution 14:12:45 DavidWood: I'm worried about a spot solution 14:12:53 ... it locks us into the affordance discussion 14:13:09 ... and it allows us to create a situation where vendors know what they're building and don't know about the future 14:13:24 ... RDFa is general purpose, and can deal with the future 14:13:29 ... we should be cautious 14:13:39 tzviya: no one is preventing you from using RDFa 14:13:47 ... we're just not making a custom vocabulary 14:13:52 ... we do that at Wiley 14:14:04 DavidWood: how will you encourage reading systems to make use of it 14:14:18 tzviya: I don't care about reading systems, I'm on the web 14:14:22 Readers = web browsers 14:14:26 Avneesh: I have the same question 14:14:32 ivan: how do we close this session? 14:14:52 tzviya: consensus is that the only use cases for terms not in DPUB-ARIA are internal workflow 14:15:08 ... as deborah has pointed out, it's bad to use aria for non-a11y use cases 14:15:29 +1 education on using ARIA correctly. 14:15:31 ... so options are new attribute to stay away from aria, or teaching people to be careful with @role 14:15:44 garth: the most common use case for UI is noteref/footnote 14:15:53 wendyreid has joined #pwg 14:16:01 ... does anyone think that's wrong to move that set of actions from epub:type to @role 14:16:13 tzviya: if you're assinging the role to the correct elements its not wrong 14:17:12 (detailed discussion of dpub-aria note tagging) 14:17:37 tzviya: doc-footnote has the same semantics as sections 14:17:58 ... if people are assuming footnotes should be list, it will overwrite that semantic 14:18:08 garth: is our most common case broken from aria perspective 14:18:11 tzviya: I don't know 14:19:08 tzviya: someone open an issue in DPUB-ARIA github, let's make sure that footnote tagging doesn't break a11y 14:19:15 ditto dauwhe 14:19:19 ... Garth, can you do that? 14:19:40 RickJ: the key is, if I'm not doing a11y, ignore aria 14:19:50 https://github.com/w3c/dpub-aria/issues 14:20:16 tzviya: it's easy to break stuff if you use aria incorrectly 14:24:02 garth has joined #pwg 14:24:06 clapierre has joined #pwg 14:27:45 dauwhe has joined #pwg 14:28:53 ivan has joined #pwg 14:29:33 marisa has joined #pwg 14:29:52 dauwhe has joined #pwg 14:30:29 Avneesh has joined #pwg 14:30:30 laudrain has joined #pwg 14:30:44 RickJ has joined #pwg 14:30:48 duga has joined #pwg 14:31:12 leonardr has joined #pwg 14:32:42 rdeltour has joined #pwg 14:33:57 rdeltour_ has joined #pwg 14:34:33 @dkaplan3 - that's how we see it too :) 14:39:16 scribenick: Rachel 14:39:24 Topic: Infoset 14:39:41 ReinaldoFerraz has joined #pwg 14:39:50 George has joined #pwg 14:39:58 tzviya: the infoset is a hot topic that leads us down many rabbitholes 14:40:10 ...we are going to attempt to finalize the infoset before lunch 14:40:44 ...we need to resolve some issues, make the spec more precise, the infoset does not (or does it??) need to include everything 14:40:55 ...we can start by going through some github issues 14:41:36 ...luc had looked over our existing infoset and let us know nothing is missing 14:42:02 laudrain: We should have the simplest infoset possible 14:42:16 ...it should be possible to have a web publication starting from the webpage 14:42:23 Requested DPUB-ARIA issue: https://github.com/w3c/dpub-aria/issues/13 14:42:29 ...we had long discussion around things like, does it need a title 14:43:02 ...I found the current requirements very short, but enough for the web publicatio and certainly for epub4 in the future 14:43:20 ...if we would compare what e have today in epub3, this infoset is too short 14:43:27 ...there a gap analysis that I did 14:43:32 dauwhe has joined #pwg 14:43:50 zakim, open the queue 14:43:50 ok, tzviya, the speaker queue is open 14:43:54 ...I don't know if we need to add the full infoset 14:44:08 BenWaltersMS has joined #pwg 14:44:10 tzviya: thoughts? 14:44:30 ivan: we have to start somewhere. At some point in time we will begin to map this into clear serialization. 14:44:47 ...the bulk of the serialization wil be in json which is inherently extensive 14:44:51 q+ 14:45:04 ...we should being this work of mapping and then new items may come up 14:45:14 q+ 14:45:28 https://w3c.github.io/wpub/#infoset 14:45:34 ...we can always see if we need additional things but I believe we are at the point that we are ready to get dirty 14:45:52 ...bigbluehat breakdown (issue 197) was helpful 14:45:55 josh has joined #pwg 14:46:09 bigbluehat: Matt has put this in the draft 14:46:42 ack leonardr 14:46:44 https://github.com/dauwhe/html-first/wiki/WPUB-examples#1-minimal-wpub-based-on-todays-spec 14:46:56 leonardr: I looked over the current draft. I think it's a good set of material, well defined. And we have an extensibility mechansim which gives us a good foundation to start from 14:47:04 ack RickJ 14:47:43 RickJ: I've not been involved in a lot of the conversation around infoset. Everything I read is around markup except for privacy 14:47:50 q+ 14:47:55 ....how can we expect the system to know this 14:48:01 zheng_xu has joined #pwg 14:48:16 ivan: the only thing we say re privacy policy is that there should be one and it should be linked from the infoset 14:48:27 ack leonardr 14:48:30 RickJ: we are clearly defining the markup - what is the privacy policy for 14:48:52 leonardr: that is if you have a publication that is declaritive 14:48:54 q+ 14:48:57 q+ 14:49:08 RickJ: we need to make clear what the privacy is for 14:49:16 ack duga 14:49:21 tzviya: let's open a ticket to clarify this language 14:49:51 RickJ will open a ticket re: clarifying language 14:49:56 ack bigbluehat 14:50:22 q+ 14:50:23 q+ 14:50:31 bigbluehat: I'd love for us to ring out what we're affording in these things (including privacy policy which the reading system may not know what to do with) 14:50:43 q? 14:50:46 ....are we saying this because it has an effect on manifest etc 14:50:56 ...how does this spill out experientially 14:51:44 DavidWood has joined #pwg 14:52:39 q+ 14:52:43 tzviya: we have to clarify the effect on the user and the system 14:52:45 ack BenWaltersMS 14:52:50 q+ 14:52:59 BenWaltersMS: of all the infoset, privacy concerns the most... 14:53:00 if we don't explain what we're affording for with the stuff we're expressing, then we're missing the point of expressing them at all 14:53:04 my (first!) issue on the privacy policy info set https://github.com/w3c/wpub/issues/203 14:54:06 BenWaltersMS: my big concerns are 1. compatibility wuth the web today 14:54:30 2. there's not one privacy policy or one way to interact with privacy 14:54:49 q? 14:55:08 ...are we enforcing that everyone interact with privacy policies? that they all click yes on them? are we requiring that everyone follow the same policy 14:55:36 tzviya: privacy seems like a publisher specific thing 14:55:44 Privacy Policy was added via PR #95 https://github.com/w3c/wpub/pull/95 14:56:05 garth: I'm with ben - the farthest we could go with this is that you may put a privacy policy in, and Reading Systems may interact with it 14:56:06 q? 14:56:09 q- 14:56:15 ack dauwhe 14:56:25 dauwhe: websites can do privacy policies, most of them do 14:56:29 q+ 14:56:33 ...often with a footer that repeats 14:56:44 q+ 14:56:44 q? 14:56:49 ...how do we define things that apply to the publication as a whole 14:56:58 +1 14:57:01 ack leonardr 14:57:09 q+ 14:57:13 ack ivan 14:57:15 q+ 14:57:39 https://github.com/w3c/wpub/issues/204 - calling out UA items 14:57:48 ivan: I propse to remove privacy from infoset 14:57:50 david_stroup has joined #pwg 14:58:21 laudrain: we do not do any privacy policies within epub but we have contracts with distributors that say how the epub can be used 14:58:28 ...we do have privacy policies 14:58:38 ...we have applications which are programmtic 14:58:44 ...they include privacy policies 14:59:02 q+ 14:59:04 ...there is a question of privacy, usage, and the data that is collected 14:59:54 q+ 15:00:18 ivan: we agreed that this is the minimal basic infoset 15:00:25 ... not that this is the complete one 15:00:38 ...we acknowledge that additional ones mat come in 15:00:59 ...the manifest, the seriaization of the infoset, is based on schema.org struture in json 15:01:02 s/mat/might 15:01:29 ... I agree with everything you said but we need to decide if this is part of the basic content of the infoset 15:01:30 ack DavidWood 15:02:11 DavidWood: of all the affordances that we;ve discussed, privacy is the key ddifferenec between webpage and epub. it's more iportant than page break. 15:03:02 ...There are lots of good reasons to sweep this under the rug and good reasons to not to 15:03:07 +1 15:03:23 ...it is the difference between a society where we have the expection of privacy when reading a book 15:04:04 ...if we do the convenient thing by treating privacy as a legal requirement or vendor requirement, we risk being complicit in a shift in the social experience of reading 15:04:15 ack duga 15:04:15 tzviya: I don't think we can solve that with a privacy policy 15:04:17 q+ 15:05:00 Hadrien has joined #pwg 15:05:07 duga: I think that's an important point - privacy is important. I don't know that we can hit the requirements necessary to address that in this spec 15:05:11 present+ 15:05:36 q? 15:05:45 ...the interaction of privacy policies make it impossible for us to specify this 15:05:59 DavidWood: we should at least make a philosophical stance 15:06:11 ...we expect privacy even if it is not provided 15:06:13 /me @Hadrien https://rakuten.webex.com/join/wendy.reidrakuten.com 15:06:44 DavidWood: I have an outstanding action to approach this in a ticket 15:06:46 q? 15:06:59 ack laudrain 15:07:10 laudrain: 15:07:13 ack RickJ 15:07:29 RickJ: I am the privacy officer for our company and implemented GDPR 15:07:52 ...we're conflating a concern we have with privacy and privacy policy determined by jurisdiction 15:08:22 ...we need to separate privacy policy, rather than privacy 15:08:23 q? 15:08:43 q- 15:08:50 tzviya: RickJ and DavidWood will be our privacy task force 15:09:29 q? 15:09:34 ...please clarify to our group what we can and cannot do 15:09:53 q+ 15:10:00 ivan: 3.3.9 doesn't cover what RickJ and DavidWood are talking about 15:10:03 q? 15:10:48 DavidWood: in relation to gdpr and I go to a website and the website collects info from me they have to tell me what they're collecting, allow the right to be forgetten, etc 15:11:01 ...if we put books on the web anyone that reads a book 15:11:12 ...even on an ereader rather than a traditional browser 15:11:17 ...the requirements apply 15:11:32 q? 15:11:33 ivan: what should I, as an author put on the webpage 15:11:50 q+ 15:11:54 ack bigbluehat 15:12:10 bigbluehat: it's recommended that it be in html - why isn't this just content in the publication 15:12:17 q+ 15:12:47 ...if your jurisdiction mrequires it, why not just add it to the content itself and as a publisher, you ccan express the requirements/concerns to the users of your content 15:12:54 ack duga 15:13:18 duga: I hear the question of what do you want done - privacy policy: is it in the infoset or not 15:13:34 ...we have to put privacy somewhere according to w3c policy 15:13:59 ack DavidWood 15:13:59 ... it's seems that we can't put enough requirements around this in order to put this in the infoset 15:14:30 DavidWood: I think part of the reason that we disagree is that we are talking about publications as if they are just content - i take a book, make it into html, and then make an epub3 15:14:44 ...therefore the publisher of the content doesn't have anything to say about proivacy 15:15:07 ...that may not be right, because if we allow js to be a part of that package we are in a different environmnet 15:15:24 ...ow we have privacy, legislation, and regulation from multiple parties 15:15:39 ... there has to be SOME mechansim if we are going to allow js in the packages 15:15:51 tzviya: is it required in the default infoset 15:16:08 DavidWood: are we ready to say it's not supposed to be in the infoset? 15:16:25 leonardr: it's currently recommended - you CAN put it in the infoset, but you don't have to 15:16:31 q? 15:16:35 tzviya: in the default metadata set does this belong? 15:16:49 ...many of us are saying it does not belong 15:16:52 ack Hadrien 15:17:06 ...we have other items we must discuss 15:17:21 q+ 15:17:27 I can hear him perfectly 15:19:21 I think that we need to be careful for infoset/metadata that are not default 15:19:31 they're very likely to be ignored by most reading systems 15:19:43 q? 15:19:50 q+ 15:19:57 for the privacy policy, there's already a rel value in the IANA link registry 15:20:08 why can't we simply use that? 15:20:17 bendugas has joined #pwg 15:20:19 there's no need to do a lot more than point to a privacy policy 15:20:28 +1 15:20:33 +1 15:20:34 +1 15:20:38 +1 15:20:42 +1 15:20:44 q+ 15:20:45 +1 15:21:04 q- 15:21:14 Someone gave Tzviya a gavel!?! 15:21:17 scribenic: Garth 15:21:18 https://tools.ietf.org/html/rfc6903 has all the goods 15:21:20 q- 15:21:24 BenWaltersMS: it's there but not used by anyone 15:21:35 +0 only because I'm uncertain of the consequences 15:21:37 tzviya: can you fix that? 15:21:38 q+ 15:22:12 BenWaltersMS: to convince edge to do something like this means convincing the other browsers which means there has to be a major user need 15:22:14 ack dauwhe 15:22:22 Ben: unclear anybody uses said IANA privacy link 15:22:25 ...it hasn't happened yet, which means it's unlikely 15:22:56 ack bigbluehat 15:23:01 dauwhe: we have needs that are so specific that it requires a brand new data structure - why can we not just put this in html 15:23:13 +1 dauwhe 15:23:54 bigbluehat: its not clear to people who write links that they need to do this - we need to define the affordance before they stick it in there 15:26:05 tzviya: we need a proposal for how to include privacy policy within the publication 15:26:24 Karen has joined #pwg 15:27:20 garth: if we can't mandate the reading of thepolicy, it belongs in the content. if the publisher cares - they'll include 15:27:33 bigbluehat: until the time the reading system can recognize it 15:28:09 Suptopic: list of resources 15:28:12 https://github.com/w3c/wpub/issues/198 15:28:17 github: https://github.com/w3c/wpub/issues/198 15:28:26 https://github.com/w3c/wpub/issues/198 15:29:03 garth: this was raised by Ben - we are in agreement a default reading order as part of the infoset 15:29:18 ...this issue is around what other resources may/must/should be included in the infoset 15:29:38 ..the reason for includingother resources is to show the bounds of the publication 15:29:56 ...for search, offlining, packaging and other affordances of the publication 15:30:27 ...end notes and footnotes are an example of the break from the linearpathway 15:30:50 ...there may be things in the publication that are not in the default reading order that can't be sussed out 15:31:03 ... ie images referenced as top level, CSS probably 15:31:03 q? 15:31:09 q+ 15:31:13 q+ 15:31:16 ... what is required to be in this other list of resources 15:31:24 ...reading systems may want exhaustive 15:31:53 ...other perspectives say that the web changes costantly, how can it be exhaustive 15:32:16 q? 15:32:20 q+ 15:33:04 leonardr: I don't think we need to mandate anything in this list but we should say "if these resources are important to your publication in XYZ use cases, then they must be here" 15:33:19 ack leonardr 15:33:19 ...having a specific list doesn't buy us anything 15:33:22 ack dauwhe 15:33:34 q+ 15:33:40 q+ 15:33:40 dauwhe: it's a burden on the author to enumerate every single list 15:33:49 q+ 15:33:55 ...that kind of thing doesn't happen on the web in general 15:33:59 +1 dauwhe 15:34:02 q? 15:34:24 q+ 15:34:39 q+ 15:34:43 garth: I agree with that and I've come to the perspective that by the time we package this the resource list is exhaustive 15:34:43 ack BenWaltersMS 15:34:46 ack BenWaltersMS 15:34:53 q+ 15:34:57 +1 dauwhe 15:35:02 BenWaltersMS: I agree with everyone. I don't like a partial list that's confusing and so not used. 15:35:59 ...if I'm a tool that wants to take web pub offline, how do I know which elements should be? 15:36:01 q? 15:36:09 ...images? videos? etc 15:36:29 ...how is that decision delineated? 15:36:36 ...we need to avid a halfway decision 15:36:38 ack ivan 15:36:39 ack ivan 15:37:18 ivan: if we have the reading order which are html files mostly, any image or CSS files referred from that reading order are automatically a part of the infoset items 15:37:25 ... we have to be precise about htat 15:37:48 q+ 15:38:03 ...we probably don't want to extend that to videos which are dangerous thing 15:38:22 q? 15:38:23 ... any resource that the author wants to be a part of the publication needs to be included 15:38:28 ...like datasets 15:38:32 q+ 15:38:49 q+ 15:38:59 ...I would feel fine with images, CSS... js is tricky 15:39:05 ack bigbluehat 15:39:26 bigbluehat: rel=external is in the html spec, which can be used on link and anchor tags 15:39:48 q+ 15:39:48 aq? 15:39:57 ...and could be extended to making exceptions to what to grab (ie images outside the publication) 15:41:05 q+ 15:41:08 ...the video tag presents a similiar opportunity - the video and format that I get depends on the venue I am using to view it 15:41:16 ack duga 15:41:16 ack duga 15:41:37 duga: the manifestin epub is somewhat unecessary - it was written before there was a package document. 15:41:49 ...for pwp - it's the stuff that's in the package 15:41:57 ...for the web, it's the stuff that's in the web 15:42:13 ...for an offlinable wp there will be bits that are not findable 15:42:38 ...even the stuff that is findable, the user experience is not great because of the processing need 15:42:42 +1 for what duga is saying 15:42:49 q+ for priority of constituencies 15:42:50 ...it slows down downloads and burns through battery 15:43:00 ack rdeltour 15:43:06 q? 15:43:23 rdeltour: we have to ask ourselves how our publications differe from the web 15:43:34 ...aer we asking how to cache? how to work offline? 15:44:03 ...the author has control how she develops the serviec worker 15:44:17 q? 15:44:38 ack josh 15:44:45 q+ on list is also to be used in other affordances like search 15:44:54 ...we are not clear what the user agent is in the publication. 15:45:40 josh: I am focused on the pub that is not offlinable etc. At some point it may be one of those things. Bt right now, we need to focus on the minimal definition of the WP. 15:45:53 ...if you want a WP - you need these three things 15:46:03 ...making it offlinable? here are the other things 15:46:07 q? 15:46:22 q+ 15:46:25 q? 15:46:29 ...if there is a lot of complication in creating these files 15:46:33 ...no one will do it 15:46:34 ack laudrain 15:47:07 zakim, close the queue 15:47:07 ok, tzviya, the speaker queue is closed 15:47:12 q- 15:47:25 laudrain: will we have badly structured web publications if we do not provide more information about what's required 15:47:56 q? 15:47:59 q? 15:48:02 ...I agree with what josh says 15:48:03 ack leonardr 15:48:27 leonardr: we seem to be coming down to the offline conversation 15:48:35 garth: also search 15:48:47 leonardr: not search - from a technical perspective i disagree 15:49:00 ...caching - maybe, maybe not 15:49:34 ...if this are the use cases, could we treat them as these specific things instead of a special resource list 15:49:37 q? 15:49:45 garth: maybe those use cases can be generalized 15:50:03 leonardr: I don't think we need to establish the bounds of the publication 15:50:18 ...when we take t offline, we need to know what is coming offline 15:50:30 josh: you must be able to search within a publication 15:50:58 garth: the one bullet point is that we have a bounded publication 15:51:05 ack wendyreid 15:51:22 @josh - but it's not clear what that means when you have external references... 15:51:25 +1 to Hadrien 15:51:39 wendyreid: as a user agent/user expereince rep - if we're giving the user the option of offlining 15:51:47 ...we need to give the appropriate information 15:52:01 @hadrian - I think it is entirely on your definition of "bounds"... 15:52:04 ...want to download this? You're getting 50 gigs of video. Still want it? 15:52:23 ack BenWaltersMS 15:52:24 ack BenWaltersMS 15:52:36 ...we need the info to be presentable and the user agent and user should have ptions around them 15:52:53 BenWaltersMS: is search needed outside the default reading order? is that a requirement? 15:53:00 q? 15:53:27 ack RickJ 15:53:31 garth: right now in epub you search the whole thing - is it important to include include nonlinear content in the search 15:53:35 ack RickJ 15:53:54 RickJ: it seems that when we talk about offline, we talk about packaging as a part of offlining 15:54:01 ...it needs to be separate 15:54:13 q? 15:54:32 ack dauwhe 15:54:32 dauwhe, you wanted to discuss priority of constituencies 15:54:49 dauwhe: conclusions - the exhaustive list of resurces is optional 15:55:03 ...there are circumatances where it is not needed 15:55:18 ...the spec will not stop people from exhaustively listing resources 15:55:36 ...we need to clearly define the boundary of the publication 15:55:37 q? 15:55:50 garth: I think yes 15:56:01 ack ivan 15:56:01 ivan, you wanted to comment on list is also to be used in other affordances like search 15:56:26 ivan: there is a difference between what the web does and a publication 15:56:47 ...if I begin to read a book of 5 chapters and I want it offline, the current web will offline what I read 15:56:58 ...the author has to specify somehow 15:57:21 ...search is one of the affordances that are important 15:57:37 dauwhe has joined #pwg 15:57:48 ...personalization as well (ie I want my book to read in night mode) I want that to apply to all chapters, not one 15:58:34 ...what dauwhe proposes is incomplete because we have to specify what the user agent does in terms of affordances and offlining. 15:58:45 ...there may be an optional list 15:59:11 +1 to defining affordances all the places 15:59:12 ack duga 15:59:40 duga: so we're back where we started - we should have an optional list of resoources with clear instructions about what they should be used for 15:59:58 ...we also need to define default with or without this list 16:00:15 Hadrien: if you don't list something, you can't expect things to work magically 16:00:30 garth: details need to be worked out 16:00:42 ...but it sounds as though there may be concensus 16:01:34 Have fun guys... I'll check in later. 16:01:47 Proposal: There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order. 16:02:08 rdeltour: you and every guy on tinder 16:02:37 s/you and every guy on tinder// 16:02:49 RickJ has joined #pwg 16:03:41 github-bot 16:03:51 github-bot, end topic 16:05:31 is it resources that are not directly referenced or deterministically identifiable 16:05:57 Perhaps a nod toward Ivan’s expansion of Proposal: “Proposal: There is a default reading order. There may be an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order (plus those images and CSS files directly referenced therefrom).” 16:07:57 rdeltour has joined #pwg 16:09:08 I would disagree to that last one garth 16:10:05 16:10:08 there are many many ways you can reference something on the Web, should we automagically include links that get dynamically added to a page using JS for example? 16:10:44 rdeltour_ has joined #pwg 16:10:46 dauwhe: {"break": "lunch"} ;-) 16:13:24 Hadrien: old habits :) 16:16:13 dkaplan3 has joined #pwg 16:35:43 marisa has joined #pwg 16:36:29 laudrain has joined #pwg 16:42:30 ReinaldoFerraz has joined #pwg 16:52:15 George has joined #pwg 16:52:17 I think I'm back... But just for the a11y discussion. I'm booked from 2-5 pm today. 16:54:11 rdeltour has joined #pwg 16:54:34 Jean_Kaplansky has left #pwg 16:55:00 Jean_Kaplansky has joined #pwg 16:55:14 rdeltour_ has joined #pwg 16:55:25 OK. Now I know I'm back. 17:01:13 RickJ has joined #pwg 17:01:18 clapierre has joined #pwg 17:01:18 marisa has joined #pwg 17:01:42 20 of Toronto’s most preposterous, over-the-top piles of poutine https://torontolife.com/food/ridiculist-crazy-poutine-stk-caplanskys-wvrst-poutinis-smokes/ 17:01:58 s/20 of Toronto’s most preposterous, over-the-top piles of poutine https://torontolife.com/food/ridiculist-crazy-poutine-stk-caplanskys-wvrst-poutinis-smokes// 17:02:15 s/I think I'm back... But just for the a11y discussion. I'm booked from 2-5 pm today.// 17:02:18 q? 17:02:24 s/OK. Now I know I'm back.// 17:02:42 zakim, open the queue 17:02:42 ok, tzviya, the speaker queue is open 17:02:45 Zakim, why are we here? 17:02:45 I don't understand your question, dauwhe. 17:02:59 david_stroup has joined #pwg 17:03:11 q+ 17:03:23 Proposal: There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order. 17:03:35 Proposal: There is a default reading order. There may be an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order (plus those images and CSS files directly referenced therefrom). 17:04:09 BenWaltersMS has joined #pwg 17:04:12 q+ 17:04:18 Avneesh has joined #pwg 17:04:44 scribenick josh 17:04:46 garth: George is first on the queue. 17:04:48 scribenick: josh 17:04:52 scribenick: josh 17:05:58 George: If we had a compiled search index on the publication, then the bounds of the search would be that index. 17:06:04 q? 17:06:04 DavidWood has joined #pwg 17:06:09 ack George 17:06:09 ack George 17:06:18 ack George 17:06:32 ack leonardr 17:06:54 bendugas has joined #pwg 17:07:02 leonardr: The problem that I have with Ivan's addition is that it could muddy the waters. 17:07:20 @hadrien - depends on what you are trying to accomplish... 17:07:40 zheng_xu has joined #pwg 17:07:43 q+ 17:07:44 q+ 17:07:45 q+ 17:08:00 ivan: If we keep with Garth's proposal then we don't know what the bounds of the publication are. 17:08:01 s/@hadrien - depends on what you are trying to accomplish...// 17:08:12 q? 17:08:39 duga: The bounds depend on what you're doing. I agree. 17:09:07 q+ 17:09:07 ... the bounds for search could be different than the bounds for offlining 17:09:14 q+ to say the word affordances again 17:09:20 q? 17:09:24 ack leonardr 17:09:27 ack duga 17:09:35 ivan: ... but this would lead to many different ways of defining the bounds. 17:10:07 q? 17:10:10 q? 17:10:18 tzviya: As a user, I would not assume that a giant chunk of Twitter would ever be in bounds. 17:10:19 ack dauwhe 17:11:08 dauwhe: In the case of an inline image, clearly that's in bounds 17:11:18 q+ 17:11:30 ack Hadrien 17:11:32 ... devtools, e.g. know what goes with a publication. 17:11:47 Hadrien: I think that the bounds should be explicit. 17:12:20 ... If different UA determine the bounds differently, then we have a big problem. 17:12:29 garth: 17:12:46 q? 17:12:47 garth: Is that an argument to have an exhaustive list? 17:13:15 q+ 17:13:22 Hadrien: We shouldn't discuss exhaustiveness. 17:13:42 garth: Do you have a proposal? Or does one of mine cover it? 17:13:44 q? 17:13:55 ack bigbluehat 17:13:55 bigbluehat, you wanted to say the word affordances again 17:14:22 bigbluehat: Depending on how we define this, it affords different stuff. 17:14:45 ... we're all bringing our own usage cases 17:14:58 q- 17:15:11 q+ 17:15:12 ...if I have a massive exhaustive list, then I have no choice but to fetch the entire publication. 17:16:02 q? 17:16:12 ...if I have an option, e.g. reading a chapter of a larger textbook, that would be good. 17:16:39 q+ 17:16:42 q? 17:16:48 ack laudrain 17:16:59 ... the HTML that loads the content can make determinations that cannot be made from an exhaustive list. 17:17:47 q? 17:18:11 ack leonardr 17:19:06 leonardr: In my world people are creating custom documents (rather than books or journals) 17:19:26 q+ to clarify that what I said has nothing to do with "connecting two publications" together 17:19:48 ...at some point we will need to deal with understanding resources and boundedness 17:20:14 tzviya: We are trying to solve a specific problem. We need to try to find agreement. 17:20:21 ack George 17:20:21 ack George 17:21:18 George: If we have our reading order and indicate "external" as appropriate, that may suffice. 17:21:28 garth: 17:21:42 q? 17:21:57 q+ 17:22:42 Proposal: There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order. 17:22:46 ivan: I see a fundamental schism in the group... 17:23:01 q? 17:23:36 bigbluehat: Let's read the proposal... 17:23:58 q+ 17:23:59 q+ 17:24:01 q? 17:24:06 ack bigbluehat 17:24:06 bigbluehat, you wanted to clarify that what I said has nothing to do with "connecting two publications" together 17:24:07 ... Ivan you have expressed concern about this... 17:24:34 ivan: The proposal is not specific enough. 17:24:43 Proposal: There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond that default reading order. 17:24:47 q- 17:24:58 ...this gives you an idea of the boundaries, but does not define the boundaries. 17:25:23 ...if someone doesn't include an image in the manifest, then it is not in bounds. 17:25:30 q? 17:25:40 q+ 17:26:03 bigbluehat: There are two approaches.. 17:26:40 https://github.com/w3c/wpub/issues/205 - we need to define the bounds 17:26:47 q- 17:26:53 q+ 17:27:01 ... some all-knowing author created a comprehensive list, or a UA gathered a list dynamically. 17:27:16 q+ 17:27:41 ivan: We are going in circles. 17:28:03 q? 17:28:15 ...I just want a clear specification of what the boundaries are@ 17:28:37 ack dauwhe 17:28:49 tzviya: Let's go back to the queue and try to make a decision. 17:28:58 dauwhe: What do we mean by boundary? 17:29:23 q? 17:29:42 ... The goal should be to preserve a reading experience when within the bounds. 17:30:24 ...From a visual point of view, boundary is less important. 17:30:41 ivan: we are still repeating things. 17:30:42 q? 17:30:51 ack rdeltour 17:32:06 rdeltour: The issue is that we are approaching from the content. Our specs contains too little guidance for the user agents. We should focus on "What must the UA do in the absence of a manifest" 17:32:08 q? 17:32:10 q? 17:32:39 George: I would like the RS to tell me whether the link is leaving the book, for example. 17:33:00 garth: I think that works with either of the proposals that we have. 17:33:06 ack leonardr 17:34:22 leonardr: Following up... I created an issue (205) we never defined what a UA should do. Let's separate the issues. There is consensus on Garth's proposal. Then let's create another in it's own section 17:34:22 q? 17:34:49 ack DavidWood 17:35:05 DavidWood: Leonard is right to raise the issue 17:35:49 q? 17:35:57 ...We can have a defined hard boundary, or we can collapse the boundary when required (e.g. printing, offlining) 17:36:27 timCole has joined #pwg 17:36:45 tzviya: from TPAC, are we wrapping the web in a package or teaching the web to package things? 17:37:33 garth: Closing an issue by opening another is not progress. 17:37:55 q? 17:38:20 DavidWood: This is evidence of fundamental disagreement. 17:39:13 ivan: This will come back and bite us. 17:39:46 q? 17:39:50 q+ 17:40:31 ... taking the search example, does an SVG file within HTML get searched? 17:40:46 ack Hadrien 17:41:24 tzviya: Accept Garth's proposal and add a new section for boundaries. 17:42:00 Hadrien: Not including a resource won't prevent it from being included. 17:43:29 ...We tend to go back and forth between two issues. We should separate "how to create a boundary" from "what does the boundary afford" 17:43:36 I actually said rendered, not included 17:44:04 s/being included/being rendered 17:44:07 Proposal: “There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order." 17:44:29 Proposal: Add section on Boundary determination to spec. 17:44:36 s/I actually said rendered, not included// 17:44:56 +1 17:45:01 Close issue #198; continue on Boundary in #205. 17:45:05 0+ 17:45:10 +1 17:45:15 +1 17:45:28 +1 17:45:35 +1 17:45:38 +1 17:45:40 +1 17:45:41 +1 17:45:41 +1 17:45:42 +1 17:45:43 +1 17:45:44 +1 17:45:46 +1 17:45:50 +1 17:45:51 +1 17:45:53 +1 17:46:01 +1 17:46:02 +1 17:46:16 jbuehler has joined #pwg 17:46:30 q? 17:46:36 +1 17:46:36 +1 17:46:41 +1 17:46:47 +1 17:46:59 rdeltour: I would vote +1 if we agree to define what the UA should do. 17:47:00 +1 17:47:11 +1 17:47:25 Resolved: There is a default reading order. There is an optional list of resources that may be provided to extend the bounds of the publication beyond the default reading order and add section on Boundary determination to spec. 17:47:51 rrsagent, draft minutes 17:47:51 I have made the request to generate https://www.w3.org/2018/05/30-pwg-minutes.html ivan 17:48:38 scribenick: rdeltour 17:48:39 scribenick: rdeltour 17:49:18 Topic: Manifest serialization 17:49:30 tzviya: there open issues around serialization 17:49:44 is there a link to any current proposal? 17:49:46 … do people know what "serialization" means? 17:50:33 … we're talking about the nitty gritty, the vocabulary we're going to use, etc 17:50:40 q+ 17:51:09 george: you're talking about the OPF/metadata-level thing? 17:51:25 tzviya: right, not the content, think about it as OPF-next 17:52:05 ack ivan 17:52:11 ivan: the spec talks about "Descrtiptive properties" vs "structural properties" 17:52:30 … "descriptive properties" is generally what people think about, it's metadata 17:52:44 s/Descrtiptive/descriptive/ 17:53:00 q+ 17:53:17 … last week I looked at the schema.org approach, assuming that we can base our infoset on it as much as possible 17:53:30 ... using JSON-LD, and see how much we can cover 17:53:50 q+ 17:53:56 … several questions there: can we rely on schema.org, can we rely on JSON-LD and not only JSON 17:54:18 q+ to talk about wiley's work with schema.org 17:54:38 ... whatever we think about it, the reality is that on the Web if people want their page to be well indexed they use schema.org 17:55:17 … there was a slight disagreement with Leonard about DC (as used traditionnally in EPUB) and schema.org 17:55:36 ... semantic-wise, there's good mapping between DC to schema.org 17:56:05 … but the migration can be a problem for the EPUB community 17:56:14 q+ 17:56:31 ... when I went through the terms, only 2-3 didn't have conterpart in schema.org 17:57:08 … they are: writing direction (ltr/rtl), reading progression 17:57:27 ... but we have good contact with the people who maintain schema.org, so we can talk with them 17:58:01 q+ 17:58:04 … the other problem I found is about value types 17:58:17 q+ 17:58:27 Schema.org does have a mechanism for community extension: http://schema.org/docs/extension.html 17:58:31 ... for instance if the author name is a string, how can I specify things like writing direction? 17:59:00 … an other issue is about order of multiple values (e.g. author names in a scholarly publication) 17:59:31 q? 17:59:33 ... besides those issues, I feel it's a really good fit 17:59:35 q+ 17:59:37 ack laudrain 17:59:43 ack leonardr 17:59:52 http://schema.org/author can also be a http://schema.org/Organization 18:00:12 leonard: we should first make a decision, regardless on the schema decision, about JSON vs JSON-LD 18:00:25 s/leonard/leonardr/ 18:00:44 q? 18:00:53 … you can serialize schema.org or DC etc in any one of them 18:01:06 ivan: I almost agree 18:01:13 q+ to clarify about JSON vs. JSON-LD 18:01:24 … if we make the choice of going with schema.org, then there's no choice since they require JSON-LD 18:01:41 ack Hadrien 18:01:42 tzviya: I don't think we need to decide yet 18:01:43 q- 18:01:47 ack Hadrien 18:02:17 hadrien: on the Readium side we also created a mapping between our infoset/EPUB (including DC, schema.org) and it worked well 18:02:29 … the ability to have context is important in JSON-LD 18:02:35 q+ 18:02:53 ... in R2 we decided to define a context document that sort of hide some details (names/ns) to make it closer to EPUB 18:03:17 q? 18:03:23 q- 18:03:24 … so we'll have to ask ourselves: do we use terms as-is or do we define our own context document? 18:03:26 JSONLD is a W3C Rec, yes? 18:03:58 ivan: AFAIK, the current handling of schema.org at Google does not handle the context documents 18:04:30 … they're working on it, but today if you're not using the terms the way they define it, even if correct for JSON-LD, it won't work 18:04:35 q? 18:04:41 ... so there's a pragmatic issue here 18:04:42 s/JSONLD is a W3C Rec, yes?// 18:05:06 ack 18:05:07 ack tzviya 18:05:07 tzviya, you wanted to talk about wiley's work with schema.org 18:05:09 ack tzviya 18:05:15 hadrien: right. it's in the list of "cons", and we shouldn't list the pros and cons now, but keep in mind the question 18:05:24 tzviya: we've also done a lot of mapping work 18:05:30 q? 18:05:39 … we'll share that with the group 18:05:50 ... almost of the stuff is mappable 18:06:05 … some of us are familiar with working with schema.org to extend the vocabulary 18:06:27 ... I fully support the schema.org approach 18:06:31 ack DavidWood 18:06:58 davidwood: schema.org does have a mechanism for community extensions 18:07:24 … that mechanism has been used succesfully by various people 18:07:35 leonardr_ has joined #pwg 18:07:41 ... but if we're going fully to schema.org, what does that give us? 18:07:49 … it requires a file separate from HTML 18:08:01 [people remind it can be inlined] 18:08:28 davidwood: I think we're crossing the streams 18:08:51 q+ 18:08:56 q? 18:08:58 … we're saying pick this base file (URL of the pub), put this schema.org doc, but this does nothing for your package, for the online search 18:09:07 ... it makes it harder for RS that are not browsers 18:09:18 q? 18:09:39 … all those RS will have to understand this schema.org data and they don't know how to do that today 18:09:50 q? 18:09:51 ack ivan 18:10:15 q+ 18:10:17 ivan: you can put @ID into the JSON-LD which is not the URL of the HTML document it contains 18:10:38 davidwood: didn't we define at TPAC that the URL of this HTML would be the address of the publication? 18:10:46 ivan: yes 18:11:04 … we can put the ID of the publication as the subject of the JSON-LD, regardless of where the document is 18:11:21 ... whether we prefer JSON or some multitude of files, I think I still prefer JSON 18:11:52 q? 18:11:55 ack clapierre 18:11:56 … if we don't use the schema.org terms (or the DC terms), we are engaging to define our own vocab, and we don't want to do that 18:12:19 clapierre: the a11y TF did get schema.org to add in various a11y-related metadata 18:12:43 ivan: right, in fact I point to them in the mapping I did yesterday 18:12:49 httttttps://idpf.github.io/epub-vocabs/package/a11y/\ 18:12:51 ack Avneesh 18:13:05 avneesh: we were succesful to add 4-5 properties 18:13:14 https://idpf.github.io/epub-vocabs/package/a11y/ 18:13:28 … but the properties critical to conformance (conformsTo, certifiedBy) we couldn't include 18:13:57 ... while working on EPUB Accessibility 1.0 at IDPF, we had to create this vocab for EPUB only since we couldn't get it on schema.org 18:14:08 … but this is very essential to a11y conformance statements 18:14:22 ... in case schema.org can't accept it, we'll have to define it in WP 18:14:30 ivan: in last resort we can do that 18:14:31 q+ 18:14:45 … it's easy to do with JSON-LD 18:15:07 ... if I understand well the terms you defined ended up in the main schema.org set of metadata 18:15:24 … you could also have proposed an extension 18:15:38 avneesh: we explored it but it wouldn't have had as much weight 18:15:50 q? 18:15:55 ivan: right. we'll have to discuss this with schema.org people 18:16:23 … as a last resort JSON-LD allows you to add your own namespace and vocab 18:16:43 q? 18:16:46 ack bigbluehat 18:16:48 ack bigbluehat 18:17:08 bigbluehat: there's an affordance that's driving the schema.org selection 18:17:22 … schema.org has been chosen for search index by various parties 18:17:41 q+ 18:18:01 ... we should not be opposed to extend the vocabularies for other UA beyond just the search engines 18:18:07 http://www.sparontologies.net/ontologies 18:18:23 … we use the ontology (linked above) at Wiley 18:18:39 ... these are in use at publishers 18:18:59 … we must keep in mind what we're trying to afford in the different scenarios 18:19:04 q? 18:19:06 ... search index is one, it's not the only one 18:19:15 ack leonardr_ 18:19:31 leonardr: +1 on what Benjamin just said 18:19:34 q+ 18:19:43 q+ 18:20:31 … another question is: should we want another openly available industry location for a metadata document? 18:20:33 q? 18:20:43 ack zheng_xu 18:21:04 Adobe XDM - https://www.adobe.io/open/standards/xdm.html 18:21:09 zheng_xu: from our point of view, JSON-LD is very convenient 18:21:23 q? 18:21:29 https://github.com/adobe/xdm 18:21:30 ack ivan 18:21:47 ivan: the fact that we'll use JSON is decided 18:21:53 q+ to clarify JSON vs. JSON-LD (some more 18:21:54 s/JSON/JSON-LD 18:22:02 … it's of course correct that search is the major reason for using schema.org 18:22:25 ... if I look at the linked data world in general, schema.org is by far the most largely used vocab 18:22:26 q+ 18:22:44 … there is a very active community around schema.org 18:23:12 ... if we use the schema.org approach, authors, publishers, etc can use other schema.org terms in the same manifest 18:23:18 q+ 18:23:30 … it's full of additional terms that are actually bloody useful for publishing 18:23:44 q? 18:23:59 ack laudrain 18:24:09 laudrain: yes, it's a very rich and active community 18:24:18 … it tries to describe the whole World 18:24:56 ... it covers the description of the publication, but also what's inside the publication 18:25:03 ack bigbluehat 18:25:03 bigbluehat, you wanted to clarify JSON vs. JSON-LD (some more 18:25:31 ack leonardr_ 18:25:32 bigbluehat: just a clarification: schema.org is only expressible in JSON-LD 18:25:46 ...and RDFa and Microdata and Turtle 18:25:53 leonardr: we all agree that using schema.org to some extent is worthwhile 18:25:58 ..but if it starts with "JSON" and has Schema.org in it, it needs "-LD" 18:26:08 … the question is should we use it for everything? 18:26:24 q+ 18:26:34 ack josh 18:26:53 josh: Ivan mentioned that the other candidate was DC 18:27:12 q? 18:27:13 … as someone in the publishing industry for 2 decades, we don't really care about getting rid of DC 18:27:17 +1 18:27:19 +1 18:27:28 ... we want to be more webby 18:27:37 … we're happy to abandon DC! 18:27:45 q? 18:27:50 Libraries and archives are used to crosswalking to and from dublin core, too 18:28:07 ack bigbluehat 18:28:34 bigbluehat: I propose we start from JSON-LD, inline in the HTML, build up from schema.org terminology 18:28:42 … look for anything we must add to schema.org 18:28:51 ... and that gets us started 18:29:14 Proposal: JSON-LD in HTML entry file; starting up from schema.org, and adding from there. 18:30:18 hadrien: I have multiple issues with always embedding JSON-LD in HTML 18:30:26 … I listed some of them in issues before 18:30:50 ... I think it's the best solution when you have a single resource in the reading order, otherwise an external file is OK 18:31:29 Proposal: JSON-LD secerialization; starting up from schema.org, and adding from there. 18:31:47 +1 18:31:48 s/secerialization/serialization/ 18:31:52 +1 18:32:16 Proposal: JSON-LD serialization; starting up from schema.org, and adjusting from there. 18:32:29 +1 18:32:30 +1 18:32:30 +1 18:32:31 +1 18:32:31 +1 18:32:31 +1 18:32:32 +1 18:32:33 +1 18:32:34 +1 18:32:35 +1 18:32:36 +1 18:32:38 +1 18:32:38 +1 18:32:40 +1 18:32:42 +1 18:32:46 +1, but I think I fell asleep for some of the conversation 18:32:50 +1 18:32:51 +1 18:33:06 (ofr now only for "descriptive properties", correct?) 18:33:07 +1 18:33:10 s/ofr/for/ 18:33:17 +0 18:33:18 Resolved: JSON-LD serialization; starting up from schema.org, and adjusting from there. 18:33:30 +1 18:34:44 { "break" : "donut" } 18:49:15 RickJ has joined #pwg 19:00:28 BenWaltersMS has joined #pwg 19:01:46 marisa has joined #pwg 19:02:13 rdeltour has joined #pwg 19:02:22 laudrain has joined #pwg 19:03:14 rdeltour_ has joined #pwg 19:03:25 zheng_xu has joined #pwg 19:03:28 dauwhe has joined #pwg 19:03:45 scribenick: garth 19:04:13 https://github.com/w3c/wpub/wiki/Descriptive-Infoset-Properties-vs.-Schema.org-table 19:04:16 Topic: Infoset items in json 19:05:24 tzviya: WPM terms & mapping to Schema.org – A11Y first 19:06:10 A11Y conformance metadata (from EPUB 3.0.1) proposed to schema.org… no action yet. 19:07:08 … Dave’s taking action items — the one just above is first. 19:07:41 … Address: url – no issue 19:08:09 George has joined #pwg 19:08:27 q+ 19:08:59 As more information for our last agenda item: 19:09:00 The DPLA Metadata Application Profile (MAP) is the basis for how metadata is structured and validated in DPLA, and guides how metadata is stored, serialized, 19:09:02 and made available through our API in JSON-LD. The MAP was originally developed in 2012 and has been updated occasionally since. It is based on the Europeana 19:09:03 Data Model (EDM), and integrates the experience and specific needs for aggregating the metadata of America’s cultural heritage institutions. The current 19:09:05 version is 4.0. 19:09:31 … Cononical Identifier: could be JSON-LD @ID and/or schema.org “identifier” (text) 19:09:32 q+ 19:09:53 ack dkaplan 19:10:15 … Should check with DanB 19:10:43 q+ 19:11:52 dkaplan: Pubs use lots of identifiers. Cononical Identifeir can be repeated; @ID could be used for THE identifier. 19:11:56 q? 19:12:00 q+ 19:12:03 ack RickJ 19:12:24 RickJ: run away from ISBD 19:12:32 s/ISBD/ISBN 19:12:34 ISBN is basically a red herring here 19:12:36 s/ISBD/ISBN/ 19:13:26 technically "@ID could be used for THE identifier." wasn't me; I was just pointing out the danger of schema.org identifier since it doesn't have the way to identify the single canonical id in a repeatable term 19:13:28 Leonard: There is a schema called “thing” — which has “same as” – good way to do DOI. 19:13:31 q+ 19:13:37 ack leonardr_ 19:13:39 also avoid the shiny object that ISSN is.... it's the same trap as ISBN http://www.issn.org/ 19:14:14 Rick++, avoid the trap of any single scheme (doi, isbn, issn, etc.). We need to be more generic for our canonical ID 19:14:25 tzviya: back to “Should check with DanB” on this topic. 19:15:05 ack big 19:15:28 Ben: @id should be the cononical identifier for a publication 19:15:38 ack ivan 19:15:45 @id = canonical identifier/publication address 19:16:03 https://schema.org/identifier can (or should be made to...ideally) be used for All The Other Things 19:16:10 ...or so goes my proposal 19:16:42 ivan: Agree. schema.org “identifier” can be used for additional identifiers. And okay to talk to DanB. 19:16:53 q? 19:17:15 tzviya: Cover 19:17:31 ivan: Did we find any for this? 19:18:10 q+ 19:18:10 Hadrien: somthing different in R2. Should it be metadata, or rel, do we worry about data replication? 19:18:23 q+ 19:18:27 q? 19:18:30 q+ 19:18:34 ack leonardr_ 19:18:38 q+ bigbluehat 19:18:47 … perhaps it shouldn’t be a pure metadata item. 19:18:50 bendugas has joined #pwg 19:19:21 Leonard: there is also a thumbnail URL — do people have big thumbs? 19:19:55 … thumbnail could semantically work 19:20:01 +1 19:20:10 ack dauwhe 19:20:44 Tzviya: could use resource with ARIA role cover 19:21:10 Dave: could use “image” for cover image. That’s shcema.org example. 19:21:15 Cover's don't have to be images. 19:21:18 ack RickJ 19:21:31 various: not reaquired 19:21:43 ivan: just part of basic set of infoset items 19:22:05 q? 19:22:37 q+ 19:22:50 rick: should this be part of the “basic” set anyhow? 19:22:56 q? 19:23:06 yes 19:23:32 @dkaplan - word salad, like that! 19:23:35 q+ 19:23:37 q+q+ 19:23:48 ack q+ 19:23:53 a bibliographic extension http://bib.schema.org/CoverArt 19:24:18 tzviya: it’s in there ‘cause it’s important to many publications 19:24:22 q+ 19:24:31 ack bigbluehat 19:24:53 ben: there are people who want a cover, we should have a standard way to do it. 19:24:56 http://ogp.me/#metadata 19:25:27 ack dauwhe 19:25:38 Dave: can’t not have cover 19:25:41 ack George 19:25:56 q+ 19:26:11 Gerorge: need descriptive alttext 19:26:12 q^2 19:26:27 ack josh 19:26:36 https://usercontent.irccloud-cdn.com/file/9vzQ5mZJ/THE_Q.png 19:27:02 josh: lots of WP’s won’t have a meaningful cover 19:27:24 … lets not be so “book” 19:27:27 q? 19:27:29 ack bigbluehat 19:27:31 q+ 19:27:52 q+ 19:27:55 q+ 19:28:15 q+ 19:28:26 q- 19:28:27 the ImageObject can have description 19:28:30 ack dauwhe 19:28:32 Ben: alttext: if you provided an image in JSON-LD you should/must have a title too? 19:28:39 ack david_stroup 19:28:43 Dave: cover is not requied 19:28:43 q+ 19:28:45 q? 19:29:06 q+ 19:29:12 David_stroup: not required; not all are images; and thmbnail too, possibly. 19:29:18 q- 19:29:39 ivan: ImageObject is pretty rich, so could be fine. 19:29:55 q? 19:30:07 ivan: could we require ImageObject, rather than URL? 19:30:34 Marisa: does this lead to multiple ways to describe an image? 19:30:37 q? 19:30:51 q+ 19:31:03 avneesh: need to consider AT 19:31:32 ack bendugas 19:31:50 present+ bendugas 19:32:04 q? 19:32:19 q- 19:33:13 bendugas: what about consistency of cover formatting? Landscape, portrait, et al. 19:33:27 ack Hadrien 19:34:06 q? 19:34:08 q+ 19:34:24 Hadrien: move Cover out of descriptive properties into structural properties. 19:34:40 … can also enable a number of affordances 19:35:11 q? 19:35:18 ack ivan 19:37:03 yeah, mised the most important part 19:37:03 … in HTML could use many elements — doesn’t need to be ImageObject 19:37:14 s/yeah, mised the most important part// 19:37:43 q? 19:37:48 q+ 19:37:57 ivan: do we need to come up with links and options? 19:38:02 ack tzviya 19:38:07 q+ 19:38:24 Hadrien: lots of options, without inventing new stuff 19:38:38 q+ 19:38:43 q+ 19:38:50 ack laudrain 19:38:52 +1 to cover in document 19:39:01 tzviya: make “cover” be a resource (in HTML with all it’s goodies), then identify with ARIA role cover? 19:39:11 q+ 19:39:15 Luc: really should be in HTML 19:39:20 +1 to cover in (or part of?) a document...fascinating possibilities 19:39:30 q+ 19:39:32 q+ 19:39:41 ack leonardr_ 19:39:50 +1 to reopen this discussion once we know how the list of resources is serialized :p 19:39:53 q+ 19:40:00 Leonard: assumption the cover will be displayed? 19:40:08 … I don’t think so. 19:40:36 q+ 19:40:37 … Purely machine readable. If you want it to be rendered, it should be in the content and reading order. 19:41:14 q? 19:41:18 ack dkaplan3 19:41:24 ack dkaplan3 19:41:26 ack dkaplan 19:41:45 dkaplan: agree with Tzviya, disagree with Leonard 19:42:17 … Cover is an image that displays in a number of ways (e.g., Bookshelf) 19:42:39 q? 19:42:58 … Lots of hoops for this in EPUB as RS’s aren’t consistent. 19:43:36 … if no shelf view, readers still expect to be able to see the cover 19:44:15 … in HTML and tagging it as such would solve these problems. 19:44:25 +1 agree about the concept, not necessarily the solution (ARIA role) 19:44:25 ack dauwhe 19:44:26 q? 19:44:33 ack bigbluehat 19:44:33 ack bigbluehat 19:44:36 Dave: dkaplan is my hero 19:45:13 Ben: +N (though perhaps there are more semantics than an ARIA role might want) 19:45:17 q? 19:45:18 ack rdeltour 19:45:21 ack rdeltour 19:45:40 ack BenWaltersMS 19:45:43 ack BenWaltersMS 19:45:43 rdeltour: “cover” ARIA role can only apply to an 19:45:51 q? 19:45:52 https://www.w3.org/TR/dpub-aria-1.0/#doc-cover 19:46:40 q- 19:46:43 Ben: agree with Leonard. If you want to show a cover, it should be in content. But, for usage like search, it wants to be metadata — can’t expect that to be dug for. 19:46:55 ack marisa 19:47:07 q? 19:47:07 +1 to what BenWalterMS said about search engines, that's why I think the concept is good but this needs to be adressed at a list of resources level 19:47:32 q+ 19:48:11 arguably doc-cover could be changed, since changes to dpub-aria are in scope for our WG. 19:48:23 q+ 19:48:35 q- 19:48:36 q+ 19:48:51 I am in favor for doc-cover being permissible on more legal elements 19:48:56 q? 19:49:27 q+ 19:49:32 ack dauwhe 19:49:34 ack dauwhe 19:50:05 tzviya: what about both? ARIA role on an for rendering. schema.org “image” pointing to ImageObject for machine readable. 19:50:39 ack Hadrien 19:50:43 ack Hadrien 19:51:10 q+ 19:51:15 q+ 19:51:24 ack rdeltour 19:51:29 ack rdeltour 19:51:44 Hadrien: starting to be like EPUB (in a bad way) — data suplication. We should wait to get into structural properties. 19:52:09 rdeltour: author can do both anyhow… is this really a best practice? 19:52:26 … both are already allowed now. 19:52:30 q? 19:52:35 ack leonardr_ 19:53:03 Leonard: agree. Need UA requirements. Multiple places will be used differently. 19:53:17 q+ 19:53:25 ack dauwhe 19:53:30 … at some we’ll need to cross that bridge. 19:53:59 "they will be used differently" is the problem that causes massive creator confusion that I was upset about. Most publication creators don't think that way and asking them to makes their heads asplode. 19:54:10 Dave: should sketch these options out… it’s complex enough. 19:54:14 ack laudrain 19:54:29 q+ josh so he can say affordances 19:54:35 @dkaplan3 - which is why we need UA requirements so thre is no confusion 19:54:50 q? 19:55:06 Luc: 2nd time today we’ve used an ARIA role for something other than A11Y… bad (maybe). 19:55:33 +1 tzviya 19:55:35 tzviya: Proposal… run away! 19:56:21 Creators: can we take schema.org’s robust set and call it a day? 19:56:30 q+ 19:56:34 ivan: proposal: any may be used 19:56:45 … all refer to Person or Organization 19:56:47 q+ 19:57:18 … is it okay to use multiple? Can order be important? 19:57:40 ack Hadrien 19:57:41 ack Hadrien 19:59:01 Hadrien: bunch of useful schema.org items — we need to specify a set of ‘em that are expected for this purpose. 19:59:10 ivan: +1 19:59:36 Luc: a “role” would be better 19:59:51 q+ 20:00:36 tzviya: schema.org may/may-not have contributor; restricting the list has problems too. 20:00:49 ack dkaplan 20:01:41 dkaplan: Can do TEI. So complex it’s unusable. 20:01:57 We will identify required schema.org entries, right? I am talking about the min set. 20:02:01 s/Can/Can't/ 20:03:02 ack Hadrien 20:03:07 … Need gerneral one (creator). 20:03:31 Hadrien: agree. Contributor is schema,org (though role is missing). 20:04:04 q+ 20:04:16 ack wendyreid 20:05:05 s/ Can do TEI/ We must learn from the dangers of what happened with TEI/ 20:05:16 wendyreid: publishers are good at deliverying very detailed metadata, but in retailing, ONIX or Excel sheets (oh my!) is really is what is being used. 20:05:17 ack wendyreid 20:05:23 Link to contributor: http://schema.org/contributor 20:06:03 q? 20:06:44 s/So complex it’s unusable./Too much specificity will (a) not capture all use cases and (b) will make it impossible for implementers to know what to display. We should try to get most use cases, and accept generic "creator" will catch the long tail./ 20:08:06 q+ 20:08:06 Language & base-direction: schema.org has language, but not text-direction (of cotent in metadata) or reading direction of publication. 20:08:19 q+ 20:08:23 q- 20:08:31 q- 20:08:41 Leonard: not relevant in context of metadata. 20:08:55 q+ 20:09:10 ivan: each metadata item should be balew to have language and text-direction 20:09:13 q+ 20:09:24 s/balew/be able/ 20:09:38 q+ 20:10:52 ivan/leonard: arguing 20:11:27 q? 20:11:32 ack dkaplan 20:12:00 ack bigbluehat 20:12:08 laurentlemeur has left #pwg 20:12:19 Ivan: concensus is that we should to take to DanB. 20:12:33 q+ 20:12:50 … just about text-direction of metadata (not content) 20:14:08 Ben: e.g., language is talking about the publication not the content 20:14:17 q? 20:14:32 s/ not the content/ not the metadata/ 20:15:18 ack zheng_xu 20:15:23 q+ 20:16:20 zheng_xu: do we need text direction in metadata? 20:16:44 ivan: this the dir attribute in HTML 20:17:31 q+ 20:17:48 … dir is missing from lotsa places 20:17:53 ack duga 20:17:55 ack duga 20:18:21 Brady: is it just direction? Do we need, e.g., ruby too? 20:18:21 Richard's doc on JSON and text direction - http://w3c.github.io/i18n-discuss/notes/json-bidi.html 20:18:46 q? 20:18:53 ack dauwhe 20:20:03 Dave: we’re getting too deep; need examples; all sovled in HTML; can we embed HTML fragements in JSON-LD? 20:20:18 ack marisa 20:20:36 ivan: there are data tags for HTML usable in JSON-LD 20:21:10 Marisa: +1 to Brady; unicode doesn’t fully cut it. 20:22:21 laurentlemeur has joined #pwg 20:23:37 ivan: @language can be added in an *inline* @context as the default for a single JSON-LD file...so there's that: https://json-ld.org/spec/latest/json-ld/#string-internationalization 20:23:46 https://w3c.github.io/wpub/#wp-language-and-dir 20:24:01 q+ 20:24:06 ivan: in our document 3.3.6 language & base-direction — we define ability to specify lang & base-direction for each text string and default — the latter would refer to the publication, not the metadata. 20:24:52 Ben: there is some funky was to do a default for an enitre JSON-LD file. 20:25:15 … still no bidi, no ruby 20:25:23 s/Ben/Benjamin 20:26:04 decided… move on, this is not the metadata you’re looking for (aka talking DanB) 20:26:36 Various dates — they map nicely 20:27:01 leonardr has joined #pwg 20:27:37 leonardr has joined #pwg 20:27:47 Reading progression direction — conceptually easy; just lacking the propery (as it does refer to the content – through reading order) 20:28:09 Title maps to “name”– funny, but true. 20:28:28 Leonard: should pull this out of DC – names just too wrong. 20:28:53 q+ 20:29:25 q+ 20:29:32 q- 20:29:41 Josh: we currently use name for title 20:29:46 ack bigbluehat 20:30:05 ack rdeltour 20:30:34 rdeltour: with a context, you can map "title" to https://schema.org/name 20:30:36 ack zheng_xu 20:30:50 zheng_xu: how do you title in multiple languages? 20:31:16 ivan: can be done in JSON-LD 20:31:33 … need to make sure it’s happy with consumers of schema.org 20:31:38 q? 20:31:44 q? 20:32:11 Karen has joined #pwg 20:32:23 thnx 20:32:36 s/thnx// 20:32:41 rrsagent, draft minutes 20:32:41 I have made the request to generate https://www.w3.org/2018/05/30-pwg-minutes.html ivan 20:32:57 laurentlemeur has left #pwg 20:34:14 So, adapting schema.org it is supposed to be {"name": {"@value": "Title of Publication", "@language": "en"}} I guess? 20:38:10 rrsagent, draft minutes 20:38:10 I have made the request to generate https://www.w3.org/2018/05/30-pwg-minutes.html ivan 20:41:45 https://docs.google.com/document/d/1Qe8Q8wMC1LKy_-JO-UCy8bFw4D4VN0si1Q5EPW9c-rY/edit# 20:41:57 Updated AGENDA for tomorrow: https://docs.google.com/document/d/1Qe8Q8wMC1LKy_-JO-UCy8bFw4D4VN0si1Q5EPW9c-rY/edit# 20:42:19 rrsagent, draft minutes 20:42:19 I have made the request to generate https://www.w3.org/2018/05/30-pwg-minutes.html ivan 20:42:32 http://hotelocho.com/food.html 20:43:31 JunGamo has left #pwg 20:44:24 marisa has joined #pwg 21:26:54 leonardr has joined #pwg 21:30:11 RickJ has joined #pwg 21:42:44 ivan has joined #pwg 21:44:10 dauwhe has joined #pwg 21:53:02 rrsagent, draft minutes 21:53:02 I have made the request to generate https://www.w3.org/2018/05/30-pwg-minutes.html ivan 21:53:02 zakim, bye 21:53:02 rrsagent, bye 21:53:02 I see no action items 21:53:02 leaving. As of this point the attendees have been ivan, dkaplan, dauwhe, RickJ, JunGamo, Rachel, tzviya, duga, josh, BenWaltersMS, marisa, Garth, laurent, DavidWood, 21:53:02 Zakim has left #pwg