https://github.com/w3c/publ-epub-revision/issues/1283

<romain> present_

<wendyreid> scribe+

<wendyreid> dauwhe: Hello everyone

<wendyreid> ... it looks like we have good attendance today, we haven't had a call in a while

<wendyreid> ... which is fine, today we have a particular issue we want to reach resolution on

<wendyreid> ... I encourage people to use github and the email list to raise and discuss issues

https://github.com/w3c/publ-epub-revision/issues/1283

<wendyreid> ... we have people all over the world with many different use cases, we want to hear from you

<wendyreid> ... we have issue #1283

<wendyreid> ... the order of <li> elements in the TOC must follow the order of the content documents

<wendyreid> ... things in <nav> must be in the same order as the linear reading order

<wendyreid> ... it has been rewritten a bit in EPUB 3.2

<wendyreid> ... however EPUBCheck did not check this until this year

<wendyreid> ... and now legacy content is failing in EPUBCheck 4.2.x

<wendyreid> ... many issues have been raised in the EPUBCheck repo, but it is a fundamental issue in the EPUB spec

<wendyreid> ... should we enforce this or modify

<romain> the reference issue in EPUBCheck: https://github.com/w3c/epubcheck/issues/1036

<wendyreid> ... I would like to hear people's thoughts on this

<wendyreid> mgarrish: I can jump in with my opinion. As you have said, this hasn't been raised, it's silently existed since 3.0

<wendyreid> ... I think this just came up because of the wording change in 3.2 (separation of bullets), it's now caused problems

<wendyreid> ... my perspective on it, without a requirement in the spec to enable, we're potentially enabling theoretical behaviours

<wendyreid> ... why do we have a MUST behaviour for something the authors are doing differently

<wendyreid> ... There's a logic that dictates that this be done, we shouldn't enforce this without a reason

<wendyreid> dauwhe: The very minimal change that might satisfy this is to change the MUST to a SHOULD, and demote the ERROR in EPUBCheck to a WARNING

<wendyreid> duga: I don't want to dominate the conversation, please speak up, we keep talking about the use cases, we see this from a group of Japanese publishers with an error in their content, and one is fixing it, I think for the better

<wendyreid> ... I don't want to support an error case in spec, but I have not seen a valid use case supporting this. What is a RS supposed to do with an out-of-order nav document

<wendyreid> ... almost every RS has something telling you where the next chapter is, or how long, etc

<wendyreid> ... I don't know what the use case is aside from "we don't want to fix this"

<wendyreid> dauwhe: How dependent are RS's depending on the nav or spine?

<wendyreid> duga: If an RS is using the spine they are wrong

<wendyreid> dauwhe: I believe this restriction has been checked in the NCX for all of history, that is concerning if it opens differently in different versions of ADE

<wendyreid> laudrain: I was thinking of the structure of the EPUB doesn't come from the nav file but from the semantic structure in epub:type, the nav document as a TOC, there's cases where the navigation is not straight forward (choose your own adventure). The problem faced by the japanese publishers is likely erroneous, but Takeshi has explained the issue with samples

https://github.com/w3c/epubcheck/issues/1036

<wendyreid> ... there are issues with vertical writing. For years they have built files that are selling well and EPUBCheck never complained

<wendyreid> ... I agree, why raise this now, I think EPUBCheck is better than ever before, I want to be prgamatic, and I support Dave's proposal to make this a SHOULD and a WARNING

<wendyreid> ... it has never been an error

<wendyreid> ... I understand we should build better files, let's go on and relax a bit

<scribe> scribenick: dauwhe

wendyreid: in response to brady, no one should use spine for nav
... I think where we are using spine as source of navigation, when nav or ncx are incomplete
... they may contain a single entity
... and then we need to take that information from spine and inject into UI navigation
... but I do think nav should reflect structure of the book
... I don't think this really impacts choose-your-own-adventure as that's likely based on anchors/links

<duga> Completely agree with Wendy

<wendyreid> Avneesh: I do not see the clarity of syncing EPUBCheck with EPUB 3.? what are we trying to change here

<wendyreid> ... if we think this is a maintenance of 3.2 or a feature for 3.3, maybe first we decide what to do with EPUBCheck and then decide what the spec needs to do, based on RS requirements

<wendyreid> ... maybe we can think this out more for the spec but make a minor change to EPUBCheck

<laudrain> +1 to Avneesh : EPUBCheck fix immediatly

<wendyreid> George: When I come to the end of a chapter in an EPUB, some reading systems do not automatically take you to the next spine item, but there's a hotkey, that's fine. The navigation is, for continuous reading, is based on the spine. There's no way to do that in the Edge reader, that's a bad example. I do think we want to be able to move continuously through the book

<wendyreid> ... the spine is how that is acheived

<wendyreid> ... I do think there are cases where the TOC is not organized in the same way (i.e. a cookbook or tour book), a chapter is devoted to restaurants or cathedrals, they're sprinkled throughout, but not referenced in the same way in the spine

