13:05:00 <RRSAgent> RRSAgent has joined #pmwg
13:05:05 <RRSAgent> logging to https://www.w3.org/2026/01/08-pmwg-irc
13:05:05 <Zakim> RRSAgent, make logs Public
13:05:06 <Zakim> Meeting: Publishing Maintenance Working Group
13:05:56 <ivan> ivan has changed the topic to: Meeting Details 2026-01-08: https://lists.w3.org/Archives/Public/public-pm-wg/2026Jan/0004.html
13:05:57 <ivan> Chair: wendy
13:05:57 <ivan> Meeting: Publishing Maintenance Working Group Telco
13:05:57 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-pm-wg/2026Jan/0004.html
13:11:02 <ivan> regrets+ avneeshsingh
13:53:21 <gautierchomel_> gautierchomel_ has joined #pmwg
13:53:47 <DaleRogers> DaleRogers has joined #pmwg
13:53:56 <GeorgeK> GeorgeK has joined #pmwg
13:54:41 <GeorgeK> present+
13:57:20 <sueneu> sueneu has joined #pmwg
13:57:30 <sueneu> present+
13:57:59 <shiestyle> shiestyle has joined #pmwg
13:59:53 <toshiakikoike> toshiakikoike has joined #pmwg
14:00:05 <toshiakikoike> present+
14:00:49 <duga> duga has joined #pmwg
14:00:52 <gautierchomel_> present+
14:01:02 <duga> present+
14:01:04 <kimberg> kimberg has joined #pmwg
14:01:13 <kimberg> present+
14:01:29 <wendyreid> wendyreid has joined #pmwg
14:01:37 <mgarrish> mgarrish has joined #pmwg
14:01:41 <wendyreid> present+
14:01:46 <ivan> present+
14:02:13 <ivan> present+ shiestyle
14:02:25 <ivan> present+ duga
14:02:58 <ivan> present+ charles
14:03:02 <gpellegrino> gpellegrino has joined #pmwg
14:03:03 <gman> gman has joined #pmwg
14:03:13 <gpellegrino> present+
14:03:22 <gman> present+
14:03:24 <CharlesL1> CharlesL1 has joined #pmwg
14:03:24 <duga> scribe+
14:03:35 <CharlesL1> present+
14:03:46 <mgarrish> present+
14:03:51 <ivan> present+ gman
14:03:59 <duga> q+
14:04:05 <duga> q-
14:04:13 <DaleRogers> present+
14:04:15 <ivan> present+ ajellinek
14:04:28 <ajellinek> ajellinek has joined #pmwg
14:04:33 <Hadrien> Hadrien has joined #pmwg
14:04:38 <duga> wendyreid: First topic is republishing 3.3
14:04:55 <rdeltour> rdeltour has joined #pmwg
14:05:04 <duga> ... some of the examples for fixed layout were wrong, so those have been updated
14:05:13 <rdeltour> present+
14:05:29 <wendyreid> Topic: Republishing EPUB 3.3
14:05:48 <duga> ... this is just in Core
14:06:07 <duga> ivan: And it is just a diagram, nothing on the text
14:06:38 <duga> ... not even the a11y text, just the image
14:06:41 <ivan> present+ Hadrien
14:06:46 <wendyreid> PROPOSED: Republish EPUB 3.3 Core for an update to the fixed layout examples.
14:06:50 <duga> +1
14:06:50 <ivan> +1
14:06:51 <Hadrien> +1
14:06:52 <mgarrish> +1
14:06:52 <wendyreid> +1
14:06:53 <CharlesL1> +1
14:06:53 <shiestyle> +1
14:06:57 <sueneu> +1
14:06:57 <gautierchomel_> +1
14:06:57 <DaleRogers> +1
14:06:57 <rdeltour> +1
14:06:57 <kimberg> +1
14:07:04 <gpellegrino> +1
14:07:08 <mgarrish> q+
14:07:11 <wendyreid> RESOLVED: Republish EPUB 3.3 Core for an update to the fixed layout examples.
14:07:13 <GeorgeK> +1
14:07:16 <wendyreid> ack mgarrish
14:07:49 <duga> mgarrish: When I went to prepare that, I got an error about Dave not being a member so he can't be listed as editor
14:08:05 <duga> ... so I moved him to previous authors, is that ok with everyone?
14:08:28 <duga> wendyreid: But he was the editor, do we need to change it?
14:08:47 <sueneu> q+
14:08:52 <duga> ivan: There is a very strict rule that when you publish the editor must be a member
14:09:04 <duga> ... we would have to request an exception
14:09:22 <duga> wendyreid: This must have come up before, people have edited old docs before
14:09:45 <duga> mgarrish: Yeah, but was the editor still in the group in those cases? That is what I have seen
14:10:26 <duga> ivan: Let's be fair to the system, we are publishing a new version with new dates
14:10:38 <wendyreid> ack sueneu
14:10:40 <duga> ... so Dave isn't the editor of the 2026 version
14:10:57 <LaurentLM> LaurentLM has joined #pmwg
14:11:07 <LaurentLM> present+
14:11:08 <ivan> present+ LaurentLM
14:11:11 <duga> sueneu: Will Dave care? We don't want to be dismissive of his work
14:11:17 <DaleRogers> q+
14:11:26 <wendyreid> ack DaleRogers
14:11:34 <duga> wendyreid: I would prefer to ask first
14:11:44 <duga> DaleRogers: Is there a former editor field?
14:11:45 <sueneu> q+
14:11:49 <wendyreid> ack sueneu
14:11:55 <duga> wendyreid: yes, that is where he will go
14:12:25 <duga> mgarrish: So his name will still be at the top, but under former editor
14:13:17 <CharlesL1> q+
14:13:27 <wendyreid> ack CharlesL
14:13:44 <duga> wendyreid: We should just go ahead
14:13:55 <duga> CharlesL1: But we should reach out to Dave and let him know
14:14:01 <duga> wendyreid: Yeah, I will do that
14:14:06 <wendyreid> Topic: Horizontal Reviews
14:14:33 <duga> wendyreid: These are on the horizon
14:14:45 <duga> ... we need these so these can go to CR
14:15:01 <duga> ... security, privacy, a11y, and architecture (TAG)
14:15:23 <duga> ... Avneesh has offered the a11y TF for a11y, but we still need the others
14:15:27 <ivan> s/security/i18n, security/
14:15:54 <duga> ... we need this for core, rs, a11y, comics, and annotations
14:16:22 <duga> ... chairs will reach out the horizontal review groups on how they want us to proceed with the reviews
14:16:28 <ivan> s/comics, //
14:16:34 <duga> ... as some of those specs have very little change
14:16:55 <duga> ... annotations will need review, even though it is based on an existing rec
14:16:58 <ivan> q+
14:17:02 <wendyreid> ack ivan
14:17:33 <duga> ivan: All the normative changes are documented in the changes section, correct?
14:17:35 <duga> mgarrish: yes
14:17:58 <duga> ivan: So when we reach out, we can pull the interesting entries from the changes,
14:18:11 <duga> ... maybe just a 3 or 4 item list
14:18:22 <duga> mgarrish: Yeah, not every change log needs review
14:18:48 <duga> ... I just did something similar for epubcheck
14:19:08 <wendyreid> Topic: Annotations
14:19:31 <duga> wendyreid: LaurentLM do you want to start with an overview?
14:19:44 <kimberg> kimberg has joined #pmwg
14:19:55 <gautierchomel_> https://w3c.github.io/epub-specs/epub34/annotations/
14:19:57 <gautierchomel_> https://w3c.github.io/epub-specs/wg-notes/annotations-ucr/index.html
14:20:42 <duga> LaurentLM: Currently stable are use cases, requirements
14:20:54 <duga> ... body and target are final
14:21:09 <duga> ... and everything you need for ??? are stabilized
14:21:36 <duga> ... ivan has a paper we need to review
14:22:01 <duga> ... and we have buy in from several reading systems on what we have done so far
14:22:36 <duga> ... ivan suggests we merge annotations into this group, and to publish soon as WD
14:23:02 <duga> ivan: If we publish FPWD, it puts a stake in the ground to get early comments
14:23:11 <duga> ... and horizontal review can start
14:23:25 <duga> ... to get them earlier rather than later
14:23:48 <duga> ... So I think it is a good thing, and having seen FPWD before, this one is very mature
14:24:12 <duga> ... so when we get to a good point we should publish. As a draft we can update it whenever
14:24:28 <duga> wendyreid: the benefit to FPWD is nothing has to really be decided
14:24:50 <duga> LaurentLM: I would like to have at least one selector before FPWD
14:25:21 <duga> wendyreid: I wonder if we should start with CFI since people know it
14:25:35 <ivan> q+
14:25:38 <duga> LaurentLM: I will go back to implementors and see what they would like as first and best
14:25:40 <wendyreid> ack ivan
14:26:34 <duga> ivan: One difference between when we made open annotations and now is new selector to specify ranges in text
14:26:59 <duga> ... It is now on the way to being part of the HTML standard, and is broadly implemented
14:27:00 <wendyreid> https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments
14:27:07 <duga> LaurentLM: With some caveats
14:27:22 <Hadrien> q+
14:27:22 <duga> LaurentLM: But that would be good as first selector
14:27:25 <wendyreid> ack Hadrien
14:28:14 <duga> Hadrien: I am in favor text fragments, but browser just scrolls to the text and selects it
14:28:25 <duga> ... but we need an API which doesn't exist
14:28:49 <duga> ... so we don't have JS APIs to get a reference to that place in the document
14:29:01 <ivan> q+
14:29:20 <duga> ... so it has to be completely implemented by the RS, so if there is no library for it
14:29:44 <sueneu> q+
14:29:50 <wendyreid> ack ivan
14:29:56 <duga> LaurentLM: There is an old buggy JS library from Google, the browsers don't have an API, it is a mess
14:30:40 <duga> ivan: Is what we define in the spec a format to exchange annotations? So we don't define the implementation
14:30:50 <Hadrien> q+
14:30:53 <duga> LaurentLM: Well, we need to define an interchangeable selector
14:31:04 <duga> ivan: But the selector is clearly define in htm
14:31:11 <duga> ... l
14:31:25 <wendyreid> q+
14:31:31 <duga> LaurentLM: Yes, but if devs don't have interoperable tools ...
14:31:41 <duga> ivan: What do you mean by interoperable?
14:31:58 <duga> LaurentLM: So if I have some text we need to be able to find it
14:32:36 <duga> ... so if there is no JS library for this or API, then we can't do anything with that selector
14:32:45 <wendyreid> ack sueneu
14:32:46 <duga> ivan: Ah, I see. Then we do have a problem
14:33:17 <duga> sueneu: LLM search does a good job of extracting and linking to text
14:33:31 <duga> ... maybe there is something the LLMs are using
14:33:42 <duga> LaurentLM: Those let the browser do the work
14:34:09 <duga> ivan: I am worried that we would define such an API
14:34:12 <wendyreid> ack Hadrien
14:34:34 <duga> Hadrien: I mentioned webview, but it is also true of a web app in a browser
14:34:59 <duga> ... sometimes the API is browser only, but in this case, it is in neither
14:35:17 <ivan> q+
14:35:19 <duga> ... I agree we shouldn't define an API, but we should figure out where this would be done
14:35:31 <wendyreid> ack wendyreid
14:35:35 <duga> ... as an API will have a huge impact on our work
14:35:54 <duga> wendyreid: I am concerned that we can't define the API for this
14:36:28 <duga> ... and there is no guarantee it would be implemented
14:36:46 <duga> ... we can go to the various groups and see if we can get support for it
14:37:02 <duga> q+
14:37:19 <duga> ... so we can at least get a yes or no on it
14:38:16 <duga> ... Maybe we can get a shell of an API, and we can provide that to all implementors
14:38:24 <wendyreid> ack ivan
14:38:29 <duga> ... we really want to avoid different syntaxes
14:38:42 <duga> LaurentLM: We can take the w3c syntax
14:39:17 <duga> ... so the primary selector should be one we know everyone can implement
14:39:30 <duga> ivan: we have to reach out to the TAG for review
14:39:35 <duga> q-
14:39:42 <duga> ... then we can get the TAG on our side
14:40:28 <duga> LaurentLM: We can say we only keep this if browsers provide an API as leverage
14:41:01 <duga> Hadrien: reading progress is the "easy" part of the discussion, and it isn't that easy
14:41:19 <CharlesL1> q+
14:41:25 <gman> google search has the capacity to highlight and lead to a given website's segment in the search results; the code is #:~:text=start_text,end_text from what i remember
14:41:38 <wendyreid> ack CharlesL
14:42:14 <Hadrien> q+
14:42:19 <wendyreid> ack Hadrien
14:42:36 <duga> CharlesL1: this needs to work on the web
14:43:01 <duga> Hadrien: text fragment can work on the web, but we need to know the URL on the web
14:43:08 <duga> ... in epub we have a path
14:43:30 <ivan> q+
14:43:33 <duga> ... so the issue between the web and epub is more the path, not the fragment
14:43:36 <wendyreid> ack ivan
14:44:08 <Hadrien> q+
14:44:08 <duga> ivan: I think in epub3.3 we discussed how URLs worked in EPUB
14:44:21 <duga> ... and we got to reasonable clarity
14:44:40 <CharlesL1> q+
14:44:42 <wendyreid> ack Hadrien
14:44:48 <duga> ... so we clearly defined the root, etc
14:45:12 <duga> Hadrien: many people have had this discussion, and it depends if the root is OPF or top level
14:45:14 <wendyreid> q+
14:45:25 <duga> ivan: in 3.3 we discussed this
14:45:32 <rdeltour> q+
14:45:37 <wendyreid> ack CharlesL
14:45:58 <wendyreid> ack wendyreid
14:46:01 <duga> CharlesL1: I thought we had brought in the TAG to this discussion, maybe we should revisit those minutes?
14:46:33 <duga> wendyreid: When it comes to the URL with the selector for the annotation - does it really matter?
14:46:59 <duga> ... there are basically two parts, the bit before the fragment, then the fragment
14:47:21 <duga> ... if the fragment tells us the chapter, then does it matter what comes before?
14:48:06 <wendyreid> ack rdeltour
14:48:13 <duga> ... if we say everything after some point must be the same, and everything before can be whatever, then does it matter what comes first?
14:48:42 <duga> rdeltour: I just want to clarify what we did in 3.3, which was how to resolve relative URLs
14:49:09 <duga> ... for this discussion, the container root is implementation dependent
14:49:56 <duga> ... so we know how to process relative URLs against the root URL, but what that URL is depends on the implementation
14:50:00 <LaurentLM> q+
14:50:05 <wendyreid> ack LaurentLM
14:50:19 <duga> LaurentLM: Inside epub it isn't really a problem
14:50:35 <Hadrien> q+
14:50:41 <duga> ... which can be relative
14:50:55 <duga> ... the only issue is translating to the web
14:51:22 <wendyreid> ack Hadrien
14:51:34 <duga> ... this is not epub dependent, it is just how do we move an epub annotation to a web publish, which isn't an epub problem
14:51:38 <CharlesL1> q+
14:51:54 <duga> Hadrien: I disagree. We need to know what the root is, we have seen disagreement on this
14:52:19 <rdeltour> q+
14:52:29 <duga> ... say we have a web reader (not publication) and the server has access to the ZIP
14:52:52 <sueneu> q+
14:53:00 <wendyreid> ack CharlesL1
14:53:04 <duga> ... this is also a problem for epub, not just web pubs
14:53:06 <wendyreid> ack CharlesL
14:53:25 <duga> CharlesL1: When you create the application you have all the info (current chapter, opf, etc)
14:53:32 <gman> q+
14:53:41 <LaurentLM> THe spec relative to the annotation Target element is https://w3c.github.io/epub-specs/epub34/annotations/#1-3-1-source
14:53:42 <duga> ... so it is up to the reading system to figure out how to find the annotation
14:53:58 <duga> ... is that what we are trying to define here?
14:54:37 <duga> Hadrien: We have a path, but we don't know how to calculate it
14:54:42 <wendyreid> ack rdeltour
14:55:29 <duga> LaurentLM: can we extract from 3.3 or 3.4 how the src is to be defined? I will check
14:56:10 <duga> rdeltour: Could Hadrien clarify what he meant by what is not currently clear? From my understanding the spec is very clear
14:56:24 <duga> ... we clarified this in 3.3
14:56:40 <duga> ... whether it is the root or the opf is speciffied
14:57:02 <duga> ... what we don't have is how to expand a URL into an epub
14:57:17 <duga> ... but that isn't needed as part of epub. Is that what you meant?
14:57:38 <duga> Hadrien: I was talking about annotation, we need to know how to build a URL?
14:58:02 <duga> ... how do we calculate that, are we at the top of the container? Or somewhere else?
14:58:09 <rdeltour> then my suggestion is to refer to "URLs in the OCF abstract container" https://www.w3.org/TR/epub-33/#sec-container-iri
14:58:27 <duga> ... I am not talking about using a URL to point at an epub
14:58:39 <duga> ... we tried that before and it didn't go well
14:59:03 <sueneu> q-
14:59:16 <wendyreid> ack gman
14:59:22 <duga> ... and we don't need to be able reference everything as a URL
14:59:43 <ivan> q+
14:59:57 <wendyreid> ack ivan
15:00:08 <duga> gman: Hadrien you mentioned different roots, can you give pros and cons for those?
15:00:18 <duga> Hadrien: not today, but maybe I can write something up
15:00:48 <duga> ivan: This is an epub annotation spec, so we should use the epub way
15:01:32 <duga> Hadrien: In the spec we have files. If we assume the annotation has a well known location we are fine, but if we don't then the path has to be constructed
15:01:42 <duga> ... so we can't just point at the epub spec
15:02:03 <duga> wendyreid: We should probably have an idea of what selectors will look like for FPWD
15:02:16 <duga> ivan: Are we moving annotation meetings here?
15:02:33 <duga> wendyreid: Seems like we should
15:02:41 <CharlesL1> +1 to move into this call :)
15:02:49 <gman> +1 too
15:02:50 <Hadrien> +1
15:02:53 <ivan> +1
15:02:54 <rdeltour> +1
15:02:56 <sueneu> +1
15:03:03 <shiestyle> +1
15:03:03 <DaleRogers> +1
15:03:34 <ivan> rrsagent, draft minutes
15:03:35 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/08-pmwg-minutes.html ivan
15:03:46 <CharlesL1> CharlesL1 has left #pmwg
15:16:57 <mgarrish> mgarrish has left #pmwg
16:08:50 <ajellinek> ajellinek has joined #pmwg
17:00:39 <Zakim> Zakim has left #pmwg
17:34:12 <gautierchomel> gautierchomel has joined #pmwg
18:50:50 <gautierchomel> gautierchomel has joined #pmwg
20:07:14 <gautierchomel> gautierchomel has joined #pmwg
20:30:13 <gautierchomel> gautierchomel has joined #pmwg
20:46:19 <gautierchomel> gautierchomel has joined #pmwg
21:02:22 <gautierchomel> gautierchomel has joined #pmwg
21:14:46 <gautierchomel> gautierchomel has joined #pmwg
21:32:21 <gautierchomel> gautierchomel has joined #pmwg
21:50:30 <gautierchomel> gautierchomel has joined #pmwg
22:06:28 <gautierchomel> gautierchomel has joined #pmwg
22:15:44 <gautierchomel> gautierchomel has joined #pmwg
22:34:09 <gautierchomel> gautierchomel has joined #pmwg
22:52:47 <gautierchomel> gautierchomel has joined #pmwg
23:09:25 <gautierchomel> gautierchomel has joined #pmwg
23:33:53 <gautierchomel> gautierchomel has joined #pmwg