Meeting minutes
Review of in-progress techniques documents.
AvneeshSingh: Gregorio and Charles have done technics drafts.
<AvneeshSingh> https://
gpellegrino: regarding ONIX techniques, first examples concerns Visual Adjustement. We found that best approach was to use XPath to define metadata we're looking for. That's why we defined 2 common functions (see section 3) to prepare and query the metadatas...
… then each technique is in 2 parts, one variable setup and one instructions...
gpellegrino: additionnaly a detail element "understanding..." gives details on each variable
CharlesL: this is the work in progress link for schema.org techniques.
<Bill_Kasdorf> +1 to Wendy
wendyreid: I understood this document as guidance for publishers to know how theire metadata will be used. It looks complexe ir.
gpellegrino: principes document is targeted at publishers, techniques for who consume, ingest and dispaly metadata.
rickj: yes, it works for us and our needs. Nice work, well usable to us.
CharlesL: I think additions will be needed in variable set, we'll iterate while writing.
gautierchomel: We should indicate the audience
… , user oriented, we are not provided useful information for searching, yet.
… dictionary of metadata would help for publishers. "does your book have images? Yes? Does those images required to understand the content? Does your images have alt text etc. at the end so you can get what ONIX metadata for your book. Guidance for publishers should be added but this is a separate document potentially.
AvneeshSingh: SMART has this tool. for metadata for OPF / ONIX
<rickj> can a link to the principles document be added to the transcript
Sure thing Rick, good idea.
wendyreid: that helps understanding the scope of the documents. Principle and techniques are deeply linked, and giving a clear view to the publisher is maybe missing.
<wendyreid> https://
<Bill_Kasdorf> +1 again to Wendy
<rickj> perhaps a resolution to w3c/
wendyreid: plain language description of what the algorithm do may be of use too.
AvneeshSingh: we'll discuss that in editors call and see what we can propose.
wendyreid: I think it's of use for publishers but also to implementers.
rickj: a visual to connect dots may help too. We've discussed that last year.
Hadrien: during accessible publishing summit organised by NNELS in Toronto, demonstrations of users showed confusion in the audience about wordings like "screen reader friendly". Recomandations highlighted that this work on accessible metadata is of use for a lot of people (like being able to use TTS).
AvneeshSingh: that's confirms the rewriting axe we've adopted here.
gautierchomel: tricky to determine what the reading system supports vs. what the EPUB has.
Hadrien: there's also confusions because the ebook can claim it works with TTS, but maybe the reading system does not provide the service.
George: Amazon says for example Screen Reader Supported
Hadrien: and some DRMs can block TTS.
wendyreid: There is some necesities on the reading system side to refine information on available funcionalities. I'm not sure how to articulate the conditionals depending on the reading system.
Hadrien: thta's make a llink with actual discussion in fxl working group about what TTS does exactlky.
gpellegrino: RS limitations are adressed in the principle, but not for every information. See example : https://
georges: reading system TTS is evaluated in epubtest.org. People who don't know needs to look at RS evaluations done where we test with diferent assistives technologies (AT) to help pêople chose the best reading system for them
rickj: there's probably a need to tie books claims and RS capabilities in the future. But not now.
CharlesL: maybe we can reuse the principles and techniques in epubtest.org to make sure funcionalities informes are tested.
/informes/informed/
Review of samples of localization JSON files.
<AvneeshSingh> https://
gautierchomel: localization, clear process for translation of the words that are used in the principals / techniques.
… same vocabulary used. We will accept multiple versions say for French. French Canadian, vs. French Belgium. Even in the same geography could have a different localization. we won't rate it either.
… interesting to have mechanism to keep track of localization and help with translations. provide a tool to help we get one translation pair.
… we agreed to use JSON file. duplicated for each localization.
… nested pair values, canonical mix of JSON was the most up to date proposal. we have 1st level of metadata
… four letter language, language french from france varient from EDRLAB scholar , academic, etc. audience we are serving, how it was obtained.
… tried to reuse the keys used in principal document for each key we have two nested keys compact / descriptive.
… example we have is in the principals. would like to get feedback on who would use this kind of file. would it be difficult to use etc.
… once we agree on the file we can see if we can use it in Transifex for translation for example.
rickj: Strongly support Mixed format others have weakness.
… using numbering system can be limiting.
… variant vs. language codes. FR-FR , FR-CA etc.
gautierchomel: varient multiple FR-FR (EDRLAB vs some other organization) maybe the author.?
… maybe we don't need the varient key,
rickj: variant in the language code yes.
wendyreid: We may want to align with EPUB. looking over C-Mixed gives the best option.
… can we stop using Read Aloud, should be more specific.
… complimentary audio / text does that mean Sync media or transcript?
AvneeshSingh: principals document we should address this not in the JSON file. this is just the structure. Please open an issue for that.
George: Matt and I wrote a document about these confusing things, we published last year. we attempted to clarify. will find the link.
<rickj> can we get a link to the clarifying document George mentioned added to the transcript?
AvneeshSingh: there has been a lot of discussion / debate for the Principals document then we can revisit there with a github issue.
gautierchomel: IETF Language tags.
Hadrien: serialization easier to not use JSON for that. we might want to consider YAML which is less likely to break things
S/gautierchomel: IETF/Hadrien: IETF
AvneeshSingh: we are discussing this with Ivan to have a repo for this.
… we would like to use a tool instead of folks editing the JSON directly.
… we need to test TransFX for accessibility.
Hadrien: all of them support different file formats but JSON is usually more difficult
gpellegrino: once we have a localization if we use TransFX only use the UI there for localization it will be only the developers who need to use the JSON files.
gautierchomel: Maybe I am over engineering this with using JSON.
AvneeshSingh: we need to start collecting the terms and we need to figure out what is the best option to capture this and then utilize with what tool we will use and what file format would be best.
AvneeshSingh: lets figure this out in the editors call
rickj: we love JSON so don't give up on it too quickly. :)
gautierchomel: you would use a JSON file directly?
rickj: Yes, and we would produce that as part of our translations as well.
AvneeshSingh: 2 weeks from now next meeting.