Publishing Working Group Telco — Minutes

Date: 2019-04-29

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Nick Ruffilo, George Kerscher, Rachel Comerford, Wendy Reid, Dave Cramer, Laurent Le Meur, Geoff Jukes, Teenya Franklin, Romain Deltour, Franco Alvarado, Gregorio Pellegrino, Jun Gamou, Avneesh Singh, Deborah Kaplan, Benjamin Young, Ric Wright, Ben Schroeter, Charles LaPierre, Marisa DeMeglio, Matt Garrish, Garth Conboy, Brady Duga, Joshua Pyle, Tim Cole

Regrets: Bill Kasdorf, Mateus Teixeira, Luc Audrain, Tzviya Siegman

Guests:

Chair: Garth Conboy

Scribe(s): Nick Ruffilo

Content:


Wendy Reid: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-04-15-pwg

Wendy Reid: First agenda item. Meeting minutes from last meeting. (4-15) Comments or questions?
… minutes approved.

Resolution #1: last meeting minutes accepted

1. packaging (LPF) format issues

Wendy Reid: Today we’re going to discuss packaging format - the “lightweight packaging format” Laurent - please take us through the issues to discuss

Laurent Le Meur: Hello! After the first time we discussed - i took the issues and modified the document with the results of the issues. I propose that we go through all of them. They should be no-brainers, so this should be quick to decide.

1.1. media type

Ivan Herman: link: https://github.com/w3c/pwpub/issues/29

Laurent Le Meur: I invite you to open reference #6 - the lpf light document. The first issue is issue #29 - we need to decide on the media type of the format. We want to use application-lpf+zip since lpf is lightweight packaging format, the +zip is that the underlying format is zip
… It was discussed - but are there any comments on this proposal?

Proposed resolution: media-type: application/lpf+zip, extension: .lpf (Ivan Herman)

Geoff Jukes: +1

Laurent Le Meur: +1

Nick Ruffilo: +1

Jun Gamou: +1

Ivan Herman: +1

Ric Wright: +1

George Kerscher: I’m assuming there are no conflicts with this extension on the various operating systems where they are registered?

Dave Cramer: https://filext.com/file-extension/LPF

Laurent Le Meur: I looked at the list, and it was only used in a very obscure way, and it wasn’t registered. Do you know of an open list of media types that we can check?

Rachel Comerford: 0 - I don’t understand the impact clearly enough to vote

George Kerscher: I don’t know, but I just recall how long it took to get epub recognized by the various browsers so that it would download. As long as there are no conflicts.

Dave Cramer: I had a similar question to George - the only LPF I find is unrelated and not widely used, so i think we’re pretty safe

Garth Conboy: +1

Geoff Jukes: FYI https://www.iana.org/assignments/media-types/media-types.xhtml

Laurent Le Meur: also found the obscure https://assiste.com/Types_de_fichiers/Extension_LPF.html

Wendy Reid: Any additional votes for the media-type application/lpf+zip and extension: .lpf ?

Ben Schroeter: +1

Gregorio Pellegrino: +1

George Kerscher: +1

Dave Cramer: 0

Brady Duga: 0

Deborah Kaplan: 0

Charles LaPierre: 0

Matt Garrish: 0

Marisa DeMeglio: 0

Resolution #2: media-type: application/lpf+zip, extension: .lpf

1.2. entry.html

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

Garth Conboy: The next item in line is issue #42 -> changing the name of the primary entry page from entry.html to index.html. Quickly looking at the comments -> Laurent?

Laurent Le Meur: we’ve seen the comments. It was opened by Dave, but there is agreements in the comments - any comments here?

Geoff Jukes: +1

Proposed resolution: go with index.html (Garth Conboy)

Garth Conboy: +1

Brady Duga: 0

Nick Ruffilo: Ivan - flip that

Ivan Herman: +1

Benjamin Young: +1

Matt Garrish: 0

Wendy Reid: +1

Geoff Jukes: recount!

George Kerscher: +1

Ric Wright: +1

