Meeting minutes
<dauwhe> Date: 2020-04-14
Date: 14/15 April 2020
<MURATA> I'm afraid that I cannot access the link in the draft agenda.
<MURATA> Since I am not a W3C member, I do not have access rights.
EPUB WG Charter Review
<dauwhe> https://github.com/w3c/epub-3-wg-charter/
<dauwhe> ^ Repo
<dauwhe> Viewable version https://w3c.github.io/epub-3-wg-charter/
<dauwhe> Issues: https://github.com/w3c/epub-3-wg-charter/issues
Wendy: current status is
that it is in the public phase and we are expecting any comments
… please feel free to file github issues in Japanese
or english, however you are comfortable
… we have had several issues and are addressing
… once the process is done it will go to the W3C
membership for approval
… likely a 6-week period for review due to corona
… highlights of the charter
… backwards compatibility is a core and main
deliverable
<MURATA> So, we are not going to repeat the mistake of 3.1.
Wendy: EPUB 3.2 it is based
on, but we are calling it 3.x
… will ensure that previous EPUB3 files are compatible
… internationalization and accessibility are key, as
is getting it as far into the W3C ecosystem for what it is
Murata: there have been 11
issues in the github
… I'm concerned that some part of the process will
break backwards compatibility
… this is not the right time to discuss in detail, but
there might be conflicts
Dave: backwards
compatibility is organizing principle, but we are bound by W3C process
… some of these things we can't say ahead of time
exactly how many implementations are of every feature
… think it is perhaps early to think that there are
features that are widely used and not implemented
… we plan to be careful and don't foresee causing
problems for existing content
Wendy: significant advantage
relative to rec track is that EPUB has at least 100 implementations
… there are tools, reading systems and many
implementations
… there are unlikely places there is only one
implementation of a feature and if we find that, it will
… give us a good place for discussion about why that
is the case and how to go forward
… features will likely make things stronger
Murata: cannot name one
feature
… think if that happens we should consider not
invalidating and bend
… cannot drop the feature
Daihei: clarify from earlier
message prepping for github
… backward compatibility is a given premise and in the
blog post from the SC f2f
… that says "unless it uses a feature never
implemented anywhere"
… hope to add a few features requested by survey
respondents
… if this will cause any kind of issues and any
problems with the business ecosystem
… this could harm the industry globally
… should not cause any issues with backward
compatibility and current EPUB3 business ecosystem
ShinyaTakami: two things
important: backwards compatibility and existing EPUB should be
considered
… another point discussion raised in the charter of
the difference between 3.2 and 3.x
… content format is HTML5 or XHTML5
… we should separate discussion in this topic
<MURATA> +1
ShinyaTakami: converting
from one to another is a big issue
… we should separate the discussion of changing of
features
<MURATA> Even allowing non-XML HTML is a big issue.
liisamk: I think there's a
value to coming back to Wendy's point about implementations
… there's a variety of implementations in our current
business ecosystem
… it is unusual for the way that W3C process usually
works
… we're talking about all of the reading systems and
tools and browsers
Wendy: worth having
discussion about the draft charter, but until we start the work
… we don't know the answers to all of the questions
… html5 serialization is a topic, but we haven't made
promises of what the new EPUB will look like yet
… charter is a guiding doc
… survey results and feedback some of it could be EPUB
3.x
… some of it may be a foundation for some future
… many of the changes will be just a better
implementation
<Zakim> dauwhe, you wanted to talk about HTML5
Dauwhe: new features and
compatibility, the biggest change we will talk about is allowing
… the serialization of html5
… but that expands and does not impact any existing
epubs or need to convert
… gives us chance of making epub a little more
flexibile
ShinyaTakami: this is coming
from a CG and as a member of BG can't participate in the new WG
… concerned that changes may happen, but cannot attend
and want to address
Daihei: would like a
proposal for how the progress of the WG can be shared with people
… who cannot participate in the WG
… having used and adding feature, we are not saying
that we don't want to make epub better
… anything that would cause issue with files would be
a problem
<MURATA> +1
Daihei: epub 3.x will need to be faithful to this bottom line of not causing existing business any issues
<jyoshii_> +1
Dauwhe: moving from CG to
WG, have had some concerns too
… we are committed to operating publicly and github
will be open to comments from anyone
… much of the real work takes place there
… the chairs will give progress reports to the BG
… we can go a long way with good communication and
working publicly
Wendy: the PWG has been open
about their work and we will continue
… trying to address html5 serialization is technical,
and we don't want to get into the weeds
… old epubs with xhtml will be just as valid, the only
issue may be new css like flexbox (as an example)
… adding new ways to create epub, not taking away old
ways to do it
jkamata: this rec track
process and epub 3.x should be welcome
… there could be issues to be resolved such as
epubcheck and other tools and browser vendors
… conforming to the changes might take time and there
are concerns
… if the business and environment can catch up to the
epub 3.x
… her company Voyager is concerned about how the
epubcheck tool will also be updated for the new spec
wendyreid: we chose not to
mention epubcheck it is not under the spec jurisdiction
… the same model we are using now for funding would
continue and build a new version
dauwhe: epubcheck is a
critical part of the ecosystem and the spec is what epubcheck says it
is
… we would not release a new version unless fully
supported by epubcheck from day 1
<MURATA> +1
+1
liisamk: I was going to say
something similar to Dave
… it came out of the BG and SC work, we engaged DAISY
to do the work
… we fundraised for it
… we won't be dropping that, the community will find a
way to make sure EPUBCheck stays in sync
translate for ??: anxious to know how to
see rec track process will affect spec
… there must be different point of view from different
domains of business
… DAISY of course want to be faithful to reading
systems and accessibility and some people want
… to make sure that media overlay is going along well
enough
… browser development could be a key issue
… different point of view could affect
… reading system based on 3.0.1 and move to 3.x and
will it will match or not have to look into
<MURATA> +1 For example, some Japanese textbook publisher heavily uses SSML. Different communities have different requirements.
<Ralph__> [Ralph arrives]
<dauwhe> Changes from 3.0.1 to 3.2 https://www.w3.org/publishing/epub32/epub-changes.html
blog post from Publishing@W3C- comments?
epubcheck fundraising
Daihei: we are still in need
of approximately $15k
… need to make clear that to complete epubcheck we
still need to fundraise
… need help to raise $$
… please help!
PBG going forward
Daihei: there was a long
discussion at the SC about how we can revitalize the Asia
participation
… want to make sure that everyone is heard and has
opportunities to participate
jyoshii: will try reaching out to publishers and participants who are entitled to join in and invite
Next PBG Meeting have guest speaker
Daihei: have guest to explain what EDRLab has been doing for new reading systems
<MURATA> I have to leave. Thanks. Bye.
liisamk: Laurent Lemeur will join us and will present shortly on the advancement of the reference system
W3C Slack
Daihei: please join in the
slack that was referenced in the agenda
… any comments?
… goodnight!