12:10:17 <RRSAgent> RRSAgent has joined #pmwg
12:10:21 <RRSAgent> logging to https://www.w3.org/2026/04/16-pmwg-irc
12:10:21 <Zakim> RRSAgent, make logs Public
12:10:22 <Zakim> Meeting: Publishing Maintenance Working Group
12:10:24 <ivan> ivan has changed the topic to: Meeting Details 2026-04-16: https://lists.w3.org/Archives/Public/public-pm-wg/2026Apr/0010.html
12:10:25 <ivan> Chair: wendy
12:10:25 <ivan> Meeting: Publishing Maintenance Working Group Telco
12:10:25 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-pm-wg/2026Apr/0010.html
12:10:26 <ivan> regrets+ George
12:15:03 <ivan> regrets+ Hadrien
12:58:47 <toshiakikoike> toshiakikoike has joined #pmwg
12:59:26 <ivan> present+
12:59:29 <shiestyle> shiestyle has joined #pmwg
12:59:34 <ivan> present+ wendy
12:59:44 <toshiakikoike> present+
12:59:49 <ivan> present+ avneeshsingh
13:00:08 <AvneeshSingh> AvneeshSingh has joined #pmwg
13:00:27 <shiestyle> present+
13:01:05 <gpellegrino> gpellegrino has joined #pmwg
13:01:10 <DaleRogers> DaleRogers has joined #pmwg
13:01:20 <DaleRogers> present+
13:02:00 <Hadrien> Hadrien has joined #pmwg
13:02:05 <gpellegrino> present+
13:02:07 <AvneeshSingh> present+
13:02:22 <duga> duga has joined #pmwg
13:02:23 <ivan> regrets- hadrien
13:02:28 <duga> present+
13:02:29 <ivan> present+ hadrien
13:02:35 <CharlesL> CharlesL has joined #pmwg
13:02:41 <CharlesL> present+
13:02:41 <mgarrish> mgarrish has joined #pmwg
13:02:46 <ivan> present+ dale
13:02:56 <kimberg> kimberg has joined #pmwg
13:02:57 <ivan> present+ charles
13:03:06 <kimberg> present+
13:03:41 <ivan> present+ rdeltour
13:03:43 <mgarrish> present+
13:04:32 <mgarrish> scribe+
13:04:35 <ivan> regrets+ suneu
13:04:53 <mgarrish> wendyreid: looks like there is the possibility of making some decisions on smil issues
13:04:54 <rdeltour> rdeltour has joined #pmwg
13:05:03 <rdeltour> present+
13:05:37 <wendyreid> Topic: Playback model for media overlays - https://github.com/w3c/epub-specs/issues/2943
13:06:32 <mgarrish> Hadrien: a bit of context - I started reading media overlays when we voted to add rolls - and we're implementing this in readium swift implementation
13:06:53 <mgarrish> ... there are a number of issues in the spec that is not completely clear and can be problematic
13:07:31 <mgarrish> ... we have a discord channel where we are discussing some of the issues
13:07:53 <mgarrish> ... looking at this first issue there is very little text about what a  reading system should be doing
13:08:28 <mgarrish> ... one question is what happens when you follow a smil document when it moves around in the reading order between spine items
13:08:59 <mgarrish> ... the spec only says to play the next document after finishing
13:09:32 <mgarrish> ... a bigger question is that the specs says to load the next content document - in some cases this can get you stuck in a loop
13:10:00 <mgarrish> ... I've written about the problems in the issue including an alternate way to handle it
13:10:25 <mgarrish> ... in the discord channel we got into where do you start playback and how do you navigate within the publication once it's started
13:10:45 <mgarrish> ... we are only focusing on the second issue here - the current approach is spine-centric
13:11:23 <mgarrish> ... media overlays are quite different from the spec - you can move around out of reading order as they are no linear
13:11:32 <mgarrish> s/no linear/not linear/
13:12:06 <mgarrish> ... what I'm proposing is another way - to make a media overlays order different from the spec/spine
13:12:29 <mgarrish> ... it could avoid the cases of being stuck in loops
13:12:51 <mgarrish> ... people who have implemented media overlays in reflowable have done it differently from each other and from the spec
13:13:04 <duga> q+
13:13:10 <wendyreid> ack duga
13:13:12 <mgarrish> ... the other issue is about how to handle audio playback
13:13:51 <mgarrish> duga: I suspect you are right and we didn't look at the spec when we implemented for play books and we figured it out for ourselves
13:14:39 <mgarrish> ... but the question is whether we can find a playback model that suits everyone - children's books may be optimized and have audio be primary
13:15:09 <mgarrish> ... it is a hard question to solve and all the spec has is a "should" - maybe we should remove that line and just leave it to implementers
13:15:33 <wendyreid> q+
13:15:35 <mgarrish> Hadrien: I don't think it is problematic for the use cases you define
13:15:59 <mgarrish> ... audio might be more problematic - you can have smil files without audio
13:16:14 <mgarrish> ... so what is the reading order and does the smil or spine define the order
13:16:18 <wendyreid> ack wendyreid
13:17:41 <mgarrish> wendyreid: I think the problems are real but in working on accessibility and spreads one of the things we covered is content across spreads - there are smil cases for this - but I worry about not going too far about moving around with user control
13:18:10 <Hadrien> q+
13:18:12 <mgarrish> ... media overlays often advance without user control - what happens to the user experience when you get moved all over the book
13:19:13 <mgarrish> ... there are ways to manage that - like a warning - do we need guardrails like having user interaction before this happens
13:19:14 <wendyreid> ack Hadrien
13:19:46 <mgarrish> Hadrien: there are no guardrails today - the current spec language doesn't handle the cases we've talked about so far
13:20:21 <mgarrish> ... it's common to go across spreads more than jumping around the book - the spec is not clear on how to handle spreads
13:20:36 <mgarrish> ... if we drop what we have and don't replace we won't have interop
13:20:56 <mgarrish> wendyreid: do we have a proposal for how we would present the smil reading order?
13:21:24 <mgarrish> Hadrien: I propose walking the spine and creating a set of the smil documents referenced - it's detailed in the issue
13:22:08 <mgarrish> ... it's not a complex way of compiling the order
13:22:35 <Hadrien> https://github.com/w3c/epub-specs/issues/2943#issuecomment-3994259158
13:22:44 <AvneeshSingh> q+
13:22:46 <mgarrish> ... the link is to use cases and examples
13:22:55 <wendyreid> ack AvneeshSingh
13:23:20 <mgarrish> AvneeshSingh: I think this is more of an implementation guideline - one way would be to make this a note - but do we really need to change the spec?
13:23:27 <mgarrish> ... what change is required?
13:23:31 <wendyreid> https://w3c.github.io/epub-specs/epub34/rs/#sec-behaviors-loading
13:23:39 <mgarrish> Hadrien: we need to change the reading systems spec
13:24:06 <mgarrish> ... this is more than an implementation detail - it's core logic
13:24:11 <DaleRogers> q+
13:24:14 <wendyreid> ack DaleRogers
13:24:46 <mgarrish> DaleRogers: my understanding in epub is that the markup document is the primary source of information and smil documents are subservient - they are called by the markup file
13:24:57 <mgarrish> ... so can a smil file be standalone and call what it wants?
13:25:13 <mgarrish> Hadrien: yes, the smil has par elements that indicate the content and audio to load
13:25:47 <ivan> q+
13:25:55 <wendyreid> ack ivan
13:26:00 <mgarrish> ... this is a technical issue but also why we have a technical spec for reading systems
13:26:21 <mgarrish> ivan: I'm suprised the original smil spec doesn't say anything about this - it defines par, etc.
13:26:44 <mgarrish> Hadrien: the problem isn't within one document but that we use multiple documents and tie them to the spine - it's how epub uses smil
13:27:04 <mgarrish> wendyreid: smil was probably also architected more with the web in mind
13:27:32 <mgarrish> ivan: no, smil allows several html document - the html documents are part of the structure but here they are adjacent
13:27:53 <mgarrish> Hadrien: what we're saying is that smil is designed to drive the whole thing but the spec doesn't cover this
13:28:09 <mgarrish> ivan: isn't it possible to go the whole way and let smil be the boss?
13:28:17 <mgarrish> Hadrien: yes, I think it works better this way
13:28:30 <AvneeshSingh> q+
13:28:41 <mgarrish> ivan: the problem is the spec is from 2008 and we don't know how much testing it has gone through
13:28:51 <wendyreid> ack AvneeshSingh
13:28:54 <mgarrish> Hadrien: no matter what we use we'll have the same issues
13:29:19 <Hadrien> q+
13:29:32 <mgarrish> AvneeshSingh: one thing I'm worried about is changing the architecture of the spec late and not being able to anticipate what new issues we'll encounter
13:30:06 <mgarrish> ... the spine gives the reading order and smil goes back to the spine when it completes
13:30:13 <wendyreid> ack Hadrien
13:30:42 <mgarrish> Hadrien: I think the spec is broken and everyone has a different implementation - going back to spine won't solve it
13:31:09 <mgarrish> wendyreid: hard to get my head around what this will look like
13:31:24 <mgarrish> ... both in spec language and reading order
13:31:54 <mgarrish> ... we do not tell reading systems how to do their interface - what would readium look like for example if we changed the language
13:32:55 <mgarrish> ... there are reading systems that care about this more than others
13:32:59 <ivan> q+
13:33:03 <wendyreid> ack ivan
13:33:32 <mgarrish> ivan: putting on my staff contact hat - do you have any idea of the amount and depth of work to make this happen?
13:33:56 <mgarrish> Hadrien: right now it's a single paragraph but would need expanding - limited to the RS specification
13:34:18 <mgarrish> ivan: more generally about all the issues you have raised
13:34:40 <mgarrish> Hadrien: these two issues are mostly about reading systems
13:35:22 <mgarrish> ivan: I'm looking at the charter and these are features that will have to be reviewed - will it require adding a year to our charter to handle all this
13:35:53 <mgarrish> ... our charter ends in less than a year and I want to avoid problems with this going on too long
13:36:20 <mgarrish> Hadrien: I don't think it's big changes but I understand the time issue - it is a departure from the current spec
13:36:38 <mgarrish> wendyreid: if we want to do this well we should do it right
13:37:17 <mgarrish> ... there is no denying this is a problem and that overlays are a powerful tool
13:37:26 <mgarrish> q+
13:37:53 <mgarrish> ... I don't want to push in small fixes in the hopes it scaffolds to a better experience
13:38:21 <mgarrish> ... I wonder if we should recharter with a specific focus on smil - push out 3.4 and then do this as a 3.4.1
13:38:33 <wendyreid> ack mgarrish
13:38:37 <wendyreid> scribe+
13:39:02 <wendyreid> mgarrish: You covered most of what I wanted to say. Everyone has implemented, but everyone has different ideas
13:39:15 <Hadrien> q+
13:39:24 <wendyreid> ... there will be implementations that won't conform if we change now. I worry about doing this in the current charter, we need to make sure everyone is on board
13:39:43 <wendyreid> ... don't want to reach a point where we make the change and someone comes and finds they don't conform
13:40:04 <wendyreid> ... I'm happy to make the changes around variable bit rates and smaller fixes, but this bigger change is worrying to me
13:40:14 <wendyreid> ... I do think this needs to be addressed, but worry about where it leads
13:40:17 <wendyreid> ack Hadrien
13:40:52 <mgarrish> Hadrien: one of the struggles we'll have if we do another dot release is that many people who have knowledge will not be participating in this group
13:41:08 <DaleRogers> q+
13:41:11 <ivan> q+
13:41:16 <wendyreid> q+
13:41:22 <mgarrish> ... we need to think about how to get more people involved - there is a lot of interest between EAA and audiobooks taking off
13:41:41 <AvneeshSingh> q+
13:42:12 <mgarrish> ... the line between audio and text is blurring - people want to implement this asap and waiting on chartering and new specs leaves people unsure what to do
13:42:28 <wendyreid> ack DaleRogers
13:42:43 <mgarrish> ... it wasn't on my radar, either, but I keep hearing about it from people
13:43:19 <mgarrish> DaleRogers: I just wonder if this is a big fix or a new feature
13:43:22 <wendyreid> ack ivan
13:43:27 <mgarrish> s/big fix/bug fix/
13:43:57 <mgarrish> ivan: I don't think anyone wants to push this under the carpet but we need to optimize our manpower to get this right
13:44:36 <mgarrish> ... we don't have to suspend our work on this even if we move this to the next release - maybe getting 3.4 out should be a higher priority so we can start again quickly
13:45:09 <mgarrish> ... we could get a quick recharter if we get 3.4 out
13:45:31 <wendyreid> ack wendyreid
13:45:44 <Hadrien> q+
13:45:57 <mgarrish> wendyreid: I want to echo the same - by rechartering with this as a second track of work it gives us time to do the outreach
13:46:16 <mgarrish> ... we can talk to some of the larger platforms we don't have feedback from yet
13:46:44 <mgarrish> ... there might be other issues that we'll find out if we have more time to engage people
13:47:09 <mgarrish> ... we also have the community group to get ahold of people - discord can also be useful
13:47:46 <mgarrish> ... we can also improve the future spec language if people are incubating solutions to these problems
13:48:22 <mgarrish> ... once 3.4 is out of the way we can focus more of our attention
13:48:24 <wendyreid> ack AvneeshSingh
13:49:01 <mgarrish> AvneeshSingh: the scope is larger - there are a lot of people in the daisy community who would like improvements but we haven't brought in because the scope of this revision seemed more limited
13:49:56 <mgarrish> ... if we have a more flexible charter to tackle media overlays that will be positive for daisy members
13:50:00 <wendyreid> ack Hadrien
13:50:36 <mgarrish> Hadrien: if we recharter sooner than later I will be more comfortable - we can't push this back a few years considering the state of the spec
13:51:37 <mgarrish> ... we have three groups of issues - the granularity issue is being done, the audio format and vbr can be tackled, the content model and reading system side, and final are the readin system issues
13:52:26 <ivan> q+
13:52:39 <mgarrish> ... if we can get the minor changes in 3.4 and the other issues in a future revision that would work but we need to keep people engaged
13:53:14 <mgarrish> ... we wrote specs without being sure about how implementations will work and we need to fix those problems now
13:53:15 <wendyreid> ack ivan
13:54:14 <mgarrish> ivan: I agree that the small issues are the ones we should settle in 3.4 - in parallel we should try to get a call with W3C folks to deal with the administration of whether to recharter or update our current charter
13:54:34 <Hadrien> q+
13:55:23 <mgarrish> ... if we do this, we have to have a hard look at what to do with annotations because we are behind on it - 3.4 is practically ready for CR absent it
13:55:24 <wendyreid> ack Hadrien
13:55:43 <mgarrish> Hadrien: we know that some parts are problematic - should we add a warning?
13:56:09 <mgarrish> ivan: that should be okay - identifying underimplemented or unclear features is fine
13:56:28 <mgarrish> wendyreid: yes, we've done this before with links to issues
13:57:52 <mgarrish> Hadrien: I've also seen a recent issue with full-bleed images that is going to be problematic to solve
13:58:01 <wendyreid> Topic: AOB
13:59:12 <wendyreid> https://github.com/w3c/webai-roadmap/issues/30
13:59:12 <mgarrish> wendyreid: we have been asked by the web and ai interest group for feedback on how ai technologies and llm have impacted on our group/epub
13:59:28 <ivan> q+
13:59:30 <mgarrish> ... we'll discuss this on the next call
13:59:37 <wendyreid> ack ivan
14:00:13 <mgarrish> ivan: we have got some feedback about ISO and seems that the obstacles are gone and we can go through the PAS format to publish our documents
14:00:30 <mgarrish> s/PAS format/PAS process/
14:01:14 <ivan> rrsagent, draft minutes
14:01:15 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/16-pmwg-minutes.html ivan
14:02:35 <ivan> rrsagent, bye
14:02:35 <RRSAgent> I see no action items