Meeting minutes
<wendyreid> date: 16-02-2022
<wendyreid> https://
wendyreid: We made a decision around duration with fragment selector
we will not allow them on the URL property
… I discovered that we had them in there for a reason.
… some books have a single track for multiple chapters
… This would require frag selectors for accurate nav
… If we keep this requirement, we need to make a requirement for tOC
Laurent: We don't necessarily need both. If there is no ToC, there will be no fallback other than tracks and we can hope that tracks are in sync with semantic chapters
andreas: allowing frag selectors introduces many other requirements for RS
wendyreid: I am in favor of making ToC required, but it could be challenging
… so we keep our original resolution w slightly tweaked language and add a note about importance of ToCs to fill the gap
andreas: Is Fragmented selector used today?
wendyreid: no
ivan: as far as I know the media fragment has remained a theoretical construct
wendyreid: we will hold off on merging the PR until I have made further edits
charter
wendyreid: are we currently charted in a way that we can make these changes?
ivan: do these changes adjust normative text?
wendyreid: yes
ivan: there are different classes of changes. If they are minor, then we can change them. We have to consider whether we can back them up with testing.
… if this doesn't invalidate our tests or implementations then I think it can be done
tzviya: It's clear to me that it's not clear to anyone how to implement the new process
ivan: Goal was to simplify things right?
ivan: If we update we still need to issue a call to AC
laurent: We can say that we are resolving a contradiction in the spec
<ivan> classes of changes per process
tzviya: It might not be in any of those categories; rather it could be errata
wendyreid: it looks like we can make some class 4 (new feature) changes
https://
https://
<ivan> github-bot, bye
issue 96 is whether we require a ToC and 97 is asking if we use the format of Publication Manifest
ivan: I heard Laurent saying that requiring a ToC is unrealistic
… it would invalidate most existing audiobooks
wendyreid: When we started discussions about toc, we were and still are concerned about a11y
… HTML is the most obviously accessible, but is it?
laurent: reading systems extract labels. We could provide samples of simple HTML ToCs.
… We have already done the work on Publication Manifest - let's use it
Andreas: we don't use the html. We convert it to an obj structure and then render as html, but it's no problem to parse it
laurent: In thorium I am planning basic HTML TOC with no css at all
… and we will be able to show a more structured html toc as well
… we should be clear that publishing manifest is the basis of ToC so that people don't create something else
tzviya: +1
wendyreid: we can consider re-wording "A TOC, regardless of situation, SHOULD be included"