Publishing Working Group Telco — Minutes

Date: 2017-12-04

See also the Agenda and the IRC Log

Attendees

Present: Luc Audrain, Ivan Herman, Deborah Kaplan, Dave Cramer, Tzviya Siegman, George Kerscher, Avneesh Singh, Romain Deltour, Baldur Bjarnason, Tim Cole, Wolfgang Schindler, Toshiaki Koike, Lillian Sullam, Jun Gamou, pkrka, Peter Krautzberger, Benjamin Young, Jasmine Mulliken, Chris Maden, Nick Ruffilo, Marisa DeMeglio, Jeff Buehler, Garth Conboy, Ben Schroeter, Rachel Comerford, Leslie Hulse, Harriett Green, Brady Duga, Hadrien Gardeur, Evan Owens

Regrets: Vladimir Levantovsky, Joshua Pyle, Matt Garrish

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Tzviya Siegman: First and foremost - do we have the new members on the call?

1. New members

Jeff Buehler: My name is Jeff and I just joined. I sent out the introductory email to the group. I am looking forward to learning more about what you’re doing on WP and PWP.

Jasmine Mulliken: I’m Jasmine Mulliken, Stanford university press - I sent out a welcome email. We have a melon grant to publish digital online content, so I’m here to contribute to the conversation about what a web publication is.

2. Last week’s minutes

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

Tzviya Siegman: First lets approve the minutes from last week - are there any comments?

Resolution #1: meeting minutes accepted

3. FPWD for WP

Tzviya Siegman: https://w3c.github.io/wpub/

Tzviya Siegman: Minutes approved. This week we are working towards first working draft. Matt is not here to comment. Lets take a look at the web-pub document. Our goal for this document as well as Locators is to get it into a state where we can put a freeze for now and along with the PWP document - get it into a state so that we can publish as soon as the moratorium on publishing is lifted. We’re going to get everything ready and publish the three documents together - so we want it all ready for the first week of January.
… This is the opportunity to comment on this. What we mean by a freeze is that - with this document as well as PWP and locators - we have issues (intentionally) this is publishing to invite people to comment and discuss. We know there are open issues - this is not meant to solve everything, we have two more years. This is putting bait out to bring in the fish. We want to invite people to come in and discuss these. Editorial, Rachel added a great image…

Tzviya Siegman: What we need today is a resolution to publish. Then we need a call for consensus, then we’ll be into the moratorium period. Any questions?

7:10:1: <NickRuffilo> …: Can we resolve to publish this?

Proposed resolution: The WG decides to publish the current WP document as a FPWD, with the short name ‘wpub’; expected publication detail jan 4, ‘18 (Ivan Herman)

Ivan Herman: +1

Deborah Kaplan: +1

Rachel Comerford: +1

Tim Cole: +1

Wolfgang Schindler: +1

Luc Audrain: +1

Ben Dugas: +1

Tzviya Siegman: +1

Peter Krautzberger: +1

Garth Conboy: +1

Nick Ruffilo: +1

Jun Gamou: +1

Benjamin Young: +1

Harriett Green: +1

Garth Conboy: +1 (george)

Romain Deltour: +1

jbuehler: +1

Ben Schroeter: +1

Dave Cramer: +.9

Nick Ruffilo: PI

Marisa DeMeglio: +1

Jasmine Mulliken: +1

Resolution #2: The WG decides to publish the current WP document as a FPWD, with the short name ‘wpub’; expected publication detail jan 4, ‘18

Tzviya Siegman: Looks like we have consensus to publish this. Very good, that went very smoothly. Excellent. We will add a security section but Baldur has not added it yet. Lets move on to the Locators document.

4. Locator document for FPWD

Tim Cole: https://w3c.github.io/publ-loc/

Tzviya Siegman: Same process for this document. Tim has done more work.

Tim Cole: After last week’s call we made a change to fragment identifiers. We reduced the potential places where you would replace JSON with the fragment. Except for the embedded resource identifier. If you have an ID consisting of two or more files - and you wanted to reference one component of that document. We wanted to provide a way to do that using a fragment identifier. We took from the epub CFI model - the model is there and explained reasonably well - much shorter than the old fragment ID. We also had placeholders for security and privacy - but we’ll work on that in January. It still has a half dozen issues called out in the draft, but most of those revolve around use-cases for the selectors so that they make more sense. I think otherwise we are in good shape. If there are any questions about fragment identifiers, let us know, otherwise we’re ready to go.

