Publishing Working Group Telco — Minutes

Date: 2018-06-18

See also the Agenda and the IRC Log

Attendees

Present: Peter Krautzberger, Avneesh Singh, Chris Maden, Franco Alvarado, Jeff Buehler, Rachel Comerford, Tzviya Siegman, Wolfgang Schindler, Ivan Herman, George Kerscher, Jun Gamou, Romain Deltour, Matt Garrish, Wendy Reid, Benjamin Young, Ric Wright, Garth Conboy, Gregorio Pellegrino, Ben Walters, Joshua Pyle, cgebhard, Marisa DeMeglio, Hadrien Gardeur, David Stroup, Tim Cole, Charles LaPierre, Derek Jackson, Brady Duga, Laurent Le Meur, Ben Schroeter, Reinaldo Ferraz, Murata Makoto

Regrets: Bill Kasdorf, Adam Sisco, Dave Cramer, Luc Audrain, Nick Ruffilo, Jasmine Mulliken, Jean Kaplansky

Guests:

Chair: Tzviya Siegman, Garth Conboy

Scribe(s): Franco Alvarado

Content:

1. minutes

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-06-11-pwg.html

Resolution #1: minutes of last week approved

Tzviya Siegman: minutes approved

2. TPAC registration opened

Tzviya Siegman: https://www.w3.org/2018/10/TPAC/

Tzviya Siegman: tpac registration is open…

George Kerscher: other relevant meeting that we need to participate in…
… WAI things, ARIA things I’m thinking of, auto-checking working group – all of these kinds of things…
… are we going to do any coordination of these things here ?

Tzviya Siegman: we’ll start having those discussions, good question

George Kerscher: math on the web, there are a lot of topics

Peter Krautzberger: -1

Peter Krautzberger: ;-)

Tzviya Siegman: 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

Rachel Comerford: pricing: Early Bird rate - until 31 July : EUR 92 (EUR 110 with VAT)

Rachel Comerford: Standard rate - until 30 September: EUR 135 (EUR 160 with VAT)

Rachel Comerford: Late/on-site rate - starting 1 Oct: EUR 170 (EUR 205 with VAT)

Avneesh Singh: deadline is July 31 for early bird

3. epub:type

Garth Conboy: this was a follow up discussion from 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…
… 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.
… We have a proposal now to not focus on epub:type probably ever for the wp / epub4 world.

Proposed resolution: 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 (Tzviya Siegman)

Wolfgang Schindler: 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 don’t want to see everything, it is useful to have a sample section. If you want to sell a wp chapter by chapter, and thats not easily expressed through html5. My concern: how to preserve structural semantics and also specific branch specific semantics in the future in a wp world?

Joshua Pyle: 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 don’t want the word epub appearing in my wp. It’s not an epub….
… I hate to duplicate glossaries or things, but we have to figure out some way that my wps that wont be packaged.

Wolfgang Schindler: what about wpub:type?

Tzviya Siegman: I understand the desire to include that type of information. The issue with epub:type is that we never actually see it implemented. It’s never actually functioned in the real world. You may 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.

Wolfgang Schindler: how to integrate some specifications or extension points into what is going to spec now?

Wendy Reid: a dictionary , esp. in mobile, we’re sourcing the dictionary from the OS. Having coded as wp or epub, specifying that this is the dictionary, it would be a departure from what RS are using. …
… for glossaries and indexes, I don’t know if we need epub:type for that. I think there are already solutions in html for those things.

Murata Makoto: What is the history of epub:type? Did it come from DAISY?

Laurent Le Meur: I would like to speak about semantics on the publisher side. I propose to look at the microdata. It is in html5. its goal is to add semantics to html. For production, reading microdata can work.

Tzviya Siegman: the original epub:type vocab does come from daisy. I want ot make sure we’re not trying to solve too many problems at once. I don’t think we’re closing ourselves off from writing a dictionary spec, I think we don’t need to solve this problem today. It doesn’t mean we cant solve it in the future

