Publishing Working Group Telco — Minutes

Date: 2017-10-02

See also the Agenda and the IRC Log

Attendees

Present: Avneesh Singh, Leonard Rosenthol, Ivan Herman, Mateus Teixeira, Baldur Bjarnason, Chris Maden, Tim Cole, Zheng Xu, Dave Cramer, Gregorio Pellegrino, Tzviya Siegman, Lillian Sullam, Romain Deltour, Deborah Kaplan, George Kerscher, Joshua Pyle, Matt Garrish, Nick Ruffilo, Laurent Le Meur, Bill Kasdorf, Heather Flanagan, Rachel Comerford, Benjamin Young, Ric Wright, Charles LaPierre, Vladimir Levantovsky, Marisa DeMeglio, Garth Conboy, Brady Duga, Ben Schroeter, Hadrien Gardeur, David Stroup, Vagner Diniz

Regrets: Luc Audrain, Peter Krautzberger

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Zheng Xu: Hi guys, I am Jeff from Rakuten Kobo Inc. Was in this wg shortly at about two years ago but had left for a while because of some internal transfor in my company. So I am “new” to PWG will start joining meeting from this week. Nice to “see” with you guys again.

Dave Cramer: welcome, jeff_xu!

Zheng Xu: Thanks :)

Zheng Xu: Lol

Zheng Xu: oh, yes I got nominated by Rauten Kobo Inc. My email address there is zheng.xu@rakuten.com

Zheng Xu: official one Lol

Joshua Pyle: josh is Joshua Pyle from Atypon

Garth Conboy: Not here yet, but will be in 4-5 min.

Laurent Le Meur: I just tried on iOS, with no issue

Tzviya Siegman: Next week I will not be around - plus there are some holidays, should we have a meeting?

Leonard Rosenthol: cancelling fine with me…

Heather Flanagan: OK to cancel

Benjamin Young: +1 to cancelling

Rachel Comerford: +1 to cancel

Bill Kasdorf: +1

Mateus Teixeira: +1 to review!

Nick Ruffilo: Instead of a meeting - take the time to review the documents, private reflection, and any todos/tasks you might have

Tzviya Siegman: Review minutes from last week. pasted here

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-09-25-minutes.html

Resolution #1: Meeting of last week accepted

Tzviya Siegman: Minutes approved. Next we have Matt to talk about the section we’re currently in - lifecycle of a publication

1. lifecycle of a WPUB

Matt Garrish: https://github.com/w3c/wpub/wiki/Options-for-Processing-a-Manifest

Matt: What i started off doing was looking at how we might integrate with web-app manifest work. I was trying to get something prepared. I (pasted in wiki page) outlining some of the issues I was finding. My personal opinion is that there is not a lot we gain from web-app manifest. It has it’s own problems it’s trying to solve - installation, native/non-native… This last week, what I was trying to do was look at what the possible lifecycle steps are - not necessarily going off web-app, but what would a user-agent need to do to intiaite a reading session…
… I opened an issue over the weekend, and some discussion has happened there… We don’t have a specific user agent in mind, such as the web-app manifest which is focused on browsers. There is also not any one lifecycle for a web publication. i said this in github, if you’re a browser and you’ve loaded a web-app manifest directly, it’s different from what an ebook reading application might do with it. There’s an endless web of scenarios we’d have to flesh out if we wanted to. What i want to do, is perhaps we don’t go into this level of detail - but potentially look at the spec as Dave said in the issue - more like a data model. What are we providing for user agents/scripts/etc….
… That’s where I’ve gotten to - I think it’s the most applicable and appropriate course of action. Should we focus on the data model, and then maybe further down the line try to standardize if things come to that. Then starting to look at more specific issues on how a browser could represent a publication. So really - what are we expecting a browser to do - such as browsing context. What would entail for a web publication to be layered on top of the existing HTML object model experience. There are probably interesting avenues to persue instead of spending a lot of time specing out a lifecycle.

Dave Cramer: That sounds reasonable to me. I’m thinking it might make sense to be orthoganal to web-app. They want an installable experience, but after trying to work with it, I believe they’re trying to solve a different problem than we are. We should learn something about all of our struggles with this. This starts drifting down the path of trying to describe what browsers should do, and at this point in time, I don’t think we’re the group to do that. We’re also somewhat lacking in implementation expertise on this, but focusing on a data model and default reading order, and resources, then we can experiment and hopefully learn something.

