15:04:20 <RRSAgent> RRSAgent has joined #pubtf
15:04:20 <RRSAgent> logging to https://www.w3.org/2018/11/19-pubtf-irc
15:04:21 <liisamk> present+
15:04:22 <laudrain> Present+
15:04:25 <ivan> present+
15:04:26 <tzviya> present+
15:06:25 <ivan> present+ dauwhe
15:07:02 <dauwhe> dauwhe has joined #pubtf
15:07:40 <dauwhe> scribenick: dauwhe
15:07:53 <dauwhe> liisamk: we've talked about all of this a lot without reaching agreement
15:08:10 <dauwhe> laudrain: we could imagine several plans
15:08:24 <dauwhe> ... and describe them, and these could serve as proposals
15:08:25 <tzviya> q+
15:08:29 <dauwhe> present+
15:08:38 <dauwhe> ... I could imagine 2-3 plans
15:08:48 <dauwhe> ... one at TPAC: 3.2 as rec in PWG
15:08:54 <dauwhe> ... and the PWG would be rechartered
15:09:30 <ivan> q+
15:09:38 <dauwhe> ... with the new work item. Let's call it Plan A.
15:09:44 <MAKOTO> MAKOTO has joined #pubtf
15:10:05 <dauwhe> ... the second plan would be the least change. EPUB 3.2 stays in CG.
15:10:16 <dauwhe> ... no rechartering for PWG
15:11:10 <dauwhe> ... in the middle there may be need to recharter for adding audiopub as module of WP and changing delivery date of EPUB4
15:11:53 <dauwhe> tzviya: I thought this group was going to try to make sense of the concerns of the larger groups
15:12:06 <ivan> ack tzviya
15:12:09 <dauwhe> ... maybe we can put to rest some of the concerns, and they might be based on misconceptions
15:12:32 <dauwhe> ... and we as a group might discuss what *we* want to do
15:12:33 <ivan> present+ makoto
15:12:48 <dauwhe> ... we've mostly heard that people want to move to REC track
15:13:15 <MAKOTO> Yes, indeed.
15:13:16 <dauwhe> ... we're worrying about change
15:13:31 <dauwhe> ivan: beyond what tzviya said
15:13:46 <dauwhe> ... there are some fundamental questions we have to ask ourselves
15:13:47 <laudrain> q+
15:14:01 <dauwhe> ... which are necessary for charter, but are important even if we don't recharter
15:14:15 <dauwhe> ... what does the publishing community want to achieve?
15:14:30 <dauwhe> ... what are the needs, and can they happen at w3c?
15:14:54 <dauwhe> ... we need an explainer for a charter proposal anyway
15:15:15 <ivan> ack ivan
15:15:47 <dauwhe> laudrain: we finished f2f with q from ivan: we'd need a clear answer from PBG before we do anything
15:16:39 <liisamk> ack laudrain
15:16:58 <dauwhe> tzviya: I felt the WG wanted 3.2, but the BG wasn't informed enough. We need to provide information to them.
15:17:18 <dauwhe> liisamk: let's go to the pros/cons doc and see if we can address concerns
15:17:39 <tzviya> https://docs.google.com/spreadsheets/d/17CyIqihtjjzT7Abbcq9sSqLNqLGKs2cuXdg4DcFulGY/edit?usp=sharing
15:17:56 <tzviya> dauwhe: who is our audience?
15:18:43 <dauwhe> liisamk: the audience is 1. the publishing business group 2. all of those parties, perhaps with the exception of the end reader
15:18:45 <tzviya> q+
15:19:11 <dauwhe> ... we build standards so people can more easily get things out there. it's governments, education, suppliers
15:19:30 <dauwhe> ... we know iso is important for some governments and educational institutions
15:19:30 <laudrain> q+
15:19:52 <dauwhe> ... if we do 3.2 but it's 3.0.1 that has ISO approval we bifurcate things
15:20:08 <tzviya> https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md
15:20:13 <liisamk> ack tzviya
15:20:21 <laudrain> q-
15:20:23 <dauwhe> tzviya: when we do write this explainer, it will be read by the AC and the TAG when rechartering
15:20:35 <dauwhe> early draft: https://github.com/dauwhe/wpub-explainer
15:20:48 <dauwhe> laudrain: we've brought lots of information to the BG
15:22:00 <dauwhe> liisamk: back to the document, do we see any of these things in the pros as inaccurate?
15:22:10 <MAKOTO> Which doc?
15:22:18 <tzviya> https://docs.google.com/spreadsheets/d/17CyIqihtjjzT7Abbcq9sSqLNqLGKs2cuXdg4DcFulGY/edit?usp=sharing
15:22:52 <dauwhe> ivan: there are a lot of comments on the google doc
15:23:26 <dauwhe> laudrain: what I hear is that there should be rec track on 3.2 with no change
15:23:49 <dauwhe> ... so that is not a pro
15:24:17 <dauwhe> ivan: this came out of the need for an editorial rewrite for ISO
15:24:25 <dauwhe> q+
15:24:29 <MAKOTO> Ivan, I cannot hear you well.
15:24:37 <MAKOTO> Is your microphone moving?
15:25:37 <liisamk> q+
15:25:42 <dauwhe> ack da
15:25:48 <MAKOTO> True
15:25:57 <dauwhe> dauwhe: I think we will make the spec better by doing rec track
15:26:17 <dauwhe> liisamk: we want to make sure we get through this without losing features
15:26:37 <MAKOTO> +q
15:26:42 <ivan> ack liisamk
15:27:09 <MAKOTO> Do you hear me?
15:27:11 <dauwhe> no
15:27:21 <MAKOTO> Sorry!
15:27:32 <MAKOTO> -q
15:27:58 <MAKOTO> It is very important for JP publishers not to invalidate what they have sold.
15:28:19 <dauwhe> liisamk: we understand that
15:28:36 <ivan> rrsagent, set log public
15:28:37 <MAKOTO> Particularly so in Japan, since we have tons of EPUB32
15:28:50 <ivan> rrsagent, draft minutes
15:28:50 <RRSAgent> I have made the request to generate https://www.w3.org/2018/11/19-pubtf-minutes.html ivan
15:28:58 <MAKOTO> What kind of adjustments?
15:29:11 <MAKOTO> Purely editorial rewrite only?
15:29:24 <tzviya> q+
15:29:34 <dauwhe> q+
15:29:35 <MAKOTO> Yes, if the normal procedure is used.
15:30:04 <ivan> ack tzviya
15:30:11 <MAKOTO> Then, will EPUB publications containing such non-normative features non-conforrmant?
15:30:47 <MAKOTO> Editorial improvements are fine.
15:30:54 <MAKOTO> No
15:31:01 <dauwhe> ack dauwhe
15:31:20 <MAKOTO> There is a definition!
15:31:37 <MAKOTO> I doubt that
15:32:01 <MAKOTO> Each spec defines conformance requirements.
15:32:18 <MAKOTO> EPUB 3.2 defines conformance requirements.  It is already there.
15:32:19 <dauwhe> ivan: we define what we mean by conformance
15:32:20 <wendyreid> wendyreid has joined #pubtf
15:33:07 <dauwhe> laudrain: the requirement for two implementations is not conformance?
15:33:07 <MAKOTO> https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#sec-xhtml-conf-content
15:33:16 <dauwhe> ivan: we are looking at edge cases
15:33:47 <dauwhe> ... the only time this comes up is if there is only a single implementation of a particular feature. That's the edge case.
15:34:00 <tzviya> q+
15:34:02 <MAKOTO> We cannot remove such a feature if some EPUB publication containing it is alreeady sold.
15:34:30 <dauwhe> tzviya: the link that makoto posted is to the conformance requirements, and it's very vague.
15:34:49 <dauwhe> ... saying it must support "visual rendering of the content documents" doesn't mean it has to support all of CSS
15:34:56 <liisamk> ack tzviya
15:34:56 <dauwhe> ... we're worrying about edge cases.
15:34:59 <ivan> q+
15:35:36 <dauwhe> ivan: the point of the w3c process is to prove that every feature **can be implemented**
15:35:40 <liisamk> ack ivan
15:35:50 <MAKOTO> I think that it is too late to improse W3C style requirements on EPUB 3
15:36:02 <dauwhe> ... based only on what is in the spec.
15:36:28 <dauwhe> ... if we don't have that, then we have a problem. If it depends on some secret sauce, we have a problem. I don't think we'll face this
15:36:53 <MAKOTO> Yes.
15:36:55 <dauwhe> liisamk: let's move on to resolve the point in line 10 about free of charge specs vs ISO
15:37:36 <MAKOTO> ISO does not really check technical equivalence.
15:37:44 <dauwhe> ivan: does ISO accept a CG report as an equivalent?
15:37:53 <MAKOTO> If SC34 people argue that it is equivalent, ISO will believe so.
15:38:02 <MAKOTO> And make it freely available.
15:38:24 <tzviya> q+
15:39:05 <ivan> ack tzviya
15:39:23 <dauwhe> tzviya: are we writing this for w3c or ISO? Maybe our goal should be writing a w3c doc
15:40:07 <dauwhe> liisamk: my understanding from TPAC was, if we wrote this as w3c REC, then it could be easier to get ISO approval, and we wouldn't have to make changes for ISO version
15:40:18 <MAKOTO> If W3C has a REC, it can easily be submitted via the PAS procedure.
15:40:31 <dauwhe> ivan: ISO just puts it's stamp on it, full stop. that's the PAS procedure.
15:40:37 <MAKOTO> Moreover, maintenance procedure is convenient for W3C
15:40:38 <dauwhe> ... it's an administrative step.
15:40:49 <dauwhe> liisamk: so we're not writing an ISO doc
15:40:55 <dauwhe> ivan: we don't have to
15:41:31 <MAKOTO> For example, ISO/IEC imposes a tough rule about registries.
15:41:49 <MAKOTO> If we use the normal procedure, we cannot use Schema.org.
15:42:05 <MAKOTO> If we use the fast-track procedure or PAS procedure, we can.
15:42:19 <MAKOTO> Indeed.
15:42:41 <MAKOTO> A11Y does.
15:42:44 <dauwhe> ivan: there's no problem with schema via W3C
15:42:57 <MAKOTO> Has to be moved to techniques.
15:43:15 <dauwhe> laudrain: we are aware of this move to techniques
15:44:52 <dauwhe> laudrain: the work in the CG didn't have real impact on WPUB until now
15:45:07 <dauwhe> ivan: I don't want to get into personal comments
15:45:41 <dauwhe> tzviya: I'm having trouble commenting in the spreadsheet
15:46:26 <dauwhe> tzviya: row 7: that's not a concern because we don't intend to drop features
15:46:32 <MAKOTO> Stil concerned.
15:46:43 <MAKOTO> I do not understand what you mean by "non-normative".
15:46:50 <dauwhe> tzviya: row 8: ocf might be in conflict with packaging
15:47:45 <dauwhe> ... if we have technical concerns about features it's better to resolve them within the working group, rather than across groups
15:47:57 <dauwhe> ivan: simpler than coordinating two groups
15:48:12 <dauwhe> tzviya: I don't think it's a concern
15:49:12 <MAKOTO> I don't think that JP publishers care ISO standardization.
15:49:28 <dauwhe> tzviya: the point about having chairs from Asia is valid but not a con for rec-track EPUB
15:50:45 <dauwhe> ... if we can people involved in the testing it can force adoption. I dont think it will slow adoption
15:51:10 <dauwhe> liisamk: there's confusion with people who are still on EPUB 2
15:51:44 <dauwhe> ... we know it's fine to go 3, safe to go to 3,0.1 or 3.2
15:52:14 <dauwhe> laudrain: the con is slowing adoption of EPUB 3?
15:52:29 <dauwhe> liisamk: maybe the con is that it requires a clarification of the timing of all of this
15:53:07 <ivan> q+
15:53:13 <dauwhe> laudrain: my concern is that 3.2 rec track will upset adoption
15:53:26 <dauwhe> tzviya: we could call what we have now as a beta version of 3.2
15:53:40 <dauwhe> ivan: why is this different than we plan to work on testing in CG
15:53:56 <dauwhe> ... if people realize we are testing, it sends the same message
15:54:11 <dauwhe> ... and most outsiders wont understand the difference betweeen CG and WG
15:54:22 <dauwhe> ivan: do you think we don't need to test the spec?
15:54:36 <dauwhe> ... any implemenation has effects on the spec
15:55:22 <liisamk> ack ivan
15:55:24 <dauwhe> laudrain: one of the first implementation is epubcheck
15:55:38 <dauwhe> ... so there are some editorial changes needed
15:55:42 <dauwhe> ivan: great!
15:57:26 <liisamk> dauwhe: testing will improve bugs and the spec
15:57:42 <liisamk> ...it is a part of it to say that the implementation is testable
15:58:00 <liisamk> ...testable assertions for reading systems and for publications
15:58:29 <liisamk> ...testing the community group will do will focus on the requirements of the reading systems
15:59:26 <MAKOTO> Yes, I can
15:59:48 <MAKOTO> I need more clear definition of what you mean by "making some features non-normative"
16:00:18 <ivan> rrsagent, draft minutes
16:00:18 <RRSAgent> I have made the request to generate https://www.w3.org/2018/11/19-pubtf-minutes.html ivan
16:00:25 <ivan> rrsagent, bye
16:00:25 <RRSAgent> I see no action items