<Rachel> scribenick: mateus

<scribe> scribenick: mateus

dauwhe: welcome everybody... another thrilling meeting of epub3cg!

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1248

dauwhe: gonna start with: new feature request, which is somewhat concerning at this stage of epub 3.2 (issue 1248)
... MURATA proposed a link relationship in the packaging file, to specify an audio rendering of a book title, so that in cases where text-to-speech (TTS) doesn't work, users with visual disabilities can still work their way through the catalog and pick their book
... my huge concern is timing. We're very close to done and I worry about adding a feature that would require changes to EPUBCheck

<MURATA> +q

dauwhe: EPUB also has generic extension mechanisms for metadata, so this would be possible within the methods we already have

romain: a clarification about EPUBCheck--introducing a new property would be very straightforward
... we could do this very quickly if we decide in favor

MURATA: I understand that my request is very late; if it's too late, I can live without it in EPUB 3.2
... but what is our plan for 3.3? Now that we have incorporated external vocabularies in 3.2, we will need a new minor version of EPUB with new extensions

dauwhe: let's go through the queue and discuss

mgarrish: two points—one, possibly one point in favor is that there's no reading system requirement, so we're adding a feature, but only for people who want to implement it, not unleashing it on everyone who develops reading systems
... two, this is the downside of bringing these definitions into the main spec, and we can use the extension mechanisms, but keeping it in the spec also avoids things like adding prefixes

laudrain: i would not be happy with a 3.3 version with just extensions to the vocabularies; there should be a path for 3.2
... this took a lot of work that took a year; we already have EPUBCheck validating 3.2, and it's a good message to implementers that it's ready to use
... should avoid working on a new release, so we don't disturb publishing industry
... i would not be against 3.2.1, if that's what we do
... given romain's advice re EPUBCheck, we can maybe not revise EPUB 3

garth: we should remember that 3.0.1 was our must successful version—i'm, open to a 3.2.1; a new feature at this late date... i was prepared to hate the idea, but this is kind of cute and seemingly useful
... i would not be opposed to putting it in 3.2

dauwhe: getting back to the feature in question, i have general concerns that EPUB often specifies things that are not widely implemented
... we need to get to a place where we can get two committed implementations
... do we have that for this feature? are we going to get multiple implementations?

MURATA: we have three implementations

dkaplan: maybe what MURATA has to say would address this, but to dauwhe's second concern... there are very rich features in EPUB that are not implemented, and there are many that are, but are not used
... it goes beyond the question of specific implementers... are there publishers who would take them up?
... when we're coming up against a deadline, adding a very particular feature... there's a question about both implementation from a reading system and from a publisher

<MURATA> +q

dkaplan: and absolutely, DAISY might use it instantly, in which case we should do it

dauwhe: great point, regarding publishers recording these titles
... MURATA, can you talk about the use cases a little more? you talked about TTS not supporting the language... is this a problem in the Japanese market?

MURATA: this is a real problem about Japanese textbooks. the thing is, Japanese TTS is not very reliable, lots of mistakes
... adult users are already aware of these mistakes and automatically fix them, but kids get very confused
... Japanese EPUB textbooks always contain recorded text, but that doesn't address the bookshelf interface
... I'm quite sure that if this feature is added, Japanese textbooks will use it from next year on

dauwhe: ok, just wanted to make sure that publishers would commit to using this

MURATA: it won't be added to the publishing guidelines, because adults would be ok, but only certain users (kids) would need it

dauwhe: but publishers would use the feature

MURATA: yes

<laudrain> Yes add it

<mgarrish> +1

<garth> +1

<dkaplan3> +1 if it sounds like Japanese textbook publishers will be signing on to it

dauwhe: should we add it?

<duga> +.5

<laudrain> +1

<ShinyaTakami> +1

<dkaplan3> +1 Rachel

<Bill_Kasdorf> +1 because apparently it won't be a problem to add to EPUBCheck at this time

Rachel: my feeling is that if we add this, this is the end of new features in 3.2... this is a one time thing, we draw a line in the sand and there's a feature freeze

<laudrain> +1 to Rachel