Charles LaPierre: +1

Laurent Le Meur: +1

Ben Schroeter: +1

Rachel Comerford: +1

Deborah Kaplan: +1

Nick Ruffilo: +1 to index.html as entry page

Romain Deltour: +1

Resolution #3: go with index.html

Franco Alvarado: +1

Garth Conboy: This one is resolved.

1.3. Renamed the required manifest.jsonld to publication.json

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

Laurent Le Meur: Next is #43 - rename the manifest jsonld to publication.json

Ivan Herman: From a JSON LD point of view, either is fine. The original comment is about avoiding using the word manifest - which is used all over the place

Proposed resolution: go with manifest.json (Garth Conboy)

Ivan Herman: +1

Garth Conboy: +1

Laurent Le Meur: +1

Joshua Pyle: +1

Deborah Kaplan: +1

Benjamin Young: The proposal says go with manifest.json - but the issue is about renaming it to publication. So the proposal should be to use publication.json…

Proposed resolution: Go with publication.json (Garth Conboy)

Brady Duga: +1

Nick Ruffilo: +1 to publication.json

Geoff Jukes: +1 to publication.json

Ben Schroeter: +1 to use publication.json

Ric Wright: +1

Benjamin Young: +1 to publication.json

Charles LaPierre: +1

Joshua Pyle: +1 publication.json

George Kerscher: +1

Wendy Reid: +1 to publication.json

Rachel Comerford: +1

Garth Conboy: Resolved…

Resolution #4: go with publication.json

1.4. Allow signing the components of a package

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

Laurent Le Meur: Issue is #31 - proposal is to do nothing.
… In OCF there was a signature and a definition about not using something complex - but to use hash mechanism of resources as a way to show completeness

Proposed resolution: Don’t define a signature mechanism (certainly not signature.xml!) (Garth Conboy)

Laurent Le Meur: it seems we do not need to define any additional information

Garth Conboy: +1

Joshua Pyle: +1 to no signature mechanism

Laurent Le Meur: +1

Garth Conboy: I put a proposal matching what laurent just said.

Nick Ruffilo: +1 to no signature mechanism

Brady Duga: +1

Dave Cramer: +1

Dave Cramer: I would note that epub has this mechanism but the community group was opposed to putting any requirements on this - so you could have an invalid signature and things still display to the reader…

Ben Schroeter: +1

Ivan Herman: +1

Ric Wright: +1

Resolution #5: Don’t define a signature mechanism (certainly not signature.xml!)

Deborah Kaplan: +1

1.5. Relative IRI-s section in the LPF document

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

Laurent Le Meur: Next - 37 - proposed by Ivan. The rewriting of the section about IRI. Section 2.3. Ivan has proposed to rewrite something simple, and I proposed to remove IRI and use URL instead, even if IRI are valid - but no one is using it…
… everyone understands a URL. Relative URLs would be the target language. There was a reference to RFC, but we removed it… I think the text that is now in 2.3 is sufficient in what we want to express.

Ivan Herman: To make it easier, and Matt is on the call, we make a reference from the packaging document to wpub - because in wpub there is a longer description of this. There is also a reference with a longer comment in the reference to URLs in the HTML spec. There is a mess about this term and a longer description in the HTML spec at the end to say “we use URL which may include other uses” so it’s taken care of.
… essentially what the web publication document does is say we won’t redefine the wheel - in that chain, the lpf document refers to the HTML one.

Romain Deltour: for the record, the Web Pub section on URLs in the manifest: https://www.w3.org/TR/wpub/#value-url

Romain Deltour: I was going to ask about what was meant about following the rules? This refers to the specific paragraph about URLs - in part 1 publication manifest. We should be more specific and link out.
… the other point is that it leads to a question about web publications and the relationship to the manifest and canonical manifest (which is authoritative). In the canonical manifest, all the URLs are made absolute. So what we see are a serialization of a manifest.

