EPUB 3 Working Group Telco -- 06 Nov 2020

scribe+

wendyreid: let's get started

F2F review

wendyreid: I thought the meetings were productive, and we covered all of our topics
... and we came to conclusions on our XML issue
... we had volunteers for testing
... and we'll have a meeting next week about FXLA11Y
... we've got a lot of work to do
... mgarrish has been REALLY busy revising the documents
... there are lots of PRs
... lots of cleaning up of errors

mgarrish: we've done some more shuffling, now that we don't have five separate docs
... we can find a more natural place for stuff
... we merged a big one on the vocabs
... there's stuff that was used in packages, content docs, and MO
... so Ivan suggested a general overview
... so now we reference an appendix
... and epub:type is an appendix
... it simplifies the cross-linking in the docs
... and there was the FXL section which got sliced up in 3.0.1
... the structural semantics vocab was an outlier
... now we don't have plans for extensive revisions for SSV, so it makes sense to put it in the core
... and there have been lots of editorial cleanup

ivan: two more things
... nav doc is now a top-level section; it used to be hidden in content docs; it's more readable
... and we had three or four different conformance sections, and now they have been unified

<George> kq+

George: the a11y spec is inside or outside of the core

mgarrish: outside

wendyreid: there are still some satellite specs

Avneesh: I was not aware of an FXL call ; I thought it was for EPUB a11y revision

wendyreid: oops
... any other questions about the reorg/editorial revisions?
... most of them are merged so you can see them in the draft
... you can also look at the previews and diffs in open or closed PRs

ivan: mgarrish did an amazing job on this

<CharlesL> +1 Matt, way to go!

<Garth> +1

ivan: it's much more readable

mgarrish: it's fun to clean up the wreckage of history :)

wendyreid: some of these PRs were purely editorial
... some of these PRs have addressed open issues

DTDs

UNKNOWN_SPEAKER: we had resolutions at the F2F, and further discussions on github
... and came to a happy place

<mgarrish> https://github.com/w3c/epub-specs/pull/1368

mgarrish: where we ended up was...
... we put in an allowance for a specific set of external identifiers that we have put in an appendix
... we have SVG and MathML that are allowed to be used in content docs or in separate files
... and we made a restriction against external entities in the internal DTD subset
... so it prevents some security issues but eases authoring
... so we'll no longer force people to remove SVG DTDs from tool-generated files
... I'm hoping this is it :)

ivan: tech comment
... in fact, the changes are such that
... makes possible something that I'm not sure we real;ly use
... I can define as part of an internal entity something that won't go out to the network
... I'm not sure if this feature is in use
... formal comment
... there was a formal resolution on the previous version; this PR slightly changes that
... can we get a formal resolution to merge, and also close a bunch of issues which were examples of the problem?

<wendyreid> Proposed: Merge PR #1368 to address outstanding DTD issues, and close GH issues 1369-1373

<Garth> +1

<mgarrish> +1

<ivan> +1

<CharlesL> +1

<MattChan> +1

<wendyreid> +1

<duga> +1

<George> +1

<LauraB__> +1

<Bill_Kasdorf> +1

<BenSchroeter> +1

RESOLUTION: Merge PR #1368 to address outstanding DTD issues, and close GH issues 1369-1373

<wendyreid> https://www.w3.org/Consortium/Patent-Policy-20200915/

New Patent Policy

wendyreid: our WG was chartered right before the new patent policy
... W3M has asked if WGs are interested in upgrading to the new patent policy
... I can't describe the new policy
... should we move to the new policy?

ivan: &ianal;
... the essence of the policy may not be absolutely clear
... the main goal of the patent policy is that, if you implement a spec, then you should not have to worry about other WG participants having a patent and coming after you to pay a royalty.
... the patent policy aims to prevent this
... if an organization joins a WG, by default it signs a statement
... even if I have a relevant patent somewhere, I will not go after anyone implementing the spec
... the 2017 patent policy comes into effect when you publish a REC
... but in many WGs, specs are implemented before reaching REC
... and during CR phase there's no patent protection
... so that's the legal loophole in the 2017 policy
... so the 2020 policy, CR starts the process for patent claims, rather than REC
... so the question is, is this work IPR-heavy?
... is there a danger of infringement? If so, we should move to 2020 policy
... but if we think the risk is low, then we can forget about it
... if we move to 2020 policy, people would have to rejoin the WG
... we can't decide today, because people might need to talk to their lawyers

Avneesh: I want to check about using evergreen feature of process 2020
... the IP used to trigger at REC, now it starts at FPWD, so specs can remain evergreen at CR
... might some sections not getting implementations, and keeping them in CR?

<wendyreid> acl ivan