Jeff Buehler: I’ve seen a few things addressed to me, but i want a better knowledge of what was written before providing comments. Lots of JSON being used as a data model, which is fine, but I find that interesting and want to learn more.

Tim Cole: This was pulled from a previous WG - and yes, there was a decided decision to use JSON - probably because it’s what they did and lets you do more than with a fragment ID.

Jeff Buehler: JSON seems OK - and I know quite a bit of developers who see that as program-eze, but not developers might have to learn a bit.

Proposed resolution: The WG decides to publish the current Locator document as a FPWD, with the short name ‘publ-loc’; expected publication date jan 4, ‘18 (Ivan Herman)

Ivan Herman: +1

Tzviya Siegman: +1

Garth Conboy: +1

Tzviya Siegman: It sounds like there are no formal questions - so proposed: lets vote on publishing.

Rachel Comerford: +1

Benjamin Young: +1

Nick Ruffilo: +1

Wolfgang Schindler: +1

Dave Cramer: +1.01

Tim Cole: +1

Deborah Kaplan: +1

Harriett Green: +1

jbuehler: +1

Lillian Sullam: +1

Jun Gamou: +1

Deborah Kaplan: +1

Evan Owens: +1

Ben Schroeter: +1

Jasmine Mulliken: 0

Jasmine Mulliken: My neutrality is simply not being familiar. So I’m not completely certain what it applies to. I’m not opposed, just don’t know enough.

Resolution #3: The WG decides to publish the current Locator document as a FPWD, with the short name ‘publ-loc’; expected publication date jan 4, ‘18

Tzviya Siegman: We have resolved to publish. The next item is review - and hopefully closing - issues that remain on the PWP repository.

5. Reviewing/closing PWP issues

5.1. Issue no. 9

Dave Cramer: Github: https://github.com/w3c/pwpub/issues/9

Tzviya Siegman: The two big issues remaining are issue 6 and 9. If you look through here - there’s a comment where Dave Wood proposes some working definitions. Proposal: ‘A PWP is a single resource…’ … There was some nit-picking, but it seems like we agree on a majority of the items. Did we have a final resolution?

Garth Conboy: https://github.com/w3c/pwpub/issues/9#issuecomment-347881185

Tzviya Siegman: We wanted to combine ‘may be published on the web’ and ‘need not be published on the web’ into one item.

Garth Conboy: I thought that what Matt proposed was what people were agreeing on. It’s similar to what you read.

Ivan Herman: Proposed text: “A Web Publication that has been packaged into a single information resource, enabling it to be transported and stored independent of any specific address or protocol. A Packaged Web Publication is typically constructed from a published Web Publication (i.e., one that has a specific URL and is accessible via HTTP), but this is not a requirement. Similarly, it is possible to unpack a Packaged Web Publication and publish it as a Web Publication, although there are practical limitations to this (e.g., re-publishing cross-domain resources will require access to all the domains).”

Garth Conboy: In the comment pasted above - it has web publication defined as (you can read comment above)

Tzviya Siegman: On github people have mostly agreed on this - but lets check with all - is this what we’re agreeing on?

Jeff Buehler: One of the obvious things is that all resources are available to the package.

Garth Conboy: There’s a concept of a spine - and then secondary resources, the ones that are part of the publication. The primary and secondary would be in the Packaged part, but there can still be external resources. Such as a link to Wikipedia - which wouldn’t be included.

Ivan Herman: The other typical example, Jeff, is referring to a specific font. The situation is that - in some cases you do not wish to include the font. The reader might provide a fallback, but that is an example of a resource that isn’t part of the package but is used.

Jeff Buehler: OK - this is a central issue in the work I’m currently doing. We work with lots of clients who have video, which breaks the epub3 spec. PDFs or other resources that are outside of the EPUB3 spec. So it’s of real interest to me.

Garth Conboy: Epub3 allows video resources to be external…

Jeff Buehler: You are right, but PDF gives you errors

Garth Conboy: : https://github.com/w3c/pwpub/issues/9#issuecomment-347881185

Garth Conboy: So, is this a fine definition? Any comments?

Proposed resolution: Accept the comment above as the definition for PWP for now (Ivan Herman)

Garth Conboy: +1

Ivan Herman: +1

Tzviya Siegman: +1

Nick Ruffilo: +1

Wolfgang Schindler: +1

Resolution #4: Accept the comment above as the definition for PWP for now

5.2. Issue no. 6

Garth Conboy: https://github.com/w3c/pwpub/issues/6

