13:05:57 <RRSAgent> RRSAgent has joined #epub
13:05:57 <RRSAgent> logging to https://www.w3.org/2021/03/26-epub-irc
13:05:59 <Zakim> RRSAgent, make logs Public
13:06:00 <Zakim> please title this meeting ("meeting: ..."), ivan
13:06:52 <ivan> ivan has changed the topic to: Meeting Agenda 2021-03-26: https://lists.w3.org/Archives/Public/public-epub-wg/2021Mar/0024.html
13:06:53 <ivan> Chair: dauwhe
13:06:53 <ivan> Date: 2021-03-26
13:06:53 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Mar/0024.html
13:06:53 <ivan> Meeting: EPUB 3 Working Group Telco
13:06:53 <ivan> Regrets+
13:07:01 <ivan> regrets=
13:50:23 <George> George has joined #epub
13:56:13 <ivan> present+
13:56:20 <ivan> present+ George
13:56:35 <wendyreid> wendyreid has joined #epub
13:56:36 <MattChan> MattChan has joined #epub
13:57:09 <ivan> present+ avneesh
13:57:30 <avneeshsingh> avneeshsingh has joined #epub
13:57:39 <avneeshsingh> present+
13:57:53 <dauwhe> guest+
13:58:07 <ivan> present+ circularken
13:58:13 <ivan> present+ MattChan
13:58:59 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:01 <toshiakikoike> toshiakikoike has joined #epub
13:59:02 <George> present+
13:59:03 <mgarrish> mgarrish has joined #epub
13:59:08 <MasakazuKitahara> present+
13:59:14 <toshiakikoike> present+
13:59:41 <circularken_> circularken_ has joined #epub
13:59:49 <ivan> present+ wendyreid
14:00:10 <gpellegrino> gpellegrino has joined #epub
14:00:51 <juliette_mcshane> juliette_mcshane has joined #epub
14:00:57 <juliette_mcshane> present+
14:00:57 <mgarrish> present+
14:01:59 <ivan> present+ clapierre
14:02:58 <MattChan> scribe+
14:03:16 <ivan> present+ teenya
14:03:30 <Teenya> Teenya has joined #epub
14:03:35 <Teenya> present+
14:03:45 <ivan> present+ dlazin
14:03:47 <MattChan> dauwhe: I believe we have a new member of the wg?
14:04:03 <ivan> present+ brady
14:04:17 <duga> duga has joined #epub
14:04:33 <duga> present+
14:04:51 <ivan> present+ billk
14:05:01 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:05:13 <MattChan> dan: I work at google. Have a diverse background. Not an epub expert yet. But I worked as designer and a technical writer. Have worked tangentially in publishing.
14:05:50 <CharlesL> CharlesL has joined #epub
14:05:50 <MattChan> ... interested in the cross platform compat of epubs
14:05:58 <CharlesL> present+
14:06:03 <dauwhe> https://github.com/w3c/epub-specs/pull/1584
14:06:11 <MattChan> TOPIC: PR Clarifying non-linear items
14:06:16 <dauwhe> https://github.com/w3c/epub-specs/issues/1480#issuecomment-764842519
14:06:21 <ivan> topic: Clarify that non-linear content can be skipped over not suppressed completely
14:06:23 <MattChan> dauwhe: much of what we are talking about is in the comment to this issue
14:06:35 <MattChan> ... there is some history to linear=no
14:06:55 <MattChan> ... items are linear=yes when they are in reading order
14:06:59 <duga> q+
14:07:01 <MattChan> ... but we don't say what to do when linear=no
14:07:02 <Hadrien> Hadrien has joined #epub
14:07:02 <ivan> scribejs, issue 1480
14:07:07 <Hadrien> present +
14:07:11 <ivan> scribejs, pr 1584
14:07:17 <MattChan> ... most common implementation seems to have linear=no content only appear when link is clicked
14:07:18 <dlazin> dlazin has joined #epub
14:07:27 <duga> q-
14:07:48 <dlazin> present+
14:07:49 <MattChan> ... belief that that content can be suppressed, but we wanted to clarify that that content must be reachable if explicitly clicked
14:07:52 <ivan> present+ hadrien
14:08:26 <MattChan> duga: linear=no was put in for publishers, to better control what RSes was doing with order of their content
14:09:00 <MattChan> dauwhe: one of the issues was with cover images right? sometimes in the spine, sometimes in metadata?
14:09:13 <MattChan> duga: no, this was more about content at the end. e.g. footnotes
14:09:39 <ivan> q+
14:09:53 <MattChan> ... where each footnote is in its own document, but only linked to the main book, not in reading order
14:10:08 <MattChan> ... so without linear the footnotes would sometimes appear in random order at the end of the book
14:10:23 <dauwhe> ack ivan
14:10:24 <MattChan> dauwhe: i think some RS will also just move all linear=no content at the end regardless
14:11:06 <MattChan> ivan: just to clarify, e.g. i have a complex illustration that i don't want in the text, like an svg, and there is a reference to it, is this an example of linear=no?
14:11:34 <MattChan> duga: if you have a link to that from something in your spine, then yes, that would be a use for linear=no
14:11:51 <MattChan> dauwhe: and in some RS clicking that sort of link would open that content in a window in front of the text
14:12:00 <CharlesL> q+
14:12:07 <dauwhe> ack cha
14:12:17 <MattChan> duga: its essentially metadata about this piece of content that enables RS to make informed decision about how to process this piece of content in its UI
14:12:27 <ivan> present+ gregorio
14:12:37 <gpellegrino> present+
14:13:03 <MattChan> CharlesL: we just had a example where extended image descriptions were marked as linear=no and but some RSes were still showing it where it appeared in the spine
14:13:23 <dauwhe> q?
14:13:26 <MattChan> ... this was kind of counter intuitive
14:13:57 <MattChan> duga: if its a link then it has to show up in the spine, so RSes that want to show it know where to do so
14:14:07 <mgarrish> q+
14:14:20 <MattChan> ... this kind of goes back to the ideological debate of whether ebooks should replicate limitations of print
14:14:48 <MattChan> ... some RS are going to show all content, and some won't
14:14:57 <MattChan> ... linear doesn't change that
14:15:10 <dauwhe> ack mg
14:15:27 <MattChan> ... it just allows publishers to have some control over whether it appears at the back of the book vs some other location
14:15:37 <Teenya_> Teenya_ has joined #epub
14:16:23 <MattChan> mgarrish: from a RS "make it render consistently" point of view, I'm not sure we can solve that
14:16:48 <MattChan> ... from a user perspective, that's why we wanted to give users an option to skip linear=no content or not
14:17:22 <MattChan> dauwhe: there's so much existing content that i'm not sure there is a path towards uniform behaviour of the linear attribute
14:17:32 <MattChan> ... that said, i think the clarifying language of the PR is good
14:17:43 <ivan> q+
14:17:47 <MattChan> ... just underlining that RS must still show linear=no content if the user clicks a link
14:17:47 <dauwhe> ack iv
14:18:17 <MattChan> ... and not just suppress that content
14:18:31 <MattChan> ivan: the current text uses a lot of MAYs
14:18:49 <MattChan> ... i just want to be sure that this is as far as we can go
14:18:51 <Hadrien> q+
14:19:15 <dauwhe> ack h
14:19:48 <mgarrish> q+
14:19:52 <MattChan> Hadrien: in Readium community (Thorium etc.), we decided 3 years ago that if something is marked as linear=no then you won't encounter if you're just moving forward through a pub, but that you will see it if accessed via a link
14:19:56 <MattChan> ... this was not a hard decision
14:20:03 <MattChan> ... but how do you present these resources?
14:20:31 <MattChan> ... some people think that linear=no resource should behave like the rest of the content (i.e. if everything is normally paginated, then it should also be paginated)
14:20:39 <MattChan> ... but it could also be scrolled etc.
14:20:54 <MattChan> ... it may not be wg's role to deal with this, but it is a problem lacking a solution
14:21:04 <dauwhe> q?
14:21:06 <dauwhe> ack mg
14:21:22 <MattChan> ... even when we simply the scenario, by excluding desktop user case, for example, there is still disagreement about what to do with it
14:21:48 <dauwhe> q?
14:22:36 <wendyreid> q+
14:22:41 <MattChan> ivan: so, the maximum we can do at this point in terms of the PR is to say yes, but i don't know whether we are in position to put the various alternatives of what can happen (along the lines of what Hadrien just discussed)
14:22:50 <MattChan> ... but that can be a separate issue
14:23:06 <MattChan> ... and maybe have it somewhere in spec as note
14:23:15 <dauwhe> ack we
14:23:29 <MattChan> ... as it currently stands, you are in for a surprise, not even sure what behaviour to expect
14:23:41 <MattChan> wendyreid: we get very similar comments about how we handle footnotes
14:23:58 <MattChan> ... need clarity about what to do with content that is linked from main text, but not necessarily required for main text
14:24:13 <MattChan> ... e.g. is it a pop-up, or does the link take you somewhere else, etc.
14:24:27 <MattChan> dauwhe: can we resolve on accepting PR?
14:24:27 <wendyreid> Proposed: Close PR 1584 with the new language around linear="no", close issue 1480
14:24:35 <duga> +1
14:24:37 <mgarrish> +1
14:24:38 <gpellegrino> +1
14:24:41 <MasakazuKitahara> +1
14:24:43 <wendyreid> +1
14:24:44 <toshiakikoike> +1
14:24:44 <juliette_mcshane> +1
14:24:45 <MattChan> +1
14:24:48 <Bill_Kasdorf> +1
14:24:49 <dlazin> +1
14:24:50 <Hadrien> +1
14:24:52 <CharlesL> +1
14:24:52 <ivan> +1
14:25:15 <wendyreid> Resolved: Close PR 1584 with the new language around linear="no", close issue 1480
14:25:44 <dauwhe> q?
14:25:54 <MattChan> TOPIC: Data URLs PR
14:26:00 <dauwhe> https://github.com/w3c/epub-specs/pull/1582
14:26:22 <ivan> https://github.com/w3c/epub-specs/issues/1564
14:26:34 <MattChan> mgarrish: this is from what we discussed last week's call
14:26:45 <MattChan> ... where do we allow data URLs, etc.
14:27:03 <duga> q+
14:27:07 <MattChan> ... browsers are starting to disallow navigation to data URLs (to circumvent security issues)
14:27:28 <MattChan> ... so last week we said we would follow that path, but still allow embedding content via data URLs
14:27:55 <MattChan> ... plus we were going to say that we wouldn't allow data URLs as spine docs
14:28:07 <MattChan> ... how to phrase this was kind of complicated
14:28:20 <dauwhe> q?
14:28:25 <MattChan> ... the language uses "top level browsing"
14:28:39 <MattChan> ... but some RSes don't use a browser based model
14:29:03 <dauwhe> ack du
14:29:13 <MattChan> ... so we say that in those cases, they still have to treat the data URLs similar to the way that a browser would
14:29:33 <MattChan> duga: its hard to get the language right so that we don't disallow things by mistake, or allow things by mistake
14:30:01 <MattChan> ... e.g. when an RS wants to provide the ability to let user pop out content embedded via data URL in a separate window
14:30:27 <MattChan> ... wonder if there is another group working on specifying how this should work?
14:30:50 <MattChan> ... or are we on the bleeding edge here? Would rather not be the ones who set this standard
14:31:09 <MattChan> mgarrish: this very much seems to be raised and discussed in the browser realm
14:31:15 <ivan> q+
14:31:23 <MattChan> ... potentially a part of the HTML spec
14:31:33 <MattChan> ... but nothing I can point to specifically
14:31:34 <dauwhe> ack iv
14:31:55 <MattChan> ivan: this PR does a lot that is not contentious, i think
14:32:28 <MattChan> ... i propose to merge PR as it is, subject to the nitty gritty about the exact terminology
14:32:50 <MattChan> ... but then open an issue saying that this terminology still has to be checked with TAG and HTML community
14:33:04 <MattChan> ... and link to our language
14:33:13 <MattChan> ... that way we specifically flag this for TAG input
14:33:20 <dauwhe> q?
14:33:29 <MattChan> ... the new issue would be more focused
14:33:37 <mgarrish> q+
14:33:40 <MattChan> ... and in the meantime we capture everything else in the PR
14:33:40 <duga> q+
14:33:42 <dauwhe> ack iv
14:34:00 <MattChan> mgarrish: in that light, do we maybe want to keep the authoring side requirements, but leave out the RS expectations side?
14:34:21 <dauwhe> ack du
14:34:38 <MattChan> ivan: pref trying to do something now, even with it being incomplete
14:34:51 <MattChan> duga: would refer this to TAG, yes
14:35:12 <MattChan> ivan: also, let's mark issues as explicitly "referred to TAG for input"
14:35:25 <MattChan> dauwhe: i'm only with merging for now, on understanding that this is not final final
14:35:45 <dauwhe> q?
14:35:48 <MattChan> s/i'm only/i'm okay
14:35:50 <dauwhe> ack mg
14:36:07 <wendyreid> Proposed: Merge PR 1582, open issue for TAG review
14:36:13 <ivan> +1
14:36:15 <wendyreid> +1
14:36:16 <mgarrish> +1
14:36:17 <CharlesL> +1
14:36:19 <MattChan> +1
14:36:19 <duga> +`
14:36:22 <duga> +1
14:36:23 <Bill_Kasdorf> +1
14:36:48 <wendyreid> Resolved: Merge PR 1582, open issue for TAG review
14:37:10 <dauwhe> https://github.com/w3c/epub-specs/issues/1129
14:37:23 <MattChan> TOPIC: Extending "role" in contributor metadata
14:37:50 <MattChan> dauwhe: this came up early in epub 3.2 in CG
14:38:07 <MattChan> ... can you have more than one metaproperty role pointing to meta element
14:38:13 <MattChan> ... schema said 0 or 1
14:38:35 <MattChan> ... CG felt it would be tricky for RS to do anything else, and there wasn't a lot of demand for change at the time
14:38:37 <mgarrish> q+
14:38:56 <dauwhe> ack mg
14:39:00 <MattChan> ... but recently people have been using role property to reflect fact that each contributor can do multiple things for publication
14:39:18 <MattChan> mgarrish: part of the restriction is because we had the OPF role attribute role in epub
14:39:23 <MattChan> ... and we were trying to match things up
14:39:31 <MattChan> ... i'm not sure its critical anyway
14:39:32 <dauwhe> q+
14:39:37 <MattChan> ... not harmful to have multiple roles
14:39:47 <MattChan> ... happy to let people do what they want with metadata
14:40:01 <Bill_Kasdorf> q+
14:40:18 <MattChan> ... for epub2 compat, maybe an informative note that you may want to limit yourself to 1 role
14:40:21 <ivan> ack dauwhe
14:40:23 <Hadrien> q+
14:40:30 <MattChan> dauwhe: more RS i'm aware of won't display this to end user at all
14:40:32 <dauwhe> ack bill
14:40:46 <dlazin> q+
14:40:57 <MattChan> Bill_Kasdorf: allowing this might be good just for removing friction for publishers
14:41:01 <MattChan> ... really common
14:41:01 <gpellegrino> q+
14:41:07 <dauwhe> ack had
14:41:11 <MattChan> ... so maybe let's allow it if it does no harm
14:41:26 <MattChan> Hadrien: from Readium perspective, we could support it
14:41:36 <Bill_Kasdorf> q+
14:41:47 <MattChan> ... we could parse it, make it easy to work with, and then its up to the RS to do with that what they want
14:42:04 <dauwhe> ack dl
14:42:11 <MattChan> ... and then about OPF, for some RSes its the only metadata they have
14:42:53 <MattChan> Dan: given that we are currently saying 0 to 1, but publishers are saying they have lots of ebooks where this is already >1, should we recommend that if there is more than 1 then it should be in priority order?
14:43:18 <MattChan> ... as an author, you don't know about RS behaviour. You just want to know what is the best value to populate
14:43:26 <dauwhe> q?
14:43:40 <ivan> +1 to dlazin
14:43:46 <dauwhe> ack gp
14:43:55 <MattChan> gpellegrino: my Q is about ONIX
14:44:26 <Hadrien> q+
14:44:27 <MattChan> ... in ONIX do you have to duplicate the contributor, or can the contributor have multiple roles?
14:44:33 <dauwhe> ack bill
14:45:00 <MattChan> Bill_Kasdorf: this is really common in higher ed publishing
14:45:31 <dauwhe> ack h
14:45:38 <MattChan> ... highly likely that they'd need to be able to do this
14:45:48 <MattChan> Hadrien: disagree that we should try to align with ONIX
14:46:03 <MattChan> ... its not produced by the same people
14:46:16 <MattChan> ... one person does OPF, and often someone else does ONIX
14:46:34 <MattChan> ... repeating roles rather than repeating author is more elegant
14:46:59 <MattChan> dauwhe: ONIX cardinality for contributor is that each can have multiple roles
14:47:00 <dauwhe> q?
14:47:12 <ivan> q+
14:47:21 <CharlesL> q+
14:47:25 <dauwhe> ack iv
14:47:28 <MattChan> ... i'm seeing strong support to relax this restriction, to allow cardinality of multiple
14:47:37 <duga> q+
14:47:44 <MattChan> ivan: agree, but i think we should also make it clear that they should be in priority order
14:47:47 <mgarrish> q+
14:47:47 <dauwhe> ack ch
14:48:19 <dauwhe> ack du
14:48:43 <MattChan> CharlesL: i just created book for diagram center that had multiple contributors, and there i had to add in all these roles for each contributor. Would have loved to have been able to do this in the epub as well.
14:48:58 <Bill_Kasdorf> q+
14:49:23 <MattChan> duga: for priority, i could seen some RS taking the first one, and some taking the last one
14:49:27 <dauwhe> ack mg
14:49:42 <MattChan> mgarrish: can we also agree to 1583?
14:49:49 <dauwhe> ack bil
14:50:22 <ivan> https://github.com/w3c/epub-specs/issues/1583
14:51:09 <wendyreid> Proposed: Relax the restriction on cardinality for OPF metadata
14:51:18 <ivan> +1
14:51:19 <dauwhe> q?
14:51:20 <CharlesL> +1
14:51:21 <MattChan> +1
14:51:22 <duga> +1
14:51:23 <Bill_Kasdorf> +1
14:51:25 <gpellegrino> +1
14:51:25 <circularken_> +1
14:51:25 <wendyreid> +1
14:51:29 <juliette_mcshane> +1
14:51:30 <toshiakikoike> +1
14:51:31 <MasakazuKitahara> +1
14:51:42 <wendyreid> Resolved: Relax the restriction on cardinality for OPF metadata
14:51:49 <MattChan> wendyreid: so we'll leave to mgarrish to draft amending language
14:52:26 <MattChan> George: does this trigger a change to our schemas, and who if so, who does that?
14:52:35 <MattChan> mgarrish: there's going to be a need to change epubcheck, yes
14:52:53 <MattChan> ivan: let's let romain, etc. know
14:53:06 <MattChan> wendyreid: there's a corresponding issue in epubcheck repo
14:53:18 <MattChan> ivan: so let's comment in their issue to let them know the resolution here?
14:53:29 <MattChan> wendyreid: i'll do that yes, once we have the comment with the resolution in
14:53:30 <avneeshsingh> q+
14:53:35 <dauwhe> ack av
14:53:57 <MattChan> avneeshsingh: about epubcheck, this change is for epub 3.3, but epubcheck is on epub 3.2 right now
14:54:07 <MattChan> ... so we'd have to request an exception to epub 3.2 compliance
14:54:33 <MattChan> dauwhe: can we do an errata to 3.2 or.... Ivan?
14:55:22 <MattChan> ivan: that goes a little beyond the current topic
14:55:34 <MattChan> ... not sure that this should be an exception
14:55:51 <MattChan> ... we've already made changes to media type, security related issues, that are very much on the same level
14:56:12 <MattChan> ... perhaps some epubcheck issues could be tagged that they've already been changed in 3.3
14:56:24 <MattChan> ... and then leave it up to epubcheck group to determine how they want to handle that
14:57:11 <dauwhe> q?
14:57:22 <ivan> q+
14:57:34 <mgarrish> q+
14:57:48 <dauwhe> ack iv
14:58:00 <MattChan> avneeshsingh: e.g. in prior spec, when we changed requirement related to order of toc, we discovered that this caused issues for jp publishers
14:58:20 <MattChan> ... in that case we made a special request for epubcheck to deviate from spec
14:58:57 <MattChan> ivan: i don't think we should be prescribing to epubcheck how to prioritize their tasks
14:59:12 <MattChan> avneeshsingh: agreed, this wg just provides recommendations
14:59:42 <dauwhe> ack mg
15:00:08 <MattChan> ivan: we've been fairly good in documenting our decision making, maybe this is enough of a basis for epubcheck to make a decision...
15:00:31 <MattChan> mgarrish: i've been flagging things as changed already when i remember to
15:00:38 <MattChan> ivan: okay, then we should be good
15:01:30 <MattChan> dauwhe: right, thanks everyone for coming!
15:01:35 <MattChan> ... see you all next week
15:01:35 <ivan> rrsagent, draft minutes
15:01:35 <RRSAgent> I have made the request to generate https://www.w3.org/2021/03/26-epub-minutes.html ivan
15:01:46 <ivan> zakim, end meeting
15:01:46 <Zakim> As of this point the attendees have been ivan, George, avneesh, avneeshsingh, circularken, MattChan, MasakazuKitahara, toshiakikoike, wendyreid, juliette_mcshane, mgarrish,
15:01:50 <Zakim> ... clapierre, teenya, dlazin, brady, duga, billk, CharlesL, hadrien, gregorio, gpellegrino, `
15:01:50 <Zakim> RRSAgent, please draft minutes
15:01:50 <RRSAgent> I have made the request to generate https://www.w3.org/2021/03/26-epub-minutes.html Zakim
15:01:52 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:01:56 <Zakim> Zakim has left #epub
15:24:29 <duga> duga has joined #epub
15:28:02 <duga> duga has joined #epub
15:58:20 <CharlesL> CharlesL has left #epub
17:19:28 <github-bot> github-bot has joined #epub
17:20:21 <Karen> Karen has joined #epub
17:22:16 <ivan> ivan has joined #epub