EPUB 3 Working Group Telco — Minutes

Date: 2021-06-18

See also the Agenda and the IRC Log

Attendees

Present: Gregorio Pellegrino, Masakazu Kitahara, Wendy Reid, Matthew Chan, Romain Deltour, Ivan Herman, George Kerscher, Deborah Kaplan, Toshiaki Koike, Brady Duga, Ben Schroeter, Matt Garrish, Ken Jones, Bill Kasdorf, Hadrien Gardeur

Regrets: Dave Cramer

Guests:

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

1. Does/should EPUB support the <base> element?

See github issue #1699.

Wendy Reid: this came up in last week’s session in discussion about root-relative URLs, HTML base, etc.
… perhaps we recommend authors not use it? or avoid discussing it entirely?

Ivan Herman: problem i see is what it means if base is given the value of a relative URI
… an absolute URL value is also problematic because it goes out of the package
… and then mgarrish pointed out that it makes it complicated if we start specifying how HTML elements can be used
… so I think we should just discourage using it

Matt Garrish: if we’re discouraging xml:base, we might as well do same for HTML base to keep some consistency
… no formal warning, but just advice to discourage

Romain Deltour: q_

Romain Deltour: why is the discouraged constructs section not normative?

Matt Garrish: we don’t really want to step in and start forbidding things that are in HTML
… just that these HTML things don’t make sense in epub, really
… so we say we don’t think authors should be using them

Romain Deltour: okay, makes sense

Matt Garrish: probably just an info message in epubcheck or something

Wendy Reid: there was one comment in support of allowing it, but no real rationale provided with that comment

Romain Deltour: do we have any sense of RS support for this element?

Wendy Reid: i’ve never seen it

Romain Deltour: no, me neither to be honest

Brady Duga: same

Ivan Herman: i’ve rarely even seen it in HTML

Proposed resolution: Discourage the use of <base> in EPUB, close issue 1699 (Wendy Reid)

Ivan Herman: +1

Matt Garrish: +1

Matthew Chan: +1

Ben Schroeter: +1

Romain Deltour: +1

Masakazu Kitahara: +1

Brady Duga: +1

Toshiaki Koike: +1

Deborah Kaplan: +1

Bill Kasdorf: +1

Wendy Reid: +1

Gregorio Pellegrino: +1

George Kerscher: +1

Resolution #1: Discourage the use of <base> in EPUB, close issue 1699

2. What is the relationship between URLs and the package doc (what is home?)

See github issue #1681, #1374, #1687, #1686.

Wendy Reid: we started this discussion last week. Core question is: Where is home (given we allow both relative and absolute URLs) in the epub context

Romain Deltour: 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
… 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
… also, i think we should look into question of what is home first, and that will inform what to do with root-relative URLs

Wendy Reid: okay, so what is the IRI of the package document then?

Ivan Herman: we can’t really answer what the IRI of the package is, and i’m not sure we should try
… rather, what do we expect RS to do conceptually?
… who epub structure relies on the idea that epub is kind of a frozen website
… i think we say this is the conceptual model within which epub exists, and we should not say exactly how RS can do that
… just as long as the observable behavior is identical
… so as long as after epub is unpacked there is a root that we can refer to, it is fine
… and whether this root is the same IRI of the package or not is none of our business

Matt Garrish: 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?
… so I don’t think there can be a consistent root unless we start to enforce these things
… inside epub resources can be within the container, but that might not be true once the epub is unpacked
… e.g. do you have to unpack everything in the zip? Or just whatever is in the epub under the package?

Brady 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)
… so why do we have to define what root is if we don’t allow absolute URIs?

Matt Garrish: 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”

Romain Deltour: even with regular relative URLs, the spec is silent on what happens if the relative URL tries to go below the container root?
… and is it possible to look at RSes today and test what they do?

Ivan Herman: i was surprised to find that some RS don’t automatically unpack the whole zip
… i thought this was obvious
… but then what if there is a relative URL that is not on manifest, but also happens to be in zip?

Matt Garrish: we have requirement in OCF that all relative resources must resolve to something in container
… i don’t think that was the issue

Gregorio Pellegrino: i know that Colibrio streams files out of zip without unzipping

Wendy Reid: yes, there are more examples of RS doing that beyond that

