13:39:40 <RRSAgent> RRSAgent has joined #epub
13:39:40 <RRSAgent> logging to https://www.w3.org/2021/06/18-epub-irc
13:39:42 <Zakim> RRSAgent, make logs Public
13:39:43 <Zakim> please title this meeting ("meeting: ..."), ivan
13:39:56 <ivan> ivan has changed the topic to: Meeting Agenda 2021-06-18: https://lists.w3.org/Archives/Public/public-epub-wg/2021Jun/0039.html
13:39:57 <ivan> Chair: wendy
13:39:57 <ivan> Date: 2021-06-18
13:39:57 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Jun/0039.html
13:39:57 <ivan> Meeting: EPUB 3 Working Group Telco
13:39:57 <ivan> Regrets+ dauwhe
13:52:51 <wendyreid> wendyreid has joined #epub
13:58:24 <gpellegrino> gpellegrino has joined #epub
13:59:06 <gpellegrino> present+
13:59:08 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:13 <MasakazuKitahara> present+
13:59:14 <romain> romain has joined #epub
13:59:24 <MattChan> MattChan has joined #epub
13:59:32 <wendyreid> present+
13:59:38 <toshiakikoike> toshiakikoike has joined #epub
13:59:41 <MattChan> present+
13:59:44 <dkaplan3> dkaplan3 has joined #epub
14:00:11 <romain> present+
14:00:14 <ivan> present+
14:00:31 <ivan> present+ george
14:00:37 <dkaplan3> present+
14:00:39 <ivan> present+ toshiakikoike
14:00:40 <George> George has joined #epub
14:01:11 <ivan> present+ brady
14:01:14 <BenSchroeter> BenSchroeter has joined #epub
14:01:20 <BenSchroeter> present+
14:01:26 <mgarrish> mgarrish has joined #epub
14:01:36 <duga> duga has joined #epub
14:01:38 <George> George has joined #epub
14:01:44 <duga> present+
14:01:59 <mgarrish> present+
14:02:16 <George> George has joined #epub
14:02:24 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:02:27 <toshiakikoike> present+
14:02:50 <George> George has joined #epub
14:03:19 <MattChan> scribe+
14:03:37 <wendyreid> https://github.com/w3c/epub-specs/issues/1699
14:03:40 <MattChan> TOPIC: Does/should EPUB support the <base> element?
14:04:16 <MattChan> wendyreid: this came up in last week's session in discussion about root-relative URLs, HTML base, etc.
14:04:31 <ivan> q+
14:04:51 <wendyreid> ack ivan
14:04:52 <MattChan> ... perhaps we recommend authors not use it? or avoid discussing it entirely?
14:05:12 <Ken_Jones> Ken_Jones has joined #epub
14:05:29 <MattChan> ivan: problem i see is what it means if base is given the value of a relative URI
14:05:36 <George> George has joined #epub
14:06:00 <MattChan> ... and then mgarrish pointed out that it makes it complicated if we start specifying how HTML elements can be used
14:06:13 <MattChan> ... so I think we should just discourage using it
14:06:17 <mgarrish> q+
14:06:21 <wendyreid> ack mgarrish
14:06:41 <George> George has joined #epub
14:06:43 <MattChan> mgarrish: if we're discouraging XML:base, we might as well do same for HTML base to keep some consistency
14:06:59 <MattChan> ... no formal warning, but just advice to discourage
14:07:13 <romain> q_
14:07:14 <romain> q+
14:07:17 <wendyreid> ack romain
14:07:35 <MattChan> romain: why is the discouraged constructs section not normative?
14:07:54 <MattChan> mgarrish: we don't really want to step in and start forbidding things that are in HTML
14:08:02 <MattChan> ... just that these HTML things don't make sense in epub, really
14:08:16 <MattChan> ... so we say we don't think authors should be using them
14:08:20 <MattChan> romain: okay, makes sense
14:08:40 <MattChan> mgarrish: probably just an info message in epubcheck or something
14:08:41 <George> George has joined #epub
14:08:48 <ivan> present+ Ken_Jones
14:08:54 <romain> q+
14:09:00 <wendyreid> ack romain
14:09:00 <MattChan> wendyreid: there was one comment in support of allowing it, but no real rationale provided with that comment
14:09:10 <MattChan> romain: do we have any sense of RS support for this element?
14:09:16 <MattChan> wendyreid: i've never seen it
14:09:18 <Bill_Kasdorf> present+
14:09:18 <George> George has joined #epub
14:09:24 <MattChan> romain: no, me neither to be honest
14:09:26 <MattChan> duga: same
14:09:34 <MattChan> ivan: i've rarely even seen it in HTML
14:09:55 <George> George has joined #epub
14:10:17 <wendyreid> Proposed: Discourage the use of <base> in EPUB, close issue 1699
14:10:21 <ivan> +1
14:10:22 <mgarrish> +1
14:10:22 <MattChan> +1
14:10:24 <BenSchroeter> +1
14:10:24 <romain> +1
14:10:24 <MasakazuKitahara> +1
14:10:24 <duga> +1
14:10:24 <toshiakikoike> +1
14:10:25 <dkaplan3> +1
14:10:29 <Bill_Kasdorf> +1
14:10:30 <wendyreid> +1
14:10:33 <gpellegrino> +1
14:10:36 <George> +1
14:10:42 <wendyreid> RESOLVED: Discourage the use of <base> in EPUB, close issue 1699
14:10:57 <wendyreid> https://github.com/w3c/epub-specs/issues/1681
14:10:58 <MattChan> TOPIC: What is the relationship between URLs and the package doc (what is home?)
14:11:35 <MattChan> wendyreid: we started this discussion last week. Core question is: Where is home (given we allow both relative and absolute URLs) in the epub context
14:11:51 <romain> q+
14:11:54 <wendyreid> ack romain
14:12:28 <MattChan> romain: we have to keep in mind: 1) what things have to be put in epub core spec, and 2) what are the rules for epub RS spec
14:12:41 <George> George has joined #epub
14:12:58 <MattChan> ... later is more important because we can say whatever we want in core, but authors may deviate, and then it is up to RS to decide how to react
14:13:42 <MattChan> ... also, i think we should look into question of what is home first, and that will inform what to do with root-relative URLs
14:14:12 <wendyreid> https://github.com/w3c/epub-specs/issues/1374
14:14:24 <ivan> q+
14:14:26 <MattChan> wendyreid: okay, so what is the IRI of the package document then?
14:14:38 <wendyreid> ack ivan
14:14:41 <George> George has joined #epub
14:15:05 <MattChan> ivan: we can't really answer what the IRI of the package is, and i'm not sure we should try
14:15:14 <MattChan> ... rather, what do we expect RS to do conceptually?
14:15:15 <mgarrish> q+
14:15:29 <MattChan> ... who epub structure relies on the idea that epub is kind of a frozen website
14:15:59 <duga> q+
14:16:13 <MattChan> ... i think we say this is the conceptual model within which epub exists, and we should not say exactly how RS can do that
14:16:15 <Hadrien> Hadrien has joined #epub
14:16:19 <Hadrien> present+
14:16:24 <MattChan> ... just as long as the observable behavior is identical
14:16:41 <George> George has joined #epub
14:17:00 <MattChan> ... so as long as after epub is unpacked there is a root that we can refer to, it is fine
14:17:14 <wendyreid> ack mgarrish
14:17:21 <MattChan> ... and whether this root is the same IRI of the package or not is none of our business
14:17:46 <MattChan> mgarrish: we have 2 issues, 1) are these resources within the container and how do we determine that? 2) what happens when you unpack, and where do these resources go?
14:18:03 <MattChan> ... so I don't think there can be a consistent root unless we start to enforce these things
14:18:16 <romain> q+
14:18:27 <MattChan> ... inside epub resources can be within the container, but that might not be true once the epub is unpacked
14:18:41 <George> George has joined #epub
14:18:50 <gpellegrino> q+
14:18:56 <MattChan> ... e.g. do you have to unpack everything in the zip? Or just whatever is in the epub under the package?
14:18:58 <ivan> q+
14:19:07 <wendyreid> ack duga
14:19:58 <MattChan> duga: so absolute URIs are not allowed, and what relative IRI is interpreted by the language in question (e.g. HTML, or CSS, depending on what type of document it is)
14:20:02 <gpellegrino> q-
14:20:03 <wendyreid> ack romain
14:20:10 <MattChan> ... so why do we have to define what root is if we don't allow absolute URIs?
14:20:41 <George> George has joined #epub
14:21:15 <MattChan> mgarrish: i think the issue is root-relative is still a relative path, so do we have to say "all relative is allowed, except _root_ relative"
14:21:45 <MattChan> romain: even with regular relative URLs, the spec is silent on what happens if the relative URL tries to go below the container root?
14:22:03 <mgarrish> q+
14:22:08 <MattChan> ... and is it possible to look at RSes today and test what they do?
14:22:09 <wendyreid> ack ivan
14:22:41 <George> George has joined #epub
14:22:41 <gpellegrino> q+
14:22:41 <MattChan> ivan: i was surprised to find that some RS don't automatically unpack the whole zip
14:23:13 <MattChan> ... i thought this was obvious
14:23:24 <wendyreid> ack mgarrish
14:23:30 <MattChan> ... but then what if there is a relative URL that is not on manifest, but also happens to be in zip?
14:24:09 <MattChan> mgarrish: we have requirement in OCF that all relative resources must resolve to something in container
14:24:14 <wendyreid> ack gpellegrino
14:24:15 <MattChan> ... i don't think that was the issue
14:24:40 <MattChan> gpellegrino: i know that Collibrio streams files out of zip without unzipping
14:24:41 <George> George has joined #epub
14:24:46 <ivan> q+
14:24:47 <Hadrien> q+
14:25:00 <wendyreid> ack ivan
14:25:03 <MattChan> wendyreid: yes, there are more examples of RS doing that beyond that
14:25:51 <MattChan> ivan: but conceptually an RS unpacks the whole zip file onto a domain (as if it were a file system). If we do that then all these concepts become clear
14:25:57 <romain> q?
14:26:01 <romain> q+
14:26:08 <wendyreid> ack Hadrien
14:26:28 <MattChan> ... but i'm not sure if a streaming based solution meets that conceptual model
14:26:41 <George> George has joined #epub
14:26:41 <MattChan> Hadrien: streaming from zip is what Readium does by default
14:27:30 <MattChan> ... unzipping is a problem for DRM. Some expectation that you keep the epub zipped. And we've done some optimizations with this in mind
14:28:20 <wendyreid> ack romain
14:28:41 <George> George has joined #epub
14:28:57 <MattChan> romain: i'm surprised that resources that are not in the same directory tree as the OPF would not be accessible in the epub
14:29:07 <wendyreid> q+
14:29:21 <George> George has joined #epub
14:29:28 <romain> https://ocf.example.org/
14:29:46 <MattChan> ... going back to the point about defining what should happen conceptually, the spec could say that we define a URL that must be used as the base when resolving relative URLs
14:29:58 <ivan> +1 to romain
14:30:04 <MattChan> ... this defines unambiguously how relative URLs are to be resolved
14:30:19 <MattChan> ... and we can say this URL is the root of the OCF
14:30:30 <MattChan> ... this makes it so that relative URLs cannot go outside of the container
14:30:41 <George> George has joined #epub
14:30:44 <wendyreid> ack wendyreid
14:30:45 <MattChan> ... and then RSes know what relative URLs point to
14:31:04 <ivan> q+
14:31:08 <mgarrish> q+
14:31:14 <romain> q+
14:31:30 <MattChan> wendyreid: going back to romain's point about testing, there are a variety of ways that RSes handle these URLs
14:31:46 <MattChan> ... we are especially unsure what happens when files are outside the container
14:31:46 <wendyreid> ack ivan
14:31:54 <MattChan> ... so this is good reason to do some testing
14:32:33 <MattChan> ivan: would some sort of conceptual model clash with how things are implemented?
14:32:41 <George> George has joined #epub
14:34:04 <wendyreid> ack mgarrish
14:34:16 <MattChan> Hadrien: we treat OPF as base, and that seems to work in most cases. Seems to make more sense to us than treating zip as base
14:34:23 <MattChan> ... but these two are most common implementations
14:34:41 <George> George has joined #epub
14:34:58 <wendyreid> ack romain
14:35:08 <MattChan> mgarrish: this originally came up in multiple renditions when we had issues referencing across sibling directories
14:35:15 <MattChan> ... not sure if this is still an obstacle, worth testing
14:35:20 <George> George has joined #epub
14:35:53 <MattChan> romain: drawback of conceptual solution is that sometimes adding this layer of abstraction makes spec harder to use
14:36:01 <MattChan> ... so we want to respect people who are actually having to implement it
14:36:36 <ivan> q+
14:36:39 <MattChan> wendyreid: is the best way forward at this point for us to do some sort of testing? (e.g. OPF as base, zip as base, examples of files living outside when OPF is base)
14:36:40 <wendyreid> ack ivan
14:36:41 <George> George has joined #epub
14:37:01 <MattChan> ivan: i think we should also test environment where multiple renditions is implemented
14:37:22 <George> George has joined #epub
14:37:31 <MattChan> ... if we end up with something that makes multiple renditions impossible, then we should just remove the multiple rendition note
14:37:50 <MattChan> wendyreid: do we know if a functioning implementation of multiple renditions?
14:38:06 <MattChan> Hadrien: barnes and noble were using multiple renditions for newspapers and magazines
14:38:13 <MattChan> ... not sure if they still use it
14:38:26 <MattChan> wendyreid: okay, so maybe we test on Nook app
14:38:41 <George> George has joined #epub
14:38:57 <MattChan> ... okay, so for now we test. Will have to ask Dan and the rest of the testing folk to help
14:39:19 <MattChan> ... for now we don't have consensus on any sort of language, right?
14:39:32 <wendyreid> https://w3c.github.io/epub-specs/reports/eu-a11y-mapping/
14:39:40 <MattChan> TOPIC: a11y TF note
14:40:06 <MattChan> wendyreid: this is a mapping between requirements of EUAA and a11y spec - e.g. for each section, which part of spec addresses it
14:40:15 <MattChan> ... we want to publish this as WG note
14:40:41 <George> George has joined #epub
14:41:36 <mgarrish> q+
14:41:38 <ivan> q+
14:41:52 <ivan> q-
14:42:11 <gpellegrino> q+
14:42:35 <romain> current short name for TR is 'https://www.w3.org/TR/epub-eu-a11y-mapping/'
14:42:41 <George> George has joined #epub
14:43:12 <gpellegrino> https://www.w3.org/TR/epub-eaa-a11y-mapping/
14:43:29 <gpellegrino> https://www.w3.org/TR/epub-a11y-eaa-mapping/
14:44:37 <wendyreid> Proposed: Publish the EU Accessiblity Mapping as a working group note, with the short name of "epub-a11y-eaa-mapping", and use the ECHIDNA publishing system to update when working group needs to
14:44:40 <mgarrish> +1
14:44:41 <dkaplan3> +1
14:44:41 <George> George has joined #epub
14:44:41 <BenSchroeter> +1
14:44:41 <ivan> +1
14:44:42 <romain> +1
14:44:43 <MattChan> +1
14:44:43 <Ken_Jones> +1
14:44:45 <gpellegrino> +1
14:44:47 <duga> +1
14:44:48 <wendyreid> +1
14:44:50 <toshiakikoike> +1
14:44:50 <Bill_Kasdorf> +1
14:44:51 <MasakazuKitahara> +1
14:44:55 <gpellegrino> q+
14:44:56 <ivan> q+
14:45:00 <wendyreid> RESOLVED: Publish the EU Accessiblity Mapping as a working group note, with the short name of "epub-a11y-eaa-mapping", and use the ECHIDNA publishing system to update when working group needs to
14:45:08 <wendyreid> ack mg
14:45:12 <wendyreid> ack gpellegrino
14:45:19 <George> George has joined #epub
14:45:43 <wendyreid> ack ivan
14:46:39 <MattChan> ivan: because of echidna, i want to understanding structure of the document itself, for where to put it in the repo
14:46:41 <George> George has joined #epub
14:47:00 <MattChan> ... we don't have to decide now, but maybe mgarrish and wendyreid can decide a more logical place to save it in the repo
14:47:08 <MattChan> ... and is the document ready to go up?
14:47:22 <MattChan> gpellegrino: yes, we've already had some feedback, and it is fine to be published now
14:47:41 <MattChan> ivan: have you checked the document with the publication checker?
14:47:56 <MattChan> gpellegrino: no, not yet. Can you link me to the documentation?
14:48:09 <MattChan> ivan: mgarrish and I will go through the details with you then
14:48:27 <ivan> q+
14:48:28 <MattChan> TOPIC: AOB?
14:48:38 <mgarrish> q+
14:48:41 <George> George has joined #epub
14:49:08 <wendyreid> ack ivan
14:49:12 <MattChan> duga: i raised 1708, so please consult that issue
14:49:15 <mgarrish> q-
14:49:36 <MattChan> ivan: we also raised the issue of removing the pronunciation lexicon from the document
14:50:00 <gpellegrino> q+
14:50:07 <MattChan> ... with makoto, we later decided that we should also remove SSML, but replace both with note about these sorts of things
14:50:09 <wendyreid> ack gpellegrino
14:50:18 <MattChan> ... but before we remove, we should have resolution of WG
14:50:41 <George> George has joined #epub
14:51:18 <MattChan> gpellegrino: I agree. This also seems to relate to a discussion we had in a11y TF about a note to differentiate between MO and TTS. Can this be the same note?
14:52:03 <wendyreid> Proposed: Remove SSML from the core specification, include along with PLS in a separate WG note
14:52:07 <ivan> +1
14:52:08 <wendyreid> +1
14:52:09 <romain> +1
14:52:09 <dkaplan3> +1
14:52:10 <mgarrish> +1
14:52:10 <gpellegrino> +1
14:52:12 <MasakazuKitahara> +1
14:52:13 <BenSchroeter> +1
14:52:13 <toshiakikoike> +1
14:52:14 <MattChan> +1
14:52:16 <duga> +1
14:52:17 <Bill_Kasdorf> +1
14:52:22 <wendyreid> RESOLVED: Remove SSML from the core specification, include along with PLS in a separate WG note
14:52:37 <George> George has joined #epub
14:53:10 <MattChan> wendyreid: thanks everyone, see you again soon!
14:53:10 <dkaplan3> dkaplan3 has left #epub
14:53:39 <ivan> rrsagent, draft minutes
14:53:39 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/18-epub-minutes.html ivan
14:53:41 <George> George has joined #epub
14:54:49 <ivan> zakim, end meeting
14:54:49 <Zakim> As of this point the attendees have been gpellegrino, MasakazuKitahara, wendyreid, MattChan, romain, ivan, george, dkaplan, toshiakikoike, brady, BenSchroeter, duga, mgarrish,
14:54:52 <Zakim> ... Ken_Jones, Bill_Kasdorf, Hadrien
14:54:52 <Zakim> RRSAgent, please draft minutes
14:54:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/18-epub-minutes.html Zakim
14:54:54 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
14:54:58 <Zakim> Zakim has left #epub
14:55:04 <ivan> rrsagent, bye
14:55:04 <RRSAgent> I see no action items