Romain Deltour: 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…
… the only reason we need such a vocab is for reading systems to do certain things.

Proposed resolution: 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 (Garth Conboy)

Matt Garrish: epub:type never had specific requirements for functionality. The closer we get to the web outside this ecosystem— I don’t think that minting new attributes is necessarily the way to go with this. it should be done through the html and w3c channels

Garth Conboy: a lot of what we invented from whole cloth didn’t 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. There is good aria mapping for important ones, and that data-* can be used for similar epub type usages.

Tzviya Siegman: s/???/Garth

Tzviya Siegman: +1

Ivan Herman: +1

Garth Conboy: +1

Derek Jackson: +1

Avneesh Singh: +1

Matt Garrish: +1

Wendy Reid: +1

Laurent Le Meur: +1

Joshua Pyle: +1

Romain Deltour: +1

Wolfgang Schindler: 0

Jeff Buehler: +1

Rachel Comerford: +1

Ric Wright: +1

Brady Duga: +1

George Kerscher: +1

Ben Schroeter: +1

Charles LaPierre: +1

Marisa DeMeglio: +1

cgebhard: +1

Ben Walters: +1

Ric Wright: RS perspective: this doesn’t look like its well supported, we haven’t figured out how to do it. We have to get the browsers involved. From rs perspective, if we start putting in attributes, we have to figure out how every single new attribute gets interpreted.

Resolution #2: 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

4. affordances

Tzviya Siegman: https://github.com/w3c/wpub/labels/topic%3Aaffordances

Tzviya Siegman: we’re going to either remind people to do their homework on affordances or get a status update. There have been a number of pull requests.

Romain Deltour: I was just wondering about issue 143. It seems to me that all this discussion about homework, what is the status there.

Garth Conboy: https://github.com/w3c/wpub/issues/143

Tzviya Siegman: do we want to close this / re-open this?

Ivan Herman: 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?

Garth Conboy: there has been talk about the term affordances and if we’ve been using it correctly …
… Matt was going to take a pass at doing intro on this. We can put this one aside and let Matt take a pass at it.

Benjamin Young: most of what is in there now are user agent. I understand its been confusing some people. An anchor tag with an href affords hyperlink, but the clicking the link, it is a feature.

Tzviya Siegman: https://github.com/w3c/wpub/issues/143#issuecomment-374888961

Tzviya Siegman: we left 143 open to have the template in there. Benjamin, if you could take that template, if you could clarify that and make it clear in the structure of the template

Ivan Herman: for non native English speakers, the term afford is difficult to understand.

Murata Makoto: +1

Murata Makoto: +10000

Ivan Herman: 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.

Tzviya Siegman: the term has been confusing for both native and non native English speakers

Benjamin Young: https://github.com/w3c/wpub/issues/135#issuecomment-398094692

Benjamin Young: 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 doesn’t 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

Joshua Pyle: I like the term affordances. I like the distinction that it creates between features. This group is focused on what the content should be. We’re not going to try to implement a reader; we’re going to try to specify what is in the content so that any reader later built can do what it needs to do.

Garth Conboy: lets start going through the list

Matt Garrish: what we’re calling affordances are features.

Tzviya Siegman: hopefully Matt will be able to clean those affordances up and we’ll be able to come to a happy conclusion.

Tzviya Siegman: https://github.com/w3c/wpub/labels/topic%3Aaffordances

Tzviya Siegman: https://github.com/w3c/wpub/issues/146

Tzviya Siegman: the first one is issue 146: propose closing this because its already in the document. This is something that I wrote up. I don’t even remember because it was a week ago. We want to be able to provide access to the user to the toc from anywhere.

Ivan Herman: I put in a comment on that one in the end. The general question 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 kind of a mixture. Most of the affordances that came in have additional examples.

Tzviya Siegman: I would like to extend the case documents

