<wolfgang> *I have no audio connection today (as I am not at my office) so that I may only act via IRC ;)

<wolfgang> *Wolfgang waves back @dauwhe :)

<wolfgang> *is it possible to ask sth via IRC only?

<wolfgang> *thx, tzviya :)

<wolfgang> *bots have a quite restricted vocab.

I can scribe

<leonardr> thanks Peter!

<leonardr> (if you need help, let me know...)

<tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-06-26-minutes

tzviya: approval of previous minutes
... => approved.

harriet: new to the group, representing University of Illinois.

<wolfgang> welcome, harriett!

harriet: digital publishing initiative

<hagreen> thank you!

tzviya: shane from Spec-Ops is here.
... we would like your input on testing etc.
... overview:
... WG was just chartered
... somewhat special since we carry on items from IDPF merger
... four deliverables:
... web publications and portable wp might end up be one specification with a layering
... epub4 is next epub version

<leonardr> <- as an Illini grad, go @dauwhe!

tzviya: dpub-aria is a continuation of the current spec
... all specs need testing, we need testable specs

<HeatherF> Yay for iterative testing!

tzviya: given the amount of specs, we have a lot of work to do.

shane: daunting tasks

tzviya: we're not necessarily talking about browser implementations

<George> The telephone access code is what?

<garth> USA: +1 (312) 757-3129

tzviya: e.g., Readium team largely here, will feed into testing via Readium. not expecting Firefox etc to implement anything.

<garth> Access code: 994-278-485

tzviya: we we need to make sure that we clarify epub notion of reading system and user agent.
... if reading system uses the same kernel as a browser but does something special, that might count as a different agent.

<tzviya> rk

leonard: each of our documents have different testing requirements.

ric: from readium foundation perspective, there are several different variants
... SDK uses different engines
... chrome app, end of life this year
... readium cloud reader => whatever browser
... all leveraging a browser engine underneath.

shane: web engine for presentation and user interface?

ric: yes, and scripting.

tzviya: to recap, somewhat different than usual W3C testing.
... note: FPWD targeted before TPAC.

<leonardr> MN in winter - +1 to that :)

shane: we have a lot of work on testing.
... focused on accelerating
... breaking the problems down a bit:
... dpub-aria space is well understood, reasonable testing strategy that seems to work
... underlying a11y platforms is also well understood.

<George> 994 278 485 does not work

shane: feel free to take advantage of the smart people around that.
... re epub, lots of platforms consume epub
... at w3c, we want to be inclusive of anyone that implement our specs
... how has epub testing been done historically?

<leonardr> (yup - no hurry)

tzviya: IDPF had different implementation requirements, more "how do you plan to implement"

<laurentlemeur> to tzviya, ok

<dauwhe> epubtest.org

garth: there is an epub test suite, maybe somewhat stale, tackling rendering and processing

<tzviya> epubtest.org tests reading systems - very manual

garth: epubcheck tool: checks epubs against specs, also a little stale but efforts to update underway

ouch.

thanks duga.

<tzviya> https://github.com/IDPF/epubcheck is test suite for epub files - overhaul in progress

leonard: from F2F, can you talk about W3C testing authoring vs consumption?

shane: authoring is not tested.

<cmaden2> Is that true? HTML and CSS validators?

shane: W3C publishes guidelines for a11y, i.e., WCAG

<laurentlemeur> to George, the US number is USA: +1 (312) 757-3129

shane: that's requirement on content but IIRC the only requirement.

<cmaden2> The XML specs are content specifications.

leonard: how does this apply to HTML and CSS validation?

shane: we only provide tools for authors to check their content.

<leonardr> Thanks @shaneM

tzviya: that's another difference from IDPF, historically provided validators, i.e., epubcheck.
... its success is not due to IDPF requiring it but people selling epub requiring it.
... to come back to testing specs.
... that's not something that's been done historically at IDPF / for epub
... it's a pretty manual process

<wolfgang> I think a validator is decisive for a publishing format

tzviya: nothing automated about it.

shane: is it correct to say: epub3 is (or will be in epub4) a superset of HTML and CSS.

garth: both sub and superset.
... this might be less true as we define epub4.
... likelihood that we will leave more alone than in the past.

<rkwright> Like SVG animation...

tzviya: for web publications, while we haven't figured details out, it's modeled on top of web app manifest.
... i.e., a superset.

<George> Tzviya sounds good

shane: there are already rich tools for testing html/css/js/dom implementations.

<ShaneM> https://github.com/w3c/web-platform-tests

shane: webplatform tests are a large collection of tools.
... these can be used to assess epub readers automatically
... if an epub reader is just something that supports the format and uses the webplatform
... then it's more about extending tests within this framework.
... this is the way forward in the W3C
... for format, it's mainly processing structure, not throwing errors
... whether manual or automatic might be open to discussion.
... manual is onerous but is ok and can be necessary
... some automated via format checks (manifests => associated files => feed them into existing processors)
... on epub side, we can use the tests you have.
... essentially, epub is a profile of the web platform.
... so you can define that profile and define tests that implementor has to pass in addition to web platform tests

rick: from F2F, do we need to test aspects of specs that are not part of the packaging structure, i.e., do we need to run html tests, do we need to create epubs that encapsulate all the web platform tests?
... or just those that are part of the packaging or specs we produce.