Ivan Herman: I noted on the issue list, but I have no problem with this approach, but I don’t like the term data model. What we’re looking at is to have some sort of abstract user agent in mind, and what are the data we need to provide to let the user agent know what to do. The data model for me means a lot of other things.

Nick Ruffilo: +1 to Ivan

Leonard Rosenthol: Ivan, you’re not wrong, we can call it whatever we want, but the idea that we’re looking to describe the data - the infoset if you will - the things that the UA is going to need in order to start the process, if not proceed further down and proceed to the presentation.

Baldur Bjarnason: +1 to Ivan (and dauwhe and Matt).

Tzviya Siegman: I spent some time talking to Matt, we get really bogged down in details - but we’ve had trouble wrapping our head on ‘what are we trying to do’ and we’re getting dangerously close to forking HTML. We know HTML does what it does, but perhaps in this document, we need to explain what we’re doing that is unique. Some of the things we’re doing have not yet been defined by any other groups.

Nick Ruffilo: What if we view it as a “package document”

Benjamin Young: NickRuffilo: perhaps “packaging” not “package”

Ivan Herman: “package” is also a loaded term

Tzviya Siegman: We don’t have to get into wording right now…

George Kerscher: Once a browser is handed a manifest and begins to process the material to provide an experience, there may be alot of different files that would have to be fetched and retrieved to build out what is initially needed. Wouldn’t it make sense that the - all that - would be preprocessed and handed to the browser so that they don’t have to go through all that work? This would also allow the author to see what exactly would be presented by the browser.

Garth Conboy: I do kinda like “package” — but could lead to confusion with PWP. So, yes, +1, on wordsmith later.

Tzviya Siegman: these are important issues, but not necessarily for now…

Dave Cramer: +1 to Ivan

Ivan Herman: The pre-processing steps make me a bit concerned. We don’t want to add extra load on anyone - we want to be as close to the web as possible.

Leonard Rosenthol: at one point we’ll get there - but who drives the process. Does the publication drive it? The UA? Or some combination of the two?

2. Pagination Pull Request

Tzviya Siegman: Next topic - we have a pull request from Florian, Dave is going to attempt to speak on his behalf.

Tzviya Siegman: https://github.com/w3c/wpub/pull/65

Dave Cramer: https://s3.amazonaws.com/pr-preview/frivoal/wpub/layout-and-pagination.html#Layout

Dave Cramer: See the #layout link. The pull request is to start writing a section on layout and pagination of web publications. I think I’m just going to make some quick comments. It starts with an issue saying we need wide review - but I’m thinking that’s applying to everything. We have text saying things should be goverened by standards - and text saying we’re not requesting new features…
… In general, I don’t think we’re in a position to say anything. We’re about to say something unprecedented - that a collection of items would be a single document - but we should start tracking what sorts of issues would come up as part of this. Florian has some great examples of this. What happens if subsequent resources have different reading directions? How do counters work across pages? I’m hoping we can focus on that sort of thing. There’s also a comment here about specifying author preferences from an author’s perspective. We’ll see how many other words we can come up with. I don’t want layout information - period - in this. I think we’re talking about how to bind together these resources. CSS can tell how the author intends the document to be paid out, then we have personal styling based on the user’s preferences, but I don’t want the UA having to go through a manifest to determine that…

Baldur Bjarnason: I wanted to mention that I’m uncomfortable or extending/modifying CSS as it’s specified normally. The entire section on paginated layout - and the entire issue - because paginated layout within an item is unspecified. I’m talking about it in the context of a W3C spec is kind of science fiction. The problem with pagination and styling in epub is that they’re using a mode that is completely

Nick Ruffilo: unspecified. If we allowed that, and we said ‘yes, we have UAs that are going to go implement their own thing…’

Dave Cramer: The CSS spec on pagination is just issues - there is no normative text. We want to tread really careful here.

Nick Ruffilo: q

