Meeting minutes
Republishing EPUB 3.3
wendyreid: First topic is republishing 3.3
… some of the examples for fixed layout were wrong, so those have been updated
… this is just in Core
ivan: And it is just a diagram, nothing on the text
… not even the a11y text, just the image
<wendyreid> PROPOSED: Republish EPUB 3.3 Core for an update to the fixed layout examples.
<duga> +1
<ivan> +1
<Hadrien> +1
<mgarrish> +1
<wendyreid> +1
<CharlesL1> +1
<shiestyle> +1
<sueneu> +1
<gautierchomel_> +1
<DaleRogers> +1
<rdeltour> +1
<kimberg> +1
<gpellegrino> +1
RESOLUTION: Republish EPUB 3.3 Core for an update to the fixed layout examples.
<GeorgeK> +1
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
… so I moved him to previous authors, is that ok with everyone?
wendyreid: But he was the editor, do we need to change it?
ivan: There is a very strict rule that when you publish the editor must be a member
… we would have to request an exception
wendyreid: This must have come up before, people have edited old docs before
mgarrish: Yeah, but was the editor still in the group in those cases? That is what I have seen
ivan: Let's be fair to the system, we are publishing a new version with new dates
… so Dave isn't the editor of the 2026 version
sueneu: Will Dave care? We don't want to be dismissive of his work
wendyreid: I would prefer to ask first
DaleRogers: Is there a former editor field?
wendyreid: yes, that is where he will go
mgarrish: So his name will still be at the top, but under former editor
wendyreid: We should just go ahead
CharlesL1: But we should reach out to Dave and let him know
wendyreid: Yeah, I will do that
Horizontal Reviews
wendyreid: These are on the horizon
… we need these so these can go to CR
… i18n, security, privacy, a11y, and architecture (TAG)
… Avneesh has offered the a11y TF for a11y, but we still need the others
… we need this for core, rs, a11y, and annotations
… chairs will reach out the horizontal review groups on how they want us to proceed with the reviews
… as some of those specs have very little change
… annotations will need review, even though it is based on an existing rec
ivan: All the normative changes are documented in the changes section, correct?
mgarrish: yes
ivan: So when we reach out, we can pull the interesting entries from the changes,
… maybe just a 3 or 4 item list
mgarrish: Yeah, not every change log needs review
… I just did something similar for epubcheck
Annotations
wendyreid: LaurentLM do you want to start with an overview?
<gautierchomel_> https://
<gautierchomel_> https://
LaurentLM: Currently stable are use cases, requirements
… body and target are final
… and everything you need for ??? are stabilized
… ivan has a paper we need to review
… and we have buy in from several reading systems on what we have done so far
… ivan suggests we merge annotations into this group, and to publish soon as WD
ivan: If we publish FPWD, it puts a stake in the ground to get early comments
… and horizontal review can start
… to get them earlier rather than later
… So I think it is a good thing, and having seen FPWD before, this one is very mature
… so when we get to a good point we should publish. As a draft we can update it whenever
wendyreid: the benefit to FPWD is nothing has to really be decided
LaurentLM: I would like to have at least one selector before FPWD
wendyreid: I wonder if we should start with CFI since people know it
LaurentLM: I will go back to implementors and see what they would like as first and best
ivan: One difference between when we made open annotations and now is new selector to specify ranges in text
… It is now on the way to being part of the HTML standard, and is broadly implemented
<wendyreid> https://
LaurentLM: With some caveats
LaurentLM: But that would be good as first selector
Hadrien: I am in favor text fragments, but browser just scrolls to the text and selects it
… but we need an API which doesn't exist
… so we don't have JS APIs to get a reference to that place in the document
… so it has to be completely implemented by the RS, so if there is no library for it
LaurentLM: There is an old buggy JS library from Google, the browsers don't have an API, it is a mess
ivan: Is what we define in the spec a format to exchange annotations? So we don't define the implementation
LaurentLM: Well, we need to define an interchangeable selector
ivan: But the selector is clearly define in htm
… l
LaurentLM: Yes, but if devs don't have interoperable tools ...
ivan: What do you mean by interoperable?
LaurentLM: So if I have some text we need to be able to find it
… so if there is no JS library for this or API, then we can't do anything with that selector
ivan: Ah, I see. Then we do have a problem
sueneu: LLM search does a good job of extracting and linking to text
… maybe there is something the LLMs are using
LaurentLM: Those let the browser do the work
ivan: I am worried that we would define such an API
Hadrien: I mentioned webview, but it is also true of a web app in a browser
… sometimes the API is browser only, but in this case, it is in neither
… I agree we shouldn't define an API, but we should figure out where this would be done
… as an API will have a huge impact on our work
wendyreid: I am concerned that we can't define the API for this
… and there is no guarantee it would be implemented
… we can go to the various groups and see if we can get support for it
… so we can at least get a yes or no on it
… Maybe we can get a shell of an API, and we can provide that to all implementors
… we really want to avoid different syntaxes
LaurentLM: We can take the w3c syntax
… so the primary selector should be one we know everyone can implement
ivan: we have to reach out to the TAG for review
… then we can get the TAG on our side
LaurentLM: We can say we only keep this if browsers provide an API as leverage
Hadrien: reading progress is the "easy" part of the discussion, and it isn't that easy
<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
CharlesL1: this needs to work on the web
Hadrien: text fragment can work on the web, but we need to know the URL on the web
… in epub we have a path
… so the issue between the web and epub is more the path, not the fragment
ivan: I think in epub3.3 we discussed how URLs worked in EPUB
… and we got to reasonable clarity
… so we clearly defined the root, etc
Hadrien: many people have had this discussion, and it depends if the root is OPF or top level
ivan: in 3.3 we discussed this
CharlesL1: I thought we had brought in the TAG to this discussion, maybe we should revisit those minutes?
wendyreid: When it comes to the URL with the selector for the annotation - does it really matter?
… there are basically two parts, the bit before the fragment, then the fragment
… if the fragment tells us the chapter, then does it matter what comes before?
… if we say everything after some point must be the same, and everything before can be whatever, then does it matter what comes first?
rdeltour: I just want to clarify what we did in 3.3, which was how to resolve relative URLs
… for this discussion, the container root is implementation dependent
… so we know how to process relative URLs against the root URL, but what that URL is depends on the implementation
LaurentLM: Inside epub it isn't really a problem
… which can be relative
… the only issue is translating to the web
… 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
Hadrien: I disagree. We need to know what the root is, we have seen disagreement on this
… say we have a web reader (not publication) and the server has access to the ZIP
… this is also a problem for epub, not just web pubs
CharlesL1: When you create the application you have all the info (current chapter, opf, etc)
<LaurentLM> THe spec relative to the annotation Target element is https://
CharlesL1: so it is up to the reading system to figure out how to find the annotation
… is that what we are trying to define here?
Hadrien: We have a path, but we don't know how to calculate it
LaurentLM: can we extract from 3.3 or 3.4 how the src is to be defined? I will check
rdeltour: Could Hadrien clarify what he meant by what is not currently clear? From my understanding the spec is very clear
… we clarified this in 3.3
… whether it is the root or the opf is speciffied
… what we don't have is how to expand a URL into an epub
… but that isn't needed as part of epub. Is that what you meant?
Hadrien: I was talking about annotation, we need to know how to build a URL?
… how do we calculate that, are we at the top of the container? Or somewhere else?
<rdeltour> then my suggestion is to refer to "URLs in the OCF abstract container" https://
Hadrien: I am not talking about using a URL to point at an epub
… we tried that before and it didn't go well
… and we don't need to be able reference everything as a URL
gman: Hadrien you mentioned different roots, can you give pros and cons for those?
Hadrien: not today, but maybe I can write something up
ivan: This is an epub annotation spec, so we should use the epub way
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
… so we can't just point at the epub spec
wendyreid: We should probably have an idea of what selectors will look like for FPWD
ivan: Are we moving annotation meetings here?
wendyreid: Seems like we should
<CharlesL1> +1 to move into this call :)
<gman> +1 too
<Hadrien> +1
<ivan> +1
<rdeltour> +1
<sueneu> +1
<shiestyle> +1
<DaleRogers> +1