Meeting minutes
Privacy and Security Review
Wendy Reid: privacy and security review have been merged and submitted.
Ivan Herman: note to ourself,we have done what we are supposed to, wait for comments from other groups
Annotations Progress Check
Wendy Reid: we've made a lot of progress, but there are still some gaps before sending to review.
Wendy Reid: we should plan two months not more if we want to achieve review by the end of our charter.
Wendy Reid: privacy and security for annotation will be a burden, accessibility too probably, the topic comes with high complexity.
Laurent Le Meur: I see no difficulty to solve open issues in the next month. We've discussed language and text direction so internationalisation should be ok. We use json so I am not worried.
Ivan Herman: less optimistic by nature. There are terms and objects not defined, not complicated ones but to be defined. Json schema is an empty section. We can try to say this is json so privacy security and accesisbility are covered by this spec. But we might be asked to give some reading suystem considerations on safe and robust implementation.
Ivan Herman: we may want to add asecurity section, even non normative, it's often done this way.
Gautier Chomel: Are we talking about having the document ready for security/privacy review by end of May or everything by end of May?
Wendy Reid: draft of the document by end of may so we can start the review process.
Wendy Reid: for EPUB, we did a risk assesment, I would suggest to follow that path. That's a way to raise questions . What happen is someone use anotations for injection? What about an EPUB silently leaking infos? We may have no response but at least knowing the risks and informing them.
Ivan Herman: two timelines: may to start the review and all testings done before january. We need to think about how to test, that would be complexer than for EPUB. At the moment I am not sure how to test annotations.
Gautier Chomel: I think that I would be happy to start the risk assessment for annotations, we have some experience since we implemented in Thorium, I can propose some first draft, should I do it in an issue or elsewhere?
… I have some ideas about how to test
… we've tested them for Thorium desktop, I have some ideas
Wendy Reid: in terms of testing, we need individual tests, as well as exemples embedded in an EPUB vs separate file
Laurent Le Meur: this sounds like testing the RS, not the spec.
Wendy Reid: short reminder, for each MUST in the spec we need a test. Two implementations to pass. We create the files, RS are invited to test.
Ivan Herman: an ebook for each MUST statement is a mean, we can work differently and asses different parts with one file. One important feature, is the interchange format, we do not define how RS do that, we have to proof that a RS can export the annotations in the format we specify and that a RS can import it.
Ivan Herman: we should concentrate on the interexchange
Laurent Le Meur: I agree with that, one annotation file with different types inside might be sufficient to proove we can import and export it.
Laurent Le Meur: let's solve issues one by one to make sure we have a good draft. There are 10 plus a PR. I have also to add a section on metadata. I will do that before the weekend.
Susan Neuhaus: happy to help if there something I can do to share pressure.
Laurent Le Meur: having implementations would be great! even from this beta. It's a few steps to align Thorium and Readium implementations but we definitely want other RS to jump in.
Aligning text-style properties - w3c/epub-specs#2971
Wendy Reid: RS have to deal with dark mode, color contrast, high contrast, etc. i feel we should clarify that "yelow" note does not mean the note must use Yellow CSS color.
Laurent Le Meur: Agree, I will add this as a clear statement.
Susan Neuhaus: may we use IDs instead of color names ?
Ivan Herman: maybe we should use different wording, let's say "yellowish" instead of "yellow" to avoid confusions.
Laurent Le Meur: I don't see a clash, yellow is not a term invented by css, they just use it to qualify a color code. We don't do HTML, we do JSON, so I would prefer to use normal color, witha note that it is defining a range of colors. In our review, all RS use similar colors, yellow, blue, magenta, a set of meaningfull color. Let's not reword but instead have a clear statement. Yellow existed before css.
Ivan Herman: agree not to use HEX color codes, it's a name, acting like an ID, we don't specify what color should a RS apply to Yellow.
Wendy Reid: also we don't want to test exact color code used by RS, we cannot impose them a color pattern that may not fit in theyre designs. The name acts as a group or a tag.
GeorgeK: redlining is a publishing use case, stroke and red usually means a correction to do. We understand that with words. All of us in the industry.
<Susan Neuhaus> GeorgeK +1
Laurent Le Meur: that's it, color name is a semantic, the appearence of it has not to be defined at a standard level.
Ivan Herman: let's see how we word that in a PR.
AOB?
Laurent Le Meur: I have some comments, I'll do them in the PR.