Benjamin Young: I was hoping someone was more qualified is available, but it takes us back to the IRI note - Japan and other cultures, less restricted to 26 characters, do use IRIs to represent their URLs. Whether that’s necessary in spec language is orthogonal, but we shouldn’t dismiss it…
… it’s heavily used elsewhere, but maybe not where we are. Specifically - what processing and parsing algorithm, as there is a host of them. The HTML one is fine for what it is, but it assumes a browser context and in the case of an audiobook, may not come with the same constraint…

Benjamin Young: URI 3986 https://tools.ietf.org/html/rfc3986

Benjamin Young: which could introduce more things - so the URI spec might be better.

Jun Gamou: In Japanese web, I believe using only URL is fine enough.

Ivan Herman: https://www.w3.org/TR/html52/references.html#biblio-url

Ivan Herman: I put in IRC a reference here. This is the normative reference. There is a reference to URL - then a very long note (somewhat unusual) about URL and all the various terms. I think as far as we are concerned, we should accept whatever the HTML spec does. The HTML spec is used in japan.
… if it works for users in general, we should just say “this is what we do.”

Garth Conboy: That seems sensible - does anyone have a different view?

Ivan Herman: As far as I remember, this is what we refer to in the web publication document. And explicitly we can refer to this note. The LPF document shouldn’t point to anything more than what is done in the web publication doc.

George Kerscher: this is for my lack of understanding - when we say absolute URL, we’re talking about www.something.com/whatever but when it’s in the package and unzipped, isn’t it necessary to use a relative URL in order to consume that file?

Ivan Herman: This comes back to the question from Romain - a relative URL is relative to the canonical URL, which is doable. On the other hand, you might have an absolute URL which refers to a file that is relative. Both should be OK for a reading system.
… this is not a perfect answer because the canonicalization gives absolute URLs - which might refer to the same area.

Benjamin Young: This is in a package, distributed into a device with or without device - there are absolute URLs that are different than what the system will have locally. The system will not know that things map together…
… a relative URL in a zip file would should relative items.
… the related thing in JSON LD which could solve for this - it’s called @base and it’s a way to include in the JSON LD what you are relative to. This introduces a way to have all urls relative to a specific value - but then locally if that isn’t there, then the processing system isn’t there.
… so it could also be used to turn the filesystem into a related url set…

Nick Ruffilo: If we use the root - such as localhost/ and everything builds off that - wouldn’t URLs all be absolute? If items are relative - could there be an issue of accessing items outside of the file itself… Would the file URL base be the origin? So - could the file itself be considered similar to using a localhost server

Brady Duga: It is dangerous to conflate “localhost” and opening a local file. In the first case, we are opening a file from a server that happens to have a well known ip address, and any file opened that way will have the same origin. In the second case, we have a local file that will have a different origin than other files opened the same way

Ivan Herman: Let step back a few levels here - I think that it is correct what Romain said - that canonicalization requiring the absolutization of the URL may create problems here. Because the canonicalization is in fact a series of specs to make clear what the user agent has to do with the information…
… there is nothing imposed there. I may propose that we raise an issue that the absolutization step should be removed from the canonicalization but maybe try to use what benjamin noted - so what Benjamin does is clear…
… then a packaging environment can go happily. I still believe this is not something that should be defined by us. The lightweight packaging format should refer to the web publication - then the responsibility to properly describe it is in the web publication document.

Romain Deltour: there is potentially another issue related to all that - which may not be resolved by removing absolutization. When it comes to obtaining a manifest, and the origin of the entry page. At some point we will have to modify the algorithm, or define the origin of the lightweight package.

Laurent Le Meur: I don’t think we can define the origin within the package. it’s when the package is put somewhere and exposed - it’s up to the publisher/distributor to define the origin of the web publication. The package itself has no origin.

Romain Deltour: I think we then have to define the rules how a user agent may or must define the origin of a package. These give a lot to the user agent, and unless we define it we will have interoperability issues.

