PWG Weekly Telco — Minutes

Date: 2019-03-11

See also the Agenda and the IRC Log

Attendees

Present: Tzviya Siegman, Wendy Reid, Deborah Kaplan, Ivan Herman, Laurent Le Meur, Avneesh Singh, Luc Audrain, Charles LaPierre, Joshua Pyle, Benjamin Young, Dave Cramer, Ben Schroeter, Garth Conboy, Franco Alvarado, Brady Duga, Mustapha Lazrek, Ben Walters, Marisa DeMeglio, David Stroup, Ric Wright

Regrets: Rachel Comerford, Bill Kasdorf, Matt Garrish

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-03-04-pwg

Tzviya Siegman: Minutes from last week - any comments? Minutes approved…

Resolution #1: last week’s minutes are accepted

1. Packaging issues

Dave Cramer: https://w3c.github.io/pwpub/spec/ocf-lite.html

Tzviya Siegman: The first item on the agenda - reviewing the document Laurent put together for packaging. We aren’t going to spend today coming up with a name - even though it needs it - but not today.
… Laurent - please give an overview.

Laurent Le Meur: This is the document that was updated by Ivan to make it respec compatible. It includes terminology and puts two names — lightweight packaging format (LPF) and Web Publication Lightweight Package (also known as package)
… there are LPF compliant user agents, LPF compliant files. There is an intro that explains the use. (reads from document). B2C and B2C items. There is some terminology that isn’t totally finalized. We would have to list every token inside..
… there is a part 2 that is very short that states we’re using ZIP format as a base — the ISO standard of ZIP. Then we state that the package must include an entry page with HTML and/or a manifest JSONLD (the web application manifest)
… we have issue 38 - where ivan is proposing changing the words of this section. If HTML and JSON-LD are both provided, then the primary entry page must make reference to the manifest. A package may contain any of the files form any place.
… We have a section about relative items. There is section 3 about user agent performance which is empty and we don’t know if we have to put something in or get rid of the section totally. The end is a definition of the media type. “application-wpub/zip” .lpf would be the extension
… and that’s it. Questions? Or we’ll move to issues.

1.1. Rec or not Rec?

Laurent Le Meur: https://github.com/w3c/pwpub/issues/39

Tzviya Siegman: so the question is — should we take this to rec track — a version of zip to rec track within the W3C. I’m sure people have strong opinions about this.

Dave Cramer: I would like to hear from people with more experience in W3c land. We are trying to standardize zip with well known file locations. What benefit do we gain from rec track on this? How do we test it? What is a browser’s obligation?

Ivan Herman: To react on that — because we refer to an ISO standard, from the W3C point of view, it becomes trivial. Taking this to rec track would be relatively simple testing around user agents doing the right thing with wpub content within the document.
… if we decide to go rec track, I’ll talk to Ralph about this to test the waters. I didn’t want to do it so far, because I wanted agreement amongst ourselves first. I don’t think there is a big problem, and I think browsers already handle it…
… most of the testing will have to be done for Audiobooks — in the sense of following what wpub says.
… I think that having a rec track stamp on it, together with audiobook format, gives more weight to the standard. Having an audiobook format without a standard package seems odd.

Luc Audrain: I agree with Dave’s questions - do we really need browsers to handle it, and I’m not sure they already do. Aren’t we trying to bring something somewhat specific to the whole community?
… Does it bring zip to all the internet?

Tzviya Siegman: When it comes to interoperability — our section says none. What we learned from epub was that when we changed the mimetype - without providing information about what should be done with it - user agents, in particular browsers, do not handle it. If we propose it, rec track or not, we need to define what it means to process it. And we have not done that.
… if there is a section in this document, or added to the use cases and requirements, we need to note what it is to handle this type of zip.

Ivan Herman: +1 to tzviya

Garth Conboy: I was going to re-chime in with what Ivan closed with. In presuming we are going to go down a rec track for audiobooks, then we pretty much have to go down a rec track with this. Audiobooks without a way to package is not interesting.

Dave Cramer: People have already noted that browsers don’t really do anything with zip right now. It also occurs to me that it would be cool if you pointed a browser at the URL of one of these things and it opened index.html and processed the manifest, but is that really what we’re asking for?
… the question of an audiobooks user agent when it comes to this - are we asking they load things directly from the manifest?

Laurent Le Meur: it will be difficult to ask browsers to download the zip file and read them from the inside, especially if the zip is huge. This happens with epub — if the epub is too big, it doesn’t work as well. The zip file is for file exchange and download, it isn’t meant to be read by browsers.
… Either we consider anything that is able to receive as a rec must be consumed by browsers. In this case, there is an issue. Or we consider that publishing will build something that works for the web, but, when taken out of the web it is packaged.
… we can’t say that user agents will consume that.

Benjamin Young: https://www.w3.org/TR/widgets/#zip-archive

Garth Conboy: +1 Laurent