<mgarrish> +1 to feature freeze

<Naomi_> Argh can't unmute

Naomi_: i managed to unmute myself!
... maybe it's just a discrepancy between how publishers in the US are displaying to users and how Japanese publishers are

<MURATA> +q

Naomi_: the title, in the US, is not coming from the ebook, but rather from the ONIX distributed to the retailer
... is this different in Japan?

MURATA: trade books and textbooks are different; for trade books, ONIX is likely to be used; textbooks would usually have embedded metadata, and reading systems will use it

laudrain: i'm not sure... this depends on the context in which the title comes from the ONIX... on websites, it comes from ONIX, but in the bookshelf of the user, when EPUB is ingested by reading system, i'm not sure it comes from ONIX
... there are differences between reading systems—some use metadata from inside the reading system (file), and some take it from the bookstore
... but metadata in the book also has to be clear and correct anyway

Avneesh: the discussion is going long, so just want to put forward the context; what MURATA explained by email is that reading systems like ??? who are DAISY users are upgrading to EPUB, and these people are ready to implement this specific feature for EPUB 3 while they are in the process of upgrading
... these are mainstream features, but they come from DAISY
... in the reader system, the user scrolls through the list of items and listens to the titles, so it's different from the usual flow

<MURATA> Thanks, everybody!

<dauwhe> https://github.com/w3c/epubcheck/issues/1036

dauwhe: it seems like we have consensus that the feature is valuable, not a burden on EPUBCheck, and should be added to 3.2... so let's go with that and move on!

<Rachel> from Marianne GP via Zoom: FYI: A new feature will give new messages when file is validated with EPUBCheck, right? EPUBCheck translations have deadline April 14.

dauwhe: next issue is EPUBCheck (1036), displaying errors when nav order doesn't match the spine order
... i think this is to spec, but don't want risking invalidating titles out there.... any concerns?

Naomi_: i can tell you that a couple of months ago, we built this check into our own systems... i think it's great that it's in EPUBCheck
... there are specific use cases for TOCs that aren't in order, but that's more about visual display inline in the book, rather than the navigational guide that the nav doc is
... not everyone will agree with me

dauwhe: any other comments? i have not run into this issue on our backlist, but we make simple books

Naomi_: I did check, and it was a good thing!

dauwhe: it could confuse the reader... any other thoughts?

laudrain: the compromise would be between being more conformant to the spec versus endangering the EPUB productions that already exist...
... whether people are building EPUBs today with this kind of issue...
... we should consider it to be more lax on this control

<MURATA> +q

dauwhe: anyone else?

ShinyaTakami: just reported this issue; i'm sorry, we didn't know the exact specification of EPUB, but Japanese publish started to generate from EPUB 3, and the printed book has such an out of order TOC... maybe in Japan there would be many such 'wrong' EPUBs... so please consider this situation

MURATA: yes, i think we should separate two issues—should we change the spec and allow discrepancies like this; and, newer versions of EPUBCheck will certainly report more errors... and whenever new types of errors are detected, some publishers will find problems (no matter the added errors)...
... should we provide a mechanism for specifying the version of EPUBCheck or changing the config of EPUBCheck?
... EPUBCheck issues and spec issues should be separated
... should we change the spec? if not, we should discuss EPUBCheck

mgarrish: the question i have is, why is it a must? i don't get why it's a big problem if the content doesn't exactly match... falls under best practice

<laudrain> +1 to mgarrish

mgarrish: if changing this to a SHOULD in the spec makes everyone happy, i don't see what's critical about having a MUST here

<Bill_Kasdorf> +1 to should

<Naomi_> +1 to should

<ShinyaTakami> +1 to should

<dauwhe> The references in the toc nav element MUST be ordered such that they reflect both: [1] the order of the referenced EPUB Content Documents in the spine; [2] the order of the targeted elements within their respective EPUB Content Documents.

garth: was gonna say that we shouldn't change the spec given the feature freeze, but i don't have the problem with SHOULD vs MUST... and we should consider whether making it a WARNING in the validation

<laudrain> +1 to garth

garth: SHOULD and WARNING would not be a bad combination

