12:44:23 <RRSAgent> RRSAgent has joined #pmwg
12:44:27 <RRSAgent> logging to https://www.w3.org/2026/04/09-pmwg-irc
12:44:27 <Zakim> RRSAgent, make logs Public
12:44:28 <Zakim> Meeting: Publishing Maintenance Working Group
12:44:48 <ivan> ivan has changed the topic to: Meeting Details 2026-04-09: https://lists.w3.org/Archives/Public/public-pm-wg/2026Apr/0006.html
12:44:49 <ivan> Chair: wendy
12:44:49 <ivan> Meeting: Publishing Maintenance Working Group Telco
12:44:49 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-pm-wg/2026Apr/0006.html
12:58:23 <shiestyle> shiestyle has joined #pmwg
12:59:45 <toshiakikoike> toshiakikoike has joined #pmwg
12:59:48 <MasakazuKitahara> MasakazuKitahara has joined #pmwg
12:59:53 <toshiakikoike> present+
13:00:00 <MasakazuKitahara> present+
13:00:16 <kimberg> kimberg has joined #pmwg
13:00:22 <kimberg> present+
13:00:44 <duga> duga has joined #pmwg
13:00:58 <shiestyle> present+
13:01:00 <duga> present+
13:01:02 <ivan> present+
13:01:05 <GeorgeK> GeorgeK has joined #pmwg
13:01:08 <ivan> present+ george
13:01:14 <sueneu> sueneu has joined #pmwg
13:01:16 <ivan> present+ gman
13:01:22 <GeorgeK> present+
13:01:22 <sueneu> present+
13:03:28 <ivan> present+ avneeshsingh
13:03:35 <Hadrien> Hadrien has joined #pmwg
13:03:39 <Hadrien> present+
13:04:27 <ivan> present+ charles
13:04:38 <LaurentLM> LaurentLM has joined #pmwg
13:04:43 <LaurentLM> present+
13:04:43 <ivan> present+ LaurentLM
13:04:55 <duga> scribe+
13:05:20 <gman> gman has joined #pmwg
13:05:25 <gman> present+
13:06:08 <duga> ivan: Some groups are looking at automatic scribe mechanisms
13:06:36 <AvneeshSingh> AvneeshSingh has joined #pmwg
13:06:49 <duga> sueneu: How does an auto scribe get proofread?
13:07:09 <duga> ivan: currently it generates the minutes, then members can review it
13:07:20 <duga> ... but it is up to the working group
13:07:43 <wendyreid> present+
13:07:52 <wendyreid> wendyreid has joined #pmwg
13:08:30 <wendyreid> https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
13:08:40 <duga> AvneeshSingh: Some group makes it the responsibility of the group for the corectness of the minutes, regardless of source
13:09:17 <ivan> present+ elizabeth
13:09:20 <duga> wendyreid: I have done this another group I chair. There are challenges, like Zoom requires AI companion. There are also accuracy issues
13:09:38 <duga> ... strong accents and non-English names are problems
13:11:02 <duga> ivan: One experiment has the info reflected directly in to IRC, so it all looks the same as now
13:11:39 <duga> wendyreid: None of the tools allow live editing when testing for the AB
13:12:10 <duga> ... but that would be ideal
13:12:25 <duga> ... who is building that?
13:12:33 <duga> ivan: Co chair of the DID wg
13:12:49 <duga> wendyreid: Are they looking for test subjects?
13:13:02 <duga> ivan: Not ready for that yet. Too much lag still
13:13:52 <duga> wendyreid: LaurentLM do you want to start with your PR?
13:14:09 <wendyreid> Topic: PR #2973
13:14:12 <AvneeshSingh> present+
13:15:01 <duga> LaurentLM: 2973 now allows A/V bodies, in two main sections
13:15:27 <duga> ... 3.4 body now allows an id so you can specify a relative url
13:15:28 <ivan> https://github.com/w3c/epub-specs/pull/2973
13:15:49 <duga> ... you can use id when it is image, sound, or video (names from the original spec)
13:16:36 <duga> ... so you now either need the value or an id that is a relative URL, depending on media
13:17:05 <duga> ... And I added a zip container that contains the annotations and the files
13:17:48 <duga> ... otherwise if it is in the epub then it needs to reference the json file in the meta-inf and all the binary files
13:17:50 <duga> q+
13:18:01 <ivan> q+
13:18:07 <duga> ... there are some issues raised by ivan
13:18:07 <wendyreid> ack duga
13:19:19 <ivan> scribe+ sueneu
13:19:06 <sueneu> duga: why don't we only use zip? then we only have one file format and one set of directions for getting it out?
13:19:24 <duga> LaurentLM: I didn'y think about that
13:19:35 <duga> ... zip in zip is not ideal
13:20:01 <duga> ... when you unpack you usually put it somewhere
13:20:05 <wendyreid> ack ivan
13:20:21 <duga> ivan: I don't see a problem with that
13:20:31 <duga> ... but there is one comment that worries me
13:20:58 <duga> ... when you import from the outside, but you already have annotations, the two sets have their own metadata
13:21:19 <duga> ... how do you merge these two? For instance the generator - does it get lost?
13:21:23 <duga> LaurentLM: yes
13:21:26 <wendyreid> q+
13:21:32 <duga> ivan: then why have it in the first place?
13:21:45 <duga> LaurentLM: This is really a technical log during development
13:22:10 <duga> ... if we know something is coming from a specific RS, maybe we can adapt to support their quirks
13:22:26 <duga> ... it is really administrative. We don't need to keep it
13:22:51 <duga> ivan: Generator is one thing, but what about other metadata?
13:23:16 <duga> ... For instance, the book. Since they are the same book, do you check to see if they are the same
13:23:48 <duga> ... So we have to explain what normatively what happens on import
13:24:19 <duga> LaurentLM: If an annotation item is tied to a book, but import to a different book, what do we do?
13:24:44 <duga> ivan: I propose we merge this PR, but then look at the processing issue separately
13:24:47 <duga> LaurentLM: Agree
13:25:01 <wendyreid> ack wendyreid
13:25:25 <duga> wendyreid: Editorial comment - we use sound, shouldn't we use audio?
13:25:47 <duga> LaurentLM: Yes, but then we depart from the W3C annotations spec. It is sound there
13:25:55 <duga> wendyreid: Can we file a bug?!
13:26:02 <duga> ivan: Sure, but there is no group
13:26:18 <duga> ... maybe we can alias audio to sound
13:26:50 <duga> wendyreid: It feels odd to call text textualBody, when there is sound, video, etc
13:26:57 <duga> ... why not 'text'?
13:27:10 <duga> LaurentLM: Same answer, the original spec
13:27:17 <duga> ivan: isn't there text already?
13:27:24 <duga> LaurentLM: Yes, but that is for remote text
13:27:41 <duga> wendyreid: Sometime you don't find bugs until you implement them
13:28:00 <sueneu> q+
13:28:02 <duga> LaurentLM: I am ok with changing things for modernization
13:28:13 <duga> wendyreid: Can we do that? Unless it is too hard
13:28:25 <duga> ivan: Audio is easy, but text is harder since it already exists
13:29:16 <wendyreid> ack sueneu
13:29:33 <duga> ... Do we allow someone to add an audio URL? No, it is always relative. But this difference makes sense now [ed note: may not have captured that]
13:30:03 <duga> sueneu: Do you need to consult the original to use this spec?
13:30:16 <duga> LaurentLM: No it is written so this is completely self contained
13:30:52 <duga> ivan: For implementor no, but we have to define terms etc. I hesitate to go down the route where we abandon the predecessor
13:31:43 <wendyreid> Topic: Annotations - Adding a replying function
13:31:51 <wendyreid> https://github.com/w3c/epub-specs/issues/2926
13:32:10 <duga> wendyreid: I have a proposal - don't do it in v1
13:32:11 <LaurentLM> +1 to wendy
13:32:16 <Hadrien> +1 as well
13:32:20 <duga> +1
13:32:24 <ivan> +1
13:32:26 <sueneu> +1
13:32:32 <shiestyle> +1
13:32:35 <toshiakikoike> +1
13:32:39 <duga> ... there are lots of issues it raises
13:33:02 <duga> ... so defer it, or close it?
13:33:10 <duga> LaurentLM: I think close and reopen if we want
13:33:36 <duga> ... we just need to make sure nothing in our implementation prevents it
13:33:41 <duga> ... which it doesn't
13:34:07 <duga> ivan: So when the minutes are generated I can close the issue
13:34:11 <wendyreid> Topic: Annotations - Different Terms for the Same notion
13:34:13 <wendyreid> https://github.com/w3c/epub-specs/issues/2929
13:34:14 <duga> wendyreid: No disagreement
13:34:47 <duga> wendyreid: We have name and title in the spec, they are very similar
13:34:53 <duga> ivan: They are used the same way
13:35:07 <sueneu> q+
13:35:30 <wendyreid> ack sueneu
13:35:34 <duga> wendyreid: We have title and name, both are human readable ids. title is for set, name is for the annotation
13:35:59 <duga> sueneu: I see nuance - title is often a work, name is often person place or thing
13:35:59 <LaurentLM> q+
13:36:09 <wendyreid> ack LaurentLM
13:36:39 <duga> LaurentLM: I don't mind renaming it. It is transient.
13:37:04 <Hadrien> q+
13:37:08 <wendyreid> ack Hadrien
13:37:12 <duga> ... The optional name is useful to for display purposes, but I don't care if it is name or title
13:37:19 <duga> Hadrien: Why do we even have title?
13:37:46 <duga> ... we have metadata about the book. I don't know when we will display it
13:37:48 <sueneu> q+
13:38:07 <duga> ... I am cautious about adding stuff that I don't understand
13:38:16 <duga> Hadrien: Why do we need it?
13:38:23 <duga> LaurentLM: It is a name for the file
13:38:23 <wendyreid> ack sueneu
13:38:38 <duga> Hadrien: Yeah, but you can do whatever you want for naming
13:38:47 <duga> sueneu: What about multiple sets imported?
13:38:59 <duga> ivan: That is a separate issue
13:39:27 <duga> LaurentLM: It is a standard so we need to support everyone
13:39:48 <duga> ... I don't see a reason to keep it, that is fine
13:39:55 <duga> ... people can add a title if they want
13:39:58 <gman> simplicity is divine
13:40:04 <duga> ivan: Can we remove it in this pr?
13:40:07 <duga> LaurentLM: yes
13:40:20 <wendyreid> Topic: Text Style Properties
13:40:22 <wendyreid> https://github.com/w3c/epub-specs/issues/2971
13:40:22 <wendyreid> https://github.com/w3c/epub-specs/issues/2971#issuecomment-4189360802
13:41:17 <duga> wendyreid: There was a comment about implementing this in a plugin
13:41:42 <duga> ... there will need to be a mapping for colors
13:41:58 <duga> ... his issue is, who creates that mapping?
13:42:27 <Hadrien> q+
13:42:35 <duga> ... it's a good implementation question
13:42:50 <duga> LaurentLM: I don't really understand
13:42:53 <wendyreid> ack Hadrien
13:42:58 <duga> ... looking at the LUA now
13:43:34 <duga> Hadrien: There are whole discords for this plugin where they share their UIs
13:43:48 <duga> ... in some cases there may be large numbers of colors
13:43:56 <duga> ... and his question is how do I handle it
13:44:25 <duga> ... this is the least problem for that plug in, as they handle annotations in a different way
13:44:37 <duga> ... I think we just need extensibility
13:44:58 <ivan> q+
13:45:26 <duga> ... on another note I saw and Android app for eink, and it is specific for eink because the standard colors don't work on eink
13:45:51 <duga> ... so you will need to adapt to your own reading system, we can't really do it
13:46:06 <duga> LaurentLM: He wants to know if he can add additional metadata
13:46:22 <duga> ... and the answer is yes, we just have to make sure in the json.ld it is correct
13:46:53 <duga> ... and he wants to add new words for values
13:46:59 <duga> ... e.g. inverted
13:47:24 <duga> Hadrien: They are both customizations
13:47:38 <duga> ... for instance, they use a hash for the volume
13:47:58 <duga> ... There are differences in the extensibility, properties and values
13:48:10 <duga> LaurentLM: Properties aren't a problem, and we can be more specific
13:48:26 <duga> ... but new values needs new text
13:48:40 <Hadrien> q+
13:48:54 <duga> ... I wrote something about this, if the RS doesn't understand the color it should pick something else
13:48:57 <wendyreid> ack ivan
13:49:00 <duga> ... which should solve the problem
13:49:41 <duga> ivan: Going back to the original, how do we answer, and what do we do in the spec to avoid this coming up?
13:50:02 <duga> ... for colors we need to make it clear that these can be adapted
13:50:21 <duga> ... and they are really to make sets of annotations
13:50:34 <wendyreid> ack Hadrien
13:50:45 <duga> Hadrien: I disagree, extensibility informs the model
13:51:08 <duga> ... if we don't consider it, then it will mess up when people extend
13:51:36 <duga> ... in this case, there will be no rgb colors in our properties, if they want that they should use a new property
13:51:37 <sueneu> q+
13:51:46 <sueneu> q-
13:51:48 <ivan> q+
13:51:53 <wendyreid> ack sueneu
13:52:06 <duga> ... extensibility does not need to conflict with interop
13:52:06 <gman> +1 will just need a list of all possible values
13:52:19 <wendyreid> ack ivan
13:52:22 <duga> sueneu: So it sound like extensilibilty won't impact interop
13:52:39 <duga> ivan: The fact that the model can be extended goes back to the original spec
13:52:50 <duga> ... we should add this comment to the data model section
13:53:20 <duga> ... beyond that, say for extensions to color, we shouldn't do that. We should just follow the original extension mechanism
13:53:31 <Hadrien> +1 for that, I wasn't suggesting that we provide guidance on how to extend our model with specific properties/values
13:53:46 <duga> ivan: For colors, we add a note that says we are not talking about CSS colors
13:54:35 <duga> wendyreid: We don't have time for the last issue
13:54:40 <wendyreid> Topic: Best practices or requirements?
13:54:41 <wendyreid> https://github.com/w3c/epub-specs/issues/2976
13:54:50 <duga> ... but maybe people can comment on it
13:55:10 <duga> ... in best practices we use normative language
13:55:20 <duga> ... some of them would be very good requirements
13:55:28 <ivan> q+
13:55:39 <duga> ... do we need a new section for RS requirements in addition to best practices?
13:55:58 <duga> ... just want to open the conversation
13:56:00 <wendyreid> ack ivan
13:56:25 <duga> ivan: Staff hat on - any MUST will need a test
13:56:41 <duga> ... just want to make sure people understand the consequences
13:56:45 <sueneu> q+
13:56:48 <wendyreid> ack sueneu
13:57:05 <duga> sueneu: for creators, interop is huge
13:57:27 <duga> ... so yes there is more work, but it is in service of the wider community
13:57:32 <duga> ivan: I do not disagree
13:58:02 <LaurentLM> LaurentLM has left #pmwg
13:58:04 <ivan> rrsagent, draft minutes
13:58:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/09-pmwg-minutes.html ivan