ivan: we have to separate process from 2020 from IPR 2020
... process 2020 we are already in
... the only thing it gives us is the possiblity it describes of infinite CR cycles
... I would prefer a traditional REC
... but once we have a REC, we can add/change much more easily than under older process docs
... but we can do that with either patent policy

Avneesh: they are independent

wendyreid: I'll send an email to the list, with a link to the patent policy
... and we can decide next week

<ivan> There is a [PP 2020 Explainer](https://www.w3.org/wiki/Process2020)

<ivan> There is a [slide deck of the DID WG](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47)

ivan: we had a discussion in the DiD WG
... and made slides about the differences

<wendyreid> dauwhe: I just want to mention that this WG is involved with a spec whose outlines were defined 20 years ago

<wendyreid> ... our exposure to new IPR is minimal at best

<wendyreid> ... it's not come up before

<wendyreid> ... does any possible change in IPR affect [the situation]

George: I like the new policy better than the old policy, as things are settled well before rec

wendyreid: I'll send an email with links and let people discuss with their organizations
... I think it's a net positive
... AOB?

George: were there media types on the agenda?

ivan: there's still WebP

wendyreid: I thought we were waiting for an answer from someone

ivan: perhaps in a non-normative fashion
... it's not registered anywhere

<wendyreid> https://github.com/w3c/epub-specs/pull/1347

<wendyreid> dauwhe: When we were talking about WebP, it's an internal doc at Google

<wendyreid> ... the person who wrote the spec didn't want to register the media type

<wendyreid> ... various W3C people have offered to help register the type

<wendyreid> ... some concern that google could change the spec

wendyreid: Chris Lilley had offered to help with media type registration

ivan: what we could do is... we can do two things
... one, keep the PR open and comes back in a year
... two, we put it in with a big yellow warning saying this is a feature that may be taken out
... because status is unclear
... I don't know which of the two is better

<wendyreid> dauwhe: I would be curious to see if WebP works in existing reading systems

<wendyreid> Hadrien: It works in readium

<wendyreid> ivan: Readium relies on Chromium or whatever is aroudn

ivan: does it rely on google engine

Hadrien: it works everywhere if iOS 14+

<wendyreid> Hadrien: Whatever is around, if you're on iOS 14 it works there, on android it has worked for a few years

Hadrien: has worked on Android for a while

ivan: what about thorium?

<wendyreid> ... Thorium uses chromium, so it works, even on a mac

Hadrien: yes

ivan: even on a mac?

Hadrien: yes
... I would expect it would work in a lot of places, because it's supported by many webviews
... probably won't work on RMSDK

Garth: I agree with Dave and Hadrien
... I think we should put it in with a warning
... that might drive more learning

mgarrish: a third option is reconsider mandating support in the spec
... there are custom implementations, we need a baseline... I don't know if that
... 's somehting the spec needs to say
... and not getting into the whole restricting things that are outside of our control
... that's a separate discussion

ivan: not separate

wendyreid: I support putting in WebP with a warning

ivan: to follow up on what matt said
... we are already in an awkward situation
... there are some media types where we are explicit
... we don't have a list of video types

<wendyreid> dauwhe: Difference between video and images, 99% of EPUBs have images, but very few EPUBS have video

<ivan> ack q+

<wendyreid> ack q+

George: I would love to see us start testing video in the titles

<Garth> ack "q+"

<gpellegrino> great bug q+ in queue! :)

George: people are waiting for that quality of content being added to educational materials
... putting it in the spec would protect from Google IP

Hadrien: ivan hinted at the larger question
... can we tackle that larger question?
... I don't think it's sustainable
... it belongs in a best practices doc
... we are not consistent with how we deal with HTML/CSS vs images

gpellegrino: for the image format I'm concerned about e-readers
... there are a lot of old e-readers which would never support webp
... and new content wouldn't work

Garth: I would like to get to Hadrien's discussion
... we can have a vote now about WebP
... then return to the larger issue
... should we move image specificity to video specificity

ivan: garth almost said what I wanted to say
... let's decide on webp today
... and open an issue on github

<wendyreid> Proposed: Merge #1347 with an additional warning about support for WebP

<ivan> +1

<Garth> +1

<mgarrish> +1

<George> +

<Hadrien> +1

<Bill_Kasdorf> +1

<CharlesL> +1

<Juliette> +1

<gpellegrino> 0

<duga> 0

<wendyreid> +1

<MattChan> 0

George: I think it's great if we put this in

<toshiakikoike> 0

<laurent_> +1

George: if it moves to a best practice that's fine

<BenSchroeter> 0

<MasakazuKitahara> 0

George: but we get the format into implentations and documented

wendyreid: that's another discussion

RESOLUTION: Merge #1347 with an additional warning about support for WebP

wendyreid: happy weekend all!

- DRAFT -

EPUB 3 Working Group Telco

06 Nov 2020

Attendees

Contents

F2F review

DTDs

New Patent Policy

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output