dauwhe: just posted the relevant part of the spec on IRC... i
... i'm not sure what to think of this
... what would be the impact on the reader if the nav were different from the spine
... i'm wary of invalidating content
... hoping for wisdom from duga

duga: i strongly object to changing to SHOULD from MUST, we had reasons, and it's very late to make this kind of change... it could make navigation confusing for sighted user, and i have no idea about a11y implications
... maybe it's fine, but i don't want to switch this today just because there are some documents that did it wrong

<MURATA> +q

duga: but there was a reason for putting this there
... once we change this to a SHOULD, anything goes
... we heard about a publisher who found actual errors in their content
... maybe leaving this in would be a good idea

Rachel: reminder that we have a lot more on the agenda

<MURATA> -q

Naomi_: there are some reading systems that i can't remember that use the nav doc to populate running heads and running feet... could be a reason for keeping it a MUST, so we don't break that functionality
... and features that show you your location in real time... this could mess that up too

Avneesh: not coming from a11y perspective, but from a process perspective, changing this now would be risky because we might not remember the reason
... the other thing is EPUBCheck... we had discussed providing an escape option to avoid problems in the backlist
... up to you to decide whether it would be a huge problem to use the escape option
... if we give the time now for publishers to make changes, that could work

<laudrain> +1 to wise advice from Avneesh !

dkaplan: +1000000 on the process thing that duga and Avneesh brought up... the particular details of the issue are irrelevant; i don't think we can loosen requirements basically on the last day
... if we do that, we need a whole new process of discovery and testing, and maybe we have to change deadlines
... from a process point of view, if it's important enough to make this change, then it's important enough to say we won't be closing this today
... can't loosen requirements suddenly

ShinyaTakami: simply speaking, errors by EPUBCheck are critical in Japan because it prevents distribution to stores

<Zakim> laudrain, you wanted to ask to Romain if it’s difficult to change it in EPUBCheck to WARNING

ShinyaTakami: changing to WARNING is fine; changing MUST to SHOULD on the spec would also be ok if we change EPUBCheck to WARNING

laudrain: just asking romain if this would be a big change in EPUBCheck

romain: not a big change

laudrain: then i would support the idea (to change to WARNING)... so not changing the spec, but consciously adopt new behavior in EPUBCheck on this issue

mgarrish: this is the sort of stuff that bugs me when EPUBCheck does different things than the spec, because we forget these custom rules
... if we missed this, the problems are already out there... we should try to have consistency between what we will report and what the spec will say

duga: +1 to mgarrish; if we change to WARNING, i want a date for when we turn it back into ERROR, so we give publishers time, but don't change it forever

<wolfgang> +1 to Matt

<Avneesh> date for making it error can be December 2019

duga: in any case, i would only support if this is a temporary thing to allow publishers to change their errors
... as Naomi_ pointed out, we would have problems with this (Google Play), because we do highlight the user's positions in content

garth: keeping the spec as is with a MUST and going with WARNING in EPUBCheck seems reasonable, but the one point that might drive us to another solution, is that this replicates paper content...
... if we see that the spec is wrong, we should do must research
... but not make the change right now

dauwhe: these are just opinions, but i don't think we should change the spec, and we should keep EPUBCheck consistent with the spec
... i understand that may cause pain for some content, but as Naomi_ mentioned, this allowed them to fix some content that was wrong, having nav and spine out of sync would cause problems in some reading systems... i would feel uncomfortable making this change
... at this point, no decision is a decision to go ahead with the status quo, and say that nav must not conflict with spine, and leave EPUBCheck as is

garth: are you giving an opinion on EPUBCheck?

dauwhe: yes, it should stay an ERROR in EPUBCheck, to keep consistency

laudrain: quick comment, because of the delay we are in now... EPUB 3.2 is almost finished, so I would support dauwhe's proposal

Rachel: me too

duga: garth was wrong!!!!!!

Avneesh: this is not a do or die decision; we decide on this for now, and people create a lot of noise, we could always do a maintenance release to change to WARNING

<dauwhe> +1

dauwhe: I propose we keep the status quo for now

