12:17:20 <RRSAgent> RRSAgent has joined #pmwg
12:17:25 <RRSAgent> logging to https://www.w3.org/2026/05/21-pmwg-irc
12:17:25 <Zakim> RRSAgent, make logs Public
12:17:26 <Zakim> Meeting: Publishing Maintenance Working Group
12:17:57 <ivan> ivan has changed the topic to: Meeting Details 2026-05-14: https://lists.w3.org/Archives/Public/public-pm-wg/2026May/0019.html
12:17:58 <ivan> Chair: susan
12:17:58 <ivan> Meeting: Publishing Maintenance Working Group Telco
12:17:58 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-pm-wg/2026May/0019.html
12:17:59 <ivan> regrets+ brady, gautier, toshiakikoike, gpellegrino
12:54:26 <shiestyle> shiestyle has joined #pmwg
12:56:19 <DaleRogers> DaleRogers has joined #pmwg
12:59:29 <MasakazuKitahara> MasakazuKitahara has joined #pmwg
12:59:56 <ajellinek> ajellinek has joined #pmwg
13:00:00 <ivan> present+
13:00:10 <ivan> present+ shiestyle
13:00:11 <sueneu> sueneu has joined #pmwg
13:00:12 <ajellinek> present+
13:00:16 <sueneu> present+
13:00:16 <ivan> present+ sueneu
13:00:52 <DaleRogers> present+
13:01:07 <ivan> present+ MasakazuKitahara
13:01:17 <shiestyle> present+
13:01:24 <MasakazuKitahara> present+
13:02:19 <mgarrish> mgarrish has joined #pmwg
13:02:42 <ivan> regrets+ wendyreid
13:03:42 <ivan> present+ mgarrish
13:06:57 <Hadrien> Hadrien has joined #pmwg
13:07:01 <ivan> present+ hadrien
13:07:27 <LaurentLM> LaurentLM has joined #pmwg
13:07:33 <LaurentLM> present+
13:08:18 <sueneu> scribe+
13:08:24 <ivan> present+ charles
13:08:31 <sueneu> Topic: Do we need the concept of Annotation Sets? https://github.com/w3c/epub-specs/issues
13:09:20 <LaurentLM> https://github.com/w3c/epub-specs/issues/3000
13:10:13 <sueneu> laurent: do we replace the annotation structure with a zip that could contain any annotation type plus any information about the book
13:10:26 <Hadrien> q+
13:10:38 <sueneu> LaurentLM: it makes sense to have information about the book outside of the structure
13:10:50 <Hadrien> ack Hadrien
13:10:51 <sueneu> …what shape should this take
13:11:14 <sueneu> Hadrien: even if we have a zip we want a way of grouping the annotations together
13:11:16 <ivan> q+
13:11:31 <gman> gman has joined #pmwg
13:11:33 <sueneu> …the concept of the set will continue to exist. we want to have a well known location
13:11:36 <gman> present+
13:11:47 <shiestyle> chair+
13:12:08 <sueneu> …we've agreed that there is a usefulness but a limited one for metadata
13:12:37 <sueneu> …mostly for services that need the metadata and for matching but this might not be so useful
13:12:52 <sueneu> …only when we have to present the metadata outside of the book
13:13:11 <sueneu> …so we should have few pieces of metadata
13:13:23 <LaurentLM> q+
13:13:29 <shiestyle> ack ivan
13:13:30 <sueneu> …citation styles would be a useful influence on the kinds of metadata we present
13:14:09 <sueneu> ivan: we are talking about standardizing the interchange format
13:14:18 <Hadrien> q+
13:14:28 <sueneu> …at that level, the set creates one single file for import and export
13:14:41 <sueneu> …when we accepted images, etc. we decided that zip is the format
13:14:57 <sueneu> …then later we decided that zip is the only accepted format
13:15:59 <sueneu> …we do not need the grouping function, one file that lists all the annotations is not needed
13:16:23 <sueneu> …if the annotations sets role is to have collective metadata, there are two things there,
13:16:34 <sueneu> …information about the generator and the publication
13:16:42 <LaurentLM> current ebook metadata relative to the book: https://w3c.github.io/epub-specs/epub34/annotations/#about
13:16:55 <sueneu> …the generator isn't a necessary item in the interchange format
13:17:15 <sueneu> …the metadata for the publication, is mostly copies of data in the package document
13:17:38 <sueneu> …so we are repeating those values.
13:18:18 <sueneu> …which seems superfluous
13:19:05 <sueneu> …my conclusion is that the simplest way to do this is to make the metadata package include a copy of the metadata in the publication
13:19:11 <shiestyle> ack LaurentLM
13:21:16 <sueneu> LaurentM: there will be import and export of files plus push and pull of sets of annotaions in the rest API
13:21:29 <sueneu> …I don't think there is an issue choosing zip as a container
13:21:40 <sueneu> …it is also possible that our format should support this
13:22:19 <sueneu> …about the generator, many files include this kind of information, though I don't suggest including the date
13:22:41 <sueneu> …this can be useful to differentiate annotations that don't conform to the specifcations
13:23:04 <ivan> q+
13:23:21 <sueneu> …I would be worried about totally tieing our format to epub by using the opf in annotations
13:23:37 <sueneu> …and it mixes xml and json which is never great
13:23:54 <sueneu> …we just need descriptive information about the book, and no list of annotations
13:24:17 <sueneu> …just title, author, etc or something that links the annotation to the book
13:24:19 <shiestyle> ack Hadrien
13:24:46 <sueneu> Hadrien: we recently released Thorium on IOS and we have academic users
13:24:53 <sueneu> …we have almost 40% of everything that is read is in PDF
13:25:14 <sueneu> …so when we implement the highlight feature we will be asked to do it for PDF as well.
13:25:29 <sueneu> …if we want to implement this feature, it has to work for more than epub
13:25:45 <sueneu> …we need something as format agnostic as we can
13:26:39 <sueneu> …when we look at what we have for interchange, de-paged annotations, we define that we use a zip, that we have an extension and profile, and a list in .json
13:27:11 <sueneu> …so we have one document in which we have a list of all documentations even if we have a set
13:27:30 <sueneu> …by definition we need a set if we have mulitiple files
13:27:50 <sueneu> …now I think we have too much data, do we need dc date, dc creator?
13:28:12 <sueneu> …at a minimum we need something to identify annotations when they are separate from the book
13:28:16 <shiestyle> ack ivan
13:28:47 <sueneu> ivan: we have currently a json structure for the set. I feel an itemized list isn't necessary
13:29:04 <Hadrien> q+
13:29:14 <sueneu> …we can have a sub directory for organizing the files
13:29:39 <sueneu> …coming back to metadata, we have never formalized that this should work outside of epub
13:29:57 <sueneu> …assuming this is a requirement now, it becomes a different discussion
13:30:18 <sueneu> …we should have a new pr about which metadata is necessary
13:30:53 <sueneu> …we must make clear how the identifiers are related to each other
13:31:12 <sueneu> …we cannot be silent about how this is related to the epub version
13:31:38 <sueneu> …I propose a pr that removes the itemized data from the annotation set/metadata
13:32:00 <sueneu> …we can discuss the exact name later, and we can further discuss it in the pr
13:32:07 <shiestyle> q?
13:32:14 <shiestyle> ack Hadrien
13:32:58 <sueneu> LaurentM: you will open a PR on the metadata? and we will leave the generator for now
13:33:19 <sueneu> Hadrien: I think having one file will all the information is more efficient
13:33:33 <sueneu> …I think there is a utility in having it all in one place
13:33:58 <sueneu> …that means if you look at annotation sets, we have metadata including items
13:34:11 <sueneu> …which is necessary because you need names in json
13:34:25 <sueneu> …i'm not sure we need type, generator, etc
13:34:37 <sueneu> …we need a minimal set of metadata
13:34:53 <sueneu> …I would go for a light weight approach but keep the set
13:35:13 <shiestyle> q?
13:35:27 <sueneu> LaurentM: it would be useful to have the advice of other reading systems. I will try to get some feedback
13:35:39 <sueneu> ivan: then I will hold off on the PR for now
13:35:59 <shiestyle> Topic: Proposing a text on merging [annotations]  https://github.com/w3c/epub-specs/pull/3001
13:36:07 <ivan> q+
13:36:14 <shiestyle> ack ivan
13:36:30 <sueneu> topic [new]
13:37:06 <sueneu> ivan: I have a question about when annotaions are merged. What can we describe normatively
13:37:31 <sueneu> …it turns out there is not much consistency in book metadata so we have to rely on the heuristics in the rs
13:37:46 <LaurentLM> LaurentLM has joined #pmwg
13:37:51 <sueneu> …so we need a paragraph to make clear to readers what they can expect on import
13:37:54 <LaurentLM> q?
13:38:01 <LaurentLM> q+
13:38:10 <LaurentLM> q-
13:39:17 <sueneu> …if I am a user and not an implementor, I may never see it
13:39:39 <LaurentLM> q?
13:39:41 <sueneu> …I don't want to hide the text from reading systems either
13:40:18 <sueneu> s/[new]/Proposing a text on merging [annotations]  https://github.com/w3c/epub-specs/pull/3001
13:40:48 <LaurentLM> q+
13:40:59 <shiestyle> ack LaurentLM
13:41:02 <sueneu> …if we are able to separate the information into implementer and user sections, then this text should go into the user part
13:41:20 <sueneu> LaurentM: most of section six is about what a user can expect
13:41:41 <DaleRogers> q+
13:41:42 <sueneu> …there are sentences that are aimed at developers
13:42:16 <sueneu> …we can change the language to make it clear that implementers should pay attention to
13:42:25 <shiestyle> ack DaleRogers
13:42:25 <sueneu> …rather than duplicating information
13:43:32 <LaurentLM> q+
13:43:33 <shiestyle> q?
13:43:40 <shiestyle> ack LaurentLM
13:43:40 <sueneu> DaleRogers: I notice section 6 is called "best practices for reading systems" we could in each section say what audience a section is aimed at
13:43:54 <ivan> q+
13:44:00 <sueneu> LaurentM: the risk is duplication and being unclear
13:44:35 <sueneu>  …developers know how to deal with a use case, if we reorient this section more like use cases we can avoid splitting and duplicating
13:44:36 <shiestyle> ack ivan
13:45:15 <sueneu> ivan: perhaps we could rewrite the section as use cases, and then have other sections or notes for implementors
13:45:27 <sueneu> …most of the sections would be use case oriented
13:46:05 <sueneu> …editorially, the simplest thing is to merge the PR and then we will move it during rewriting
13:46:11 <sueneu> q+
13:46:41 <sueneu> LaurentM: I can take a run on rewriting it, I'll show you the branch before the PR
13:46:52 <shiestyle> ack sueneu
13:47:47 <LaurentLM> q+
13:48:36 <sueneu> Do users look at the reading system spec? I expect not, so rewriting it with a use case framing makes sense
13:48:44 <shiestyle> ack LaurentLM
13:48:58 <ivan> s/Do users/sueneu: Do users/
13:49:28 <sueneu> LaurentM: I think users won't read the spec but there is an interim party, people who make articles and usage notes who would need this information
13:49:41 <sueneu> …and they will pick up on this vocabulary
13:49:47 <shiestyle> q?
13:50:29 <sueneu> Topic: Add some context to the use of the term Segment in the Target section https://github.com/w3c/epub-specs/pull/2990
13:51:02 <sueneu> LaurentM: we know we can create bookmarks and annotations. A bookmark is a placeholder in a text or image but not so precise for a user
13:51:23 <sueneu> …an annotation is a highlight of text or other media, and has some range in the content
13:51:54 <sueneu> …the selectors we define can isolate a range even for a bookmark, since there is no specific marker for a book mark
13:51:56 <Hadrien> q+
13:52:23 <sueneu> …will we accept that the selector of a bookmark can be a range or must be a single point?
13:52:30 <shiestyle> ack Hadrien
13:52:52 <sueneu> Hadrien: reading systems usually have a specific affordance for bookmarks
13:53:16 <sueneu> …like an icon on the corner of the page, we look at what is currently displayed to the users
13:53:25 <sueneu> …and check if there is a bookmark there
13:53:33 <ivan> q+
13:54:01 <sueneu> …if there is a superlong range, the text could be displayed across many screens and cause problematic behavior
13:54:22 <LaurentLM> q+
13:54:26 <shiestyle> ack ivan
13:54:28 <sueneu> …i suspect rs will want to define a bookmark that won't cross the boundary of multiple screens
13:54:56 <sueneu> ivan: this is related to the previous discussion because th choice of selectors is done behind the scenes by the rs
13:55:24 <Hadrien> q+
13:55:31 <sueneu> …so this is a matter of the affordance that LaurentM was talking about. So the situation you describe won't happen
13:56:19 <sueneu> …so reading systems should do this properly. We should say if a readers intent is to set a bookmark, we should use a single selector
13:56:57 <sueneu> LaurentM: a text position selector has a beginning and end, and is a range
13:57:17 <DaleRogers> q+
13:57:20 <shiestyle> ack LaurentLM
13:57:33 <sueneu> …do you agree that a bookmark should be a single location we should add that to the spec
13:57:35 <LaurentLM> ask
13:57:38 <LaurentLM> ack
13:57:42 <shiestyle> ack Hadrien
13:58:31 <sueneu> LaurentLM: if reading system A generates a bookmark, it will still work on reading system A, but export that annotation to reading system B and B handles bookmarks differently, we could have problems
13:59:06 <sueneu> …even if we include a specification, reading system B will have a sanitisation process
13:59:24 <sueneu> …that will then decide if the bookmark would be at the beginning or end of a range
13:59:40 <sueneu> …we can try to force whatever and people will do what they want
14:00:01 <sueneu> …I don't think we will be able to control what people will do
14:00:22 <shiestyle> ack DaleRogers
14:00:28 <sueneu> …it might be good to have some recommendations but reading systems shouldn't expect it
14:01:16 <sueneu> DaleRogers: a reading system can do what it wants with our declarations, and we can make those declarations
14:01:42 <ivan> rrsagent, draft minutes
14:01:44 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/21-pmwg-minutes.html ivan
14:43:32 <LaurentLM> LaurentLM has joined #pmwg
14:55:41 <mgarrish> mgarrish has left #pmwg
14:56:59 <LaurentLM> LaurentLM has joined #pmwg
15:01:47 <gpellegrino> gpellegrino has joined #pmwg
16:01:12 <Zakim> Zakim has left #pmwg