Ivan Herman: 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
… but i’m not sure if a streaming based solution meets that conceptual model

Hadrien Gardeur: streaming from zip is what Readium does by default
… unzipping is a problem for DRM. Some expectation that you keep the epub zipped. And we’ve done some optimizations with this in mind

Romain Deltour: i’m surprised that resources that are not in the same directory tree as the OPF would not be accessible in the epub
… 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 (e.g., https://ocf.example.org))

Ivan Herman: +1 to romain

Romain Deltour: this defines unambiguously how relative URLs are to be resolved
… and we can say this URL is the root of the OCF
… this makes it so that relative URLs cannot go outside of the container
… and then RSes know what relative URLs point to

Wendy Reid: going back to romain’s point about testing, there are a variety of ways that RSes handle these URLs
… we are especially unsure what happens when files are outside the container
… so this is good reason to do some testing

Ivan Herman: would some sort of conceptual model clash with how things are implemented?

Hadrien Gardeur: 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
… but these two are most common implementations

Matt Garrish: this originally came up in multiple renditions when we had issues referencing across sibling directories
… not sure if this is still an obstacle, worth testing

Romain Deltour: drawback of conceptual solution is that sometimes adding this layer of abstraction makes spec harder to use
… so we want to respect people who are actually having to implement it

Wendy Reid: 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)

Ivan Herman: i think we should also test environment where multiple renditions is implemented
… if we end up with something that makes multiple renditions impossible, then we should just remove the multiple rendition note

Wendy Reid: do we know if a functioning implementation of multiple renditions?

Hadrien Gardeur: barnes and noble were using multiple renditions for newspapers and magazines
… not sure if they still use it

Wendy Reid: okay, so maybe we test on Nook app
… okay, so for now we test. Will have to ask Dan and the rest of the testing folk to help
… for now we don’t have consensus on any sort of language, right?

3. a11y TF note

Wendy Reid: https://w3c.github.io/epub-specs/reports/eu-a11y-mapping/

Wendy Reid: this is a mapping between requirements of EUAA and a11y spec - e.g. for each section, which part of spec addresses it
… we want to publish this as WG note

Romain Deltour: current short name for TR is ‘https://www.w3.org/TR/epub-eu-a11y-mapping/’

Gregorio Pellegrino: better use https://www.w3.org/TR/epub-a11y-eaa-mapping/

Proposed resolution: Publish the EU Accessibility 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 (Wendy Reid)

Matt Garrish: +1

Deborah Kaplan: +1

Ben Schroeter: +1

Ivan Herman: +1

Romain Deltour: +1

Matthew Chan: +1

Ken Jones: +1

Gregorio Pellegrino: +1

Brady Duga: +1

Wendy Reid: +1

Toshiaki Koike: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Resolution #2: Publish the EU Accessibility 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

Ivan Herman: because of echidna, i want to understanding structure of the document itself, for where to put it in the repo
… we don’t have to decide now, but maybe mgarrish and wendyreid can decide a more logical place to save it in the repo
… and is the document ready to go up?

Gregorio Pellegrino: yes, we’ve already had some feedback, and it is fine to be published now

Ivan Herman: have you checked the document with the publication checker?

Gregorio Pellegrino: no, not yet. Can you link me to the documentation?

Ivan Herman: mgarrish and I will go through the details with you then

4. AOB?

Brady Duga: i raised 1708, so please consult that issue

Ivan Herman: we also raised the issue of removing the pronunciation lexicon from the document
… with makoto, we later decided that we should also remove SSML, but replace both with note about these sorts of things
… but before we remove, we should have resolution of WG

Gregorio Pellegrino: 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?

Proposed resolution: Remove SSML from the core specification, include along with PLS in a separate WG note (Wendy Reid)

Ivan Herman: +1

Wendy Reid: +1

Romain Deltour: +1

Deborah Kaplan: +1

Matt Garrish: +1

Gregorio Pellegrino: +1

Masakazu Kitahara: +1

Ben Schroeter: +1

Toshiaki Koike: +1

Matthew Chan: +1

Brady Duga: +1

Bill Kasdorf: +1

Resolution #3: Remove SSML from the core specification, include along with PLS in a separate WG note

Wendy Reid: thanks everyone, see you again soon!

5. Resolutions