<laudrain> +1

<Rachel> +1

<wolfgang> +1

<duga> +1

+1

<garth> +0.1

<Bill_Kasdorf> +1

<dkaplan3> +1

dauwhe: ok, now some truly exciting issues....
... those two were the big ones up for group discussion
... been also working on cleaning up some lingering issues
... the first one is #1240 around the definition of content documents
... mgarrish provided changed language—wondering if romain is ok with what mgarrish wrote

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1240#issuecomment-468008599

dauwhe: if that's ok, i can just edit it into the spec and close the issue
... does that work, romain?

<dkaplan3> dauwhe++

[browser wars]

scribe: is everyone generally ok with this language?

[seems like it]

<Rachel> +1

scribe: then so be it, this was mostly to avoid the SVG font thing

<Naomi_> +1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1236

scribe: now #1236

<garth> +1

<duga> +1

<Rachel> +1

<mgarrish> +1

<dauwhe> +1

scribe: many truly enlightening and stimulating conversations on sizing the initial containing block for SVG documents... revert to what 3.0.1 said about this, is everyone ok with that?

<Naomi_> +1 because we don't use it so I don't have an opinion

scribe: good enough for me at this stage

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1207

<garth> +1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1207#issuecomment-476328668

scribe: #1207, getting more and more annoyed by the rate of change of the zip spec... ok to point to the more general section in the spec, so we can be done with this problem?
... not an issue of cosmic importance
... or, does anyone object?

Rachel: no objection

Naomi_: i don't think this applies to us

dauwhe: not unless you have 4GB EPUBs...

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1186

dauwhe: looks like we are resolved there
... #1186, this is introductory text in the EPUB non-normative part... we relaxed the warning, as we see this EPUBCheck stuff, saying all EPUB 3.1 files are valid 3.2 files...
... any more wordsmithing?
... Naomi_: as long as we make it clear to people that the reason they're seeing valid files that are now invalid... it was an EPUBCheck thing, not that the files were perfectly valid before; it's a message to users, not a spec problem
... agreed

romain: some tiny changes here and there where 3.2 is not strongly backwards compatible with 3.0.1
... for example, sometimes due to dependent specs (like HTML) being updated, such as removed elements
... some that were valid in 3.0.1 might not be in 3.2...
... maybe not a big problem

dauwhe: i'll go back and look again at rewording
... this section based on what romain just said... that underlying technologies change and EPUBCheck are improving
... we face the facts that the ecosystem is evolving

MURATA: this is about our approach, rather than actual statements... it's just our position

dauwhe: i'll try to make that more explicit

laudrain: agreed. we have to sell 3.2 and EPUBCheck 4.0.2, and sell it with positive vision
... if EPUBCheck is revealing errors now, it's because HTML validation is better
... the core EPUB 3 is the 'living' HTML and CSS, bringing us into the future, but that means we have to cope with Web Platform evolution
... and to make publishers confident that they are producing better files and validating using better tools

dauwhe: sounds good. i'll see what i can do

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1070

dauwhe: last profoundly annoying issue, #1070, related to IDL... do we want accurate reference or stable reference? we have the accurate reference now, and i'm ok with that
... we don't use WebIDL much
... any profound thoughts?
... just gonna let ReSpec do what it does

Rachel: fine with status quo

<MURATA> +1

dauwhe: at 59 after the hour... just waiting for clock to run out!
... looks like we got through the entire agenda, another productive meeting!

laudrain: voting for 3.2 is next time?

dauwhe: yes, i'll talk to W3C team about IP commitments, which is the final step
... then we can work on publishing formally

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/cant/can't/
Present: mateus dkaplan3 Rachel ShinyaTakami dauwhe laudrain Bill_Kasdorf romain mgarrish gpellegrino Garth Avneesh duga wolfgang Naomi_
Regrets: Tzviya_Siegman Wendy_Reid George_Kerscher Zheng(Jeff) Xu
Found ScribeNick: mateus
Found ScribeNick: mateus
Inferring Scribes: mateus

WARNING: No "Topic:" lines found.

Found Date: 11 Apr 2019
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)