13:41:28 RRSAgent has joined #epub 13:41:28 logging to https://www.w3.org/2021/05/28-epub-irc 13:41:31 RRSAgent, make logs Public 13:41:31 please title this meeting ("meeting: ..."), dauwhe 13:41:45 Meeting: EPUB 3 Working Group Virtual F2F, Day Two 13:41:51 chair: dauwhe 13:41:57 chair: wendyreid 13:44:55 ivan has joined #epub 13:46:07 zakim, start meeting 13:46:07 RRSAgent, make logs Public 13:46:08 please title this meeting ("meeting: ..."), ivan 13:46:25 ivan has changed the topic to: Meeting Agenda 2021-05-28: https://lists.w3.org/Archives/Public/public-epub-wg/2021May/0048.html 13:46:26 Chair: dauwhe, wendy 13:46:26 Date: 2021-05-28 13:46:26 Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021May/0048.html 13:46:26 Meeting: EPUB 3 Working Group vF2F, 2nd Day 13:53:40 dkaplan3 has joined #epub 13:54:59 Better twice than none :-) 13:56:26 gpellegrino has joined #epub 13:57:29 Ken_Jones has joined #epub 13:58:05 duga has joined #epub 13:58:11 present+ 13:58:19 present+ 13:58:26 present+ avneesh 13:58:37 avneeshsingh has joined #epub 13:58:42 BenSchroeter has joined #epub 13:58:43 present+ 13:58:44 toshiakikoike has joined #epub 13:59:04 present+ 13:59:18 present+ 13:59:22 present+ 13:59:22 present+ dkaplan3 13:59:22 present+ gpellegrino 13:59:26 MasakazuKitahara has joined #epub 13:59:28 present+ BenSchroeter 13:59:32 present+ 13:59:35 present+ tzviya 13:59:44 present+ 13:59:49 present+ Ken_Jones 14:00:07 present+ toshiakikoike 14:00:17 present+ MasakazuKitahara 14:00:25 present+ dauwhe 14:02:10 CharlesL has joined #epub 14:02:14 present+ CharlesL 14:02:22 present+ george 14:03:05 mgarrish has joined #epub 14:04:02 George has joined #epub 14:04:16 present+ matthew 14:04:29 present+ dlazin 14:04:34 present+ 14:04:54 present+ mattg 14:05:06 present+ 14:05:21 scribe+ mgarrish 14:05:23 https://github.com/w3c/epub-specs/issues/636 14:05:35 topic: @issue 636 14:06:34 dauwhe: time to talk about serialization of html5 - I used to be more of an advocate for this but reality is that this is going to require a fair amount of work for reading systems that depend on xml tools 14:06:59 q+ 14:07:02 ... I don't see strong demand for a change like this from the authoring side - authors are not asking for it 14:07:03 ack du 14:07:14 q+ 14:07:47 duga: last night we discussed this and my position is that yes we can do this but it'll be a bit of work - we're not hearing for demand for this from publisher so we'd rather spend the time on more important things 14:08:40 q+ 14:08:46 q+ 14:08:50 ack tz 14:08:50 ... thinking about self-publishers, while big publishers use xml, these publishers do more of their own work and using their own tools that generate html - not sure if it's true as they don't come to these meetings but should see if this is important to them 14:08:58 dlazin has joined #epub 14:09:56 tzviya: I agree with Dave. I think we need to defer this to another major version of epub. There are some things we've been thinking about doing in epubcheck that would make it easier to maintain. Some of that will be deferred until will have HTML epub. 14:10:01 Karen has joined #epub 14:10:17 q+ 14:10:20 ack wen 14:10:23 ... we talk a lot of things like identifiers and we don't have that in epub but would be nice to have 14:11:06 q+ 14:11:25 wendyreid: self-publishing is a constituency we need to think about - we have a big community of them at kobo. I haven't heard these publishers expressing difficulty with xhtml because they have tools to create epubs or getting outsourcers to do the work for them 14:12:01 ... it is worth asking as the authors are innovative and see if they're missing out on anything 14:12:07 ack Geo 14:13:22 George: the word-to-epub add-in does an excellent job of making epubs. google docs produces them but would be nice to have a facelift. scholarly publishing content that is distributed in pdf is awful for disability. wonder if the process of converting from pdf is easier or harder with xhtml 14:13:27 ack gp 14:13:54 gpellegrino: what are the benefits of switching from xhtml to html - is it only non-closing tags? 14:14:29 q+ 14:14:36 dauwhe: some arguments are that it makes it easier to repurpose html content - most scripting libraries aren't tested with xhtml so may work better with html 14:15:02 q+ 14:15:06 ... it's more annoying to have to change html pages to xhtml to make them valid for epub 14:15:08 ack dl 14:15:43 q+ 14:16:13 dlazin: this seems like the kind of thing we should defer to later - xhtml is losing popularity - we may be fine with it for a while but in the future we may need to change - put on a note on the issue to upvote and explain why they need it so there is more info 14:17:16 ... I came to epub as a self-publisher and I would say that it was not at all difficult to do xhtml - indesign just does it for you but I cleaned up some things by hand - self-publishers may not be fully tech savvy but are willing to do things that we don 14:17:25 't expect 14:17:26 ack iv 14:17:59 q+ 14:18:51 ivan: I made a script to translate W3C TR documents into EPUB. It was very easy to find HTML parsers but when I need XHTML I get syntactically incorrect markup. I had to spend a lot of time to find a library to convert the HTML to XHTML. The evolution of tools long term works against XHTML long term 14:19:58 ack du 14:20:02 ... the doctype, the xml declaration, etc. - the small things from our point of view to make it proper xhtml are complex. Today we may not want to do this but we need to keep the issue open so the community is aware we have to make this change eventually 14:20:37 q+ 14:21:10 duga: most reading systems display their content as html, not xhtml. moving to html removes an unnecessary intermediary step for us. I'm in favour of punting but we do this every single time 14:21:13 +1 to duga - we can't keep kicking the can 14:21:23 ack avn 14:22:14 avneeshsingh: from a management perspective with only 6 months remaining we need support in reading systems and epubcheck. we should have compelling reason to move on this now given this timeline. 14:23:06 ... it looks safer not to do HTML at this time. we don't need to drop or delay it but we can move it to the community group to incubate it and get momentum. will give us a longer timeline to research before the next revision 14:23:21 q+ 14:23:26 ack Ken 14:23:27 +1 to Avneesh suggestion to punt to CG. 14:24:04 Ken_Jones: the self-publishers I'm aware of are not writing any code - they use tools so they are not pushing for this. they will wait for their tools to update and use whatever is available 14:24:06 ack dl 14:24:49 q+ 14:25:29 dlazin: agree with Brady that most reading systems are using html internally - we could relax validation standards so the document is supposed to be xhtml but we allow syntactic invalidities - authors just want to dump html into the body, they don't care about the head 14:26:04 ... most reading systems will take whatever you throw at them so not complicated to display what is in the body 14:26:12 ack iv 14:27:35 ivan: I would be scared to describe formally this kind of looseness. The reading systems spec could allow them to use html5 but formally the content spec says you must use xhtml5 14:27:39 ack du 14:28:30 duga: I don't think this would solve the problem - reading systems still process the xhtml as xml prior to display so having html in the body would cause us to reject 14:28:42 q+ 14:29:26 dlazin: what I'm thinking is to use an attribute on the body tag so you could fork the pipeline or skip the step that requires xml conformance 14:29:46 ack dau 14:30:47 dauwhe: I've gotten the sense from all the discussions that we have kicked this can for a long time and is not ideal but I think we've had good reasons for doing that. I don't see eagerness to change without a more compelling reason that we supplied so far 14:32:01 ... as Dan said, xhtml becomes less viable with time. I think at some point we have to do a bunch of changes at once - EPUB 4 - we're constrained on both sides by EPUB 3 and the inability to change requirements 14:32:15 ... we're improving the spec but we're not changing how epub works 14:32:55 ... we could also remove all the deprecated and unwanted parts that exist today 14:33:04 q+ 14:33:09 ack tz 14:33:24 tzviya: we tried that in 3.1 and it didn't go well 14:33:52 ... we'd have to solve the namespace issue, etc. - something we'd all like to do but now is not the time 14:34:22 ... maybe this is a community group topic - not html serialization but issue like how to get rid of epub:type, etc. 14:34:50 q+ 14:35:11 q+ 14:35:24 dauwhe: we have the goal of making EPUB 3.3 a W3C REC but do we want to persist this incremental backwards compatible mode for 3.4, 3.5, etc. - we need to make a break at some point and not just have working groups to make editorial changes 14:35:28 ack av 14:36:04 avneeshsingh: looking at W3C culture, a lot of work begins in the CG before getting a WG to formalize 14:36:10 ack wen 14:36:55 wendyreid: I want to have some of these ideas incubated as we're running into the limits of EPUB 3 compatibility. we need to go big at some point. 14:37:26 ... I think we need a clear goal for the CG not just incubate ideas 14:38:40 q+ 14:38:48 ack ge 14:38:56 dauwhe: are we prepared to defer 636 and hand it off to the CG to look at the long-term future of epub? 14:39:03 q+ 14:39:07 George: is there a reason to keep the ncx? 14:39:14 q+ 14:39:29 ... I know why it got in there so that US publishers could provide it 14:39:32 q- 14:39:57 ivan: we can't do anything about people including it - not part of epub 3 14:40:00 ack gp 14:40:08 q+ 14:40:27 gpellegrino: reading systems use it for compliance to allow old readers to open epub 3 14:40:31 ack du 14:40:50 q+ 14:40:54 duga: forbidding it doesn't help me as I have legacy epubs with it 14:41:18 ... means more bookkeeping in the ingestion pipeline 14:41:27 ack iv 14:41:27 dauwhe: would be different in an epub 4 14:41:59 ivan: you said defer this - what do you mean? are we closing in github for now or are we keeping it open for next version? 14:42:29 dauwhe: github issue are easy to find with labels. I would push-to-CG-closed label on it 14:42:51 Proposed: Close issue 636, move discussion to the community group 14:42:53 +1 14:42:54 +1 14:42:55 +1 14:42:55 +1 14:42:56 +1 14:42:57 +1 14:42:57 +1 14:42:57 +1 14:42:57 +1 14:42:57 +1 14:42:58 +$B#1(B 14:42:59 +1 14:43:00 +1 14:43:03 14:43:07 +1 14:43:39 ivan: maybe it's worth saying that in the earlier discussion last night there was additional agreement - worth noting it's across both meetings 14:43:47 RESOLVED: Close issue 636, move discussion to the community group 14:46:13 tzviya: romain had some comments about epubcheck 14:46:16 TOPIC: Satellite Specs and EPUBCheck 14:46:58 ... had some comments about the satellite specs - epubcheck supports edupub, indexes and dictionaries and partial support for scriptable components 14:47:04 q+ 14:47:46 s/scriptable components, multiple renditions, and previews 14:47:54 ack dl 14:47:59 dauwhe: concerns are about reading system support and author use - some of these specs do nothing more than extend markup patterns and epub:type 14:48:19 dlazin: do we consider epubcheck to be a reading systems for the purpose of candidate recommendation 14:48:35 dauwhe: no. it is purely a validator 14:48:43 s/scriptable components/scriptable components, multiple renditions, and previews 14:49:20 ... you can use the features but nothing supports them and user don't benefit from them 14:49:21 q+ 14:49:28 ack iv 14:49:48 ivan: can someone tell me how many documents we are talking about? 14:49:55 dauwhe: something like 10 or 12 14:50:15 q+ 14:50:37 ivan: if we republish all of them as w3c notes it is a non-trivial and boring amount of work - they all have to be transformed to respec 14:50:57 ... they will also have to be formally approved by the group and by the w3c director 14:51:22 ... it's doable but we need to make sure it's worth it 14:51:27 ack av 14:51:44 avneeshsingh: an alternative way might be to have a member submission? 14:51:48 q+ 14:51:50 ivan: the work is the same 14:51:51 ack du 14:52:24 duga: decision last night was to let ivan and matt decide what to do - whatever makes the most sense from a bookkeeping perspective 14:52:27 q+ 14:52:39 ack iv 14:52:43 dauwhe: and communicating to users that implementing this stuff is pointless 14:52:45 q+ 14:53:21 ivan: process-wise it might be easier to publish them as CG notes - still have to convert but less publishing work 14:53:37 ack dl 14:53:47 q+ 14:54:15 dlazin: one of the intents is to make sure users find the right document - with specs in both idpf and w3c it's hard to know which to review 14:54:18 ack ge 14:55:02 q+ 14:55:05 George: I agree with Dan that as long as these are in a place where they can be repurposed in the future and without confusing people about whether they are in 3.3 is a good thing 14:55:06 ack iv 14:55:32 ivan: if the issue is to find them easily then the working group note is the best solution as it will go in the TR library of documents 14:56:11 ivan: let me and the chairs talk to Ralph to see if there is a way to publish these without going the full formal route 14:56:25 dlazin: 14:56:25 q? 14:57:03 dlazin: as these are not important spec maybe we can farm these out to other people to work on - not important to have these done on the same timeline as 3.3 14:57:59 ivan: the idpf documents may or may not be updatable - need some way to point people to the new docs 14:58:47 rrsagent, draft minutes 14:58:47 I have made the request to generate https://www.w3.org/2021/05/28-epub-minutes.html ivan 14:59:54 15:11:07 gpellegrino has joined #epub 15:16:06 George_ has joined #epub 15:16:42 scribe+ 15:17:21 https://github.com/w3c/epub-specs/issues/716 15:17:31 topic: @issue 716 15:18:13 George_ has joined #epub 15:18:35 q+ 15:18:40 ack iv 15:18:49 dawhe: not sure what problem we need to solve right now 15:19:01 George_ has joined #epub 15:19:27 ivan: we have a resolution saying scripting is at risk. What more should we do at this point? 15:20:24 dawhe: we have learned that real -world support is spotty, so hard to address. Should we move on? 15:20:32 topic: testing 15:20:38 s/dawhe/dauwhe/ 15:21:05 George_ has joined #epub 15:21:56 tinyurl.com/epub-tests 15:22:09 George has joined #epub 15:22:19 dlazin: state of testing: some are easy, many are tricky. I put together a spreadsheet that breaks down the rs spec at the time into testable normative statement. 15:22:46 George has joined #epub 15:22:56 ...roughly 200 tests that need to be written; we are through about 40 - many of the MUSTS 15:23:29 ...what we need is a 'testing guide' that organizes the tests so that people can jump in and contribute 15:23:43 ...how to name, organize, track the tests 15:24:04 George has joined #epub 15:24:09 ...we should use data tests attribute for test repo 15:24:23 https://github.com/w3c/epub-tests/pull/20 15:24:31 ...here are pull requests 15:24:38 https://github.com/w3c/epub-specs/pull/1685 15:25:05 ...we could discuss whether to approve and merge the second PR here 15:25:28 ...then I can write up a document explaining how to participate in testing 15:25:56 q+ 15:26:03 ...having trouble in some cases finding reading systems viable to support tests 15:26:04 George has joined #epub 15:26:35 ack iv 15:26:48 ...I feel behind on testing; we need to chip away at these 15:27:24 ivan: need to think about how to report results in a consistent format - some sort of data file that includes metadata about the tests 15:27:48 ...and we need advanced structure on how to report the testing result 15:28:04 George has joined #epub 15:28:22 -> Audiobook test results https://www.w3.org/publishing/groups/publ-wg/implementation/results.html 15:28:45 ...for audiobooks we had metadata that we could use to produce readable reports 15:29:45 q? 15:30:26 dlazin: we are going to have a lot more failures than audiobooks testing 15:30:36 q+ 15:30:55 q+ 15:31:20 ack iv 15:32:04 George has joined #epub 15:32:23 ivan: CR has to prove that spec is implementable through >2 cited implementations 15:33:24 ...not worried about lots of failures, conceptually 15:33:55 q+ 15:33:55 ack dau 15:33:57 ...sometimes we get requests to retest after the publication as implementations catch up 15:34:04 George has joined #epub 15:35:04 dawhe: one example is manifest fallbacks, which is not widely supported across reading systems 15:35:07 ack dl 15:35:27 q+ 15:35:41 dlazin: maybe we need a regular testing meeting to help answer questions as they come up 15:36:05 George has joined #epub 15:36:34 ...for example, SVG requirement is hard to test thoroughly 15:36:54 dawhe: I would attend such a meeting 15:36:54 ack tz 15:37:51 q+ 15:37:55 tzviya: we need help putting EPUB 3.3 into epubcheck 15:39:04 George has joined #epub 15:39:04 Matt: I've been doing this as we go along 15:39:23 ack iv 15:40:07 ivan: what is the role of EPUBcheck in our testing strategy? In some sense it's an implementation 15:40:30 ...epubcheck checks content, not RS 15:40:50 ...what does the CR mean for the content document? 15:41:50 ...with a declarative spec, the approach to testing is to see whether those terms and features are used in the community 15:42:04 George has joined #epub 15:42:21 ...are fallbacks implemented or not? do publishers use those features effectively? 15:42:44 q+ 15:42:54 ack mg 15:43:01 ...we should have evidence for each feature in the package document to justify it to be included in the spec 15:43:55 mgarrish: we have a lot of features that are rarely used, or only used by a single feature. Does that mean we should deprecade stuff that isn't in wide use? 15:44:04 q+ 15:44:04 George has joined #epub 15:44:11 ack iv 15:44:20 q+ 15:44:30 q+ 15:44:48 ivan: maybe we have to have a list of those features where we have doubts that they are widely used 15:45:12 ...and ask the community in advance before we deprecate 15:45:30 mgarrish: we did a survey of publishers for 3.1 15:46:04 George has joined #epub 15:46:24 q+ 15:46:26 ack george 15:46:36 ivan: we are obliged to honor backwards compatibility, but don't have to keep features that nobody uses 15:47:05 q+ 15:47:08 george: prununciation task force is putting forth a new proposal; ;we should harmonize our requirements with theirs 15:47:09 ack we 15:47:45 q+ 15:48:14 q+ 15:48:18 wendy: we don't know if manifest fallbacks are used by anyone - should we do a survey across publishers and reading systems for this type of questionable feature? 15:48:28 q+ to ask about the difference between putting a feature in an EPUB and having that feature work 15:48:31 ack ch 15:48:55 CharlesL: if we can't find implementations, we could deprecate those because we can't find 2 implementations 15:49:35 ack tz 15:49:41 ...for Dan's tests, epubtest.org might already have tests or you could use those as a blueprint 15:50:35 tzviya: we did an investigation for epub cfi to see if they were in use in Google books 15:51:08 ...so it is possible to this sort of survey 15:51:14 ack mg 15:52:18 mgarrish: it gets complicated when we drop specs from authoring but not reading systems or vice-versa so it would have to have zero support anywhere to have no impact 15:52:34 ack dau 15:52:34 dauwhe, you wanted to ask about the difference between putting a feature in an EPUB and having that feature work 15:52:42 +1 mgarrish 15:52:59 q+ 15:53:09 dawhe: it's a disservice to authors if they have stuff in their content that we know doesn't work 15:53:34 ...would rather push a little to far and get blowback than not do anything 15:53:47 ack ch 15:53:57 ...*too* 15:54:03 q+ 15:54:38 ack mg 15:54:48 CharlesL: new developers have to support legacy code; we shouldn't keep supporting if not necessary 15:55:51 mgarrish: if we drop fallbacks, are images in the spine valid? there is a ripple effect to getting rid of stuff 15:56:03 q+ 15:56:34 george: mathml continues to be poorly implemented, but that's a core component of something we really need and support will slowly improve over time 15:56:51 q- 15:57:05 q+ 15:57:16 q+ 15:57:20 ack dl 15:57:29 ivan: there is no risk for mathml even though implementation needs to be improved 15:58:06 q+ 15:58:58 q+ 15:58:59 dlazin: if we have a weekly meeting we can go through these topics. epubtest repo had a nested heirarchy - does this organization make sense or should it just be flat? 15:59:17 ack w 15:59:23 dawhe: fine with me 16:00:17 s/dawhe/dauwhe/ 16:00:20 ack iv 16:00:26 wendyreid: sounds like we have agreed to a regular testing call. We can discuss organization of tests and how to formulate results. 16:00:42 ivan: Dan youu own the repository and can organize it the way you want. 16:02:11 ...re: the SVG case, this applies to testing html and CSS as well. we need to cleary position ourselves that the reading systems must be con[pliant with html and css and we are not in a position to test that. 16:04:13 ...we can only rely on the fact that reading systems render html 16:04:39 ack mg 16:04:52 duga: there is a large provider that uses a bunch of defferent ways to render 16:05:41 mgarrish: do you want us to review the PR? 16:06:16 dlavin: I would like people to review the individual tests to validate my interpretation of the spec 16:06:54 Garth has joined #epub 16:07:06 ...for the PR, is this the right direction? are we polluting the spec? 16:07:45 mgarrish: so the specs will be coupled with the tests 16:07:48 dlavin: yes 16:07:51 q? 16:09:34 q+ 16:09:45 q- 16:09:46 dlavin: will set of Doodle poll for testing meeting times 16:11:31 https://github.com/w3c/epub-specs/pull/1685 16:11:45 dlavin: need to be an owner of the spec to approve 1685 16:11:48 s/dlavin/dlazin/ 16:13:32 dlazin: would like to do a branch in the test repo 16:13:51 rrsagent, draft minutes 16:13:51 I have made the request to generate https://www.w3.org/2021/05/28-epub-minutes.html ivan 16:21:30 >@UªEFI PART 16:22:56 scribe+ 16:22:58 https://github.com/w3c/epub-specs/issues/1464 16:23:13 Thanks, Matt! 16:23:22 topic: @issue 1464 16:23:31 Dave: came about from testing. 16:23:44 …, json with HTML fallback, all normal EPUB stuff 16:24:12 …, when looking at it in an EPUB Reading system, but they just displayed the raw text. 16:25:25 …, weird behavior. Spec says if a RS does not know about or support something it should use the fallback, but I didn't see this. 16:25:39 q+ 16:25:59 …, JSON as raw text, or as a tree view, etc.. 16:26:32 ack iv 16:26:36 …, This shocked me that the core media types if not supported should default to the fallback but that doesn't seem to be happening. 16:26:36 q+ 16:26:42 Ivan: So what. 16:27:33 …, I can imagine that I write a paper which relies on a bunch of data files, and xml or csv data etc. It may not be nice but we just ack that and leave it. 16:28:04 Dave: write something in doc book but may not render in all systems so you put in the HTML as a fall back. but that didn't seem to happen. 16:28:52 Ivan: is it a problem if a RS displays the data directly, having a fallback would be a nice idea but maybe have to accept it. Is it ok to put a docbook in the spine, if I link to it or put it in the spine are two separate issues. 16:29:15 ack mgarrish 16:29:15 Dave: RS offering to download a some mimetype seems really bad. 16:29:22 ack mg 16:29:47 Matt: Why do we care what renders in spine items. offering guidance. 16:30:14 …, seems its not working as intended, but we don't want to reproduce PDF. 16:30:59 …, EPUB was trying to do better. we can look at these issues separately. Why are we concerned about Core media types. what do we say about the spine. we are an accessible text format. 16:31:51 q+ 16:31:56 ack ivan 16:32:05 Wendy: DMG file is a massive security issue, that an issue that RS would handle on their side. if a RS detects an executable within an EPUB it should do something. But we don't want to spec that executables be included in the spine that may open up a can of worms. 16:33:18 q+ 16:33:22 ack duga 16:33:25 Ivan: It must be part of the security section in the RS document if you are a RS be careful about downloading a binary file. EPUB check could react to this. the manifest fallback is ignored anyways… so it may not make sense there. EPUBCheck may not complain. 16:34:06 Brady: Yes core media types are important and maybe the RS are already supporting them and not worry about fallbacks. 16:34:34 q+ 16:34:59 ack mgarrish 16:35:07 Brady: here is this fundamental thing in the spec and core principle and Dan tested it and it seems it isn't . 16:36:11 Matt: I have no issue getting rid of fallbacks. Spine XHTML / SVG, but we could make it a formal allowed spine item. but there could be neat stuff and our fallbacks don't work. We are just calling it a failed feature of EPUB. we don't really want to have them all in the spine just the two of them. 16:36:18