<laudrain> q.

<wendyreid> ... I am leaning toward a SHOULD here, I do think that reading systems must provide sequential reading of the content

<wendyreid> romain: Just to mention that if we ever the restriction on the TOC nav, we should at the same time clarify what George just mentioned, the meaning of the spine and what an RS should do with it

<wendyreid> ... what is a RS supposed to do with this information, if they must provide a way to provide a way to move to the next spine item

<wendyreid> ... in the WCAG, ?.? "moving multiple ways" this is automatically fulfilled in EPUB because of the presence of the TOC and the spine, if we remove one of these, it could become a practical accessibility issue

<wendyreid> dauwhe: Just to Avneesh's point about versions, it is possible for us to make some evergreen changes to the spec, since we're not on the rec track, we do have options here.

<Zakim> dauwhe, you wanted to respond to avneesh

<laudrain> +1 to evergreen standard stuff with EPUB

<wendyreid> duga: I wanted to come back to Wendy, I have a question, it's not a big deal to us to get a weird TOC, what does Kobo do?

<wendyreid> dauwhe: I think I need to make a sample file where Moby Dick is ordered by Chapter title alphabetical

<wendyreid> laudrain: How does the RS know about the end of the main body text?

<wendyreid> ... there is more and more often additional text placed at the end of the text

<wendyreid> ... i.e. author interviews, notes, etc. These remaining files are not often read by the reader. The book is not "finished"

<wendyreid> ... the book is not a "good" book because the reader is not finishing it

<wendyreid> ... there is epub:type smenatics we could use, like "backmatter" and marking the body with "body matter"

<wendyreid> ... I would like to include this in the discussion on structure

<wendyreid> ... it may be independent of the nav progression

<wendyreid> dauwhe: That is a worthy issue, but we should raise it in the repo as a reading system issue and something to look into solutions for

<duga> +1 to Dave

<wendyreid> Avneesh: Now I'm for the usability, from the accessibility POV, if the TOC is in a different order, I'd expect a warning if that is the case, its bad UX

<wendyreid> ... there should be something that invokes a warning in the RS that this is case

<wendyreid> duga: To try and drive this to some sort of conclusion, can we now request EPUBCheck turns this to a warning, with text that it might be a ERROR eventually, look at the spec

<wendyreid> ... Dave create the version of moby dick and we test it to come to a consensus

<laudrain> +1 to duga

<wendyreid> +1

<wendyreid> dauwhe: That seems like the great idea, I want to solve the business problem, but today's discussion shows that we need more information, we've acidentally uncovered something that uncovers more fundamental problems

<wendyreid> laudrain: I support the proposal for both Brady and Avneesh. And the idea it could be checked in ACE, it's a warning in EPUBCheck, but ACE calls it out as an error

<wendyreid> romain: Just to mention that moving it to a warning is very simple

<Naomi> +1 for warning

<wendyreid> ... to Brady about adding info about it being a warning eventually, it's just a matter of UX, welcoming any suggestions to add that as a feature

<wendyreid> duga: I was thinking just some added text

<wendyreid> dauwhe: I would like to get agreement on the formal proposal, the EPUBCG recommends that EPUBCheck demotes this from an ERROR to a WARNING while we investigate this

<garth> +1

+1

<ShinyaTakami> +1

<duga> +1

<romain> +1

<laudrain> +1

<wendyreid> ... do we all agree?

<wendyreid> +1

<mgarrish> +1

<toshiakikoike> +1

<Bill_Kasdorf> +1

<wendyreid> mgarrish: So long as we investigate, let's make sure we get feedback from the Japanese reading system developers as well

<wendyreid> dauwhe: This feels like progress!

<wendyreid> dauwhe: I have an action item to make a very strange EPUB

<laudrain> I’ll have dinner very soon

<wendyreid> ... I forgot to ask if we have any new people

<wendyreid> ... there was one other thing I wanted to discuss today

https://github.com/w3c/publ-cg/issues/88

<wendyreid> ... Issue #88 in the PCG repo

<wendyreid> ... now that the IDPF is more or less gone, one consequence of that is that there was an IDPF forum that people could turn to to ask questions

<wendyreid> ... it is no longer functional

<wendyreid> ... as we've talked about best practices and documentation

<wendyreid> ... one thing that seems to be missing is somewhere for people to ask questions

<wendyreid> ... EPUB isn't the simplest thing in the world, it's hard to find a place where there are people around to answer these questions

<wendyreid> ... there's the twitter #eprdctn community, and a section for it on StackOverflow, but no one is answering those consistently

<wendyreid> ... I'm not clear if that is an appropriate thing for the CG to take up

<wendyreid> ... how would we do it?

<wendyreid> ... there's more or less consensus that GitHub issues aren't the way to go, an increased presence on StackOverflow maybe?

<wendyreid> ... what does everyone think?

<wendyreid> Naomi: I just want to say that I would love it if I had time to answer people's questions

<wendyreid> ... I don't know if anyone in the group has the time, if we can't commit to doing it, we maybe aren't the best source

<duga> +1

<wendyreid> dkaplan: I would say that if there is a commitment, I would be in favour of something low-tech and easy, like a mailing list

<wendyreid> ... StackOverflow has a few problems, a fear factor for non-devs, and a lot of people don't have public twitter accounts for #eprdctn

<wendyreid> ... whereas if there's a mailing list, with a few people who are happy to answer, a lot of people asking questions aren't everywhere

<wendyreid> George: I posed this question to Dave Gunn from DAISY, he replied that Q&A maker from microsoft, which is easy to use, it's a gateway to their Azure bot, it can take information from emails, it can take info from web content

<wendyreid> ... this is something requiring curation, but it might provide a mechanism for common questions

<wendyreid> ... having links to source code that can be copy-pasted, we're looking into this for higher ed for questions about RSs

<wendyreid> Naomi: One of the other issues with StackOverflow is we are going to run into people who don't realise that the question is EPUB-specific not a web question.

<dkaplan3> naomi++ -- this is why StackOverflow is terrible for accessibility!

<wendyreid> ... it's good in isolation but there's just so many other people. I don't know if an email list is any better, since it's private, we'll answer a lot of the same questions repeatedly

<wendyreid> ... I have no suggestions though

<wendyreid> dauwhe: At least W3C takes email archives seriously

<wendyreid> ... there's a tradition of looking for old proposals

<wendyreid> ... there's a possibility of making that work

<wendyreid> ... it allows us to create a FAQ of sorts

<wendyreid> ... it would be modest amounts of work to link people to common issues

<wendyreid> romain: I just want to mention someone in the tracker mentioned an alternative to StackOverflow but creates a nice area for EPUB. It's called StackExchange, it has all of the features. I think the mailing list, the solution has to make it easy to have quality participation, and has to be easy to look at informatino

<wendyreid> ... It's key for knowledge bases or community forums, the silent majority is just looking for information, it's hard for them to do with an email archive

<wendyreid> dauwhe: I hear you on those issues. One thing about email is it would be easy to start small and see if its workable

<wendyreid> ... we could learn as we go along

<wendyreid> ... I'm concerned about anything that involves an investment of setting up

<romain> good point about the benefit of "starting small"

<wendyreid> mgarrish: Any solution is going to run into the inertia of people moving

<dkaplan3> Starting small is good, going back to Naomi's first point about whether we'll answer questions at all!

<wendyreid> ... even if is not the best way, we should look where people are going

<wendyreid> ... the stack exchange is great if "I have a problem"/ "here's a solution" but not good for discussions of best practices

<wendyreid> ... we might need different forums for different kinds of questions

<wendyreid> George: It would be great to capture these discussions, we have the KB for accessibility, if we could have things that are general and fall into the same kinds of guidance that would be good

<wendyreid> dkaplan: There are absolutely going to be people happy on twitter, or on SO, those are places who are answering those questions

<wendyreid> ... I think a mailing list is a good idea, but who is the we

<wendyreid> ... and how much of a commitment are people willing to make

<wendyreid> ... if people are willing, we can assign them to different areas

<wendyreid> ... how do we make it happen

<wendyreid> dauwhe: Any billionaires willing to pay us to answer questions about EPUB?

<wendyreid> Naomi: I think my main thing that I see a lot of, we need ways to tell people nicely and with compassion that they are trying to do things they can't do

<wendyreid> ... I think a lot of the time is "how can I put this fun thing in an EPUB", but not everyone wants to hear "no that won't work"

<wendyreid> ... not everyone is as focused on a single file as we are

<wendyreid> dauwhe: I'm reminded of many forums with checklists of questions

<wendyreid> ... then we can set up an autoresponder with the EPUB motto

<wendyreid> ... I'm not thinking of a great conclusion, but we have brought up some good issues

<wendyreid> ... we can mull over this

<wendyreid> ... any other thoughts?

<wendyreid> ... it's nearly the end of the hour, and we might be all hungry

<liam> time for a facebook page maybe :)

<Avneesh> https://github.com/w3c/publ-cg/issues/89

<wendyreid> Avneesh: Just want to remind everyone that we're revising techniques for EPUB accessibility

<liam> (i wasn't able to join the call today but have been following the minutes)

<wendyreid> ... if anyone has suggestions, please help us

<wendyreid> ... right now this is the most visible place for the issues

<wendyreid> dauwhe: Thanks everyone!

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)

Present: wendyreid dauwhe ShinyaTakami romain laudrain toshiakikoike George dkaplan3 Naomi duga Avneesh Garth mgarrish gpellegrino Bill_Kasdorf
Found ScribeNick: dauwhe
Inferring Scribes: dauwhe

WARNING: No "Topic:" lines found.

Found Date: 11 Jul 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.)