Ben: I wanted to continue what Romain said - the origin isn’t something the publisher decides, it’s the user agent. On the web, it’s related to where you hit the thing, but the origin is restricted to a space defined by the user agent. We have the origin spec to determine what to do with that.
… in the case of something opened out of a zip file - there is a defined origin for that. Because zip file could be used within an android app and unpackaged - they are going to create their own origins, then create a space of null origin where it’s heavily (or un) restricted
… and the developers need to know what they can/should do. We haven’t said that the manifests in the package are restricted to what is in the package - for example, it could bull in data from outside the package and from the web.

Garth Conboy: We wanted to get through more, but not sure we can push through this.

Dave Cramer: I wanted to emphasis what Romain and Benjamin just said - this is a problem we need to solve and is key to security. We can’t end up where there is not an origin and we have issues like in epub.

Garth Conboy: Given that, can we say the changes made in LPF should point back to WP
… Can we agree on this at this stage? That is where the LPF spec is in the current draft.

Proposed resolution: LPF draft is okay as (with deep link added), additional issues to be raised in WP. (Garth Conboy)

Laurent Le Meur: I can try to add a deep link to the proper section in the web specification - a link to 2.6.3.3 but I don’t really know the best way to do it. Maybe I would need some advice.

Proposed resolution: LPF draft is okay as is (with deep link added to WP), additional issues to be raised in WP. (Garth Conboy)

Romain Deltour: -0.5

Nick Ruffilo: +1 to move language and table conversation

Ric Wright: +1 to tabling. Too many questions

Romain Deltour: (-0.5 because it’s likely that the origin issue will need to be addressed specifically in the LPF)

Laurent Le Meur: in section 3 - maybe it would be there we express that the user agent exposes a package as a web application, it has to decide what the origin is of the web publication. It’s not an issue of web publication, but processing a package when it becomes a web publication…
… so it’s related to packaging…

Garth Conboy: There seems to be lots of votes for tabling for next week in Boston. Then we do need to have some time for F2F logistics

Summary: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (Ivan Herman)

Garth Conboy: +1

Ivan Herman: I agree with Tabling - whatever semantics we use on it. Those items are the 3 that came up that we have an agreement on that we need to discuss.

Romain Deltour: +1

Ivan Herman: We will have to discuss origin VS packages. Not sure what document - I have no idea what should be put there yet. Maybe both should be separate issues?

Proposed resolution: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (at F2F) (Garth Conboy)

Garth Conboy: +1

Ivan Herman: +1

Laurent Le Meur: +1

Garth Conboy: I’m turning your summary into a proposal - then we’ll revote

Romain Deltour: +1

Tim Cole: +1

Nick Ruffilo: +1

Joshua Pyle: +1

Ric Wright: +1

Garth Conboy: Do we have time for 1 more?

Resolution #6: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (at F2F)

1.6. First-class citizenship of resources in PWPs

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

Laurent Le Meur: Issue 5 - if we summarize - there was an ask that any resource should be addressable via URI/URLs - that’s what we’ve done in the wording

Proposed resolution: Existing text resolved this. (Garth Conboy)

Garth Conboy: +1

Laurent Le Meur: +1

Ivan Herman: +1

Geoff Jukes: +1

Nick Ruffilo: +1

Joshua Pyle: +1

Ric Wright: +1

Resolution #7: Existing text resolved this.

Ivan Herman: before we move to the next topic - i have an admin question for Laurent - When I clean up the minutes, I’ll put in comments on all the resolutions, which means most of the issues can be closed. Will you close them when you have them in the document?

Laurent Le Meur: I can close them - but there is one that requires additional action.

Garth Conboy: Lets take 38, 17, and 40 which we can discuss in Boston

2. F2F practicalities

Garth Conboy: https://docs.google.com/document/d/1-TB-_KCg97smmjcsbIVpi728qduOwESr3Og91-2Gtd4/edit#heading=h.9kn2s1bey23f

Garth Conboy: let’s take 1-2 minutes to talk f2f stuff. It’s very close to the RED line at the Kendall MIT stop. The logistics are in the document.


3. Resolutions