Meeting minutes
<ivan_> Date: 2023-08-04
wendyreid: Welcome back! We have a big agenda
<wendyreid> https://
wendyreid: we have to maintain all our doucments
… they are spread out over multiple repos, and we have carried over issues from previous groups
… we can make errata, and some new changes on some types of docs
<wendyreid> https://
wendyreid: We need to agree on the classification of changes
… some of the issues have been assigned a class, but we need to make sure there is agreement on those
ivan_: Short summary
… class 1 and 2 are insignificant changes, no big difference between the two
… markup, css, metadata, spelling, etc
… jump to class 4, this is new features
… we cannot do this for class 4, but we can for audiobooks and pub manifest
… class 3 is more vague, signinficant changes in the document
… e.g. maybe we need new tests, and RS may need to think about whether the implementation will change
… If it doesn't really force that, then we can consider it class 2
… bad thing is we don't have a great algorithm for class 3 vs 2, it is up to the WG to determine
… issue 2560 is an example. There was a report of referencing webp, and we need the final ref to it
… so is that 2 or 3? Text changed, so definitely 2, but what about 3? Are there significant changes to webp that make people look at implementations
… Just one example of a borderline
wendyreid: Need to keep this short (lots of agenda items)
… so let's jump to those and see if we agree on the assigned classes
… Next item, pub schedule
… Matt and Ivan have been busy with prep work for class 1 and 2
… If we move to merge those, we should republish
… But going forward we should consider timing and cadence
ivan_: Need to understand that when we make a change it does not mean we change a WD and go through the original process of publishing
… instead we publish a new rec, not a big deal for small things
… but bigger things need a little more work
… but what we publish is immediately a new rec
… too frequently might be burdensome
<AvneeshSingh_> +1 to 6 months interval
ivan_: we should not publish more than quarterly, and maybe even every 6 months
… Publishing now may not be a good idea, since we will discuss things at TPAC
… for instance issue 2412 (webtoons) may need more discussion at TPAC
<tzviya> +1 to wait to publish until we have more issues
ivan_: so probably better to pile up, and publish in Oct or Nov
wendyreid: Our community is change averse
… so let's do fewer
… 6 months is predictable
CharlesL: I agree generally
… but editorial changes maybe go out sooner?
… just to make the doc as accurate as possible
… For instance, a bad link that is causing confusion may want to be updated quickly
wendyreid: By end of year seems to hit those points
wendyreid: any oppo to 6 month cadence? <crickets>
<wendyreid> w3c/
wendyreid: On to TPAC agenda planning
… We have 2 sessions over 2 days, ~7 hours
… would like input on topics
… speak up now or add it to the issue
ivan_: Will we have enough info to make the ISO decision?
<Zakim> tzviya, you wanted to ask about BG.CG
wendyreid: Still waiting on the European commision
tzviya: We need to ask Cristina directly
… We need more coordination between business, cg, and this group
… we need more cross coords
shiestyle: Gregorio suggested a11y
<CharlesL> Charles is attending TPAC in person
wendyreid: Yes, I will handle that
<George> George virtually
<toshiakikoike> koike virtually
wendyreid: [summarizing who is attending TPAC physically/virtually]
tzviya: Anything on audiobooks or pub manifest?
… invite Laurent to discuss his work on TDM
… what about Hadrien?
wendyreid: We will do some reach out
<wendyreid> https://
wendyreid: Let's go through issues
… mostly epub issues due to carryover
… Matt or Ivan, do you want to go over things?
ivan_: I leave it to Matt
mgarrish: I have put in pull requests for everything in epub that could be fixed
… just webp left, due to timing issues
… do we want to go over them one at a time? Or something else?
wendyreid: Let's do one at a time
<wendyreid> w3c/
wendyreid: 2578 looks easy
ivan_: For each one we have to officially decide if it is an errate
<CharlesL> +1
wendyreid: This looks like errata, forgot to remove a note when we published
<tzviya> +1
ivan_: This is on record, that is fine
wendyreid: Oppo to calling it errata? <no>
… reolved it is errata
<wendyreid> w3c/
wendyreid: 2567 looks like an obvious error, class 1, make it errata
<tzviya> errata
<wendyreid> duga: Raising this on GH and in issues, it's been reviewed by the group.
duga: Github is bringing it to the group
<wendyreid> w3c/
tzviya: Is there anything on the list we need to discuss?
wendyreid: 2556 is class 3 (maybe), there is currently a restricton on epub:type in svg content docs for anchors
… this should be better defined
mgarrish: We have 3 classes in svg where it is allowed
… but it turns out there is another element that also needs it
ivan_: But it is an obvious example of class 3, e.g. epubcheck at least will need to change
… is it ok to be errata?
mgarrish: Should we leave these open or close them?
ivan_: depends
wendyreid: Editorially it is hard to keep things open due to merge conflicts
… if we are accepting the PRs we don't need to leave things open
… The editors draft will just be more up to date
ivan_: Are the PRs changes directly, or updates to the text?
<wendyreid> w3c/
mgarrish: class 1 and 2 are direct, class 3 has full edits (ins/del/etc)
ivan_: Ok, lets merge
wendyreid: 2569 summary
mgarrish: 2569 and 2570 are similar
… Just need a note to say use "none" for a11y
<wendyreid> w3c/
mgarrish: and the other change is to note exemptions
… mainly for data tracking to identify which allows for tracking a11y exemptions and understand why
… so this is class 2 clarification and suggestions
… The exemption value can live in a note, don't need to add it to the spec itself
… We can decide if we do a 1.1 or 1.2. WG note is fine now
wendyreid: Comments or oppo?
ivan_: That means we need to define a new WG note
<AvneeshSingh> +1 from me
mgarrish: Yes
CharlesL: Do we need to point to the note from 1.1?
mgarrish: Yes, the informative section needs to ref the note, so we need to get the note out first
AvneeshSingh: Just want to say this was incubated in the CG and brought to the WG
… want to encourage more of that
George: Anything that would trigger an epubcheck change would be class 3, right?
ivan_: Yes
<AvneeshSingh> anything that will trigeer error in EPUBCheck or remove an error from EPUBCheck
tzviya: It has to be, anything that triggers a change in epubcheck changes our must/may statements, so that is a real functionality change
CharlesL: With some other things like webp that is being updated which is just changing the ref, couldn't this cause a functional change?
mgarrish: We need to wait for the RFC change first
… How much changes in the RFC will impact how substantive our change is (2 or 3)
dauwhe: But unlikely they will break the web with updates to webp
ivan_: In the current spec we ref a Google dev page, the only thing we had at the time
… It is an odd normative reference
… this means we move to an ietf ref
… slightly more than have a good ref to a format
… it is also removing a company doc reference out of a standard
wendyreid: Actual doc changes are still minimal
ivan_: But it has symbolic meaning
… so we might want to make it class 3 to call attention to it as an important change
… probably implementations don't change, but would support class 3 to call attention to it
wendyreid: Don't mind be prudent to call attention when it could be signficant
CharlesL: It will be in the change logs
… so could call out the importance in the change logs
ivan_: You are right, but there is a little more to it
… publishing a rec with class 3 changes is a several change process, there is an AC review
… editorially it is a pain, esp for Matt
… it needs to be presented with the changes marked clearly to the AC
mgarrish: Draws people attention
… not sure how to even do it
<wendyreid> duga: One thing to consider, if we're going to point this out, it will call people's attention to it, and people might spend half a day reading WebP RFCs they don't need to.
<tzviya> +1 to duga
<dauwhe> +1000 to Brady
<wendyreid> ... I understand it's an important change to the spec, but not necessarily to implementers.
<wendyreid> ... I would suggest caution
ivan_: I personally have no idea if there is a difference to the ietf version vs google one
<wendyreid> duga: Agreed, but we can be cautious, someone here could spend that day and we could highlight that. Or we might look and say it's identical, it's not a big deal
<wendyreid> ... not highlight it as much
<wendyreid> ... we don't need to tell every implementer to read it
<wendyreid> ivan_: Action item for Brady?
<wendyreid> duga: I am happy to ask someone from google to review it
CharlesL: If epubcheck reports an error, will it ref the RFC??
mgarrish: No, it won't point people at specs
wendyreid: Let's leave it where it is now
… and we can leave it to Brady to tell us if anything significant has changed?
ivan_: editors job is different for class 2 and class 3