Benjamin Young: “The table of contents is a listed as a structural property in the infoset (https://w3c.github.io/wpub/#wp-table-of-contents).”

David Stroup: features are “enabled” by markup/data. Can we some how use the word ‘enable’ or ‘enables’?

Joshua Pyle: I don’t know if any one saw the comment that 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

Tzviya Siegman: github UCR: https://github.com/w3c/dpub-pwp-ucr/issues

Ivan Herman: +1 to josh!

George Kerscher: the link to the toc is great. I hope we have in our use cases that you would be focused on the same place that you are in the publication. So if I’m in ch 10, I would want want to have focus on the ch 10 not on the whole toc. If I’m 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.

Romain Deltour: +1 to tzviya

Tzviya Siegman: 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 being explicit about what the user agent should do. Unless we talk explicitly about how it should be implemented, I don’t envision it being implemented

Garth Conboy: we’re going to allow people to put information to have user agents do cool things, eg, noteref, nav file. Most RS allow you to pull up 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

Romain Deltour: I was wondering about the testability.

Benjamin Young: +1

Ivan Herman: so I was wondering as an editor how I should understand what Benjamin said and how maybe the current structure of the document should be changed in the sense that maybe what we try to do together in affordances here should be merged with what 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. Matt, I don’t know if thats something that is understandable. Having separate sections leads us
… to disparate examples. Everything depends on Matt now…

Tzviya Siegman: I think thats a good idea but I think that we might also do some conformances. I don’t think its useful to just link it to use cases

Ivan Herman: one thing at a time. we should have a consistent document that is more readable and then we can look at this .

Benjamin Young: we can test whats in the infoset which is essentially these affordances are expressed, the ones we required and then develop if we want. capability tests for user agents.

Garth Conboy: we are not in a position to dictate what user agents do with this data. that is for what the market is to decide

Peter Krautzberger: gotta run

George Kerscher: in our fundamental accessibility epub, we test where I am. Can the person understand where 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.

Joshua Pyle: it’s become kind of clear to me that based on some of the work that I’ve done and some comments I’ve made, I’ve seen duplication on the document. The suggestion that Benjamin is always suggesting…
… we don’t have an affordances section. We place them in the specification as needed. If we want — I don’t know if we should — want to start saying: as an implementer these are things we think you should have. And link to those implementations

Tzviya Siegman: people have been assigned tasks in github to flesh out these items. It is more helpful to create issues rather than pull requests.

Tzviya Siegman: the next step: transfer these to use cases and have Matt work on them

5. ToC bikeshedding

Tzviya Siegman: we need to do decide on the names of things.

Tzviya Siegman: I vote for table of contents (spelled out)

Ivan Herman: tableOfContents is the proposal

Wolfgang Schindler: +1 to Tzviya’s proposal

Garth Conboy: tableOfContents I guess we’re ok on, but the other issue (225), we should deal with that first

Ivan Herman: tableOfContents is easier to vote on. 225 is more important

Hadrien Gardeur: I’m not convinced that we need something in json for tableOfContents. It is related to the discussion of rel value. if we’re discussing the term for table of contents, it is already in the manifest. I don’t think we need one

Ivan Herman: formally, in abstract, you’re right. From an author’s point of view, it is better to have one…

Jeff Buehler: +1 to keeping toc as manifest resource for usability

Ivan Herman: I think from an author point of view I would prefer to use it as it is

Benjamin Young: what we’ve 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.

Hadrien Gardeur: I disagree with Ivan. I don’t think we should be drawing a line between what resources 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 don’t want to be in a position where we start drawing a line between what resources are already available. I don’t like that in terms of consistency. I’d rather treat them all the same.

Garth Conboy: next week we should discuss issue 225. It’s probably worth explicitly putting Ben’s issue. Right now table of contents is pointed to in the manifest. it may be on the entry page. ben: it must be on the entry page

6. Resolutions