15:47:07 <RRSAgent> RRSAgent has joined #pwg
15:47:07 <RRSAgent> logging to https://www.w3.org/2018/06/18-pwg-irc
15:47:08 <ivan> rrsagent, set log public
15:47:08 <ivan> Meeting: Publishing Working Group Telco
15:47:08 <ivan> Chair: Tzviya
15:47:08 <ivan> Date: 2018-06-18
15:47:08 <ivan> Regrets+ BillK, adamsisco, dauwhe, laudrain, nickruffilo, jmulliken, JeanK
15:47:08 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jun/0062.html
15:47:09 <ivan> ivan has changed the topic to: Meeting Agenda 2018-06-18: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jun/0062.html
15:50:43 <pkra> pkra has joined #pwg
15:51:43 <Avneesh> Avneesh has joined #pwg
15:54:41 <cmaden2> cmaden2 has joined #pwg
15:55:20 <Franco> Franco has joined #pwg
15:55:42 <jbuehler> jbuehler has joined #pwg
15:56:49 <Rachel> present+
15:57:18 <tzviya> present+
15:57:37 <wolfgang> present+ wolfgang
15:57:39 <ivan> present+
15:57:55 <Franco> present+
15:58:15 <ivan> present+ george
15:58:25 <JunGamo> JunGamo has joined #pwg
15:59:24 <George> George has joined #pwg
16:00:33 <George> present+ George
16:00:40 <romain> romain has joined #pwg
16:00:48 <ivan> scribenick: Franco
16:01:14 <mattg> present+
16:01:17 <romain> present+
16:01:20 <JunGamo> present+
16:01:34 <wendyreid> wendyreid has joined #pwg
16:01:46 <pkra> present+ pkra
16:02:02 <bigbluehat> present+
16:02:15 <rkwright> rkwright has joined #pwg
16:02:21 <ivan> present+ wendyreid
16:02:23 <garth> garth has joined #pwg
16:02:32 <garth> present+ Garth
16:02:33 <gpellegrino> gpellegrino has joined #pwg
16:02:36 <rkwright> present+ rkwright
16:02:37 <BenWaltersMS> BenWaltersMS has joined #pwg
16:02:55 <BenWaltersMS> present+
16:02:55 <ivan> present+ jpyle
16:03:02 <gpellegrino> present+
16:03:12 <ivan> present+ jbuehler
16:03:16 <josh> josh has joined #pwg
16:03:18 <tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-06-11-pwg.html
16:03:23 <Franco> topic: minutes
16:03:28 <cgebhard> cgebhard has joined #pwg
16:03:31 <cmaden2> present+ Chris_Maden
16:03:34 <ivan> resolved: minutes of last week approved
16:03:36 <Franco> tzviya: minutes approved
16:03:37 <cgebhard> present+
16:03:57 <tzviya> https://www.w3.org/2018/10/TPAC/
16:04:00 <marisa> marisa has joined #pwg
16:04:08 <Franco> tzviya: tpac registration is open...
16:04:20 <George> q+
16:04:24 <tzviya> ack George
16:04:27 <Hadrien> Hadrien has joined #pwg
16:04:38 <Franco> george: other relevant meeting that we need to participate in...
16:04:54 <Franco> ... WAI things, ARIA things I'm thinking of, auto-checking working group -- all of these kinds of things...
16:04:57 <Hadrien> present+
16:05:10 <Franco> ... are we going to do any coordinatin of these things here ?
16:05:12 <david_stroup> david_stroup has joined #pwg
16:05:13 <timCole> timCole has joined #pwg
16:05:22 <Franco> tzviya: we'll start havingthose discussions, good question
16:05:28 <Franco> george: math on the web, there are a lot of topics
16:05:30 <ivan> q+
16:05:30 <clapierre> clapierre has joined #pwg
16:05:36 <tzviya> ack ivan
16:05:45 <derekjackson> derekjackson has joined #pwg
16:05:48 <wolfgang> s/coordinatin/coordination/
16:05:52 <clapierre> present+
16:05:54 <timCole> present+ Tim_Cole
16:06:11 <pkra> -1
16:06:13 <pkra> ;-)
16:06:24 <duga> duga has joined #pwg
16:06:31 <derekjackson> present+
16:06:48 <Franco> tzviya: we'll open a wiki to talk about coordination. the pricing goes up for TPAC sometime in the july. it is in your best interest to register early
16:06:56 <ivan> present+ garth
16:06:57 <duga> present+
16:06:59 <laurentlemeur> laurentlemeur has joined #pwg
16:07:08 <Rachel> pricing: Early Bird rate - until 31 July : EUR 92 (EUR 110 with VAT)
16:07:08 <Rachel> Standard rate - until 30 September: EUR 135 (EUR 160 with VAT)
16:07:08 <Rachel> Late/on-site rate - starting 1 Oct: EUR 170 (EUR 205 with VAT)
16:07:10 <laurentlemeur> present+
16:07:20 <Avneesh> deadline is July 31 for early bird
16:07:48 <tzviya> topic: epub:type
16:08:00 <Franco> garth: this was a follow up discussion frrom the face to face in toronto. we had a lengthy discussion about epub type and its values. tentative conclusion: there are a set of epub type values that often times cause RS to do interesting things...
16:09:09 <Franco> ... those that cause interesting things to happen in the ecosystem tended to have solid aria mapping. we can turn them into aria roles. the other epub types tend to be used for internal workflow. there are ways to do that without having to standardize it.
16:09:30 <wolfgang> q+
16:09:31 <tzviya> Proposal: since there are no implementations of epub:type other than internal workflows (beyond those [e.g., noteref, footnote] with solid ARIA mappings), do not move forward with broad replacements for epub:type
16:09:31 <ivan> Proposed: since there are no implementations of epub:type other than internal workflows (beyond those [e.g., noteref, footnote] with solid ARIA mappings), do not move forward with broad replacements for epub:type*
16:09:36 <garth> q?
16:09:37 <Franco> ... we have a proposal now to not focus on epubtype probably ever for the wp / epub4 world
16:10:07 <josh> q+
16:10:15 <ivan> ack wolfgang
16:10:18 <tzviya> q+
16:11:00 <Franco> wolfgang: for example, there is the dictionaries and glossaries spec in the idpf. use case: if you are consulting a dictionary on mobile and it is a big dictionary and you dont want to see everything, it is useful to have a ssample section. if you want ot sell a wp chapter by chapter, and thats not easily expressed throuhg html5. my concern: how to perserve structual semantics and also specific branch specific semantics in the future in a wp world
16:11:01 <garth> ack josh
16:11:02 <ivan> ack josh
16:11:03 <BenSchroeter> BenSchroeter has joined #pwg
16:11:12 <BenSchroeter> present+
16:11:49 <Franco> josh: i agree with wolfgang that there are things that are useful that the glossaries and whatnot that epub has come up with that we should somehow include in wp. perhaps my concern is petty, but i think its meaningful-- i just dont watn the word epub appearing in my wp. its not an epub....
16:12:08 <ivan> ack tzviya
16:12:09 <Franco> ... i hate to duplicate glossaries or things, but we have to figure out some way that my wps that wont be packaged
16:12:16 <wolfgang> what about wpub:type?
16:12:42 <ReinaldoFerraz> ReinaldoFerraz has joined #pwg
16:13:02 <garth> q?
16:13:03 <Franco> tzviya: i understand the desire to include that type of information. the issue with epub type is that we never actually see it implemented. its never actually functioned in the real world. you mya have encoded it, but we've never seen it actually work. if the goal is to do something like to create a dictionary fucntionality, that would be a separate specification
16:13:14 <wolfgang> q+
16:13:18 <wendyreid> q+
16:13:48 <laurentlemeur> q+
16:13:54 <Makoto> Makoto has joined #pwg
16:13:55 <tzviya> ack wolfgang
16:13:59 <Franco> wolfgang: how to integrate some specifications or extension points into what is going to spec now
16:14:08 <garth> q?
16:14:14 <ivan> ack wendyreid
16:14:51 <BenWaltersMS_> BenWaltersMS_ has joined #pwg
16:14:55 <Franco> wendy: a dictionary , esp in mobile, we're sourcing the dictionary from the OS. having coded as wp or epub , specificying that this is ithe dictionary, it would be a deparature from what RS are using. ...
16:15:06 <garth> q?
16:15:09 <Franco> ... for glossaries and indexes, i dont know if we need epubtype for that. i think there are already solutions in html for those things.
16:15:10 <ivan> ack laurentlemeur
16:15:42 <Makoto> What is the history of epub:type?  Did it come from DAISY?
16:16:08 <tzviya> q+
16:16:15 <Franco> laurent: i wold like to speak about semantics on the publisher side. i propose to look at the micro data. it is in html5. its goal is to add semantics to html. for production, reading microdata can work
16:16:16 <garth> ack tzviya
16:16:20 <ivan> present+ makoto
16:16:26 <romain> q+
16:16:56 <garth> q?
16:17:04 <mattg> q+
16:17:06 <Franco> tzviya: the original epubtype vocab does come from daisy. i want ot make sure we're not trying to solve too many problems at once. i dont think we're closing ourselves off from writing a dictionary spec, i think we dont need to solve this problem today. it doesnt mean we cant solve it in the future
16:17:08 <garth> ack romain
16:17:30 <ivan> present+ gpellegrino
16:17:32 <Franco> romain: i think the dict and index spec are good examples that working on a vocabulary before making sure that it can be implemented by RS is a mistake...
16:17:57 <garth> q?
16:18:01 <Franco> ... the only reaosn we need such a vocab is for reading systems to do certain things.
16:18:05 <garth> ack mattg
16:18:48 <garth> q?
16:19:00 <garth> Proposal: since there are no implementations of epub:type other than internal workflows (beyond those [e.g., noteref, footnote] with solid ARIA mappings), do not move forward with broad replacements for epub:type
16:19:09 <Franco> mattg: epubtype never had specific requirements for funtionality. the closer we get to the web outside this ecosystem--- i dont think that minting new attributes is necessarily the way to go with this. it should be done through the html and w3c channels
16:20:02 <ivan> present+ marisa
16:20:11 <josh> present+
16:20:36 <Avneesh> present+
16:20:42 <Franco> ???: a lot of what we invented from whole cloth didnt get a lot of usage. the ones that did get usage do have aria mapping to it. we're not gonna have whole sale mapping from epub type to aria. theres good aria mapping for important ones, and that data-* can be used for similar epub type usages.
16:20:43 <garth> q?
16:20:50 <tzviya> s/???/Garth
16:20:55 <tzviya> +1
16:20:56 <ivan> +1
16:20:58 <garth> +1
16:21:03 <derekjackson> +1
16:21:03 <Avneesh> +1
16:21:03 <mattg> +1
16:21:04 <wendyreid> +1
16:21:05 <laurentlemeur> +1
16:21:05 <josh> +1
16:21:06 <romain> +1
16:21:06 <wolfgang> 0
16:21:09 <jbuehler> +1
16:21:09 <Rachel> +1
16:21:10 <rkwright> +1
16:21:15 <duga> +1
16:21:21 <George> +1
16:21:22 <BenSchroeter> +1
16:21:22 <clapierre> +1
16:21:30 <marisa> +1
16:21:30 <cgebhard> +1
16:21:31 <rkwright> q+
16:22:26 <Franco> wright: RS perspective: this doesnt look like its well supported, we havent figured out how to do it. we have to get the browsers involved. from rs perspective, if we start putting in attributes, we have ot figure out how every single new attribute gets interpreted.
16:22:34 <ivan> present+ rkwright, ReinaldoFerraz
16:22:41 <BenWaltersMS> +1
16:22:42 <ivan> Resolved: since there are no implementations of epub:type other than internal workflows (beyond those [e.g., noteref, footnote] with solid ARIA mappings), do not move forward with broad replacements for epub:type
16:22:58 <ivan> Topic: affordances
16:23:20 <tzviya> https://github.com/w3c/wpub/labels/topic%3Aaffordances
16:23:27 <romain> q+
16:23:39 <garth> ack rkwright
16:23:43 <Franco> tzviya: we're going to either remind people to do thier homework on affordances or get a status update. there have been a number of pull requests.
16:23:43 <tzviya> ack romain
16:24:22 <Franco> romain: i was just wondering about iss 143. it seems to me that all this discussion about homework, what is the status there.
16:24:22 <garth> https://github.com/w3c/wpub/issues/143
16:24:33 <Franco> tzviya: do we want to close this / re open this?
16:24:36 <bigbluehat> q+
16:25:34 <Franco> ivan: there are some of the affordances that do come in, they are very different from one another, but i would think that once we have those in, and we have an editor like matt, he can edit them in a coherent way. do we want to modify the style, etc?
16:25:45 <Franco> garth: theres been talk about the term affordances and if we've been using it correctly ...
16:26:11 <Franco> ... matt was going to tkae a pass at doing intro on this. we can put this one aside and let matt take a pass at it.
16:26:14 <garth> ack bigbluehat
16:26:17 <tzviya> ack bigbluehat
16:27:22 <Franco> benjamin: most of whats in there now are user agent. i understand its been confusing some people. an anchor tag with an href affords hyperlink, but the experience of clicking the link, it is a feature.
16:27:30 <ivan> q+
16:27:54 <tzviya> https://github.com/w3c/wpub/issues/143#issuecomment-374888961
16:28:17 <bigbluehat> q+
16:28:21 <tzviya> ack ivan
16:28:25 <Franco> tzviya: we left 143 open to have the template in there. benjamin, if you coudl take that template, if you could clarify that and make it clear in the sturucte of the template
16:29:04 <Franco> ivan: for non native english speakers, the term afford is difficult to understand.
16:29:16 <Makoto> +1
16:29:55 <Makoto> +10000
16:30:02 <Franco> ivan: its not the kind of term that is widely used and understand by people who are not in that world. that worries me. it makes it possible to do certain things, then lets call it that even though it is more convoluted. but it makes it more understandable for people who sometimes have to fight with english.
16:30:23 <Franco> tzviya: the term has been confusing for both native and non native english speakers
16:30:33 <tzviya> ack bigbluehat
16:30:35 <bigbluehat> https://github.com/w3c/wpub/issues/135#issuecomment-398094692
16:31:16 <josh> q+
16:32:26 <tzviya> ack josh
16:32:32 <Franco> benjamin: the reason i introduced the word, conversationally we have continued to conflate features with what goes into the document. it was gumming up the gears because we cant tell the user agent what to do. it doesnt need to be that word. but the goal was to map the stuff that is going in the doc to allow what is going to happen in the document
16:33:33 <mattg> q+
16:33:35 <garth> q+
16:34:12 <Franco> josh: i like the term affordances. i like hte distinction that it creates between features. this group is focused on what the content should be. we're not going ot try to implement a reader; we're going to try to speicify what is in the content so that any reader later built can do what it needs to do.
16:34:38 <ivan> +1 to Garth and Matt
16:34:47 <garth> q?
16:34:49 <tzviya> ack mattg
16:34:51 <garth> ack garth
16:34:52 <ivan> ack garth
16:34:59 <Franco> garth: lets start going through the list
16:35:53 <Franco> matt: what we're calling afforances are features.
16:35:53 <garth> q?
16:36:27 <Franco> tzviya: hopefully matt will be able to clean those affordances up and we'll be able to come to a happy conclusion.
16:36:44 <tzviya> https://github.com/w3c/wpub/labels/topic%3Aaffordances
16:37:08 <tzviya> https://github.com/w3c/wpub/issues/146
16:37:41 <Franco> tzviya: the first one is issue 146: propose closing this . because its already in the document. this is something that i wrote up. i dont even remember because it was a week ago. we want to be able to provide access to the user to the toc from anywhere.
16:37:42 <garth> q?
16:37:55 <bigbluehat> q+
16:38:25 <Franco> ivan: i put in a comment on that one in the end. the general thing is do we want in this document to add new examples or do we want to extend the use case document? i prefer the second. we have a ckind of a mixture. most of the affordances that came in have additional examples
16:38:35 <tzviya> ack bigbluehat
16:38:36 <Franco> tzviya: i would like to extend the case doucments
16:38:40 <bigbluehat> "The table of contents is a listed as a structural property in the infoset (https://w3c.github.io/wpub/#wp-table-of-contents)."
16:38:41 <garth> ack bigbluehat
16:39:05 <josh> q+
16:39:13 <George> q+
16:39:33 <tzviya> q+ to express concern that affordances will be too wishy washy
16:39:44 <tzviya> ack josh
16:39:45 <garth> q?
16:39:49 <david_stroup> features are "enabled" by markup/data. Can we some how use the word 'enable' or 'enables'?
16:40:11 <ivan> present+ david_stroup
16:40:20 <ivan> +1 to josh!
16:40:36 <Franco> josh: i dont know if any one saw the comment htat i made. if people create issues, we can add them to the UCR. afterwards i can go back into the affordance and make links back
16:40:38 <tzviya> github UCR: https://github.com/w3c/dpub-pwp-ucr/issues
16:40:43 <tzviya> ack George
16:41:20 <bigbluehat> q+
16:41:37 <garth> q+
16:41:45 <Franco> george: the link to the toc is great. i hpoe we have in our use cases that you would be focused on the same place that you arein the publication. so if im in ch 10, i would want want to have focus on the ch 10 not on the whole toc. if im reading in ch 10 and the previous heading to me is abc, i want to go to the toc ch 10 with the subheading abc.
16:41:52 <tzviya> ack tzviya
16:41:52 <Zakim> tzviya, you wanted to express concern that affordances will be too wishy washy
16:41:53 <garth> ack tzviya
16:42:36 <romain> q+
16:42:42 <Karen> Karen has joined #pwg
16:43:07 <garth> ack bigbluehat
16:43:08 <tzviya> ack bigbluehat
16:43:11 <romain> +1 to tzviya
16:43:12 <Franco> tzviya: one point i want to make about what concerns me about the affordances. if we're saying that the data that exists in the info set is x, i prefer ebing explicit about what the user agent shoudl do. unless we talk explicitly about how it should be implemented, i dont envision it being implemented
16:44:32 <garth> q?
16:44:44 <ivan> ack garth
16:44:54 <ivan> q+
16:45:47 <garth> q?
16:45:52 <garth> ack romain
16:45:55 <Franco> garth: we're going to allow people to put information to have user agents do cool things. noteref, nav file. most RS allow you to pullup a toc. i think we have had some success with it and i think if we do this in wp land, if we have this in there, the user agent will do because its better for the consumers of the content
16:46:18 <Franco> romain: i was wondering about the testability.
16:46:19 <garth> ack ivan
16:47:04 <bigbluehat> +1
16:47:28 <tzviya> q+
16:47:35 <Franco> ivan: so i was wondering as an editor how i should understand what ben said and how maybe the current stucture of the document should be changed in the sense that maybe what we try to do together in afordances here should be merged with waht we describe on the info set. for each info set item we could put what those info sets items afford us to do in the ucr document. matti dont know if thats something that is understandable. having separate sections leads us [CUT]
16:47:40 <garth> q?
16:47:43 <Franco> ... disparate examples. everythign depends on matt now.
16:47:44 <garth> ack tzviya
16:47:54 <bigbluehat> q+
16:48:09 <Franco> tzviya: i think thats a good idea but i think that we might also do some conformances. i dont think its useful to just link it ot use cases
16:48:16 <garth> q+
16:48:16 <George> q+
16:48:25 <Franco> ivan: one thing at a time. we should have a consistent document that is more readable and then we can look at this .
16:48:34 <tzviya> ack bigbluehat
16:49:06 <josh> q+
16:49:09 <Franco> benjamin: we can test whats in the infoset which is essentially these eaffordances are expressed, the ones we required and then develop if we want. capability tests for user agents.
16:49:11 <tzviya> ack garth
16:49:29 <tzviya> ack George
16:49:30 <ivan> ack garth
16:49:33 <Franco> garth: we are not in a position to dictate what user agents do with this data. that is for what the market is to decide
16:49:46 <pkra> gotta run
16:50:08 <garth> q?
16:50:13 <tzviya> ack josh
16:50:14 <ivan> ack josh
16:50:14 <Franco> george: in our fundamental accessibility epub, we test where am i. can the person understand wher they are in this whole document. getting to do the table of contents in the correct chunk where they are now. that will usually pass that test. we test it hat way but it is with a human being doing the interactions.
16:51:09 <Franco> josh: its become kind of clear to me that based on some of thw owrk that ive done and some commnets ive made, ive seen duplicaiton on the document. the suggestion that benjamin is always suggesting...
16:51:48 <Franco> ... we dont have a n affordances seciton. we place them in the specification as needed. if we want --- i dont know if we should --- want to start saying: as an implementer these are things we think you should have. and link to those implementations
16:51:50 <garth> q?
16:52:39 <Franco> tzviya: people have been assigned tasks in github to flesh out these items. it is more helpful to create issues rather than pull requests.
16:52:41 <garth> q?
16:53:04 <Franco> tzviya: the next step: transfer these to use cases and have matt work on them
16:53:12 <Franco> .. we need to do decide on the names of things.
16:53:31 <ivan> Topic: ToC bikeshedding
16:53:46 <Franco> tzviya: i vote for table of contents (spelled out)
16:53:52 <ivan> tableOfContents is the proposal
16:53:54 <wolfgang> +1 to Tzviya's proposal
16:54:27 <garth> tableOfContents
16:54:30 <Franco> ???: tableOfContents i guess we're ok on, but the other one 225, we should deal with that first
16:54:34 <Hadrien> q+
16:54:46 <tzviya> ack Hadrien
16:54:50 <Franco> ivan: tableofcontents is easier to vote on. 225 is more important
16:54:55 <ivan> s/???/Garth/
16:55:27 <garth> q?
16:55:32 <Franco> hadrien: im not convinced that we need something in json for tableofcontents. it is related to the discussion of rel value. if we're discussing the tterm for table of contents, it is already in the manifest. i dont think we need one
16:55:33 <ivan> q+
16:55:37 <garth> ack ivan
16:56:10 <bigbluehat> q+
16:56:13 <Franco> ivan: formally, in abstract, you're right. for a user agent point of view, it is better to have one...
16:56:20 <Hadrien> q+
16:56:24 <jbuehler> +1 to keeping toc as manifest resource for usability
16:56:24 <tzviya> ack bigbluehat
16:56:27 <Franco> ... i think from a user agent point of view i would prefer to use it as it is
16:57:12 <Franco> ivan: the html table of contents is in a nav file. so we have it.
16:58:02 <clapierre> clapierre has left #pwg
16:58:11 <Franco> benjamine: what weve done by putting it in the manifest, the implementer makes sure that it is talking about the one in the manifest. if you have a toc its gonna be in html anyway. my suggestion is to use the html we're already saying you have to return.
16:58:14 <garth> q?
16:58:19 <tzviya> ack Hadrien
16:59:07 <garth> q?
16:59:22 <Franco> hadrien: i disagree with ivan. i dont think we should be drawing a line between what reseources get their own element. ivan mentioned that toc is gonna be used all the time. we could say the same thing about cover, etc. i dont want to be in a position where we start drawing a line between what resources are already avaialble. i dont like thatin terms of consistency. id rather treat them all the same.
17:00:09 <Franco> garth: next week we shoudl discuss issue 225. its probably worht explicitly putting ben's issue. right now table of contents is pointed to in the manifest. it may be on the tentry page. ben: it must be on the entry page
17:00:29 <marisa> present+
17:00:37 <BenWaltersMS> BenWaltersMS has left #pwg
17:00:48 <cmaden2> cmaden2 has left #pwg
17:01:05 <ivan> rrsagent, draft minutes
17:01:05 <RRSAgent> I have made the request to generate https://www.w3.org/2018/06/18-pwg-minutes.html ivan
17:01:05 <ivan> zakim, bye
17:01:05 <ivan> rrsagent, bye
17:01:05 <RRSAgent> I see no action items
17:01:05 <Zakim> leaving.  As of this point the attendees have been Rachel, tzviya, wolfgang, ivan, Franco, george, mattg, romain, JunGamo, pkra, bigbluehat, wendyreid, Garth, rkwright,
17:01:05 <Zakim> Zakim has left #pwg
17:01:08 <Zakim> ... BenWaltersMS, jpyle, gpellegrino, jbuehler, Chris_Maden, cgebhard, Hadrien, clapierre, Tim_Cole, derekjackson, duga, laurentlemeur, BenSchroeter, makoto, marisa, josh, Avneesh,
17:01:08 <Zakim> ... ReinaldoFerraz, david_stroup