Benjamin Young: I wanted to mention that W3C was down this before — on the widget spec. It’s titled web-apps. It’s as close to what we’ve talked about in the whole of web publications. It was conceived as a similar system with a manifest and put in a zip file opened by a web browser.
… it ultimately failed. In part because of zip and in part because of what should go int the manifest, and in part that it wasn’t expandable. The zip related conversion is in the same items. We should be working more in web principles. Web-based distribution needs to be considered.
… we can have the package be something that is outside, something that publishers use to distribute to retailers.

Ivan Herman: we should be careful not to open up certain conversations. The ideal approach for the browser is a packaging format that is built for the browser. What we have here — which is why we call it lightweight — we know it’s not the full solution for web-based publishing. We should not put on requirements, against the document as if it was the final solution.
… We have to be careful how we say that. In this sense, we can say it’s not a recommendation — but I’m very curious what the publishing community would say if we said there was an audiobook standard without a packaging standard. We could say the primary usage for the package is for non-browser reading systems.
… to answer one note that Laurent noted — we can say the primary target is for recommendation to user agent to handle wpub structure - awaiting a future package.

Laurent Le Meur: If we don’t make a rec for this document, we could leave it to the community as epub 3.2 for the moment (short term). I think it’s not the same. Epub 3.2 is the latest IDPF standard, this is new… This is a spinoff of OCF. If there is no standardization, just a note from W3C, it won’t have any traction. If we don’t go Rec with W3C, we’ll have to go Rec elsewhere.

Ivan Herman: I think the alternative is not to make it a community group document. The alternative is to publish a w3c note from this group. It has the presence of the working group, and the weight and we can refer to that we don’t have a web packaging standard.

Tzviya Siegman: We’re in a difficult position. We need to have something until there is a web packaging standard. I don’t like doing a intermediary, but we need to. I’d like to publish a note, with a line in it that when we have a web packaging spec, we will use that, but until, we are using zip.
… I want to add a comment that we’re waiting for the web packaging standard for a user agent.

Avneesh Singh: +1 to WG note

Dave Cramer: For audiobooks, I can easily imagine having a spec where you put all these mp3 files in a folder, put in a manifest, then send it to your distributor somehow. I don’t see a rec for that, if we don’t expect a user agent to be reading that. I could just use TAR…
… A note is a better choice than a rec. I don’t see packaging being at the essence of what we’re doing. It just lets us get to the next step without losing pieces.

Garth Conboy: I think ivan and Dave’s suggestion of the note makes sense. I would NOT want to see us make a commitment to, ‘switch to/transition to’ I would think we would want to augment with.

Ivan Herman: Two things. First - I think, nevertheless, if the working group agrees, I’d like to discuss this with Ralph. Then I’ll come back to the group with his reaction. Second — regardless of whether it is a rec or not a rec, we should write the document as complete as possible.

Tzviya Siegman: +1 to ivan

Ivan Herman: things that talk about what the user agent should do — we should write that down as if it were a rec. It’s important for everyone and we need to take it seriously. Even if it is only a note, I don’t want it any weaker than if it was a rec.

Luc Audrain: +1 to Ivan

Laurent Le Meur: It’s a new issue with conformance issues that we’ll need to address. As for this being a note - i do agree that we can keep it as a working group note. At least for the year. It will help finalizing the audiobook profile and getting the first implementations of that. Once we have implementations we will be able to decide if we move to rec or not, and we won’t have lost time.

Luc Audrain: +1 to Laurent

Tzviya Siegman: So the proposal is that this becomes a working group note. Do we have a resolution on that?

Proposed resolution: Packaging-to-be-named format will be a WG Note (Tzviya Siegman)

Garth Conboy: +1

Ivan Herman: +1

Brady Duga: +1

Nick Ruffilo: +1

Tzviya Siegman: +1

Luc Audrain: +1

Wendy Reid: +1

Joshua Pyle: +1

Geoff Jukes: +1

Avneesh Singh: +1

Ben Schroeter: ++1

Laurent Le Meur: +1

Charles LaPierre: +1

Ric Wright: +1

Deborah Kaplan: +1

Benjamin Young: +0

Tzviya Siegman: OK - it is resolved.

Resolution #2: Packaging-to-be-named format will be a WG Note

Tzviya Siegman: the next issue would be about re-organizing the repo and renaming. We do need a name and short name but I don’t think it’s work a discussion - please submit any suggestions you have though.

1.2. proposed changes to 2.2

Laurent Le Meur: https://github.com/w3c/pwpub/issues/38

Laurent Le Meur: The issue opened by Ivan - 38 - This one is an easy one. It’s an extension of the wording in section 2. I made it very light originally (in 2.2) but Ivan would like it to have a bit more meat.

Ivan Herman: Let me explain. It’s mostly terminology. It’s an editorial question. The only difference — which is a technical difference — in the current document, the JSON-LD document has a fixed name. From the WPUB point of view, the entry page can point to any manifest.
… so if someone creates an audiobook with an entry page, they can name the manifest whatever they want. Technically speaking, this is the only thing that is a little bit different. Otherwise, I think it’s mostly editorial to make the text more firm.