Ivan Herman: If I look at that section, I don’t think what florian said is what you describe. Florian is on the CSS working group. What he says is that we may have some problems that would require us to work with the CSS working group to add one or two features in the document they are developing - which is a completely different thing. It doesn’t say that this WG will define a CSS feature. When it says in one of the issues that page counters need to be extended - that means working with them to achieve that. That’s fine - we’re expected to identify the features that need to be extended. The whole section is 1,2,3,4 open issues.

Leonard Rosenthol: Process question - I’ve been adding comments to the pull request - do you want to review here? Or just continue in the pull request?

Ivan Herman: What I propose to do - if we find the pull request is acceptable - is to merge the pull request, then probably tomorrow, turn the issues into proper github issues so that it would be part of our discussions - then they become usual issues which we can put in comments. The reason why I prefer we do it that way is that we have to recognize that florian did this pull request as a guest - I don’t expect him to regularly go through things.

Leonard Rosenthol: my concern from the other side is that we’re trying to get a document out within the next 4 weeks. I worry - I find a few very clear things we as a group don’t agree on or are problematic. I worry that if we put out a document with some of these things in it, it might create issues. I worry about using the normal process on that.

Ivan Herman: And we can change the text between then.

Dave Cramer: My opinion is that I’d do significant editing of the pull request before merging it.

Ivan Herman: But will it happen - do we have the time/energy to do that?

Dave Cramer: Yes, I think so.

Ivan Herman: Ok, then, we wait.

Tzviya Siegman: So the proposal is to edit it, then merge it. Dave can you do this before then?

Ivan Herman: Just to speed things up, I propose that Dave makes the editing and merges it… Lets not wait the two weeks.

Garth Conboy: Dave - is there any overview of the editing you want to do - something to run by us?

Dave Cramer: I think one thing is that most of the notes do not add alot - things like having a list of existing of CSS specs, I’m not sure thats the kind of thing we need to have. I think this could be half as long with the same information. That’s one thing.

Ivan Herman: Very technical comment - I’m not sure how to solve this - but Florian did the editing on the fork of the repo, not the repo itself…

Resolution #2: dauwhe will do some editing on the pull request and merge it then

3. new members

Gregorio Pellegrino: I work as a software engineer in accessibilty. I do research and development in accessibility. We’ve certified over 17,000 epubs in italy and we are working on making them better and better
… I was in the epub 3 working group, but this is my first time in the working group

4. Security section

Tzviya Siegman: Moving on, we have Leonard on Security section

Leonard Rosenthol: Not done, but I have made progress. It is coming along, I’ll have it ready before next week. Other things have come up. I apologize.

Ivan Herman: I have a question - Were you around when we had the presentation on the web packaging items? One thing that was very promenant was not exclusively security - but was the integrety issue - using signatures over signatures to make sure that the document - such as a legal document - has been unchanged. Is this something you’d be interested in addressing? We were wondering if it might make sense as Security and Integrity.

Leonard Rosenthol: This is on WEB publications - so what’s different between a web publication and the web itself. We don’t want to change the web security model. Especially on the packaging - things will come up in the PWP document.

Ivan Herman: I don’t agree. As a web publication, if I put up legal text or a scholarly article, I want to make sure that the content has not been changed since it’s creation. For packaged, it’s there…

Leonard Rosenthol: Here’s how I see the difference. A web publication - the author controls. They are the ones who had to put it on the web - it’s not distributed outside of the standard web. I don’t think we have to worry about that in terms of web publication. When it comes to portability - and items off the web - then I agree 100%.

Tzviya Siegman: In the browser section of the HTML , there is a ton of information on security. Leonard - here’s my question - do you need help from others in this group?

Tzviya Siegman: https://www.w3.org/TR/html52/single-page.html#browsers

Leondard: Not to get the first draft, but afterwards, yes.

Ivan Herman: +1 to Hadrien

Hadrien Gardeur: I just wanted to say that this isn’t really tied to packaging. As long as we have to offline these web publications, we’ll deal with these issues. The top reason things are signed is that the implemenation is that the service worker will be sending an HTTP request on behalf of a server - which is why you need to use HTTPS. That’s not just for PWP - it’s something we’ll have to deal with all the time.

Baldur Bjarnason: I wanted to express the concern that the feature ivan mentioned is a web feature, not just publications. It’s very risky adding - like protecting a resource - it’s a web issue, not necessarily just to publications. This affects tons of work - but it’s general purpose features - and i want to make sure that we are not trying to define these sorts of features.

