15:25:27 RRSAgent has joined #pwg 15:25:27 logging to https://www.w3.org/2019/10/07-pwg-irc 15:25:28 rrsagent, set log public 15:25:28 Meeting: Publishing Working Group Telco 15:25:28 Chair: wendy 15:25:28 Date: 2019-10-07 15:25:28 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0000.html 15:25:28 ivan has changed the topic to: Meeting Agenda 2019-10-07: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0000.html 15:25:29 Regrets+ Luc, Josh 15:41:15 regrets+ mateus 15:54:51 geoffjukes has joined #pwg 15:57:13 present+ 15:57:17 present+ 15:57:25 present+ geoffjukes 15:59:40 laurent_ has joined #pwg 15:59:48 present+ 15:59:52 JuanCorona has joined #pwg 16:00:09 present+ JuanCorona 16:00:18 mgarrish has joined #pwg 16:00:19 romain has joined #pwg 16:00:27 present+ gpellegrino 16:00:36 present+ wendyreid 16:00:46 present+ 16:01:03 present+ george 16:01:06 Avneesh has joined #pwg 16:01:35 scribenick: dauwhe 16:01:43 present+ 16:01:47 rkwright has joined #pwg 16:01:57 (footsteps in background) 16:02:03 wendyreid: let's get started 16:02:06 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-09-30-pwg 16:02:09 ... let's approve minutes from last week 16:02:12 present+ 16:02:29 ... minutes approved 16:02:31 resolved: last week's minutes approved 16:02:44 https://github.com/w3c/pub-manifest/issues/75 16:02:47 wendyreid: first issue is about directionality 16:02:59 Topic: Directionality 16:03:00 present+ 16:03:08 -> https://github.com/w3c/pub-manifest/pull/92 Pull request for directionality 16:03:37 ivan: I have already reported that this whole direction issue now has a clear solution 16:04:06 duga has joined #pwg 16:04:13 BenSchroeter has joined #pwg 16:04:21 ... I've made a PR 16:04:27 present+ 16:04:30 marisa has joined #pwg 16:04:35 regrets garth 16:04:38 ... you can do direction much like you can do language 16:04:45 present+ 16:04:53 ... with the same syntax, either globally or for a given member 16:05:02 ... so the PR fixes all the bits 16:05:04 present+ 16:05:21 ... there is one issue which I put into the document 16:05:32 q? 16:05:41 ... having direction in the system means that we have a dependency on JSON LD 1.1 16:06:01 ... which is running in parallel with our spec; they plan CR at the same time, they have implementations. 16:06:16 ... so they may be ahead of us 16:06:17 Kenneth has joined #pwg 16:06:24 franco has joined #pwg 16:06:32 present+ 16:06:45 ... but if you want to run a manifest through a JSON-LD processor that only supports 1.0 you will get errors 16:06:56 ... so I created a separate context file that doesn't have direction 16:07:05 ... and made an appendix to the doc 16:07:13 -> https://pr-preview.s3.amazonaws.com/w3c/pub-manifest/pull/92.html#json-ld-1.1-1.0 Appendix on JSON-LD 1.1 vs. 1.0 16:07:30 Nellie has joined #pwg 16:07:53 ... so you can use this context if you don't need direction, and need to use a JSON-LD 1.0 processor 16:08:07 ... so the question to the group is that it's OK to keep this as an appendix in the document 16:08:29 g_pellegrino has joined #pwg 16:08:33 Bill_Kasdorf has joined #pwg 16:08:34 ... or put it somewhere else, or not do it at all and depend on JSON-LD 1.1 16:08:39 present+ 16:08:41 present+ 16:08:44 ... so I want help from the group in deciding what to do 16:08:48 wendyreid: any questions? 16:08:50 present+ 16:08:55 q+ 16:08:59 ack duga 16:09:11 CharlesL has joined #pwg 16:09:16 duga: I don't have strong feelings, but it does feel strange to put in the spec itself 16:09:18 present+ 16:09:27 ... most things that process this won't be JSON-LD processors 16:09:30 q+ 16:09:31 ... but I'm not against it 16:09:41 ack mgarrish 16:09:42 ... I think it should be in a read me or impl guide 16:09:53 mgarrish: I'm concerned about how this might be interpreted 16:10:01 ... changing our context which is required seems weird 16:10:10 ... it could add confusion to have an alternate context 16:10:12 q+ 16:10:23 ack ivan 16:10:29 ivan: I put it there without being convinced it's a good idea 16:10:42 ... I'm fine removing it 16:10:48 ... so where would this information go? 16:11:06 ... we could give it to the testing people and have this added to information about testing 16:11:16 q+ 16:11:28 ack mgarrish 16:11:44 mgarrish: I would put in our wiki for implementation details, so it's discoverable 16:11:50 wendyreid: a wiki is good 16:11:55 q+ 16:12:00 ack dauwhe 16:12:36 dauwhe: This seems like it would be a helpful note in the spec itself, if this language property is used, mention that JSON-LD 1.1 is required 16:12:46 ... it's a good use of non-normative text 16:12:57 ivan: any other comments? 16:13:16 ... one comment... for those of you who have been looking at this 16:13:37 -> https://pr-preview.s3.amazonaws.com/w3c/pub-manifest/pull/92.html#manifest-lang-dir-local Example for direction usage 16:13:40 ... if you look at this URL 16:13:53 ... there is a good example there for real cases where base direction is necessary 16:14:15 ... some people were wondering if this stuff was necessary 16:14:28 ... We found a book with a title in arabic and english 16:14:35 q 16:14:45 q 16:14:49 ... so it's good to have a real-world example 16:15:13 mgarrish: I think it's useful to have direction; we have it in EPUB. 16:15:35 ivan: is there a consensus to merge? 16:15:40 +1 16:15:45 +1 16:15:47 +1 16:15:47 +1 16:15:52 +1 16:16:06 ivan: we should also pledge to never talk about direction again :) 16:16:23 Resolved: ivan to merge direction PR 16:16:34 topic: wrap-up items for CR 16:16:36 wendyreid: the rest of the meeting will be wrap-up items for CR 16:16:45 https://github.com/w3c/pub-manifest/issues/ 16:17:04 ... we have three remaining issues 16:17:11 https://github.com/w3c/pub-manifest/issues/57 16:17:28 subtopic: issue 57, metadata in the publishing world 16:17:51 ... dave raised an issue about how metadata works in the publishing world 16:18:10 present+ marisa 16:18:25 dauwhe: Everybody knows I worry about a lot of things, our experience with EPUB has been spent in metadata rabbit holes, new vocabularies 16:18:36 ... everyone has a property that is important to them, we spend a lot of effort 16:18:46 zakim, who is here? 16:18:46 Present: ivan, dauwhe, geoffjukes, laurent_, JuanCorona, gpellegrino, wendyreid, romain, george, mgarrish, Avneesh, rkwright, duga, BenSchroeter, marisa, franco, g_pellegrino, 16:18:50 ... Bill_Kasdorf, Nellie, CharlesL 16:18:50 On IRC I see CharlesL, Bill_Kasdorf, g_pellegrino, Nellie, franco, Kenneth, marisa, BenSchroeter, duga, rkwright, Avneesh, romain, mgarrish, JuanCorona, laurent_, geoffjukes, 16:18:50 ... RRSAgent, Zakim, ivan, dauwhe, Karen, wendyreid, plinss_, github-bot, jamesn, achraf, sangwhan, Travis, bigbluehat, astearns, jyasskin 16:18:56 ... metadata is not always exposed to the reader, and it travels separately from the EPUB itself 16:19:03 except VitalSource is starting to expose the Accessibility Metadata 16:19:08 q+ 16:19:13 ... I raised this so we could be thoughtful about the metadata we expose 16:19:25 q+ 16:19:27 ack BenSchroeter 16:19:28 BenSchroeter: to add to that 16:19:41 q+ 16:19:47 q+ 16:19:47 ... we do supply a11y metadata in the epub that is used by distributors 16:19:49 q+ 16:19:49 ack CharlesL 16:19:54 q+ 16:19:57 CharlesL: I'm on the a11y metadata thing 16:20:02 present+ laurent_ 16:20:08 ... vitalsource is exposing EPUB a11y metadata to users 16:20:22 wendyreid: that metadata is in ONIX, too? 16:20:32 CharlesL: some of it; it's not a 1:1 mapping; there's more in ONIX 3 16:20:40 ack duga 16:20:45 present+ CharlesL 16:20:48 ... but it's not in ONIX 2.1, which is still widely used in US 16:21:03 zakim, who is here? 16:21:03 Present: ivan, dauwhe, geoffjukes, laurent_, JuanCorona, gpellegrino, wendyreid, romain, george, mgarrish, Avneesh, rkwright, duga, BenSchroeter, marisa, franco, g_pellegrino, 16:21:05 q+ 16:21:05 George has joined #pwg 16:21:07 ... Bill_Kasdorf, Nellie, CharlesL 16:21:07 On IRC I see CharlesL, Bill_Kasdorf, g_pellegrino, Nellie, franco, Kenneth, marisa, BenSchroeter, duga, rkwright, Avneesh, romain, mgarrish, JuanCorona, laurent_, geoffjukes, 16:21:07 ... RRSAgent, Zakim, ivan, dauwhe, Karen, wendyreid, plinss_, github-bot, jamesn, achraf, sangwhan, Travis, bigbluehat, astearns, jyasskin 16:21:13 duga: what Dave said is true for publisher-supplied ebooks, but not so much from user supplied epub 16:21:23 ... but the metadata that matters is mostly author and title 16:21:28 ack ivan 16:22:06 ivan: I've said several times, if this manifest exercise becomes successful, it may not be in the worlds where EPUB is already successful 16:22:23 ack laurent_ 16:22:25 ... we should not be bound by EPUB or ONIX 16:22:52 laurent_: in the thorium reader we try to present metadata in the OPDS feed or in EPUB 16:23:03 ... but there is no consistent set of user-oriented metadata 16:23:23 ... but we would like to get it right... publisher, language, category, subject, narrator... 16:23:28 q- 16:23:28 ... all would be useful 16:23:29 ack mgarrish 16:23:45 present+ 16:23:46 mgarrish: there's room to do metadata standardization outside of the standard itself 16:24:04 ... rather than putting every metadata scheme in the spec itself, leave it to the communities 16:24:13 ... there should be some core stuff 16:24:36 ... it's probably more efficient to do things outside 16:24:39 q+ 16:24:45 ack Bill_Kasdorf 16:25:06 q+ 16:25:06 Bill_Kasdorf: will there be a generic way to incorporate community-specific metadata? 16:25:08 q+ 16:25:26 ... so scholarly publishers can include what they think is essential? 16:25:33 ack mgarrish 16:25:41 mgarrish: that's exactly how it would work and how it is set up right now 16:26:01 ... we're a proxy for schema.org; we can use anything there without having it directly in our spec 16:26:07 ... and our context files include more prefixes 16:26:13 ... we are very flexible 16:26:14 +1 Matt 16:26:25 q+ 16:26:25 ... there should be a clear purpose to list metadata in the core spec 16:26:35 Bill_Kasdorf: I am anti-bloat 16:26:45 q+ 16:26:48 ack g_pellegrino 16:26:59 g_pellegrino: I understand what Matt says but some metadata is essential, like description 16:27:02 q+ 16:27:16 ack laurent_ 16:27:23 ... we should suggest to use some metadata, because otherwise reading systems won't implement 16:27:42 laurent_: I agree that in the core spec maybe we don't need an extensive set 16:27:49 ... communities can define their own community 16:28:02 ... who is the community? Is the audiobook community literally this working group? 16:28:09 q+ 16:28:13 ... but we need something defined somewhere 16:28:18 ack ivan 16:28:33 ivan: one of the reasons we took JSON-LD is because schema.org used it 16:28:49 ... but JSON-LD is ideally suited for this... you can just add things and it's OK. 16:29:05 ... laurent is right; for different areas there should be communities defining metadatas 16:29:09 q+ 16:29:25 ... I don't know if there is additional metadata required by audiobooks, if so let's add it 16:29:50 ... it depends... a CG might be able to define some of these things 16:29:59 ... the main goal is to provide a framework 16:30:06 ack dauwhe 16:30:10 q+ 16:31:02 dauwhe: I'm not opposed to metadata, we seem to think that embedding metadata is always good but past experience shows this data is rarely used, I'm aware of few reading systems that use title and author but we've made many EPUBs using copyright statements 16:31:07 ack Avneesh 16:31:15 Avneesh: let this spec go to CR as is 16:31:26 -> https://w3c.github.io/pub-manifest/#extensibility example to link external metadata (ONIX in this case) 16:31:37 ... and we have the audiobooks spec; we need to know what audio publishers want 16:31:45 +1 to Avneesh 16:31:50 ... and we can do a note or registry with metadata 16:31:53 ack g_pellegrino 16:32:01 g_pellegrino: I agree with avneesh 16:32:17 present+ 16:32:23 ... the possibility to define the role of contributor in schema.org are very poor 16:32:41 q+ 16:32:43 ack laurent_ 16:32:44 ... we need ways to add that 16:32:57 laurent_: adding metadata can be done step-by-step 16:33:05 ... we need a group that can host these needs 16:33:11 q+ 16:33:14 ... which group is it? This WG working on audiobooks? 16:33:28 ack mgarrish 16:33:29 ... then we can wait for needs from publishers of audiobooks 16:33:51 mgarrish: to what gregorio said, we can request that schema.org add stuff that's missing 16:33:52 +1 to matt 16:33:56 +1 to matt 16:34:03 ... it never ends well when we add metadata to our own standards 16:34:15 ack ivan 16:34:23 ivan: a partial answer to laurent 16:34:47 ... there are two issues. one is, who are the groups that develop metadata? I don't think there is one answer. 16:35:02 ... two: how do you find the metadata that has already been developed? 16:35:12 q+ 16:35:40 ... we may need a registry 16:35:49 ack Bill_Kasdorf 16:36:09 Bill_Kasdorf: in some sectors of publishing there are organizations that govern metadata 16:36:25 ... IPTC, JATS, etc 16:36:42 ... as we reach out to other sectors, we will find there are already metadata standards 16:37:01 wendyreid: this is not a question for us to solve today 16:37:33 ... we have suffiecient metadata in our specs for now. We'll see how it goes in CR. 16:37:42 q+ 16:37:45 ... so let's move on 16:37:47 ack ivan 16:37:56 ivan: is it OK if we close this issue? 16:38:22 q+ 16:38:27 dauwhe: refresh your github 16:38:47 g_pellegrino: if we close the issue, how can we say we are thinking about this? 16:38:54 Fine 16:39:03 ack g_pellegrino 16:39:03 ivan: we could say it's deferred 16:39:09 https://github.com/w3c/pub-manifest/issues/98 16:39:21 Deffer 16:40:30 romain: this is mostly an editorial issue? 16:40:32 subtopic: WebIDL yea or nay? 16:40:36 ... after talking to marcos at TPAC 16:40:50 ... for web app manifest spec they are going to stop using WebIDL 16:40:58 ... they think it's a poor fit for data structures 16:41:08 ... there's an issue in their github 16:41:29 ... so I wondered if we should align with what they are doing 16:41:42 ... and there's also a TAG issue about the proliferation of manifest formats 16:41:46 q+ 16:41:48 ack ivan 16:41:52 ... so I think it's good we use the same kind of specification process 16:42:00 ivan: for those who did not read the thread 16:42:03 ... there are two issues 16:42:24 ... one, the community is coming up with an agreement to use similar language when describing processing for these things 16:42:36 ... matt has looked at it, and we could adopt this language 16:42:42 q+ 16:43:05 ... the other problem is that those approaches do not provide one place where you can look at the whole data structure 16:43:12 ... and WebIDL does 16:43:25 ... nobody really likes webidl, neither do I 16:43:32 ... but I don't have an alternative 16:43:54 ... if an alternative comes up, then we can use a new things 16:44:04 ... but I think we should go ahead with CR 16:44:04 bkardell_ has joined #pwg 16:44:19 q+ 16:44:20 ack romain 16:44:28 romain: a couple things 16:44:41 ... since we first discussed things, the specification landscape evolved 16:44:57 ... we now know how to parse JSON into infra parts 16:45:05 ... and that's what the app manifest folks will use 16:45:16 ... the question to matt, our use of webidl 16:45:32 david_stroup has joined #pwg 16:45:32 ... we don't rely on it in the same way, I'm told, and I don't understand 16:45:44 help 16:45:45 mgarrish: what I'm getting at is that it's integrated--they define via their dictionary 16:46:03 ... we don't do that--our properties are not defined via webidl dictionaries 16:46:11 ... and our processing is separate 16:46:28 ... so we're independent, it's just a way of visualizing our data structure 16:46:54 ... what they're going to do in WAM is to take the interleaving of the webidl, and depend less on that and more on infra 16:46:57 q+ 16:47:18 ivan: if I remember well, use of WebIDL is not only for data structure but for functions 16:47:27 ack dauwhe 16:48:21 dauwhe: I'm a little puzzled by Ivan saying that there is no alternative for WebIDL but that is only as a way to visualize the data structure? I am confused that Matt says we're defining it in the spec but we depend on it as expressing vocabulary? 16:48:39 ivan: it would be equivalent to using ??? 16:48:53 s/???/Typescript interface/ 16:49:05 dauwhe: And where do things like JSON schemas fit into this question? 16:49:06 ... I don't know what other kind of formalism would I use 16:49:16 ivan: json schemas are orthogonal to this 16:49:19 ack romain 16:49:37 romain: one of the similarities we have with app manifest 16:49:51 ... the result of processing the manifest is what we define with webidl 16:50:11 geoffjukes has joined #pwg 16:50:11 ... so this algo defines a string is converted into webidl 16:50:26 ... I'm not an expert in webidl, and I've only read their issue a couple of times 16:50:40 q+ 16:50:41 ... the issues are in defining the details of the conversion logic 16:50:54 ... and then we have to define the conversion of json to web idl 16:50:55 ack mgarrish 16:51:09 mgarrish: I wouldn't say that what we're processin g is intended to be webidl 16:51:16 ... it was canonical json 16:51:18 present+ bigbluehat 16:51:26 ... we'll probably end up with infra trypes 16:51:33 ... which is problematic 16:51:46 ... and the fact that it gives the impression we have a web api 16:52:01 ... I don't know what else there is that easily describes the objects that are going to be created 16:52:11 ... possibly the solution is that we don't define the webidl 16:52:17 ... and web devs figure it out 16:52:37 romain: it does seem that it's mostly an editorial issue? It doesn't affect normative language? 16:52:43 ... we can deal after CR? 16:52:49 wendyreid: can we call this postponed? 16:53:04 q+ 16:53:08 ack romain 16:53:09 ivan: I would love to have a replacement for WEbIDL 16:53:27 romain: in some ways it's editioral, on the other hand it's a big thing to change how things are described 16:53:36 ... it's a profound editorial change; not lightweight 16:53:41 ... the sooner we know the better 16:53:44 q+ 16:53:48 ack ivan 16:54:01 ivan: yes, it is a profound editorial change 16:54:12 ... I don't see what we are changing for 16:54:17 ... and I don't see alternatives 16:54:31 q+ 16:54:33 ... I've looked at many things 16:54:49 ... using typescript is not a good idea 16:55:15 ... it's weird that there's no standard formalization for data structures 16:55:27 q+ 16:55:27 ack romain 16:55:53 romain: one thing worth clarifying before CR, is to clarify what is the type of the result of processing algo 16:56:12 ... we say we convert to an internal representation, but we don't say what the internal representation is 16:56:23 ... what does the algo produce? a json object? 16:56:29 ... we should clarify that? 16:56:30 q? 16:56:39 ack mgarrish 16:56:57 mgarrish: that's part of what I hope to clean up with the infra types 16:57:04 ... the normalization is more complicated than I thought 16:57:11 ... our outcome will be an infra map 16:57:19 present+ 16:57:37 ... if it's purely about visualizing the data, maybe it doesn't belong in the spec, maybe it should be in a wiki 16:57:50 ... so we have the processin steps and then a separate numbering 16:58:14 wendyreid: could we see a PR with the infra in it? 16:58:19 mgarrish: it's coming 16:58:27 ... I hope it's done later today 16:58:32 ivan: I'll have to merge the other PR 16:58:35 wendyreid: we're out of time 16:58:50 topic: cr timing 16:58:54 ... goal is CR by end of month 16:59:00 ... so we need horizontal review 16:59:08 ... I've sent messages to everyone 16:59:18 ... next monday, the 14th, is the final day to accept issues 16:59:27 ... speak now or forever hold your peace 16:59:40 q+ 16:59:48 ack ivan 16:59:49 ivan: I learned today 16:59:58 ... that on the 14th there is a holiday in the US 17:00:41 wendyreid: that's all 17:00:52 rrsagent, draft minutes 17:00:52 I have made the request to generate https://www.w3.org/2019/10/07-pwg-minutes.html ivan 17:00:52 zakim, bye 17:00:52 rrsagent, bye 17:00:52 I see no action items 17:00:52 leaving. As of this point the attendees have been ivan, dauwhe, geoffjukes, laurent_, JuanCorona, gpellegrino, wendyreid, romain, george, mgarrish, Avneesh, rkwright, duga, 17:00:52 Zakim has left #pwg 17:00:53 ... bye