13:04:40 <RRSAgent> RRSAgent has joined #epub
13:04:40 <RRSAgent> logging to https://www.w3.org/2021/05/07-epub-irc
13:04:42 <Zakim> RRSAgent, make logs Public
13:04:44 <Zakim> please title this meeting ("meeting: ..."), ivan
13:05:22 <ivan> ivan has changed the topic to: Meeting Agenda 2021-05-07: https://lists.w3.org/Archives/Public/public-epub-wg/2021May/0004.html
13:05:23 <ivan> Chair: dauwhe
13:05:23 <ivan> Date: 2021-05-07
13:05:23 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021May/0004.html
13:05:23 <ivan> Meeting: EPUB 3 Working Group Telco
13:05:23 <ivan> Regrets+ mattg
13:32:29 <wendyreid> wendyreid has joined #epub
13:50:16 <dauwhe> dauwhe has joined #epub
13:54:12 <dauwhe> Zakim, who is here?
13:54:12 <Zakim> Present: (no one)
13:54:14 <Zakim> On IRC I see dauwhe, wendyreid, RRSAgent, Zakim, tzviya, ivan, join_subline, github-bot, florian
13:54:18 <dauwhe> present+
13:57:18 <MattChan> MattChan has joined #epub
13:57:40 <wendyreid> present+
13:57:54 <BenSchroeter> BenSchroeter has joined #epub
13:59:00 <toshiakikoike> toshiakikoike has joined #epub
13:59:15 <toshiakikoike> present+
13:59:27 <ivan> present+
13:59:36 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:42 <MasakazuKitahara> present+
13:59:42 <George> George has joined #epub
13:59:55 <MattChan> present+
14:00:07 <George> present+
14:00:22 <BenSchroeter> present+
14:01:07 <ivan> present+ toshiakikoike
14:01:21 <tzviya> present+
14:01:31 <MattChan> scribe+
14:01:35 <gpellegrino> gpellegrino has joined #epub
14:01:41 <ivan> present+ gpellegrino
14:02:41 <MattChan> TOPIC: Update on FXL and Locators TFs
14:02:52 <MattChan> wendyreid: FXL and Locators met as usual
14:03:10 <MattChan> ... FXL TF gave updates, we now have best practices doc on github
14:03:19 <MattChan> ... you should start seeing PRs updating that document
14:03:34 <MattChan> ... also talked about how we are going to update Daisy KB
14:03:44 <MattChan> ... and some epub experiments
14:04:10 <ivan> q+
14:04:13 <MattChan> ... we also talked about possible change to spec, possible proposal of what we could do to help FXL be more accessible (esp. in light of EUAA)
14:04:15 <dlazin> dlazin has joined #epub
14:04:19 <MattChan> ... will post explainer doc soon
14:04:19 <dlazin> present+
14:04:49 <MattChan> ... Locators TF was trying to refine use-cases this week, in terms of what we can do with CFIs, vs where a simple locator scheme might work
14:05:09 <dauwhe> ack iv
14:05:25 <MattChan> ivan: can you elaborate on change to spec?
14:05:58 <MattChan> wendyreid: there's a lot of discussion yet to come
14:06:21 <MattChan> dauwhe: essentially alternative stylesheet to provide a reflowable version of FXL content
14:06:53 <MattChan> ... RS could then provide UI to switch to this alternative stylesheet
14:07:02 <laurent__> laurent__ has joined #epub
14:07:05 <MattChan> ... similar to darkmode, reduced media use mode, etc.
14:07:21 <laurent__> present+
14:07:26 <dauwhe> https://github.com/w3c/epub-specs/issues/1659
14:07:38 <ivan> Topic: @issue 1659
14:07:40 <MattChan> TOPIC: is our scripting requirement normative?
14:07:51 <MattChan> dauwhe: right now RS spec has non-normative section on security and privacy
14:08:08 <MattChan> ... in here is where we have the statement that RS must behave as though each epub is its own origin
14:08:24 <MattChan> ... but this is the cornerstone of our security model
14:08:24 <dauwhe> q?
14:08:25 <ivan> q+
14:08:27 <MattChan> ... so should it be normative?
14:08:29 <dauwhe> ack iv
14:08:36 <MattChan> ivan: yes
14:09:07 <laurent__> q+
14:09:15 <MattChan> ... the question is whether putting that as a normative requirement now would create backwards compat issues for existing RS
14:09:15 <dauwhe> ack lau
14:09:25 <MattChan> laurent__: for Readium, no, there will be no problem
14:09:43 <MattChan> ... for other RS, not sure at all, because there is extra effort to do this
14:09:47 <dauwhe> q?
14:09:58 <MattChan> ... not sure that RMSDK for example has this possibility
14:10:07 <ivan> q+
14:10:24 <MattChan> ... if we make this normative, could this invalidate existing readers (e.g. eINK readers)?
14:10:35 <dauwhe> ack iv
14:10:42 <MattChan> dauwhe: not sure if any RS is compliant to that extent
14:11:01 <MattChan> ivan: what we can do is declare as normative today, but put it as "at risk feature" when we go to CR
14:11:08 <dauwhe> q+
14:11:23 <MattChan> ... so if it turns out to create huge problems that implementations cannot handle, then we can remove it from normative section (and keep it as informative)
14:11:49 <Ken_Jones_> Ken_Jones_ has joined #epub
14:12:04 <MattChan> dauwhe: we already have at least one implementation
14:12:18 <laurent__> q+
14:12:18 <dauwhe> ack da
14:12:19 <tzviya> q+
14:12:21 <MattChan> ... fairly confident we can get at least one more
14:12:22 <dauwhe> ack laur
14:12:46 <Bill_Kasdorf_> Bill_Kasdorf_ has joined #epub
14:12:51 <MattChan> laurent__: usually user storage is the issue
14:12:51 <Bill_Kasdorf_> present+
14:13:05 <dauwhe> ack tz
14:13:08 <MattChan> ... and for user storage there is a simple test we can do (i.e. if one epub can store something that another reads)
14:13:27 <MattChan> tzviya: i think Ivan's "at risk feature" is a good process solution
14:14:07 <MattChan> ... maybe also add an informative note with it to explain the history (and why we're marking it "at risk")
14:14:30 <ivan> q+
14:14:39 <MattChan> dauwhe: if epub 3.3 becomes REC, and there are some RS that don't separate epubs from each other, I don't see how that's any different from the last 20 years
14:14:55 <MattChan> ... doesn't affect validity of epubs
14:15:10 <MattChan> ... this is about what RS do, and we know that they make their own choices about what to implement
14:15:24 <MattChan> ... prefer not to call this out as "at risk"
14:15:32 <dauwhe> ack iv
14:15:46 <dauwhe> q?
14:15:50 <MattChan> ivan: agreed. Withdrawing my earlier proposal.
14:16:27 <MattChan> ... is there any serious epub out there that will become unreadable if we change to normative status?
14:17:06 <MattChan> dauwhe: i see backwards compat issue, but if that book is doing something sketchy from security POV, we don't have to maintain compat for it
14:17:24 <MattChan> ivan: right, so my question is about valid epubs only
14:17:29 <wendyreid> Proposed: Make statement in issue 1659 normative
14:17:36 <BenSchroeter> +1
14:17:38 <ivan> +1
14:17:39 <tzviya> +1
14:17:41 <toshiakikoike> +1
14:17:41 <wendyreid> +1
14:17:42 <MasakazuKitahara> +1
14:17:42 <dauwhe> +1
14:17:43 <MattChan> +1
14:17:44 <Bill_Kasdorf_> +1
14:17:44 <dlazin> +1
14:17:45 <gpellegrino> +1
14:17:59 <wendyreid> RESOLVED: Make statement in issue 1659 normative
14:18:13 <dauwhe> https://github.com/w3c/epub-specs/issues/1650
14:18:23 <MattChan> TOPIC: mimetypes for dc:description
14:18:38 <MattChan> dauwhe: the use-case here is to provide rich formatting for epub metadata in the package file
14:19:09 <MattChan> ... there were various proposals on how to do this (e.g. escaped markup, markdown)
14:19:18 <MattChan> ... but I have concerns about all of these
14:19:31 <MattChan> ... they increase burden on RS to parse info out of package file
14:19:52 <MattChan> ... plus, we already have an alternative to this via linked metadata
14:20:08 <laurent__> q+
14:20:12 <MattChan> ... and few RS use metadata other than title and author, not overwhelming demand
14:20:13 <dauwhe> ack lau
14:20:55 <MattChan> laurent__: Atom(?) provides the ability to do this
14:21:06 <MattChan> ... but the results are often poor
14:21:19 <Bill_Kasdorf_> q+
14:21:32 <MattChan> dauwhe: book descriptions in our ONIX feed use escaped markup
14:21:54 <MattChan> ... once found something that was nested 37 level deep, found javascript fragment, found OpenOffice XML fragments
14:21:54 <dauwhe> ack Bill
14:21:58 <MattChan> ... very messy
14:22:11 <ivan> -> Atom syndication format https://tools.ietf.org/html/rfc4287
14:22:29 <MattChan> Bill_Kasdorf_: in the trade book side of things, its not comment to embed things in metadata
14:22:44 <ivan> q+
14:22:46 <MattChan> ... although it does tend to happen in other areas of publishing
14:23:05 <MattChan> ... perhaps we can leave this to a successor format to epub
14:23:37 <dauwhe> ack iv
14:23:43 <MattChan> ... e.g. in educational publishing, Macmillan wasn't even familiar with ONIX
14:24:05 <dauwhe> q?
14:24:16 <MattChan> ivan: for those areas of publishing, would linking to metadata be acceptable?
14:24:22 <MattChan> ... that is what we have today
14:24:39 <MattChan> Bill_Kasdorf_: if that publisher's ecosystem supports that, then yes
14:24:40 <ivan> q+
14:24:43 <dauwhe> ack iv
14:25:04 <dauwhe> q+
14:25:38 <MattChan> ivan: the only minor thing that came up is that if we say we prefer the linked element solution, then we may want to add ability to use link to more elements
14:25:53 <dauwhe> ack dau
14:25:54 <MattChan> dauwhe: i'm also not aware of a RS that supports linked metadata elements
14:26:03 <George> q+
14:26:19 <dauwhe> ack geor
14:26:38 <MattChan> George: what about where the book is ingested and that link is used to provide information about that book
14:27:01 <MattChan> ... its not the RS itself that is using that link, but the link is being used elsewhere in supply chain
14:27:07 <MattChan> ... does that pass our implementation test?
14:27:10 <laurent__> q+
14:27:14 <dauwhe> ack laur
14:27:17 <MattChan> dauwhe: I think so, but I'm not aware of this happening
14:27:35 <MattChan> laurent__: from what i heard, epub metadata is not used in ingestion, they use mostly ONIX
14:27:42 <wendyreid> q+
14:27:43 <George> q+
14:27:45 <dauwhe> ack we
14:28:18 <tzviya> q+
14:28:23 <MattChan> wendyreid: some epub metadata is used on ingestion, e.g. epub 3 vs 2, FXL vs reflow
14:28:31 <dauwhe> ack geo
14:28:37 <MattChan> ... generally identification and classification of the type of epub
14:29:11 <Bill_Kasdorf_> q+
14:29:32 <dauwhe> ack tz
14:29:35 <MattChan> George: VitalSource uses epub metadata, RedShelf uses it, CG is working on ways to expose epub metadata, we're working with libraries (EBSCO, Proquest) to expose it
14:30:21 <MattChan> tzviya: our research showed that the field that was used most was the identifier, and that was used to correlate to ONIX, for example
14:30:28 <George> q+
14:30:40 <MattChan> ... covers were extracted, sometimes the author field
14:31:06 <dauwhe> ack Bill
14:31:11 <MattChan> ... as far as linked metadata, I was proponent, but we're not seeing that used in real world right now, even in scholarly
14:31:15 <ivan> q+
14:31:36 <MattChan> Bill_Kasdorf_: all GCA certified publishers are putting accessibility metadata in their epubs
14:32:02 <dauwhe> ack Ge
14:32:22 <MattChan> dauwhe: agreed that metadata in epubs are useful, but not sure that we should complicate that metadata
14:32:23 <tzviya> +1 dauwhe
14:32:47 <dauwhe> ack iva
14:32:59 <MattChan> George: Micha Bowers is working on a way to create citations and bibliographic references, and that work depends on the metadata in epubs
14:33:16 <wendyreid> s/Micha/Micah/
14:33:19 <Bill_Kasdorf_> s/Micha/Micah
14:33:36 <dauwhe> q?
14:34:21 <MattChan> ivan: so it seems the WG is not in favour of complicating the way we do metadata in epubs, with the exception of maybe adding a new relationship
14:35:34 <MattChan> wendyreid: the new relationship piece can be a new issue or PR, i think
14:35:43 <wendyreid> Proposed: Close issue 1650, add new property to linked metadata
14:35:51 <wendyreid> Proposed: Close issue 1650, add new property to linked relationship
14:36:09 <ivan> +1
14:36:17 <BenSchroeter> 0
14:36:20 <George> +1 add the relationship, then close
14:36:22 <laurent__> +1 to close, 0 for a new link
14:36:25 <toshiakikoike> 0
14:36:27 <dlazin> 0
14:36:30 <Bill_Kasdorf_> 0
14:36:30 <MasakazuKitahara> 0
14:36:39 <MattChan> tzviya: can we clarify what we are adding?
14:36:42 <dauwhe> https://w3c.github.io/epub-specs/epub33/core/#app-link-vocab
14:37:07 <tzviya> +1
14:37:45 <MattChan> dauwhe: little afraid that this will open a can of worms with other people wanting their own vocab added
14:37:56 <dauwhe> +1 to close issue, -1 on new link relation
14:37:58 <wendyreid> Proposed: Close issue 1650
14:37:59 <wendyreid> +1
14:38:04 <dauwhe> +1
14:38:07 <MattChan> +1
14:38:08 <laurent__> +1
14:38:09 <ivan> +1
14:38:09 <BenSchroeter> +1
14:38:11 <toshiakikoike> +1
14:38:12 <MasakazuKitahara> +1
14:38:13 <gpellegrino> +1
14:38:24 <wendyreid> RESOLVED: Close issue 1650
14:38:40 <Bill_Kasdorf_> +1
14:38:51 <MattChan> ivan: should I come up with separate PR about the new relationship?
14:39:02 <MattChan> dauwhe: a new issue, i think, where we can further discuss it
14:39:11 <dauwhe> https://github.com/w3c/epub-specs/issues/1323
14:39:15 <MattChan> TOPIC: Validation of SVG
14:39:39 <MattChan> dauwhe: this is the question of how to validate SVG, given that there are so many kinds of SVG
14:39:47 <ivan> q+
14:39:54 <MattChan> ... DTDs in SVGs interact poorly with existing validation tools
14:39:57 <dauwhe> ack ivan
14:40:10 <MattChan> ivan: first, the DTD problem has been settled
14:40:43 <MattChan> ... second, currently what we do, like with HTML, is that our references in the spec are to SVG2
14:40:54 <MattChan> ... which is what validator.nu validates against
14:41:10 <MattChan> ... so it seems like events may have dictated the way that we go
14:41:16 <dauwhe> q?
14:42:15 <MattChan> dauwhe: perhaps we should postpone this issue to a later call, we are missing some members today
14:42:33 <ivan> +1
14:43:00 <gpellegrino> +1
14:43:00 <dauwhe> https://github.com/w3c/epub-specs/issues/808
14:43:05 <MattChan> TOPIC: OCF Document: RFC3986 or RFC3987?
14:44:00 <MattChan> dauwhe: basically the question is generally how we define URLs in our spec
14:44:45 <MattChan> ... essentially how URLs work on the web is determined by the WHAT-WG
14:44:54 <ivan> +1
14:45:00 <MattChan> ... if we change our spec to refer to that instead of these RFCs then we are better off
14:45:22 <George> Agree to getting closer to the current web
14:46:02 <wendyreid> Proposal: Use the WHATWG URL specification instead of the RFCs
14:46:09 <ivan> +1
14:46:11 <wendyreid> +1
14:46:13 <MattChan> +1
14:46:13 <toshiakikoike> +1
14:46:14 <Bill_Kasdorf_> +1
14:46:18 <MasakazuKitahara> +1
14:46:18 <George> +1
14:46:25 <BenSchroeter> +1
14:46:32 <dauwhe> +1
14:46:35 <wendyreid> RESOLVED: Use the WHATWG URL specification instead of the RFCs
14:46:36 <tzviya> +1
14:46:48 <dlazin> +1
14:47:53 <gpellegrino> +1
14:49:06 <MattChan> TOPIC: AOB?
14:49:15 <ivan> q+
14:49:19 <dauwhe> ack ivan
14:50:09 <MattChan> ivan: i was looking at the list of changes on epub 3.3, and i think the spec is way way better today than it was in 3.2
14:50:26 <MattChan> ... but nobody in the community knows about this spec at the moment
14:50:28 <tzviya> q+
14:50:28 <dauwhe> q+
14:50:44 <MattChan> ... wonder if there is a way to draw epub community to our work
14:50:56 <MattChan> ... ask them to pay attention to what we've produced so far
14:51:00 <dauwhe> ack tz
14:51:08 <tzviya> https://docs.google.com/spreadsheets/d/1Jx5VvkMTQ4EL0Xfb3pDMDUiccq79mmIPHetSRfbziFM/edit?usp=sharing
14:51:20 <MattChan> tzviya: i sent an email the other day about videos for the community
14:51:31 <MattChan> ... we're looking for people to do short presentations
14:51:33 <George> q+
14:51:39 <dauwhe> ack dau
14:51:41 <MattChan> ... maybe one video could be able our changes to the spec
14:52:18 <MattChan> dauwhe: i'm wondering if now is the time for a communication like this vs when we reach CR
14:52:23 <ivan> q+
14:52:27 <MattChan> ... we could then fold in some of the testing work
14:52:52 <MattChan> ... we're going to need participation on running the tests
14:52:57 <dauwhe> ack Ge
14:53:15 <MattChan> ... we could then explain difference between what happened before between IDPF and CG, vs what is now happening with the WG
14:54:01 <dauwhe> ack iv
14:54:02 <MattChan> George: i'm doing presentations soon (IMS, etc.) and can include references to this spec work if the group wants
14:54:19 <MattChan> ivan: yes, agree to inclusion in the upcoming conferences
14:54:39 <MattChan> ... i don't think communication now excludes future communication at CR stage
14:55:30 <MattChan> ... CR stage is for when the spec design is done, in that regard, having communication earlier may avoid issues at that late stage
14:55:36 <dauwhe> q+
14:55:56 <MattChan> ... although I don't expect major issues to be raised
14:56:20 <George> q+
14:56:27 <dauwhe> ack dau
14:56:53 <dauwhe> ack ge
14:56:53 <Bill_Kasdorf_> q+
14:56:54 <MattChan> dauwhe: we've also made tremendous strides in recent weeks on closing issues
14:57:18 <MattChan> George: i don't know how to explain to someone that they should embrace epub 3 now, but also tell them that the epub 3.3 spec is much clearer
14:57:30 <MattChan> ... can i say that there is complete backwards compat?
14:57:33 <dauwhe> ack Bi
14:57:33 <MattChan> ivan: yes
14:57:46 <BenSchroeter> q+
14:57:50 <dauwhe> ack Ben
14:57:56 <MattChan> Bill_Kasdorf_: another reason for having people outside the group reading the spec is to surface things that they don't understand
14:58:25 <dauwhe> q?
14:58:33 <MattChan> BenSchroeter: the transition from IDPF to W3C is a significant thing to mention to outside parties, even if we don't get into the specifics of how the spec has changed
14:59:09 <MattChan> dauwhe: okay, thank you everyone, we'll see you next week!
14:59:16 <ivan> rrsagent, draft minutes
14:59:16 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/07-epub-minutes.html ivan
14:59:50 <ivan> zakim, end meeting
14:59:50 <Zakim> As of this point the attendees have been dauwhe, wendyreid, toshiakikoike, ivan, MasakazuKitahara, MattChan, George, BenSchroeter, tzviya, gpellegrino, dlazin, laurent__,
14:59:53 <Zakim> ... Bill_Kasdorf_
14:59:53 <Zakim> RRSAgent, please draft minutes
14:59:53 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/07-epub-minutes.html Zakim
14:59:55 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
14:59:59 <Zakim> Zakim has left #epub
15:00:09 <ivan> rrsagent, bye
15:00:09 <RRSAgent> I see no action items