shane: I suspect it's up to the group.

see what I did there, shane?

scribe: depends on the architecture of the reader
... e.g., Readium built on platform browsers who already run these tests.
... would find approval in W3C to state that you use browsers that are known to run all tests

rick: went through test suite, some don't use readium at all, just testing underlying browser engine (e.g., fetching a file and rendering)

dauwhe: for testing browser features, the history of epub shows that we have challenges. every reading systems has mangled some CSS, so we do need to test.

leonard: also, security.

tzviya: shane, any recommendations to get started with these tests?
... not many people have experience with W3C test

shane: start with assertions, testable statements.
... people tend to start with a wiki to capture them
... then work out how that might be tested
... that usually reveals how this could be tested
... once you have some momentum there, then work on a general strategy
... at that point bring in somebody like shane
... e.g., fetching requests, there are tests, including lots of edge cases.

tzviya: any suggestions?

shane: e.g., benjamin.
... also browser vendor people are available to W3C.
... I will do some reflection and come back with suggestions.
... it's a social critical task.
... for us

tzviya: ok, we will follow up.
... agenda item: packaging format update

<garth> https://github.com/WICG/webpackage

garth: see link.

web packaging update

garth: briefly discussed at F2F
... the new web packaging effort seems to be alive
... brady and garth met with some of Googlers
... they are open to working with us
... to see how it can fit our needs as well
... it is being bifurcated, formatting and signing taking to IETF while browser and packaging will remain in W3C.

<HeatherF> :-)

<HeatherF> Which working group?

garth: IETF in Prague this month, the work will be presented there.
... after that we might get an update from them
... might have news late this month.

<leonardr> @heatherF - I'm wondering the same thing because AFAIK it's not be taken up by anyone...

billM: re coordination with web platform WG
... latest conception of spec in recharter of web platform WG has drifted quite a bit
... connection with web app manifest
... we might need further coordination on that that's broader than publishing
... not clear if co-chairs have signed off on moving to IETF

leonard: spoke to our IETF reps, IETF does not seem to have taken this up

HeatherF: what group is supposed to be discussing this?

leonard: that's the question. couldn't find a group.
... maybe we can ask Jeffrey what IETF group is taking this up.

garth: will do.

tzviya: topic manifest

Manifest

dauwhe: one of our issues has 72 comments.
... struggling to focus some of the conversation.

<tzviya> https://github.com/w3c/wpub/issues

dauwhe: some premature discussion on serialization.
... somewhat worried about re-inventing the wheel.
... e.g. navigation
... web publication and the web works, we should build on that
... instead of stuff that's only implemented in a very narrow world.

tzviya: agreed. some issues are getting into very technical details.
... but we need to focus on broad FPWD not specifics if json is best
... we need to get the broad scope of that down.

dauwhe: I think we are wrestling with some fundamental issues
... trying to write something down in the broadest way possible, forces us to work through these issues.
... they will be very impactful later on.
... e.g., idea of dauwhe going through issues, splitting off smaller bites
... that seems like a reasonable next step.

tzviya: and don't hesitate to close issues.

garth: issue with high-level stuff in manifest
... if we break them down, do we risk rat-holing on the technical issues
... as opposed to driving towards agreement on the 5/6 items that should end up in manifest.

dauwhe: makes sense. Maybe try to move that issue more towards on consensus on the big picture.
... on required vs nice to have bits.

tim: re spawning more issues. providing a venue for discussion details like serialization.
... if we break it off now, it can continue for as long as it needs to, say a year.
... you don't want your main issue to go on that long.
... but those one's can.

tzviya: note that we don't have to resolve issues before starting to write.
... dauwhe, maybe getting something down on pixels will be better to make progress.

dauwhe: agreed.

leonard: some of the long threads came to good points of agreements.
... e.g., what is (not) required for manifest.
... I think there's good work already.
... happy to help sorting out spin-off issues

tzviya: any other groups want to get started?

Accessibility TF

avneesh: send out call of participation

<garth> Doc of tasks from NYC: https://docs.google.com/document/d/1sXM51YzrfahFmkJBL-rt69Jvo0LGbOesleuEgwRWvP0/edit#heading=h.3y4ve9p5vwos

avneesh: about a dozen interests, mostly US.
... we can only formulate our plan once we talk to wcag.
... we've reached out, some delays due to vacations.
... but we need to prepare well.
... once we do that, we need to figure out the timeline and sort out what goes where (on which WG )

tzviya: rich from WCAG reached out on interest in co-chairing personalization TF

avneesh: we have to work out priorities. There are groups where we need to participate vs we need to drive.

tzviya: agreed but they are actively looking for a co-chair.

clapierre: tentatively interested.

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/specOps/Spec-Ops/
Succeeded: s/duga/garth/
Present: laudrain timcole Vlad mateus-teixeira dauwhe Rachel tzviya rkwright harriett_green Garth Avneesh Leonard Chris_Maden Peter Krautzberger ShaneM laurentlemeur duga Bill_Kasdorf Hadrien fchasen BillMcCoy mattg George clapierre
No ScribeNick specified.  Guessing ScribeNick: pkra
Inferring Scribes: pkra

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

Got date from IRC log name: 10 Jul 2017
Guessing minutes URL: http://www.w3.org/2017/07/10-pwg-minutes.html
People with action items: