Daniel and Frederick of TexTalk introduce themselves

<scribe> scribenick: Tzviya

Fredrik: TexTalk works on Accessible Publishing, including EPUB output
... created a PR in epucheck to match Nordic Guidelines for EPUB which would enable validation for a11y in their pipeline
... Now they rely on daisy pipeline
... TexTalk is offering to help with epubcheck, time permitting

Daniel: Nordic formats is structured very similarly to DTBook - very strict rules

Romain: I'm slightly familiar with nordic guidelines. The DAISY pipeline tech is not used in epubcheck
... for this sort of feature request, when you'd like epubcheck to integrate a specific set of rules, I don't think it should be integrated into the core
... I do think that it's a good idea to make it into an API that we can plug features into

Tzviya: What do we do with the PR now?

Romain: Integrating natively now is not the way to go. Adding extension hooks is a better way to go. We should have the mechanisms in place, as we did with edupub

<bigbluehat> https://github.com/IDPF/epubcheck/pull/805

Recommendations to clean up the site

for reference, see https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

<bigbluehat> https://github.com/BigBlueHat/web-annotation-protocol-tester/tree/master/test

bigbluehat: In Web Annotations, we used behavior driven tests
... these tests are written in JavaScript
... these can be written in other languages

<bigbluehat> https://github.com/BigBlueHat/web-annotation-protocol-tester/blob/master/test/musts.js#L18-L32

<Kalaspuffar> Hello.

<bigbluehat> https://github.com/BigBlueHat/web-annotation-protocol-tester/blob/master/test/musts.js#L18-L32

bigbluehat: this is a selection of behaviour-driven tests

<bigbluehat> https://github.com/BigBlueHat/web-annotation-protocol-tester/blob/master/screenshot.png

bigbluehat: the output looks like the specification itself, with the prose removed
... one approach is to go through the spec and bring everything in as pending tests

<rdeltour> +1 great idea, it would enforce more atomic tests as well

Tobias: is your proposal to do a complete rewrite of the test suite?

bigbluehat: It tends to work best if it happens gradually
... perhaps there are ways to make use of schematron
... the hope is that if you narrow the code that needs to be written, it's easier to be written
... maybe new tests are written in a new way?

tobias: Do you think we could run this alongside current implementation?

bigbluehat: yes

tobias: would this integrate well with the current structure of epubcheck

bigbluehat: I got lost in the current structure of the repo, so i can't answer
... I'm not proposing that the tests have to be in JS, but I think that you will engage more developers that way

rdeltour: There are 2 things that need to be tested, the source code and integration tests (validation of an epub)
... I think bigbluehat's test are about integration
... Historically, we have a lot of source code, and limited integration
... We proposed suite clean up a few months ago, and I'm wondering why we didn't think of behavior driven before
... It would make clean up much more approachable
... The practicalities - JS vs other languages

The test suite could be done in JS and envoke existing tests. I don't have a strong opinion.

rdeltour: Having solid unit tests is requirement for future tests

Daniel: one of the things that I found when I encountered this project is that i was able to understand everything I needed based on info in the issue
... I like that Maven does the build for you
... I found it difficult that some was done in schema and some in Java
... when it comes to code - there is a lot of dead code

https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

proposal for cleaning test suite https://docs.google.com/document/d/1v7-aSgdA-6dd-5zOTOqwAJGlh2Aa4hYFX1TcCdDesYo/edit?usp=sharing

Tobias: Cleaning test suite has to happen even if we do rewrite

bigbluehat: it is possible to do rewrites as a form of cleanup

duga: some of the tests i looked at needed to be rewritten because they were one test that should have been replaced by 20

rdeltour: the test was originally about data files - the epub files that are input to the test suite
... people didn't know what to do with the test without changing the Java driver as well
... I think we should keep doing the testing cleanup

Tobias: I have cleaning as I stumble upon bugs

Daniel: We could identify which tests are good and which are not good
... some tests are tests themselves. Some tests output info in JSON, and the JSON and XML, and it's not clear what's being tested

<bigbluehat> set some targets, and make them as easy to hit as possible

rdeltour: If you are willing to help, please review the clean up plan https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

bigbluehat: let's make this a game

<bigbluehat> 🍪 <-- that

<Fredrik> we'll check the plan

<rdeltour> the funding question has to be raised to the BG

rrrsagent, make minutes

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/Daneil/Daniel/
Present: mattg tzviya duga rdeltour Daniel_Persson Fredrik_Schill Garth Benjamin_Young
Found ScribeNick: Tzviya
Inferring Scribes: Tzviya

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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.)