Ivan Herman: Risky it is, and probably doing it by ourselves is not the way to go, but lets not forget that this group does 2 things. It identifies those things that publications really really need, then it separates those things it has to define by itself or by other groups. It’s our job to talk to other groups when necessary. Same thing I said about CSS applies here. The integrity aspect might be more important for us than for other areas - so it is an area that comes up with use cases - a legal text is an obvious example. Yes, we should not do it ourselves, we should talk to web security, but we have to identify it.

Tzviya Siegman: Unless it’s urgent, can we table - we have more to talk about

Baldur Bjarnason: I think Ivan underestimates the disfunction of the technical side of the publishing industry and be careful not to suggest things that will be taken and run with… We need to treat this industry like a misbehaving child.

5. TPAC Agenda

Tzviya Siegman: https://docs.google.com/document/d/12J3Y3bb5fdPh1r2XH9YloINkNSxBJArocKY108sYCZ0/edit?usp=sharing

Tzviya Siegman: If you are attending TPAC, we’d love to see you, if you’re not attending, we will miss you. If you propose a session, we tried to squeeze it in.

Tzviya Siegman: The other sessions are things we think will affect us later on. There is our rough agenda. We are open to recommendations for change - there is one note here from garth in relation to user agents - we weren’t sure we needed 90 minutes - but we might…

Nick Ruffilo: Is there a dial in?

Ivan Herman: YES - if you are calling in, please note in the document if you are calling in.

6. 2018 Spring F2F

Ivan Herman: The issue for the face to face is that we’ll need a meeting for springtime. We have not found the ideal solution. There is an AC meeting in Berlin in May - and some of us will be there. However, the same week Laurent also wants to have the epub summit.

Leonard Rosenthol: what are the May dates?

Tzviya Siegman: AC Meeting is 13-15 May

Ivan Herman: We have to have the face-to-face separated from that week - so when and where? One idea that did come up - in April, there is the London Book Fair - which means several people will be in London. One idea is to combine it with the LBF - either in London or somewhere else nearby. London probably more expensive than NY.

Leonard Rosenthol: April 10-12 for LBF

Tzviya Siegman: Passover ends April 7

Leonard Rosenthol: and the week afterwards is ISO meetings for PDF

Dave Cramer: I’ll be in Berlin April 10-12 for CSSWG

Laurent Le Meur: EDRLab can host the meeting in Paris also. London / Paris is a 2 h trip.

Garth Conboy: And TPAC is Lyon (way later in the year)

Ivan Herman: I think the idea was to have the event either right after or before the fair. One possibility is London, the other is to have it in Nice or Pris. Obviously that means for North Americans and Brazilians coming over to the F2F then coming over to Berlin for the AC meeting/Epub summit - twice the trip. If we have it in North America - I have already found some possible dates at MIT.

Ivan Herman: But then that means we have a F2F meeting 3 times in a row in NA, which is a drag on Europeans. This are about the changes, and so one possibility is either April - the week of the 10th, in Europe. Paris is an option (as it’s not far from London). The MIT possible date is towards the end of May. As usual we have to decide this relatively quickly. Places are getting full, we have to find meeting places…

Bill Kasdorf: April adjacent to LBF would work best for me

Heather Flanagan: Would a doodle poll with the options listed out in one place be useful?

Baldur Bjarnason: Meetings in the USA are also problematic in terms of ability to attend. Some of us face a small but non-zero risk of being denied entry. So, if we can avoid US meetings that’d be appreciated.

Tzviya Siegman: There is also the possiblity of Canada…

Baldur Bjarnason: (Make that very uneasy about travelling to the US)

Ivan Herman: Yes, it might be easier for Europeans and Americans…

Garth Conboy: I like London. :-)

Zheng Xu: Welcome to Toronto

Dave: There are publishing companies in Toronto

Bill Kasdorf: I like the London or Paris options

Ivan Herman: I’ll work on an initial doodle poll

Heather Flanagan: thx!

Mateus Teixeira: Thanks all

Tzviya Siegman: Ok - next meeting in 2 weeks.

7. Resolutions