Laurent Le Meur: it’s also about the renaming the PEP index.html and I totally agree. Personally, I agree, so I can put it in the draft.

Benjamin Young: I was going to ask for clarification on naming requirements.

Tzviya Siegman: Right now entry.html and mainfest.jsonld are required.

Laurent Le Meur: If you want the user agent to find them easily, then yes, but we can try to relax them as ivan proposed.

Ivan Herman: I think there is a 3rd one Laurent that may be worth discussing. Is it really necessary to have a separate section on relative URIs when there is already a section written in the WPUB document. There’s only one place it should be.

Laurent Le Meur: I’ll review the WP document and see if we can remove the additional one.

1.3. signature

Laurent Le Meur: https://github.com/w3c/pwpub/issues/31

Laurent Le Meur: There is one thing we could possibly discuss. Issue 31 about signatures. It seems there is a sort of consensus in OCF - there is a notion of signature in the package.
… Maybe it would be better to use MD5 or hash to the resources, and not pretend to sign the document. We have to choose between these two levels. We either want security for the node, or signature as an anti-hacking proof.

Tzviya Siegman: Wendy - was this one item you wanted to discuss as a larger issue?

Wendy Reid: Yes, this is a spec issue and not exclusive to audiobooks.

Tzviya Siegman: While it primarily effects packaging, it can be done in a non-packaged wpub, so it’s an issue that’s already on the wpub tracker.

Ivan Herman: related to https://github.com/w3c/wpub/issues/398

Dave Cramer: https://www.w3.org/TR/SRI/

Tzviya Siegman: Lets address this next week or the following week.

Laurent Le Meur: OK - we’ll see that later.

2. horizontal reviews

2.1. privacy and security

Tzviya Siegman: https://w3ctag.github.io/security-questionnaire/

Tzviya Siegman: Part of horizontal review is a security and privacy review. Does anyone want to volunteer to help filling out the questionnaire.
… If you feel you have expertise in this area, and you can help us fill that out - please let us know.

Dave Cramer: This is one of the things that worries me because this stuff does really require steeper expertise than any of us have. E.g., the fact that in CSS font-family names are a security risk doesn’t always occur to me. Stakes can be very high…

Luc Audrain: +1 to Dave

Tzviya Siegman: that’s the feedback that I’m providing to those redesigning horizontal review.

2.2. accessibility

Tzviya Siegman: Continuing on this topic - we need to do a formal review with the accessible group. It’s generally someone working closely with APA. If anyone is working with/for APA and you want to work with helping to get things done…

Charles LaPierre: I am with APA

Charles LaPierre: sure

2.3. internationalization

Ivan Herman: I wanted to report back that I’ve been hearing about internationalization and primarily directionality. It’s still pending. Up to now i have not been successful.

3. F2F agenda

Garth Conboy: https://docs.google.com/document/d/1-TB-_KCg97smmjcsbIVpi728qduOwESr3Og91-2Gtd4/edit

Garth Conboy: Tzviya and Wendy and I spent some time on a face-to-face document on Wednesday. We have some location information. There are 4 important sections to contribute to. Agenda item requests. Everyone should have edit rights. Do not delete other suggestions, please only add.
… there are two RSVP sections - one for remote, one for in person. Lastly, at the very bottom, there’s a point about dinner. If you’re up for sponsoring dinner, let us know.

4. Ben & Moustafa leaving

Ben Walters: Sorry for the long silence, it took us a while for us to figure out our next steps. I want to share that Moustafa and I have been reassigned and are now not working on books in edge anymore. The 2nd thing is that …
… edge is being re-imagined on top of chromium. That’s a big effort. Chromium doesn’t have native epub support, so the first version of the new edge will not support epub. But we are committed to it and we’re working towards that.
… Since we’re not actively working on ebooks, we will not be active in the group but we will be looking to recommend others to be joining who are active. Thank you for the good will and we’re sorry we have to leave.

Mustapha Lazrek: Thank you for having us.

Luc Audrain: thaks to you Ben and Mustapha

Garth Conboy: +1 — Thanks & sad.

Tzviya Siegman: Let us know how we can bring epub to chromium

Ben Walters: Well noted - we’ll pass that along. It’s been a pleasure and we’ve learned quite a bit from this experience. Thank you.

Tzviya Siegman: Thank you. And thanks for coming back to let us know.

5. Accessibility review (cont.)

Avneesh Singh: A note about the accessibility review. I invoked accessibility review a month before Lyon TPAC. In TPAC we had joint session of APA+PWG in which Janina Sajka (co-chair of APA) informed us that in a rapid review of WP specifications, she did not find anything alarming for accessibility. She said that a more thorough review should be done when specifications is near CR stage, and I should inform her at the right time. Moving forward, early this year we confined the WP specifications to a core, and extension of audio books is the major piece that is advancing. Therefore my focus is now more on audio profile, and I will open the accessibility issues regarding it.

Ivan Herman: avneesh & janina rock!

6. Resolutions