Dave Cramer: github: https://github.com/w3c/pwpub/issues/6

Garth Conboy: https://github.com/w3c/pwpub/issues/6#issuecomment-347396713

Tzviya Siegman: Issue 6 now - Now that we have a working definition, Hadrien started an issue around listing requirements. Most can be resolve by pointing to what was said in issue 9.

Hadrien Gardeur: I think the issue is about the requirements - not necessarily the definition. I like the proposal that was rephrased, but it’s separate from a definition, so it’s still useful. We should extract something out of it, not replace it with the definition

Tzviya Siegman: garth’s proposal https://github.com/w3c/pwpub/issues/6#issuecomment-347396713

Garth Conboy: I agree, it’s different than a definition and it’s appropriate for inclusion in the first public working draft.

Tzviya Siegman: I think the requirements can be different from the working draft. I posted a link (above) to what Garth proposed.

Tzviya Siegman: https://www.irccloud.com/pastebin/3vRnKT3R/

Ivan Herman: For the minutes, the proposal:

  • MUST contain a WP manifest at a well-known location (e.g. manifest.json)
  • MUST contain all resources that are part of the publication (reading order + secondary resources)
  • MAY contain additional resources that are referenced by the publication (for example a metadata record in a different format)
  • MAY contain the request & response HTTP payloads for each resource

Tzviya Siegman: Do we have any comments on these?

Garth Conboy: Ship it!

Wolfgang Schindler: What’s the advantage of the 4th bullet point? Do we need it?

Garth Conboy: Though in this case I think it’s important that such support is available, though not required.

Hadrien Gardeur: There is a number of HTTP header information that is important. This is something necessary for the implementation in many cases. For a format like web-packaging, to support offline reading (which is almost exactly the same as packaged) you need the response. You need the request and the response as they go hand in hand - for the service workers… There is information and it’s needed for implementation

Ivan Herman: I disagree with some things here. There is information that’s useful, but is the whole HTTP payload - which may include a number of things that are totally irrelevant. The spec - the number of possible headers is HUGE. For the first working draft, it should be fine, but my preference is to make explicit which items in the HTTP request/response - that in some way in other - must be made available. The way described here is a number of unnecessary things.

Garth Conboy: Even though I see a queue, I resolve we discuss later.

Baldur Bjarnason: We need HTTP for full compatibility with web-stack. If we leave that out of packaging, we’ll have quite a few situations where a packaged web publication will act much differently than a regular web-publications. A host of things, especially around javascript… We’re trying to encompass all the possible interactions. It’s more complicated to leave it out than it is to support it.

Hadrien Gardeur: +1 with what Baldur said

Ivan Herman: Can we at least say - that we refer here only to the standard HTTP verbs? We don’t have to include the extension verbs simply because a server users them and sends them back?

Hadrien Gardeur: There might be a few extras, but it shouldn’t be that bad.

Ivan Herman: We should create a separate issue that looks only at this. If we include everything or just cherry pick from the header. And we flag this as something to discuss

Tzviya Siegman: So we’re agreeing on the first 3 bullets - and we’re adding a new issue to discuss the 4th

Garth Conboy: I recommend we agree on the 4 then attach the issue to the 4th

Hadrien Gardeur: I’ll also open some issues about a dedicated media type and file extension

Ivan Herman: A media type often gets a file extension - so you may not need both

Proposed resolution: Agree on those four bullet, add a new issue exclusively on the HTTP and refer to it (Ivan Herman)

Garth Conboy: +1

Nick Ruffilo: +1

Tzviya Siegman: +1

Wolfgang Schindler: +1

jbuehler: +1

Ivan Herman: +1

Baldur Bjarnason: +1

Tim Cole: +1

Ben Dugas: +1

Deborah Kaplan: +1

Jasmine Mulliken: +1

Hadrien Gardeur: +1

Jun Gamou: +1

Romain Deltour: +1

George Kerscher: +1

Resolution #5: Agree on those four bullets, add a new issue exclusively on the HTTP and refer to it

6. AOB

Tzivya: Reminder - we are meeting next week, and the following, then we’re off for two weeks

Ivan Herman: I have a question - if I understand, we’ll have a call later with David. Then what will you try to get out of him in terms of when the first public working draft vote will come?

Tzviya Siegman: Hopefully before next week he will have something, but it might be longer, but it will be next week or the following.

Ivan Herman: I have to submit a transition request on the week of the 11th the latest.

7. Resolutions