Meeting minutes
Guidelines Techniques for Metadata
George: Principals - harmonizing the strings, fixing rich content. addressing all the issues coming in. No major changes.
<AvneeshSingh> principles: https://
George: working on EPUB Techniques and fixing them.
<AvneeshSingh> EPUB metadata techniques: https://
<AvneeshSingh> ONIX metadata techniques: https://
George: one issue is around Audio which is in the agenda. Complimentary audio, small chunks (reading of a poem) for example just complimentary when audio is present but when it is not an audio book. Modes of reading we have the area for visual adjustments, non visual reading, or if it is an audio book it could be just audio or audio synced with text.
… transcripts provided is Rich content.
… pre-recorded audio (maybe called Audio Book - discussions ongoing).
… current "pre-recorded audio"
… audio book with no text alternative, other option audio book with synchronized text. but Heading PreRecorded Audio.
AvneeshSingh: Issue #?
… Gregorio has created a comparison table between the 3 documents with the ID strings for language support.
rickj: Techniques Duff Johnson created some PDF techniques should this be in this version or a later revision.
AvneeshSingh: Latter revision would be best.
rickj: For our initial release froze on the Nov. release we had to get things done.
The principles and technique documents are being finalized.
Input from the group is required for the headings structure in the guidelines and the techniques. What is appropriate for implementers?
<rickj> Duff's PDF techniques post: See: https://
<rickj> And, for context…
<rickj> https://
AvneeshSingh: we discovered a gap in the techniques.
<AvneeshSingh> w3c/
mgarrish: When I was updating the Metadata viewer we no longer have specific headings, those are mostly gone, but there isn't a lot of instruction on how to deal with these various categories, and what headings should be used is up to the developer. We are shifting the burden to folks who may not understand this. like "this information is not available" but what information? Its very open and I don't think this might be a good idea.
gpellegrino: The heading structure issues was 3 key a11y requirements "Ways of Reading" could be grouped instead of a separate heading for each item which would only have 1 item under each heading.
… should we group these 3 requirements, should we implement headings in the techniques. more an issue of time, than meaning of these.
gautierchomel: EDRLab respond yes and yes, Readium will have "Ways of Reading" instead of supports non-visual reading, etc.
Charles: having specified headings would be a good idea. like the Nutrition label for food. having a consistent heading that can be translated is good.
AvneeshSingh: won't this require a major restructuring.
CharlesL: I dont think so.
mgarrish: I am not sure if it will be easy or not, how much do we want to control the end output display. i.e. ordering of this information etc.
AvneeshSingh: how important is headings with IDs?
rickj: if there is something in that section the heading will show up.
AvneeshSingh: we should refactor the code to improve headings. It will take some time. How much time do you expect.
mgarrish: its more an issue of agreement, if we are removing categories things will need to be reviewed 2-3 weeks I think.
rickj: should we consider this to be a 2.1 release issue?
gpellegrino: JSON issue non-stable structure, if we want the JSON with all the strings and is canonical we should make this change before making the JSON.
George: I agree getting the JSON file finalized, putting the headings back into the technique areas. I don't think it means reverting as other things were done at the same time the Principals hadn't yet removed the headings. some implementations may have a heading with 1 item under it. but that is the only drawback
… the JSON file will be finished and the future if we want to restructure I don't see it to be a major issue "Ways to Read" less technical than "Reading Modes" could be added right now even if its not in the display.
Charles: the reason why this was a major issue was for Vital Source but they are already using the Nov. release.
rickj: we will just need to work through it as the translations are the main concern.
gautierchomel: the issue on our side is Readium we have 3 weeks to 1 months so it is an acceptable delay.
AvneeshSingh: Is 3 weeks acceptable for Vital Source.
George: what are we going to do? are we going to add Ways to Ready. with the 3 areas.
Charles: Yes
gpellegrino: Yes
gpellegrino: is that 3 chunks of code that generates 1 of 3 statements code blocks. and the final condition of not available 3 times how do we deal with that?
… we need to merge the 3 code blocks
Issue #563: Fixed layouts can be display modifiable.
Charles: we could group it with one block but will take more work potentially.
<AvneeshSingh> w3c/
mgarrish: the order for the algorisms for fixed layout or display transformable should the author's statement as law. do we want to accept fixedlayouts are display transformable even if they aren't. Not sure if we are saying the right thing in that section, if its "fixedlayout and it says displaytransformable" should we call this out separately? Fixed Layouts usually can't be controled like normal display conformability.
George: if I can't change the font size, color etc. and if I need to figure something out what I can do normally I don't see that as being transformable.
… if its fixed layout then its not reflowable.
Charles: we should call out portions "MAY" be transformable for certain potions of this book when both exist.
gautierchomel: french prototypes we never say appearance can't be modified. Fixed Layout means appearance can not be modified.
gpellegrino: in France fixed layout is used as a package for specialized users (dyslexic, etc.) transforming the text is present in the fixed layout) what about that type of publication what info would be displayed?
gautierchomel: both information would appear.
… it just says "Fixed layout" and can have "Display Transformability"
… we should not tweek, we should change the wording regarding for fixed layout.
mgarrish: we are opening up a can of worms here a "fixed layout" anything in HTML is display transformable. is fixed layout also displayed. most users will know what limitations there are with a Fixed Layout book. respect what the author says. mixed FL and reflowable is another case that Charles brought up. Leave it up to the user to figure out if this works for them or not.
AvneeshSingh: displaying what the publisher is declaring and not interpret what that means?
mgarrish: displayTransformable:Fixed Layout, displayTransformable:Reflowable.
Chris: Should this be a new ONIX consideration?
gpellegrino: I think Onix already supports this.
<gpellegrino> https://
gpellegrino: we have a section highlighting file format, reflowable / fixed is found in another part. Matt maybe also consider adding that information in the general section about the book.
George: we don't have IDs for those sections.
gpellegrino: Rick what do you think that more of the general not specifically for a11y.
RickJ: none of that would be in the a11y tab, we could include it in the a11y section.
George: I like the idea of keeping it simple and not adding this complexity as its already covered outside of the a11y section.
gautierchomel: we should keep that information and we just need to find the write wording. provides information about a11y. they may not be looking there
… have consistent design.
Charles: I agree with Gautier, and should have both information
AvneeshSingh: editors call at 16:00 tomorrow
George: are we calling out audio books as a separate section whats the difference.
AvneeshSingh: pre-recorded audio includes audio books and synchronized does not include snipits of audio, thats covered in Rich Content.
George: is the heading Pre-Recorded Audio? - YES