12:44:12 RRSAgent has joined #pwg 12:44:12 logging to http://www.w3.org/2017/06/22-pwg-irc 12:45:46 Agenda: https://www.w3.org/dpub/IG/wiki/June_2017_F2F#First_day 12:45:58 Meeting: Publishing BG, IG, & WG Joint F2F, 1st day 12:46:17 Chair: Tzviya, Garth 12:46:53 ivan has changed the topic to: agenda: https://www.w3.org/dpub/IG/wiki/June_2017_F2F#First_day 12:46:55 tzviya has joined #pwg 12:47:23 tzviya has joined #pwg 12:48:00 rrsagent, draft minutes 12:48:00 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 12:48:36 rrsagent, set draft public 12:48:36 I'm logging. I don't understand 'set draft public', ivan. Try /msg RRSAgent help 12:48:42 rrsagent, set log public 13:06:09 dauwhe has joined #pwg 13:06:29 Hello, world 13:06:37 present+ Leonard 13:06:53 clapierre has joined #pwg 13:07:00 RickJ has joined #pwg 13:07:11 leonardr has joined #pwg 13:07:19 present+ Leonard 13:07:20 takeshi has joined #pwg 13:07:26 rkwright has joined #pwg 13:07:34 present+ 13:07:38 duga has joined #pwg 13:07:56 present+ 13:08:32 scribe: dauwhe 13:08:51 pkra has joined #pwg 13:08:52 jun_gamo has joined #pwg 13:08:54 scribenick: dauwhe 13:09:01 present+ 13:09:02 tzviya: let's get started 13:09:09 present+ Takeshi_Kanai 13:09:14 Topic: introductions 13:09:16 present+ pkra 13:09:23 present+ dauwhe 13:09:26 present+ clapierre, duga, jun_gamo, george, tzviya, RickJ, rkwright 13:10:08 ... welcome everyone 13:10:18 present: laurent 13:10:23 ... Ivan will talk about administrative stuff 13:10:25 topic: administrative stuff 13:11:26 Bill_Kasdorf has joined #pwg 13:11:29 ivan: quite a few of us have never been to a w3c meeting 13:11:34 present+ 13:11:35 present+ Bill_Kasdorf 13:11:41 ... so I'll go into some details which may be boring for the old hands :) 13:12:23 [general webex disasterousness] 13:12:30 rdeltour has joined #pwg 13:12:49 Avneesh has joined #pwg 13:13:03 ... how we work, how we operate day-to-day, what kind of tools we use... 13:13:14 ... there is a home page for the working group 13:13:34 tzviya: does everyone know how to use IRC? 13:13:44 garth has joined #pwg 13:13:51 present+ Avneesh 13:13:57 https://www.w3.org/publishing/groups/publ-wg/ 13:14:42 q? 13:14:43 George has joined #pwg 13:14:46 present+ 13:14:54 present+ Garth 13:14:57 mateus-teixeira has joined #pwg 13:15:01 ivan: we use IRC for lots of things, including taking minutes during the meetings 13:15:06 present+ 13:15:10 present+ duga 13:15:12 ... the minutes themselves are stored on the web 13:15:39 ... published a day or two after the call 13:15:41 present+ George 13:15:46 mattg has joined #pwg 13:15:59 info about IRC: https://www.w3.org/Project/IRC/ 13:16:16 ... there are lots of references on the working group home page 13:16:26 ... apart from IRC, we have two major tools for work 13:16:32 ... one is email, the other is github 13:17:04 BillMcCoy has joined #pwg 13:17:25 ... there's a public mailing list (the archives themselves are public). this is the one we'll use most of the time 13:17:27 Dan_Sanicola has joined #pwg 13:17:34 kuznicki has joined #pwg 13:17:36 ... probably mainly for administrative things 13:17:48 ... there is also a member-only mailing list 13:17:52 Rachel has joined #pwg 13:17:58 ... it is rarely used 13:18:06 ... mostly for very confidential stuff 13:18:08 bigbluehat has joined #pwg 13:18:11 q+ 13:18:22 ... often for copyright, patent stuff 13:18:49 ... if you want to send something only to the chairs, there's an email list for us 13:19:57 [various newcomers enter] 13:20:03 Cristina has joined #pwg 13:20:09 ... there's more info in the work mode page 13:20:17 ... the other big tool is github 13:20:25 ... all our documents will be in github 13:20:42 ... we plan to have a separate repo for each document 13:21:03 ... there is also an overall repo for the wg (which we are using for the home page) 13:21:28 ... every repo also has a wiki 13:21:42 ... and the most useful tool of all is github issues 13:22:03 ... threads around specific issues can be organized, found, labelled, etc 13:22:20 ... for those who haven't used github before, it can be frightening 13:22:35 ... I've put together a GitHub for Poets :) 13:23:07 ... everyone will need to have a github account, and let me (Ivan) know 13:23:17 ... due to access control for github 13:23:43 ... WG members can edit wikis, etc 13:24:00 @pkra - we don't have audio working right now in the conference room, sorry! 13:24:05 ... and there's a separate admin group with doc editors who can accept PRs and make direct updates to the repo 13:24:14 ... some of you might be already in that group 13:24:20 @leonardr np. just wondering if that was an attempt at dialing in. 13:24:59 fchasen has joined #pwg 13:25:06 ... everything I'm saying here is for working group members (as opposed to BG) 13:25:18 ... we plan to have one 1hr call per week 13:25:31 ... we will reuse the slot we used for DPUB 13:26:26 laurentlemeur has joined #pwg 13:26:37 ... it's Monday at Noon Eastern time 13:27:14 tzviya: the timing works well for US and Europe, but we need to take everyone in account 13:27:40 jun_gamou: The call is 1AM in Japan; I think it's OK 13:27:44 takeshi: I'm used to it 13:27:47 q+ 13:28:15 tzviya: when the US changes clocks in November, should we ask again? 13:28:18 jun_gamou: yes 13:28:47 rkwright: the IDPF oscillated 13:28:51 ack d 13:28:52 ivan: that was complicated 13:28:56 chair: Tzviya 13:29:39 dauwhe: csswg has one call a month scheduled for an Asia-friendly time 13:29:56 vlad: we've tried things like that 13:30:01 ivan: time changes are always messy 13:30:11 sel has joined #pwg 13:30:28 ... for next Monday, we will have lots to do 13:30:45 ... (US holiday coming up) 13:31:08 ... I would propose to use the DPUB IG webex data for next Monday, then I'll set up a new series 13:31:08 q? 13:31:13 ... for face-to-face meetings 13:31:25 ... every year W3C has a week-long extravaganza called TPAC 13:31:39 ... where most WGs have their F2F meetings, and talk to other groups 13:31:51 ... this will be important to us due to our interactions with lots of other WGs 13:32:09 ... TPAC is in Burlingame, CA Nov 6-10. Make hotel reservations now! 13:32:21 tzviya: somewhat less fun than Lisbon :( 13:32:40 ivan: TPAC 2018 is in Lyon, France, which is more fun than silicon valley 13:32:58 ... TPAC 2019 is in Korea, possibly 13:33:24 ... we will need to decide if we want a springtime F2F 13:33:34 ... much depends on money 13:34:09 ... we also need to talk about the patent policy (IPR) 13:34:23 ... there are a number of process steps at w3c that look complicated 13:34:30 ... and some of that complication is due to the IPR policy 13:35:01 ... w3c's goal is that any formal specification can be implemented by anyone without any patent encumberances or royalties 13:35:32 ... what is expected from w3c members of a WG is, even if they have a patent, they accept that the patent is free to use 13:35:48 leonardr: when we start to have documents, official notices will be sent out 13:35:50 ivan: yes 13:35:59 Vagner_Br has joined #Pwg 13:36:07 ... we recognize that there may be companies who consider these patents as their crown jewels 13:36:14 ... in that case they are required to disclose the patent 13:36:20 ... and the group has to work around that 13:36:55 ... there are milestones in the spec process, and FPWD is one of the milestones where all members are asked about patent exclusions 13:37:08 FPWD = First Public Working Draft 13:38:12 Vlad: does not responding to the call for exclusions mean that you accept things? 13:38:15 ivan: yes 13:38:30 tzviya: lots of people in publishing don't may much attention to IP law 13:38:46 ... when you submit to github, you are agreeing to the license terms of that repo 13:38:57 ... if you have questions, talk to your own lawyer 13:39:08 Vlad: if you want to get something done, don't talk to your lawyer :) 13:39:16 garth: we can make an example of dave 13:39:34 ... he did a "q+" in the IRC channel when he wanted to ask a question 13:39:48 ... in a f2f it's somewhat stilted to do that 13:39:56 ... the chairs will watch the queue 13:40:13 tzviya: or raise your hand 13:40:23 garth: we want to make sure everyone can participate 13:40:39 q+ 13:40:44 ivan: anything I forgot? 13:40:50 q? 13:40:51 BillMcCoy: just being a good example :) 13:40:54 ack Bill_Kasdorf 13:41:03 ack BillMcCoy 13:42:06 [fun discussion about details of licensing of github repos] 13:42:09 Vlad has joined #pwg 13:42:28 Cristina: if you want to add other people to the WG? 13:42:40 ivan: The AC rep of the company has to appoint a person to the WG 13:42:46 Hadrien has joined #pwg 13:43:03 ... it's a two-step process. the company has to join the WG, due to the IPR issues (as IPR is on a company) 13:43:17 ... then the AC rep has to nominate a person, even if that person is the AC rep 13:43:33 q+ 13:43:36 ... there are two companies who've joined the WG, but have not nominated any people 13:43:52 tzviya: if you joined the IG (DPUB), your membership does not automatically transfer 13:43:57 ivan: one more thing on membership 13:44:06 ... we do have the notion of an "invited expert" 13:44:22 ... it's an exceptional thing, but there are some exceptional people who can't join as members 13:44:28 q? 13:44:43 ... these people can apply for invited expert status, and we have to evaluate 13:44:47 ... right now we have two 13:45:05 ... both were members of DPUB, one is Heather Flanagan, IETF spec editor 13:45:18 ... and the other is Peter Krautzberger 13:45:21 Micah has joined #Pwg 13:45:31 ... who is a core person for MathJax 13:45:37 q? 13:45:38 *waves* 13:45:48 Cristina: you email the chair? 13:45:49 ack g 13:45:55 ivan: no, there's a form 13:46:10 George: what is the minimum time commitment to the working group 13:46:26 ivan: official is half a day a week that you'd need to commit to be effective 13:46:50 ... the reality is that some people who only lurk, which is OK 13:46:51 invited expert form: https://www.w3.org/2002/09/wbs/1/ieapp/ 13:47:00 ... as long as they don't veto everything at the last minute :) 13:47:24 ... even if you look at the DPUB list, there are some unfamiliar names who've never been on a call 13:47:24 q? 13:47:33 tzviya: any other questions or comments? 13:47:46 clapierre: for a particular company, how many people can you nominate? 13:47:56 ivan: as many as you want 13:48:27 ... w3c operates on the principle of consensus. It is our goal. 13:48:36 ... this can require a lot of talking. 13:48:51 ... we may have votes and record resolutions, and votes are taken per individuals 13:49:04 ... but there might be decisions where the vote may be taken by members 13:49:25 ... anything else? 13:49:40 ... let's go on with the agenda 13:50:00 [general praise for Ivan's voice] 13:50:13 Topic: Charter 13:50:32 ivan: there's a link to the charter from our home page 13:50:53 ... we are chartered for three years, which is unusually long... it's usually two years 13:50:58 ... the reason I will come back to 13:51:26 ... let me go to the deliverables 13:51:40 ... we are charted to deliver four recommendations (in the jargon of w3c) 13:51:47 ... REC = web standard 13:51:54 ... and we can publish w3c notes 13:52:18 ... in this charter we did put in examples for possible notes that we might publish 13:52:32 ... and we took over one document from DPUB, which is Latinreq 13:53:00 ... a collection of knowledge about western typesetting, inspired by JLreq 13:53:13 ... work continues on Korean, Chinese, Indic scripts, etc. 13:53:39 ... we are chartered to do a web publications spec 13:53:48 ... with publications as first-class citizens on the web 13:54:05 ... we separated the publications from packaging 13:54:23 Latinreq: http://w3c.github.io/dpub-pagination/ 13:54:44 ... these are books, journals, all sorts of publications 13:54:54 George: these are two separate RECs? 13:54:54 ivan: yes. 13:55:05 leonardr: this afternoon we'll start of the details 13:55:20 ivan: then we have a separate rec for EPUB4 13:55:30 ... we don't know what these will contain 13:55:44 ... EPUB4 might be one page :) 13:56:16 ... but the core work is web publications 13:57:03 ... BFF work was done in EPUB 3.1 WG 13:57:12 ... there is also a rec called DPUB-ARIA 2.0 13:57:26 ... there has been joint work between DPUB and ARIA, which resulted in DPUB-ARIA 1.0 13:57:48 ... the epub:type vocabulary has been transferred to ARIA @role 13:58:02 mattG: I think it's in CR 13:58:35 ivan: here, there are many vocabulary items that the EPUB community uses, especially around Education, which may be added to make DPUB-ARIA 2 13:58:53 ivan: these are RECs, which means we have to follow The Process 13:59:09 ... the first draft we produce, a First Public Working Draft, is a milestone 13:59:25 ... it may not include all features, it may just be an outline 13:59:41 * dauwhe... DPUB-ARIA 2 - This time it's personal 13:59:59 ... FPWD gives us a list of what we want to develop 14:00:12 ... FPWD triggers IPR review 14:01:25 ... some members were advised not to join the WG by their lawyers since the scope wasn't completely clear 14:01:39 ... FPWD should make that more clear 14:01:51 ... from that point on, we are supposed to publish relatively frequently 14:02:11 ... my preference is that we publish frequently 14:02:55 ... then there is CR, Candidate Recommendation 14:03:14 ... where the work is feature-complete and relatively stable, and invite implementations 14:03:31 ... then we have to document multiple implementations and tests 14:03:47 ... before it can become a REC 14:04:15 ... I've had experience with other WGs where testing comes as an afterthought, and it's a major pain 14:04:23 ... the earlier we start, the better 14:04:46 ... one reason we're chartered for 3 years is that for this complexity, testing will require a lot of work and time 14:05:05 Vlad: from webfonts WG experience 14:05:17 ... developing the test suite took more time than the spec itself 14:05:39 ... for version 2 of webfonts, every time we had a "must" in the spec, we started developing the test then 14:05:52 ... you must work in parallel to make life better 14:05:58 ivan: absolutely 14:06:10 ... I used to be RDFa staff contact and implementer 14:06:24 ... every time a new feature came in, we implemented it in our own systems 14:06:53 ... at some point we will have a feature freeze, unless you come with a test :) 14:07:18 Vlad: you have 2 options, you have capital "MUST" or lowercase "must", the latter a common-sense statement that does not require testing 14:07:23 ivan: one more thing... 14:07:39 ... that came up during charter review 14:07:46 ... this work is not done in isolation 14:07:56 ... this is work done to put publications on OWP 14:08:19 ... we always must look at what other technologies are available at w3c or under development 14:08:26 ... we must not reinvent wheels 14:08:35 ... even if the other wheels are not ideal 14:09:00 ... furthermore, every WG has a constant shortage of volunteers 14:09:33 ... we can't really ask other WGs to do stuff for us, we should work together with them 14:10:01 ... some comments during charter review were afraid we were trying to fork the web 14:10:32 ... we want to be integral part of web 14:11:13 q? 14:12:02 Ivan: perhaps quick re-introductions 14:14:09 [another round of introductions] 14:14:22 ivan: if you are already on IRC, please do a "present+" 14:14:22 present+ 14:14:24 present+ 14:14:25 present+ 14:14:26 present+ 14:14:31 guests+ Fred_Chasen 14:14:32 present+ 14:14:33 present+ Rachel_Comerford 14:14:40 present+ 14:14:43 present+ 14:14:44 ... if you're not on IRC, ask your neighbor to help 14:14:55 present+ 14:14:55 present+ Hadrien_Gardeur 14:15:12 rrsagent, draft minutes 14:15:12 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 14:15:50
14:15:54 present+ 14:16:47 toshiaki-koike has joined #pwg 14:16:47 present+ 14:22:33 Dan_Sanicola has joined #pwg 14:35:31 clapierre has joined #pwg 14:35:43 garth has joined #pwg 14:36:14 rdeltour has joined #pwg 14:36:52 Micah has joined #Pwg 14:37:44 tzviya has joined #pwg 14:38:51 Hadrien has joined #pwg 14:38:55 rdeltour_ has joined #pwg 14:39:43 Avneesh has joined #pwg 14:39:58 Vager_Br has joined #Pwg 14:41:00 Vagner_Br has joined #Pwg 14:41:34 sel_BR has joined #pwg 14:41:48 topic: horizontal reviews 14:42:04 rkwright now scribe 14:42:18 scribenick: rkwright 14:42:41 And continued problems with WebEx — so this channel is the only path for now. 14:43:08 This means that every REC has to be reviewed by experts in the W3C in several areas. Tech arch, accessibility, etc. 14:43:42 These reviews are required. There are checklists and patterns to smooth it but it must be done 14:44:06 Intent is to ensure there is no security, privacy or accessibility problems. 14:45:32 cristina has joined #pwg 14:45:38 This group will need to be very careful that we stick to the WP aspects of the spec and not intrude into the other areas of the W3C (e.g. HTML, CSS) 14:46:51 ivan: We then have to have champions for each of these areas (i18n, A11y, security, privacy) 14:47:50 ivan: Leonard will speak shortly about security. We have good coverage on accessibility 14:48:27 ivan: On the i18n side, we will need to be careful about ids, uris, iris, etc. w/respect to i18n char-sets 14:49:06 ivan: another area we need to be careful about is metadata, which also have issues with the char-sets for the actual text content 14:50:21 ivan: One example is mixing bidi text in the metadata content. 14:51:06 q? 14:51:44 astearns has joined #pwg 14:51:47 laurent: Do we need to review the work of other groups whose work touches on us? 14:52:04 ivan: No, we just need to make sure that they are aware and there is no conflict 14:53:36 q? 14:53:38 tzviya: Remember that we need to be sure to be proactive about letting other WGs know about what we are doing. This also extends to the IETF 14:54:22 tzviya: We cannot assume other WGs are following our work. We need to be proactive in letting them know what we are doing 14:54:51 ivan: We also need to ensure that our OWN documents are accessible 14:56:01 ivan: For accessibility, we will need to defer to Avneesh, Romain, Charles and others 14:56:28 leonard: Security in one our key horizontals. 14:57:05 Slides at https://www.dropbox.com/s/ysghm63wknk3occ/Web%20Security-Intro.pdf?dl=0 14:57:22 leonard: Security is all about trust 14:58:29 leonard: First is where is the content coming from, what is its origin (domain) 14:59:03 OK. Works for me. 15:00:49 BillMcCoy has joined #pwg 15:01:32 leonard: How does this relate to ad hoc distribution of web publications? 15:01:54 leonard: How does the origin aspect relate to WP? 15:02:17 leonard: Protecting against attacks: 15:04:13 q? 15:04:29 leonard: Note that there are many overlaps between security and privacy. We will need to bear that in mind. 15:06:16 q+ 15:06:29 ivan: Some of these seem to be general Web security problems, which are not our purview. What is different? 15:06:33 ack B 15:06:47 leonard: I will cover this tomorrow but there are differences. 15:07:15 q+ brady 15:07:16 billm: We cover that today in EPUB where the origin is the root of the docuement 15:08:10 leonard: But that is not a requirement but a lower case "must", but as we move to browsers are UA, that significantly changes this problem 15:08:26 ack br 15:09:24 brady: In the web today we have third parties providing content which breaks the model. 15:09:51 leonard: #3: Don't surprise the user 15:10:31 q? 15:10:43 Google serves third-party documents from their own CDN and domain in the case of AMP 15:11:03 leonard: We want to leverage the capabilities of the web, but will user's be ready or willing to accept this? 15:11:51 q? 15:13:07 RickJ: Talking about publications we don't always know which part is the document what is the UA. 15:13:14 leonard: Yes 15:14:03 billk: Isn't it true that the user expects that the UA is sandboxing the document for the user. 15:14:10 leonard: Yes 15:14:42 @hadrien - funny you should mention AMP, I am talking about that tomorrow s a good example of security... 15:15:18 q+ 15:15:20 tzviya: Again, we need to ensure that we work with other WG but that work we are doing is specific to WP 15:15:54 present+ leslie 15:16:20 tzviya: But if we feel other WG are missing something we should work with them to fill that gap 15:16:26 q? 15:16:47 q+ 15:17:34 Micah has joined #Pwg 15:17:40 george: We have succeeded with the ally folks to get some publication recognition into the a11y spec. We need to continue to do so. 15:18:09 q? 15:18:17 george: But we need to ensure that our work doesn't break any of the AG specs. 15:18:24 ack B 15:18:30 Present+ Micah_Bowers 15:18:58 jun_gamo has joined #pwg 15:19:03 q+ 15:19:47 billk: Ivan spoke of choosing a champion for the 4 areas, which is good, but perhaps we should have some more systematic connection to the other relevant WGs 15:20:18 ivan: True it is my job to do this, but it would help if the load could be shared 15:21:50 q? 15:21:52 ivan: Dave helps out, DanielW will help, but any help would be appreciated 15:22:11 billk: But perhaps it would help to make this more explicit 15:22:50 q? 15:23:27 ack du 15:24:12 q+ 15:24:26 brady: One of the horizontals not listed is rights-management. Its tricky area but... 15:24:59 tzviya: IDPF never considered it. 15:25:18 q? 15:25:19 brady: Yes, but on the open web... 15:25:20 ack av 15:26:20 leslie has joined #pwg 15:26:27 avneesh: Speaking of the plurality of groups, there are many a11y groups and perhaps it is too much for a single champion but instead a TF 15:27:02 tzviya: Yes, but the champion would be the point person for a TF, perhaps 15:27:38 ivan: Perhaps "champion" is not a good name. More like the point person or something else. 15:27:41 ack lr 15:27:47 ack le 15:28:37 leonard: At the last TPAC there was a meeting with the POE group (permissions, etc.) would they be a good contact re "rights" 15:28:47 q? 15:28:51 ivan: No, they are only about vocabulary 15:29:05 q+ 15:29:22 ack cl 15:29:38 ivan: That will relevant when we get to the metadata relevant to "rights" 15:29:46 q+ 15:30:11 clapierre: Would it be useful to have a chart that lays out how all these WGs intersect? 15:30:35 ack bi 15:30:57 ivan: Yes, but it is a very complex graph. clapierre: Would you like to start that? 15:31:14 clapierre: Yes, I'll look at it. 15:32:21 q? 15:33:38 tzviya: WHo would be volunteer? 15:34:17 ivan: I would be the "ambassador" to the i18n area 15:34:41 q+ 15:35:01 ack Avneesh 15:35:19 avneesh: A TF for a11y, I would be willing to lead that. 15:35:39 tzviya: So avneesh is ambassador for a11y 15:36:48 leonard: I will volunteer to be ambassador for security 15:38:06 ivan: Currently, there is no security WG at the moment in the W3C 15:38:28 rkwright: Oops. Meant "privacy" 15:38:40 Brady may well be excited about helping Leonard out on security. 15:40:18 q+ 15:40:36 tzviya: Please note that Brady knows a lot about security and it willing to help. 15:41:14 q? 15:41:16 ack cl 15:41:18 ack clapierre 15:41:19 Benetech announces "Global Certified Accessible" https://www.benetech.org/2017/06/22/benetech-establishes-global-certified-accessible-program-to-ensure-content-serves-all-students-equally/ 15:41:41 George has joined #pwg 15:42:55 rrsagent, draft minutes 15:42:55 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 15:43:15
15:46:07 fchasen has joined #pwg 15:55:45 present+ Liisa_McCloy-Kelley 16:02:16 jun_gamo has joined #pwg 16:06:28 fchasen has joined #pwg 16:17:25 rkwright has joined #pwg 16:24:42 tzviya has joined #pwg 16:41:15 mattg has joined #pwg 16:45:56 kuznicki has joined #pwg 16:51:55 toshiaki-koike has joined #pwg 16:52:49 George has joined #pwg 16:53:07 Dan_Sanicola has joined #pwg 16:58:41 takeshi has joined #pwg 17:00:34 clapierre has joined #pwg 17:02:05 rdeltour has joined #pwg 17:02:06 clapierre has joined #pwg 17:02:20 fchasen has joined #pwg 17:03:03 rdeltour_ has joined #pwg 17:03:38 laurentlemeur has joined #pwg 17:04:28 chair: arth 17:04:40 chair: garth 17:05:09 scribenick: duga 17:05:30 garth: Start with Rick on testing implementation plans 17:05:31 leonardr has joined #pwg 17:05:38 Topic: Testing, implementation plans 17:06:05 Avneesh has joined #pwg 17:06:05 Ric's slides at https://www.w3.org/2017/06/Ric-Wright-NYC-20170622.pdf 17:06:07 Vagner_br has joined #Pwg 17:06:16 rkwright: Only here because he doesn't trust webex 17:06:42 ... structured the talk more as a list of questions 17:06:50 cristina has joined #pwg 17:06:54 q? 17:07:03 ... wants this to be more interactive, looking for input from the group 17:07:05 zakim, who is here? 17:07:05 Present: laurent, tzviya, Bill_Kasdorf, Avneesh, rdeltour, Garth, mateus-teixeira, duga, George, mattg, Le, Meur, Vlad, Dan_Sanicola, fchasen, rkwright, Rachel, kuznicki, jun_gamo, 17:07:09 ... sel, Hadrien, Toshiaki, Koike, Vagner_Br, leslie, Micah, Liisa 17:07:09 On IRC I see cristina, Vagner_br, Avneesh, leonardr, laurentlemeur, rdeltour_, fchasen, clapierre, rdeltour, takeshi, Dan_Sanicola, George, toshiaki-koike, kuznicki, tzviya, 17:07:09 ... rkwright, BillMcCoy, astearns, garth, bigbluehat, Rachel, mateus-teixeira, Bill_Kasdorf, duga, RickJ, dauwhe, RRSAgent, Zakim, ivan 17:07:31 mattg has joined #pwg 17:07:34 present+ Cristina_Mussinelli 17:07:46 liisamk_ has joined #pwg 17:08:13 ... Readium 2 to look at what might be the future of epub 17:08:18 sel has joined #pwg 17:08:22 jun_gamo has joined #pwg 17:08:36 present+ 17:08:37 ... Hadrien and Laurent will discuss in more detail 17:08:55 s/Laurant/Laurent/ 17:09:19 ... started in authoring 17:09:32 ... epub authoring has been the Achilles heel 17:09:48 ... epub 3 has been particularly terrible, no decent tool for it 17:10:39 leslie has joined #pwg 17:10:42 Hadrien has joined #pwg 17:10:57 ... has written some epub 3s, but using only existing web tools and text editors 17:11:11 leonardr: Why is that bad? 17:11:40 rkwright: There is a chicken and egg problem. For instance, webgl - need to use a text editor 17:11:47 ... there is no decent tool for it 17:12:06 George: What RS supports webgl? 17:12:17 rkwright: Readium does! 17:12:44 ... Doesn't work as well in iBooks for instance, as they may muck with the css 17:13:04 garth: Probably doesn't work in other RS that may be quite large 17:13:20 ... so people code to lowest common denominator 17:13:39 Vlad has joined #pwg 17:13:48 tzviya: publishers don't write epubs with these features because there are no tools and RSes don't support them 17:14:37 rkwright: There isn't much authoring support for epub 3, epub 4 will likely be more complex 17:14:38 * 100% agree tzviya but have forgotten how to say that in IRC... +1? 17:15:02 ... When we talk about testing, what are we testing? 17:15:24 ... consumption side? That is the standard w3c approach 17:15:43 ... but what about authoring tests? Traditionally ignored 17:16:00 ivan: testing also means whether the spec is consistent and precise 17:16:06 ... so it is testing the spec as well 17:16:51 ... Should be making sure the spec is implementable, and all the details are exposed and known to be implementable 17:17:52 ... originally the whole point of testing was the spec 17:18:10 ... and has now also become a test of the consumption apps (UAs) 17:18:24 ... but need to remember that original reason for the requirement 17:18:34 q? 17:18:47 rkwright: Are we inventing a spec that can actually be implemented? 17:19:37 rkwright: Who decides that the tests are written, run, and pass? 17:19:50 q+ 17:19:53 ivan: Usually honor system, self conducted tests 17:20:19 ... which is why we require 2 independent implementations 17:20:38 ... The fact that it is self interested parties is fine 17:20:41 q? 17:20:57 leonardr: A lot of RSes use the same core engine. Do those count? 17:21:06 ivan: No known answer 17:21:10 q+ 17:21:11 ack tzviya 17:21:22 tzviya: Part of what we need to talk about as we write is test as we go 17:21:37 ... don't want FPWD and definitely not CR with no testing 17:21:45 ... don't want a unicorn spec 17:22:19 ... Need to make sure that actual humans can implement this 17:22:45 ... need a bunch of people familiar with testing to cover all the areas 17:23:04 ... We talked about ambassadors before, do we need a testing one as well? 17:23:17 .... Probably yes, maybe rkwright? 17:23:55 RickJ: One problem with epub 3 was not being fully implemented. Self testing tends to be the stuff they support 17:24:06 ... who decides what is a correct test? 17:24:44 q? 17:24:45 rkwright: Atomic tests are nice, but they are really just testing the underlying the UA. 17:24:49 q+ 17:24:58 ... We need to test the more complex stuff to really test the RS 17:25:05 ack Hadrien 17:25:24 Hadrien: Question about the number of testers 17:25:55 ... what if the tests are in multiple languages? Is that multiple implementations? 17:26:09 dauwhe: I don't think so 17:26:33 ivan: We are testing ourselves, so there is no reason to cheat 17:26:41 ... we are doing it to convince ourselves 17:27:08 q? 17:27:09 ... if you can convince this group that the two implementations are different, then that is good enough 17:27:35 Hadrien: In the context of Readium 2, one thing we are struggling with is a consistent enough set of examples 17:27:43 for an example of a small set of tests for DPUB-AAM, see https://w3c.github.io/test-results/dpub-aam/#index-of-implementations-in-reports 17:27:56 ... having two groups, one writing the tests, the other working on integrations 17:28:18 q? 17:28:54 ... want to have people with knowledge of the spec writing the examples 17:29:06 ivan: Exactly right, and why we are discussing this now 17:29:26 ... need to write the tests from the start 17:29:34 ... Granularity of the tests? 17:29:39 ... no simple answer 17:29:56 ... in annotations, had to discuss exactly what was meant by a "feature" 17:30:12 ... Did not define a feature as each term in the metadata 17:30:22 ... defined it as groups of metadata 17:30:34 ... What is it in this case? don't know yet 17:30:49 ... We should not test things that just test the browser engine 17:30:58 ... that is irrelevant for this group 17:31:54 ... we won't repeat the 10K to 100K tests for css and html 17:32:10 ... our goal is to add to that those things that make sense just for us 17:32:15 ack ivan 17:32:17 q? 17:33:47 Micha: real world requirements of implementors become the test bed 17:34:12 ... need to make sure who is it out there that has a mission to create these things and will work with us to do that? 17:34:31 ... If we are having resource problems then we aren't getting the right people to help us 17:34:38 s/Micha/Micah 17:34:40 tzviya: So open source? 17:34:49 Micha: not necessarily 17:35:28 http://testthewebforward.org 17:35:40 q? 17:36:08 tzviya: Did this before and just collected results 17:36:32 ... at the end had a question if that was good enough, without the code behind it 17:36:44 ... Was ok, but may not be enough for exit criteria 17:37:03 ivan: Not sure what the scale is for us, less than CSS/html 17:37:26 ... RDFa was several hundred tests, there was a web site where all the tests were available 17:37:44 ... it ran the tests and provided a report, everything was public 17:37:59 ... test site remained so new implementors could test their code 17:38:24 rkwright: At Readium, were lucky to get a school of QA people to test for them 17:38:43 ... Had 4 or 5 people at a time 17:39:06 ... But results mainly just got stored somewhere 17:39:16 ... Goals? 17:39:25 ... adherence to the spec 17:39:29 ... interop 17:39:37 ... quality (find bugs) 17:39:46 leonardr: But that's not a spec issue 17:39:51 ... out of scope? 17:39:58 tzviya: It's a bonus! 17:40:23 ivan: We had spec testing for RDFa which helped implementators later 17:40:43 q? 17:41:04 rkwright: Performance. Not really part of spec, but must be able to make a performant impl 17:41:17 ... reliability 17:41:18 q+ 17:41:23 ... a11y 17:41:52 ... failure conditions. Need to test failure cases 17:42:03 ack George 17:42:04 q+ 17:42:14 George: One of the objectives is to make sure UAs are out there when we go to rec 17:42:23 pkra has joined #pwg 17:42:28 ... when we test these RSes are we also testing a11y of them? 17:42:44 ... Don't think it was done for annotations. 17:42:52 ... just adds another layer of difficulty 17:43:24 garth: Tough nut to crack. 17:43:46 ... Spec needs to be implementable with a11y, but product may be able to ignore it 17:44:25 tzviya: Epub specs support a11y, but implementations don't all provide it 17:44:33 ... testing can't really solve that 17:44:47 dauwhe: Can we add tests that check a11y? 17:45:10 q+ 17:45:13 q? 17:45:18 q+ 17:45:19 leonardr: You are imagining a RS with a user on the other end. May just be extracting data, etc 17:45:29 ack RickJ 17:45:41 RickJ: I hear us looking at the qualifications for exiting CR 17:45:53 ... pass/fail tests 17:46:13 ... then I look at the screen and see things that aren't reasonable for pass/fail for exit criteria 17:46:22 ... are we going down a rat hole? 17:46:31 rkwright: Just asking questions here 17:46:51 ack clapierre 17:46:58 ... Need to find a good comprise between not enough and too much testing 17:47:31 clapierre: Need some tests for the horizontals, otherwise we have a spec that claims it supports x,y,z, but without tests how do we know 17:47:32 ? 17:47:55 ack ivan 17:47:58 tzviya: We do have checklists for the horizontals, which we have to work through 17:49:07 ivan: At the end we have WP check, then we have more than we need, but it is good for the community 17:49:15 q+ 17:49:41 ... There is what we need for the group, then there is a little extra like performance, etc. We need to deicde what the right mix is 17:50:09 ... This looks really scary, but a lot is already covered by the other specs. We don't need to test those 17:50:20 ... just need to be careful to test what we define 17:50:31 q? 17:50:38 q+ 17:50:43 ... we do not test any html check. But eoub 4 check should (when it comes out) 17:50:53 ... because it will integrate those tests 17:51:05 leonardr: Why should we do that? 17:51:13 ivan: Because it is a useful service 17:51:16 q? 17:51:23 leonardr: But not for exit criteria! 17:51:26 ivan: Right! 17:51:54 ... one thing we need before tpac is what already exists and how we can leverage it 17:52:07 ... then use tpac to discuss with other groups 17:52:18 garth: How much is left? 17:52:22 rkwright: Tons! 17:52:48 RickJ: The tests for the RSes, sound like a successor to the epub test grid 17:53:03 ... should the business group be helping with it? 17:53:15 ack RickJ 17:53:23 BillMcCoy: This is a joint meeting 17:53:29 ack BillMcCoy 17:53:32 q? 17:53:36 ... so when we say "we", it isn't just the WG 17:53:39 rrsagent, draft minutes 17:53:39 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 17:54:01 q+ 17:54:11 ... so things like epub 4 check might not be exit criteria, but also not a "worry about it later" 17:54:18 ack b 17:54:28 ... so we can get people from the other groups (who are here) to sign up for some work 17:54:29 present+ leonardr 17:54:40 garth: Test grid is kind of stale 17:54:51 ... epubcheck is also kind of stale 17:54:57 present+ RickJ 17:54:59 q? 17:55:03 ack liisamk_ 17:55:05 q+ 17:55:07 ... Approach from different directions 17:55:32 liisamk_: Need to keep going so we have a reference platform 17:55:53 ... almost no one sells what is actually provided 17:56:04 ... so side loading doesn't really help 17:56:21 ... currently best way to test is to actually put it in the market and see what happens 17:56:22 q? 17:56:35 ack Avneesh 17:56:44 Avneesh: In general we seem to be talking about testing the spec 17:57:08 ... previous testing has been to test what was in the market 17:57:28 present+ BillMcCoy, Ivan, dauwhe 17:57:34 ... so this is a more constrained environment 17:57:57 present+ leslie, Hadrien_Gardeur 17:58:20 rrsagent, draft minutes 17:58:20 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 17:59:40 rkwright: epub test suite not that useful. Mainly just regressions testing 17:59:54 ... automated tests hard to build and maintain, very expensive 18:00:31 ... Unit tests are nice for the RS, but irrelevant for us 18:00:47 q? 18:00:47 ... BISG test suite, mainly a RS test 18:01:07 ... doesn't cover 3.1, lots of browser tests, nothing to do with RS 18:01:18 ... doesn't really test the spec 18:01:40 garth: The purpose was for publishers to know what works on each reading system 18:02:00 ... so a publisher would know that say, forms, doesn't work on a particular RS 18:02:27 rkwright: We are testing 3 things: spec, and something else, and RSes 18:02:52 ... Missing a lot of what we covered 18:02:58 ... Missing fxl! 18:03:15 ... limited Japanese tests, almost no Chinese, a little Arabic 18:03:43 ... hard to verify as non-native speakers 18:04:37 ... authoring: I like it, but don't need to talk about it 18:04:49 leonardr: What even is testing authoring? 18:04:55 Sel has joined #pwg 18:05:21 rkwright: Must test authoring systems against RSes. Does the authored content match the expected result? 18:05:31 leonardr: So more about testing the tool, not the spec 18:05:42 rkwright: Right, which is why I skipped over it 18:06:01 leonardr: How is this different than testing the files? 18:06:22 rkwright: It is making sure that the output is what the user expected to get out 18:06:40 RickJ: Agrees with Leonard! 18:06:56 ... irrespective of the workflow that creates the file, why do we care? 18:07:09 rkwright: We don't! Stop talking about it! 18:07:25 garth: css html tests don't cover authoring? 18:07:29 dauwhe: correct 18:07:40 leonardr: There may be cases where it is relevant 18:07:48 ... for instance, zip 18:07:58 ... we don't test the actual zipping 18:08:12 ... if we move away from that we might want to test package creation 18:08:16 q? 18:08:30 rkwright: Slippery slope! Packaging isn't much different than content 18:09:27 leonardr: Does epub check validate the zip? 18:09:32 rkwright: To some extent 18:09:39 garth: Does look at the signature 18:09:50 dauwhe: Checks other things specific to epub 18:10:02 rkwright: Exit criteria 18:10:33 ... because the nature of WPs testing whether a feature works could be interesting 18:10:47 ... might in practice be simple, but seems unlikely 18:10:52 ... need a better test suite 18:11:09 George: Do we need a test to take a WP to a PWP? 18:11:23 leonardr: Some may be under service workers 18:11:27 ... but some may be ours 18:11:38 rkwright: Tastes like implementation to me 18:11:49 ivan: And in theory may not use service workers 18:11:57 ... so we may not require it 18:12:15 garth: We could define a PWP that you can't create with a WP 18:13:07 (with a given set of technologies) 18:13:14 ... we either need to list the technologies explicitly required, or leave it up to implementors. Hopefully the latter 18:13:16 q? 18:13:39 rkwright: defined the spec, have a bunch of tests 18:13:53 ... at what point do we say this is so slow we can't say it is complete 18:14:12 ivan: Judgement call. But if it is that bad it is a spec bug 18:14:36 ivan: If one is fast and one is slow, then it isn't our problem 18:14:36 q? 18:15:12 rkwright: If we have 2 implementations, do they have to be perfect? 18:15:16 ... no bugs? 18:15:23 ivan: Yes, no bugs! 18:16:01 rkwright: These tests tend to be very atomic, so may not be too bad 18:16:09 dauwhe: Yes, they should be pass/fail 18:16:26 rkwright: Need a champion 18:16:42 ivan: Reach out to a group that lives on testing 18:16:48 ... testing is what they do 18:17:18 ... Shane is there, reaching out to them 18:17:42 ... Annotation wg was saved bv them 18:17:47 ... org is Specops 18:18:34 ... problem is Shane knows how to handle the testing side, but doesn't necessarily have the domain background 18:18:42 ... so may need co-ambassadors 18:18:47 https://spec-ops.io/ 18:18:54 George has joined #pwg 18:18:56 ... Shane and someone with domain knowledge 18:19:10 rkwright: I am willing to start the process 18:19:14 https://github.com/Spec-Ops 18:19:21 ... not sure how I will do my other job (Readium) 18:19:30 q? 18:19:31 ... looking at BillM 18:20:01 garth: Ivan, anything else for "these" other topics? 18:20:07 ivan: No, covered it all 18:20:27 garth: Agenda wise we move input technologies until after the break 18:20:35 ... take early break now, back in 15 minutes 18:20:41 rkwright has joined #pwg 18:20:53 leonardr: And sugary snack is here 18:21:16 rrsagent, draft minutes 18:21:16 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 18:21:49 Wrong syntax: 15-min break 18:31:39 laurentlemeur has joined #pwg 18:32:35 jkamata has joined #pwg 18:37:26 garth has joined #pwg 18:41:19 scribenick: mateus-teixeira 18:41:47 topic: input technologies 18:41:51 clapierre has joined #pwg 18:42:21 liisamk has joined #pwg 18:42:22 garth: looking into input tech: wp, pwp, epub 4, aria, browser manifestations, web app manifests 18:42:28 cristina has joined #pwg 18:42:44 rdeltour has joined #pwg 18:42:47 ... starting with tzviya, continuing tomorrow with other technologies 18:43:06 Digitial Pubishing WG Doc: https://www.w3.org/TR/pwp/#packaged-web-publications 18:43:19 https://www.w3.org/TR/pwp/ 18:43:42 jkamata has joined #pwg 18:43:44 tzviya: we had some publications in the interest group, will do quick overview of input documents 18:43:57 rdeltour_ has joined #pwg 18:44:18 q? 18:44:28 ... what's a web publication? wp is a publication that lives on a browser 18:44:41 ... won't use word "package" because not necessarily packaged like epub 18:44:46 The logo possibilities are wonderful! 18:44:59 ... got started because we were frustrated with how things functioned in epub land 18:45:14 Dan_Sanicola has joined #pwg 18:45:26 ... trying to have something that works when you open them in a browser, more than just a regular document, but a collection of linked documents 18:45:56 ... collected together and with a relationship, work TBD in this group 18:46:39 ... packaging is important if we want to share publications; also need linking mechanisms to reference other publications 18:47:02 ... metadata is a huge part of epub and needs to be in WP as well 18:47:08 BillMcCoy has joined #pwg 18:47:09 Vagner_Br has joined #pwg 18:47:24 ... important for distribution, need to look at things like URI and IRI and find out how these work in the world of publications 18:47:39 ... need to consider how ISBN is expressed in the world of the web 18:47:58 Avneesh has joined #PWG 18:48:04 ... we love the word "manifest" here; we don't always mean the same thing, but we need to figure out how to get to that in web publications 18:48:34 ... the manifest for our purposes might just mean a list of things included in a publication, and that binds it together 18:49:05 @dauwhe - let's start a support group :) 18:49:14 ... WPs also need to be styled, which might be work for the CSS WG, but we talked a bit about how to control this in WP and allow for different presentations 18:49:53 ivan: there should be a mechanism like service workers to also provide offline access 18:50:23 ... a bridge would have to be built between the info that characterizes a web pub and what characterizes a service worker 18:50:44 ... service workers are now separate wg from web platform wg 18:51:12 garth: talking a little bit about packaged web publications (PWP) 18:51:29 ... and how epub 4 might play into it as well 18:51:38 Sel has joined #pwg 18:51:52 ... PWP should be "renderable" offline, but most of it might go down when you're offline 18:52:26 ... whether this is done by service workers of other system is TBD, there are many valid ways of accomplishing this 18:53:17 ... may be along while before someone like PRH puts a web publication online and allows offline access or distributes a file to third parties or distributes in a flash drive 18:53:47 ... there's an example of this in epub (zip package), so that is a possibility 18:54:17 ... there is work on web packaging, done in early 2000s when we were talking about what the packaging format should be 18:54:59 ... switched to what became zip, ocf, etc. in epub -- Bill M's fault 18:55:19 q+ 18:55:41 leonardr: need to look at whether definition of the packaging format belongs in pwp or individual profiles like epub 4, for backwards compatibility 18:56:09 ... look at the option of having the flexibility of different packaging formats 18:56:24 garth: Completely agrees with Leonard! 18:57:07 q? 18:57:20 ... the definitions for packaging format have evolved, and epub 4 could be different constraints on what a PWP is 18:57:52 ... but we could also say that epub 4 can use a different method, in theory; there is some flexibility about how we approach it 18:58:10 ... pwp and epub 4 are currently set up as somewhat separable 18:58:29 BillMcCoy: it was the IDPF's fault, really 18:59:05 ... it was a group effort, but we chose zip over multi-part mime because the latter was mostly used for email; the situation is almost the opposite now 18:59:13 ack b 18:59:37 garth: the issue of security for a PWP that doesn't necessarily have a domain associated with it is also an interesting problem 18:59:49 ... do we go no further than we did with epub or explore it more? 18:59:53 q? 19:00:02 ivan: the only thing we can say is that this group will not define a new packaging format 19:00:32 q+ 19:00:38 ... that is an important thing; we will not define something that is neither zip or whatever; need to rely on packaging formats defined somewhere, whether it is w3c work for a new rec (?) or zip 19:00:57 q+ 19:01:11 (yes, I see folks on the queue) 19:01:12 leonardr: i don't disagree, but need to clarify if w3c won't allow, or if this is based on experience 19:01:19 ivan: a little bit of both 19:01:32 ... if there's work in w3c on a technology, we would not be allowed to replicate the work 19:01:54 ... at this moment there is open work for web packaging, so we should not do it 19:02:29 ... one of the reviewers in the charter process said he doesn't understand why we need the separate recommendation in the first place, because we will have packaging already defined somewhere else 19:02:31 And somewhat disagreeing with Dave (back a bit): I will continue to harp on some level of round-trip-ablity between EPUB3.x and EPUB4. 19:02:45 ... we may need a 1-page document to specify, e.g., metadata, like in epub 19:02:54 ... may be that the pwp spec will be no more than one page 19:02:57 ack du 19:03:18 duga: we will just use something that is already there like zip or web package? zip is not a packaging format 19:03:35 ... will we use the epub definition from IDPF directly and not modify it? 19:04:00 garth: paraphrasing ivan to say we will not do an archiving format 19:04:25 ivan: we may not simply refer to IDPF format, because, e.g., we might not want those files in XML; need to modernize 19:04:35 ... we would not define a compression or archiving format 19:04:50 q? 19:04:55 Ack RickJ 19:04:57 ... I agree with what Garth said... this time 19:05:30 RickJ: while our document specifies we will create a profile of PWP, will we possibly create others? 19:05:42 garth: we will not rule it out but we are not chartered to do it 19:06:06 tzviya: the language is flexible, intentionally vague, but we have four defined deliverables 19:06:18 q? 19:06:18 q? 19:06:20 ivan: we may need to define this in a separate document 19:06:37 Bill_Kasdorf: new technologies can come along that define these things 19:06:56 q? 19:07:21 george: two thoughts: tzviya mentioned we won't talk just about books, but it's not a sinful thing 19:07:32 ... we can bring publishing industry into the fold 19:08:02 ... point two: when we talk about a profile of PWP with more accessibility requirements, I intend to lobby for WP to be fully accessible, so be ready! 19:08:20 garth: next thing on agenda-- leonard wanted to talk about next-gen pdf 19:08:51 leonardr: there's an organization called PDF association; int'l org of 150-ish members representing companies, universities, vendors, etc. 19:09:04 ... that have some amt of interest in PDF 19:09:28 ... been working for about 9 months on what we are now calling "next-generation PDF", aka PDF next, responsive PDF, etc. 19:09:42 ... it is not a revolution and is not just for books, though we love books! 19:10:34 ... attempt to bring PDF and OWP closer together by leveraging existing features (mathml, SVG, etc.), so we can present a classic PDF representation and also a more responsive web representation 19:11:06 https://www.youtube.com/watch?v=n166VJm6SKA 19:11:23 NextGen PDF talk by Leanoard 19:11:35 ... ideas of what may go into a manifest, accessibility, etc., are also in the picture; we may use this as a profile of PWP int he future -- there is a lot of alignment between next-gen PDF and WP/PWP 19:11:41 preso about Next Generation PDF in the first session at https://www.pdfa.org/slides-and-video-recordings-of-the-pdf-days-europe-2017/ 19:11:57 q? 19:12:04 garth: Ric posted a youtube video of your presentation on IRC 19:12:05 fchasen has joined #pwg 19:12:27 ivan: what would be in that profile? or, why would it be different from PWP? 19:13:04 leonardr: in my vision, i believe PWP defines things like "here's what has to be there", the natural reading order, certain types of metadata--things that are common across all profiles 19:13:27 ... profiles then define their own packaging formats, manifest types, etc. 19:13:59 ... might decide certain things like metadata is in json-ld and all WPs need to use that--still an open question 19:14:20 q? 19:14:20 ... if we keep packaging out of PWP spec and leave it up to profiles, it enables us to make more useful profiles in future use cases 19:14:50 ivan: understood, but what i want to understand is: why can't we say that what you want to achieve with PDF-next is exactly the same as PWP or epub 4? 19:15:07 ... why having two doc formats when we can produce one that works for everyone? 19:15:37 leonardr: from our constituency, need backwards compatibility with existing PDF, just like bc is important in epub community 19:15:53 q+ 19:16:07 ... if we can have a rainbows/unicorns solution, that would be great, but my position is that we have a community that needs backwards compatibility 19:16:31 tzviya: even if epub 4 is backwards compatible, it does not mean PWP will be; we don't know this yet 19:16:55 leonardr: if we think of profiles as relative to their constituencies (epub, PDF, etc.), that's fine 19:17:18 garth: probably something like a json manifest would be higher level, like in a WP spec 19:17:37 q? 19:17:47 q- 19:17:51 ivan: at this point, goal would be to try to get to a point where difference between EPUB 4 and PDF-next (in vague terms) disappears 19:18:18 ... we have the opportunity to do that, but we might not be able; we have to minimize the differences, but if we could achieve one format lots of people would be very happy 19:18:44 in Readium-2, the PWP part of it is simply a naming convention for the manifest in a package 19:18:59 BillMcCoy: elephant in the room is that PDF is not a packaged format, so whether PWP can be jammed into this kind of format, we don't know yet 19:19:22 ... at the moment, we need to consider if it's worth stretching PWP to allow a paginated format like PDF 19:19:40 garth: it's good to acknowledge this now 19:19:53 subtopic: dpub aria 19:19:55 https://www.w3.org/TR/dpub-aria-1.0/ 19:20:03 https://www.w3.org/TR/dpub-aam-1.0/ 19:20:05 ... now mattg will discuss dpub-aria 19:20:37 i|leonardr: there|suptopic: PDF next| 19:20:40 mattg: ARIA is Accessible Rich Internet Applications, means for user agent and AT to communicate with each other so AT can present content to user 19:20:57 PDFNext->Next Gen PDF 19:20:59 ... talks to OS APIs and build a representation (accessibility DOM) 19:21:24 ... ARIA was a bridging between interactive components so they could still be used by ATs 19:21:43 ... also includes document structure like landmarks, which is key for this group--the semantics that allow a user to navigate around 19:22:11 ... we had the epub:type attribute and a vocabulary, but one of the issues is we don't have mappings and user agents don't understand it 19:22:20 i|talking a little bit|subtopic: Packaged WP| 19:22:38 ... it's useful for landmarks, but doesn't have high binding with AT 19:22:59 ... a question was how we can find a OWP-friendly mechanism for doing semantics? 19:23:04 i|looking into input tech|subtopic: Web Publications| 19:23:32 ... trying to come up with a specification and vocabulary for industry semantics in dpub-aria 19:24:08 ... what we did was outline fundamentals/essential semantics first, though we need to decide exactly what these criteria are 19:24:38 ... we need to meet the 2 implementations exit criterium, so we can't just prescribe the specifications; publishers need to actually use them 19:25:24 ... originally envisioned this going straight into ARIA; now we have an extension mechanism (reason for "doc-" prefix) 19:26:35 ... we talked to different groups working on APIs, can now identify note references, landmarks, etc., in current dpub-aria spec 19:27:13 ... but we need to figure out the next iteration of landmarks specifically, and extend the vocabulary 19:27:40 garth: this is my first time looking at aria spec. looks influenced by epub vocabulary 19:27:55 q? 19:28:17 mattg: yes, then got worked a little further by ARIA WG 19:29:18 george: the accessibility aspect i totally get; does this help publishing and using HTML as a master format for internal production? 19:29:27 q+ 19:29:35 tzviya: yes, we use it at wiley ... no longer need to create classes in CSS to identify something 19:30:04 ... can use roles (e.g., role="abstract") and don't need to create something artificial 19:30:31 mattg: moving forward we don't need to map everything, so we don't overload documents with so many semantics that impedes rendering 19:30:33 q? 19:30:58 george: one of our deliverables is a 2.0 version of this vocabulary, and we can't have 10k options 19:31:11 q+ 19:31:28 tzviya: anything we add to the vocabulary needs to be added to HTML later, but don't need to create API mapping document as mattg said 19:31:49 q? 19:31:54 ack clapierre 19:32:03 clapierre: when this was done, we needed two implementations by publishers, but don't need implementations for AT? 19:32:24 mattg: yes, for AAM particularly 19:33:31 tzviya: we had API mappings done by Microsoft, Gecko ... Apple was first one to do it and helped us with testing 19:34:01 laurentlemeur: the body matter is not expressed here yet? 19:34:20 q+ 19:34:39 ack laurentlemeur 19:34:39 ack laurentlemeur 19:34:46 mattg: no because it could conflict with other semantics. need to see how body matter is split. didn't add to first version yet, we needed more time to figure it out, but we could do so in the future 19:34:59 laurentlemeur: who chose "doc" prefix? 19:35:19 mattg: i think i did! but we had other variants like "dpub" 19:35:27 to see implementation report: https://w3c.github.io/test-results/dpub-aam/#index-of-implementations-in-reports 19:35:34 ivan: that was pushed back because the roles should be usable by those who are not publishers 19:35:51 q? 19:36:06 leonardr: good that it addresses things other than HTML documents, we can use it elsewhere 19:36:13 george: is there an existing AT that uses this? 19:36:50 tzviya: yes, fully implemented in webkit, VoiceOver, and there are some other partial implementations 19:37:15 george: this is very useful 19:37:15 ack ivan 19:37:39 ivan: the difference in this group is that we define it and publish it, but it is not the ARIA version 19:38:09 ... still need to coordinate with others, but we have to determine who; aria wg determines the mechanism, which is already defined, so we don't need aria wg anymore 19:38:16 ... only need to confirm with HTML groups? 19:39:00 tzviya: yes, for validation... if we have a role that is not mapped, it would override the semantics of the HTML element 19:39:14 ... let's start with aria group before HTML 19:39:41 ivan: yes, as a courtesy, but we they would just check with HTML group as well; we can do that directly 19:40:39 ... are we free to determine our own terminology and validation to meet our exit criteria? my understanding is that if we have a properly defined document, the values can be added to the validator as just another step 19:40:47 q? 19:41:02 mattg: we need to formally state that we can define our own vocabulary 19:41:23 ivan: yes, the charter says that, and this is not a joint deliverable with ARIA; it is our deliverable 19:42:01 subtopic: browser friendly format 19:42:04 garth: shuffling next agenda items and go to browser friendly manifestations with dave 19:42:20 dawhe: browser friendly format! (BFF) 19:42:41 ... a little history: if there's an epub on a server and you use a browser to access it, it will just download the file instead of displaying it 19:42:56 ... one of the missions of EPUB 3.1 WG was decreasing distance between epub and OWP 19:43:14 ... an obvious thing to do is unzip/explode an epub on a server so a browser can display it 19:43:23 ... turns out readium was already doing this internally 19:43:39 ... even further back in history, there was an alternate epub format that wasn't even zipped 19:44:02 ... so we started exploring idea of unzipping epub and making content directly available to web browser 19:44:15 ... but so much of the structure of epub is encoded in custom XML vocab, which browsers don't know 19:44:26 ... e.g., container.xml, various namespaces, etc. 19:45:02 ... thought was we can take the information from these files and put in an easier format for browsers/dev to use them 19:45:29 ... the idea evolved to have this exploded epub with an alternative serialization for the structural/metadata info 19:45:49 ... and started experimenting with json, which is useful for JS, but almost impossible for humans to use 19:46:42 ... hadrien and i went through details of the json, e.g., to avoid duplication in defining sequence in manifest, nav document, etc. 19:47:18 ... but we needed to consider whether it should support every idea the IDPF had 19:47:32 q? 19:47:33 ... Hadrien took off with the idea and built things with it 19:48:00 subtopic: readium's bff and readium-2 19:48:00 Slides at https://www.edrlab.org/public/slides/w3c/r2-webpub 19:48:28 laurentlemeur: a little history on BFF on readium: the initial scope was EPUB 3.1, and needed better format for browsers 19:49:03 ... using schema.org or json-ld to refine manifests for BFF 19:49:06 https://www.edrlab.org/public/slides/w3c/r2-webpub/assets/player/KeynoteDHTMLPlayer.html 19:50:02 ... IPTC has set of XML structures for expressing news documents 19:50:41 ... schema.org gives a full ontology of a vocabulary, including for books 19:51:05 s/bff/web publication manifest/ 19:51:06 ... the web publication manifest is a further refinement of BFF 19:52:47 ... Readium-2 evolves the Readium reading engine, using RESTful API for web publication manifests, platform-native languages, OWP technologies, and designed to be accessible 19:53:01 ... several companies are involved 19:53:22 Hadrien: want to point out we're working on internal plumbing, not a distribution format at all 19:54:00 ... the BFF work turned out very useful for Readium-2; when we started this project, we realized quickly that BFF was a good starting point 19:54:55 ... core ideas: manifests tend to be long lists, but this is not the influence here; the influence was hypermedia formats, where building blocks express something simple or something very complex 19:55:45 ... involves concepts of metadata, linked objects for discoverable interactions (i.e., via REST), and collections 19:56:02 ... everything must have basic requirements, but must be powerful and extensible 19:56:29 ... single requirement in this manifest model is that we need a title element, expressed as a single string 19:56:59 ... using JSON-LD contexts to map, e.g., with schema.org 19:57:32 ... we can express something fairly complex with simple expressions linked to schema.org definitions 19:57:44 ... for example, expressing author names in different scripts or languages 19:57:56 q? 19:57:59 ... most important part is the idea of core extensibility 19:58:26 ... don't necessarily consider "epub" as first-class, but consider different parts of epub as extensions 19:59:07 ... can use different context documents to express different elements depending on the implementation's needs 19:59:43 ... harnessing JSON-LD, can also use URIs to point to other vocabularies, and easily extend the metadata 19:59:53 ... this same idea also applies to link objects 20:00:15 ... the only requirement is that there is a self link so the manifest can always be found 20:00:46 ... started with idea that if something is on the web, it needs a URI for access; so we need to provide that URI in the link object 20:01:11 ... in epub we tend to reinvent the wheel, so we have one element for a spine item, another one for the manifest, etc. 20:01:29 ... the concept of a link object works in many places, instead of reinventing the wheel in different contexts 20:01:37 pkra has left #pwg 20:01:54 ... also useful for URI templates 20:02:18 ... using URI templates you can add as many services as you want and extend it easily 20:02:37 ... manifest should also be a way to discover different services, e.g., that a publisher can provide 20:02:48 ... such as a search engine, index, etc. 20:03:08 ... we also want to have good support for other media, not just text 20:03:55 ... can add basic additional information about different asset types, such as dimensions, duration, and so on, so browsers can select the most appropriate asset depending on your device 20:04:17 leonardr: why mix metadata with a link? why not have a link to the metadata for that object rather than directly including it? 20:05:13 Hadrien: we could do that, such as IIIF, which finds metadata first. you don't necessarily want to fetch the resource before you know more info about it 20:05:14 q? 20:05:34 leonardr: yes, but why include the metadata and the link together upfront? 20:06:11 Hadrien: it is easier to manipulate the JS object like this 20:06:31 ... the idea is to have something easy to work with 20:06:54 ... so we have some first-class metadata/properties 20:07:35 ... can also extend link objects by listing multiple values for one key in JSON data 20:08:22 ... some examples: multiple rels, media types, and properties, where metadata can be stored; two properties are default part of vocabulary, orientation and one other i can't remember now 20:08:49 takeshi: this looks like a new metadata scheme 20:09:43 ... some of the properties can be delivered by schema.org as properties of the vocabulary element 20:10:10 ... if you have no intention to reinvent the linked data scheme, we should just use the LD specification 20:11:05 ivan: in some sense, we come back to leonardr's question: if we have metadata and in the metadata we use schema.org, it seems misleading/unnecessary to separate this scheme from what's already in schema.org 20:11:49 ... why separate all these things? why don't we say we have all the metadata already available in schema.org, but then only specify outliers in the JSON? 20:12:18 Hadrien: the purpose is to balance the information available externally on schema.org, along with usability of the data 20:12:50 ivan: in the world of web publications, i would prefer to have as homogeneous a structure as possible. we could use schema.org. but it would be good to have one homogeneous structure. 20:13:01 Hadrien: i think that would be sub-optimal for our use case 20:13:23 leonardr: that's fair, but we should value purity of semantics 20:14:16 ivan: not necessarily about purity of semantics; using this format for your plumbing is fine, but we have to find a balance between the schema.org data and clarity of the metadata in the package 20:14:17 q+ 20:14:43 garth: we ought to treat this as an input document but not necessarily a proposal of our exact semantics; we will have lots of other opportunities to debate 20:14:59 laurentlemeur: even a discussion about the syntax would be useful 20:15:02 q? 20:15:27 Hadrien: a lot of the epub-specific stuff is not accounted for in schema.org 20:15:46 ack l 20:16:03 tzviya: schema.org lives in W3C, so should look at that work 20:16:38 leonardr: there are other standards that we can look at, considering, for example, publishers with a lot of metadata, who want to incorporate the data in their publications 20:17:14 Bill_Kasdorf: we can use different schemas in the same format 20:17:26 Hadrien: that's the goal. let them use what they already use 20:17:47 BillMcCoy: this is super general. was there nothing this general that already existed? 20:18:26 Hadrien: not really. most hypermedia models that already exist some have missing components, e.g., metadata definitions 20:18:42 ... the final principle is the idea of "collections" 20:19:25 ... the concept is pretty simple; only one requirement: need one collection (e.g., "spine") with one resource 20:20:02 ... the collections use the same linked object format; no reinventing the wheel 20:20:50 ... spine vs resources: no need to repeat yourself; spine contains reading order, and resources are linked objects pointing to assets needed for rendering, but not necessarily in reading order; no need to repeat spine elements and resource elements 20:21:09 leonardr: are all hrefs absolute? 20:21:23 Hadrien: yes, it's much easier to work with absolute URIs 20:21:55 ... but nothing forces us to use absolute URIs 20:23:12 ... a collection in this model can also be a collection--it can include a role, metadata, links, etc., but it can include sub-collections as well 20:23:48 ... finally, a minimal manifest, has a context declaration, a title, a self link, and one resource in the spine 20:24:31 ... can also provide text direction 20:24:35 scribenick: mattg 20:24:57 q? 20:25:17 subtopic: Readium-2 internal structure 20:25:24 laurent: in readium 2 we have streamer and navigator 20:25:43 ... work of the stream is to pass the content to the navigator 20:25:47 +1 to @mateus! 20:25:54 ... navigator takes the information and puts it on the web view 20:26:37 ... the streamer has several flavours - golang is used in web application 20:26:57 ... streamer and navigator are two parts on the same server 20:27:23 ... streamer can take epub 2 and 3, cbz and later pwp or epub4, etc. 20:27:33 ... with one piece of code you can handle all 20:27:47 ... relies on caching 20:28:21 ... navigator exists in swift, java and typescript - it takes the web manifest and paginates 20:28:49 ... nypl implementation makes use of service workers to take content offline for reading 20:29:02 ... plug-in system allows different navigators even on the same system 20:29:36 ... we are finalizing the streamers and then will work on the navigators 20:30:05 ... by end of 2017 we want to finalize the navigators 20:30:20 ... subwaylibrary.com is a current implementation 20:31:09 hadrien: they create a static version of the manifest - and web app manifest so you can add to your home page 20:31:35 ... using appcache and service workers because sw are not yet implemented on ios 20:32:35 laurentlemeur: have a prototype of readium, aldiko to build r2-based mobile apps by end of year 20:34:44 ivan: i'm trying to understand what is the takeaway for the group - one thing is the work on manifest affects how we implement web publications - using or not using json-ld and how it works with web manifests, etc are all questions we need to answer. how flexible is the code in terms of demonstrating a test implementation? 20:36:08 laurentlemeur: if the group adopts the same vocabulary and model then you have a reference implementation in readium, second option if you don't use is that we could ingest - we keep our internal model so won't be a perfect model 20:36:14 garth has left #pwg 20:36:53 garth has joined #pwg 20:36:57 hadrien: when work started on bff we wanted something roundtrippable - we have shown that it can be done with a json manifest - only requires one json manifest and not all the files that epub uses 20:38:39 q? 20:39:04 ... we use this not just as a representation but as an internal model - two core building blocks: ingestor is all about building blocks - should be able to work with other formats - the navigator needs to work with the internal model and whatever pwp offers - pwp will always be consumed by the streamer part 20:39:11 subtopic: web app manifests 20:39:11 slides available at http://rdeltour.github.io/presentations/2017-06-pwg-web-app-manifest/ 20:40:02 romain: web application manifest is part of progressive web apps - try to reproduce with web technologies what you get with native apps 20:40:11 Hadrien has joined #pwg 20:40:21 ... web manifest provides the ability to install the app on your device 20:40:41 ... is a simple json document that you can link from your web page 20:41:13 ... example has lang, short_name, name, description, icons, etc. 20:41:53 ... google recognizes that you can add the site to your web site when the manifest is found 20:42:37 ... can identify the background color and links to related apps in the store 20:42:59 ... the start url is launched when you open the app 20:43:31 ... the scope defines which url of your web site are part of your application 20:44:09 ivan: does this mean any resource in the scope will be made available offline 20:44:25 romain: it is up to the developer whether to make available offline 20:44:46 hadrien: you have a different scope when you define a service worker - this scope is not the same 20:45:32 romain: the orientation property defines the default orientation of the app 20:46:18 ... display mode specifies the preferred mode: fullscreen standalone, minimal-ui, browser - potentially could be a reading system mode 20:46:42 ... https://www.w3.org/TR/appmanifest/ 20:47:39 tzviya: web app manifest is possibly extensible - we can work with them on extending 20:48:44 ivan: we may need to step up as potential co-leaders to move this forward and add the features that we need 20:48:58 q? 20:49:05 ... web app manifest is only a working draft at this time 20:50:15 leonardr: tomorrow i'm going to talk about w3c packaging 20:51:15 ivan: web app manifest is not bound to progressive apps - different emphases between the two - we need to find a balance 20:51:40 and web packaging uses web app manifest as a basis for its metadata 20:51:43 hadrien: there is a lack of abstract model and extensibility in the web app manifest model 20:52:19 tzviya: that's something we can work with them on - was only a first draft 20:52:43 ivan: we can't push json-ld on them 20:53:03 garth: we need to research and see how practical it is 20:53:54 topic: In Memoriam Pierre Danet 20:56:04 billm: one of the former idpf board members - pierre danet - passed away recently - i want to take some time to honour him today - he was a super-influential person in the formation of this effort - it would have not happened without his support as he kept things rolling even when times were tough - i would like to honour his memory by trying to accomplish his goals: create an open standard and to innovate 20:57:39 ... in one of his last emails he said we need to revolutionize the reading experience - we have to forget the traditional turn page and reinvent reading - I encourage us as we move forward that we focus on the future - this is our chance to evolve publishing for the future, not just about the details or moving forward what we've already done 20:58:16 ... the boundaries between books and apps are converging - where do we want to get with this 20:59:01 ... i'm very sad to not have him here as a friend and colleague 20:59:01 [One minute silence in the room] 20:59:19 rrsagent, draft minutes 20:59:19 I have made the request to generate http://www.w3.org/2017/06/22-pwg-minutes.html ivan 20:59:41 jun_gamo has left #pwg 20:59:54 leonardr has joined #pwg 21:00:51 clapierre has joined #pwg 21:06:46 garth has joined #pwg 22:03:31 rdeltour has joined #pwg 22:24:39 BillMcCoy has joined #pwg 22:30:59 fchasen has joined #pwg 23:38:44 BillMcCoy has joined #pwg