Meeting minutes
w3c/epub-specs#3076
Brady Duga: How annotations should work with manifest fallbacks, I can summarize it
… the issue here is if we restrict annotations to a spine item, and I have jpg 1 in the spine, put a book mark on it, and it has an html fallback, how does it look to an rs that is displaying the fallback?
Laurent Le Meur: I propose that as the bookmark is one of the top level elements, if there is a fallback, the bookmark is not displayed when the rs is showing the fallback
… reading system A puts a bookmark on the image, reading system B hides the bookmark, since you cannot necessarily highlight the fallback
Brady Duga: I propose an RS should do its best to display the annotation in the fallback. That should work in the real world 99% of the time. Most of the time this will be a bookmark in manga. If it is a drawn annotation, it should be pixel perfect to display in both.
… in theory this could break. A ChemML document that fallsback to a jpg could break. But some effort should be made to display it anyway so that there are not invisible annotations that can't be deleted.
… what happens if we are looking at an inline annotation? How would that work in a jpg.
… things could fallback, and even a reading system wouldn't know it was there
Hadrien Gardeur: I dislike the idea of hiding things. Like when a book is updated, we might have a bookmark with a note, having access to that is important
… in general it is best to show something even if you can't resolve it. That's why having enough information in an annotation is importan
… we've just implemented fallbacks in readium mobile. We are trying to support fixed layout. We exposed and API where a creator can use the html or the image. Because we support progression and other types of implementation, we can smoothly move between the two. At the spine level.
… we knew there would be variations among systems. Yes, you can't really bookmark something that isn't in the spine isn't that difficult. You can use the image URL for instance
Charles LaPierre: I agree it shouldn't be hidden, although if the target of the annotation isn't there it might make no sense, so some indication of what the orphaned annotation is referring to would be good.
Laurent Le Meur: My issue is about an image with html fallback, a highlight rectangle on the image itself. How would you solve that?
Hadrien Gardeur: if this is a fixed layout, that is no problem
Brady Duga: you can do a mix of fallbacks and reflowable fallback but that isn't a common usage. Playbooks does do this. It has an image mode and a text mode. Literally pictures of books that map to the reflowable text. It can map an annotation on the image to the reflowable.
… but most often the content we have is Manga
Hadrien Gardeur: Manga and light novels. LNs are essentially relowable layouts with random fixed layout elements. Sometimes a spread, sometimes a single page
Laurent Le Meur: we can say that there is a best effort requested to map the annotation from a top level document to its fallback when necessary. We should add that to the reading system expectations.
… we a few sections where this might fit, should we put it in one of those? Or make a new section? We can discuss this in the github issue
@Ivan Herman: I thought this might be the answer, to put an indication in the RS recommendations, since fallbacks are often messy, it should have its own section. Without an all caps "should"
w3c/epub-specs#3002
Laurent Le Meur: I will add that to the next PR
Ivan Herman: this gets into another problem, that an annotation in a specific book with a specific author should have a unique identification
Laurent Le Meur: we can still link annotations
Ivan Herman: If an annotation is unique within a book that is one thing, but when you import an annotation that could clash
Laurent Le Meur: we could impose a UUID
Hadrien Gardeur: in practice this will be done as an external function and RS won't trust them. I understood this was out of scope for this
Brady Duga: this could be rat's nest. What if I allow people to edit an annotation? Should it get a new identifier because it was modified? Should the reference include the original annotation? I don't want to go down this path.
… let's us the UU ID and see what the industry does
<Hadrien Gardeur> +1 for what @Brady Duga said, pretty much my thoughts as well
<Ivan Herman> +1 to move it to future versions
Laurent Le Meur: I agree this should be out of scope for now.
Ivan Herman: we may have a label that says "future" or "postponed"
Wendy Reid: could we add a note that we are considering this?
Laurent Le Meur: we could use "status deferred"
Wendy Reid: not everyone sees our github repository
w3c/epub-specs#3072
Wendy Reid: I'm asking that we have a pointer to it
Laurent Le Meur: this is from a previous meeting, there are several small modifications that we previously agreed on.
… looking at the modifications, I removed the generator object, changed the note at the beginning
Brady Duga: we raised the issue here because of the comment thread, do we require the values of the metadata field to match those of the metadata in the Ebook?
… one argument is to make it "dumb" and match just what is in the EPUB
… another is that there is sometimes better information from external sources. Like if a user types in a more accurate title. We know that internal EPUB data can be inaccurate
Ivan Herman: unless we provide an annotation on the package document, so the author can make a comment or change the metadata, then I don't see why we should let the reader invent new metadata
Wendy Reid: I think we probably should have a way for metadata to be edited. I've opened books where I needed to modify or fill in the blanks in the metadata. Especially in an academic setting. If I need to provide the city of publication, which is almost never provided in an Ebook, I have to add it manual
… there is a necessary need for that editing
Ivan Herman: that raises another issue. The about object and all the fields there are filled in by the rs, and readers can annotation the about object, then why would the rs use anything other than the metadata in the ebook.
… for now in the specification, it is the rs that does something with metadata
Brady Duga: in Playbooks I think none of the implementers know the metadata title of an ebook. Publishers can edit that at many points. These get overwritten. The user/reader sees the title the reading system provides. They will be completely surprised when they see the title from the metadata, which could be something obscure like "mob_dick_v2"
… we know the data in the epub is the worst data. We are asking reading systems to work harder to display bad data
Wendy Reid: I think Ivan Herman and I are closer in concept. I can totally see that some reading systems will allow readers to edit the metadata, like a Vital Source having these features, so we can leave this in the hands of implementers.
… if implementers hear from their users they can respond. Series data is an example of that, users always want the ability to update that
Laurent Le Meur: it is largely requested for users to change the title, etc. within the publication. We don't implement that now, but people will expect to see their title, not the one from the metadata
Hadrien Gardeur: there are 2 types of reading systems, some of them provide ability to edit metadata or even bring in 3rd party data. These types get better data from PDS
… another type is libraries and institutions, where all the metadata are coming from ONIX or similar services.
… for category two, it is odd to expect users to change the metadata. It is more common for category one, where users have more time to catalog their own files.
… so it is hard to come up with one recommendation for both. It will be hard to convince type 2 to change their ways.
Ivan Herman: it is clearly a clash between theory and practice. I have to accept that the practice is much messier. For this issue, I yield to the practice. But none of the problems we have talked about here are addressed in our recommendations
… perhaps we should come back to this in the charter. But here we should include a note about why we don't take into account the package metadata.
… because this might seem illogical
Wendy Reid: this is probably a good EPUB 3.5 conversation. We really do have two very different types of users and use cases. We have focused more on the ecosystem publisher/distributor/end user pipeline. Where gaps are shored up by ONIX
… there is a very large community that consumes EPUB outside of that system, even if the use it sometimes. They be managing their own metadata. That community talks about annotations more. Like the Calibre community. Where people are customizing their library, even writing their own reading software. We should probably document it better
Hadrien Gardeur: this group is unrepresented here. I'm in touch with them because they all use OPDS. They do sometimes contribute to Github issues. Right now we are not connected to that community and it is huge.
… do we want to serve this community and how do we want to reach out. They want to move fast and test things. They know a lot about what goes wrong in EPUB production in general.
… this is a bit off topic but we should come back to this as WG and decide if we want to serve them and how we reach out
Wendy Reid: we should add this to charter talks?
Ivan Herman: Yes, but should we add something about not allowing metadata in the annotations?
Laurent Le Meur: I can change the metadata source to something more generic, like "that is used by the reading system" with a caveat that this may vary from one rs to the next.
Thanks, Hadrien Gardeur
Laurent Le Meur: I had an ai help me review this for security issues and it found few things to fix
Ivan Herman: the W3C is leaning toward making threat models, and it is a lot of work. The emphasis of the threat model is on processing operations. Our situation might be simpler.
… I propose that you put what you have in the spec, and when we send it for horizontal review, we will see if they want the new proceedure
Wendy Reid: we did a threat model for 3.3?
Ivan Herman: these threat models are new. We should have a discussion in Dublin.
Brady Duga: I sent a few comments on the privacy section, and I didn't read the security section because I thought it might be re-written, but I can take some time to read it.
Are we OK with this PR, or do we need others?
Laurent Le Meur: I will wait for Brady Duga to have a look by Monday
AOB
Ivan Herman: A big open issue for me is annotations is how will we test this? I expect this will be a long discussion. It doesn't fit the kind of testing we do for EPUB itself.
Wendy Reid: we should open an issue for it.