Publishing Working Group Telco — Minutes

Date: 2019-01-28

See also the Agenda and the IRC Log

Attendees

Present: Tzviya Siegman, Ivan Herman, Deborah Kaplan, Luc Audrain, Nick Ruffilo, Evan Owens, Dave Cramer, Romain Deltour, Wolfgang Schindler, Ric Wright, George Kerscher, Gregorio Pellegrino, Benjamin Young, Avneesh Singh, Garth Conboy, Bill Kasdorf, Derek Jackson, Franco Alvarado, Ben Schroeter, Joshua Pyle, Caitlin Gebhard, Brady Duga, Mateus Teixeira, Leslie Hulse

Regrets: Marisa DeMeglio, Rachel Comerford, Wendy Reid

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

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

Tzviya Siegman: Minutes approval. Any comments from 2 weeks ago minutes?
… Minutes approved.

Resolution #1: last week’s minutes approved

Tzviya Siegman: https://pr-preview.s3.amazonaws.com/w3c/wpub/pull/394.html

1. WPUB revision/republication

Tzviya Siegman: Next topic: we’ve had some revisions thanks to Matt. We want to formally approve the WP revisions and we want to finalize the merge. Matt is at the Toronto Accessibility meeting.

Ivan Herman: I can talk about what he did… As we had the discussion about the topics for the coming year — that was 3 weeks ago. We agreed that the main draft document would describe the manifest only…
… it would have a section on affordances, etc. What this PR did — was that. He made all the necessary changes so that the draft is in line with the agreement that we made a few weeks ago. What we would also like to do is have an approval here.
… that we would formally publish this as a working draft so that it will be an official version as well.

Tzviya Siegman: https://github.com/w3c/wpub/blob/master/explainers/wpub-explainer.md

Tzviya Siegman: as Garth pointed out, we also updated the explainer. We don’t need a formal approval on it, but there is a formal update if you want the short version of this. We do need a formal vote on the draft, not the explainer.
… If you approve this going to the next version of a working draft, then do a +1, 0, -1

Ivan Herman: +1

Deborah Kaplan: +1

Garth Conboy: +1

Tzviya Siegman: +1

Wolfgang Schindler: +1

Luc Audrain: +1

Nick Ruffilo: +1

Franco Alvarado: +1

Bill Kasdorf: +1

Joshua Pyle: +1

Dave Cramer: +1ish

Caitlin Gebhard: +1

Gregorio Pellegrino: +1

George Kerscher: +1

Derek Jackson: +1

Ben Schroeter: +1

Avneesh Singh: +1

Ric Wright: +1

Resolution #2: publish the last version of the WP draft on /TR

Tzviya Siegman: Seeing no 0s or -1s, we can send this next version out as a public working draft…

1.1. TAG review

Dave Cramer: Since Garth mentioned the explainer, one of the purposes is to get feedback from the TAG. Do we have a plan for reaching out to the TAG?

Tzviya Siegman: Now that we have the explainer in a pretty clear shape, I think we’re in pretty good shape to go to the TAG.

Ivan Herman: My feeling is Yes. But… If we have an agreement on what is now the lightweight-packaging-format — something more documented. That would help. But if that will take several weeks, then we shouldn’t wait….
… but if we can include that it would help.

Tzviya Siegman: That’s our next agenda item — assuming we get to it and can document it at least in the explainer — it would be in PWP — hopefully we’ll have that to give to the TAG.
… IIRC, the TAG asks for a heads up about this — so I can take it on as an action item to open up the GITHUB item as a heads up for them.

2. packaging

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

Tzviya Siegman: The next item is packaging. Wendy did a nice summary — but since the last meeting we’ve defined success criteria. Here is the issue with success criteria. Those who attended the AB publishing meeting, we got to see how things stand with packaging.
… we got info about the HEIF format — and Dave did a presentation on OCF-lite. We heard from the Chrome team about the current incubating format that google proposed. All that said, we have the success criteria put out.
… We are all but agreed agreed on OCF-Lite — but that’s a bad term for it because it’s possibly misleading…

Dave Cramer: I have a question about what we are specifying — it came up in a packaging thread. There is an ISO standard that basically is very close to being a subset of ZIP that OCF uses. It mentions restricting the types of compression — it has an appendix on restricting filenames…
… it’s also oddly, for an ISO standard, you can get the PDF without paying a bunch of Swiss franks. I think it would be good if we didn’t copy a whole bunch of text from OCF, but borrowed things that work like folder locations…

Tzviya Siegman: Dave — so you’re in favor of using a restricted format of ZIP instead of rewriting a spec?

Dave Cramer: I’m worried that we have an OCF spec, and we could be normatively adding more items. If we’re saying we want to use ZIP the ISO zip has some nice items in there.

Dave Cramer: https://www.iso.org/standard/60101.html

Dave Cramer: which is ISO/IEC 21320-1:2015

Garth Conboy: I think we could probably make — I don’t disagree with Dave — I think we could make a resolution to do something like OCF-Lite. Whether built up from the ISO Zip or down from OCF — I think we’re in the same neighborhood.
… One decision is about creating compatibility with meta-inf. We’re in the neighborhood that we want to use something zip based with minimal restrictions. We can probably resolve that now and there is some work to do if it’s build up or build down.

Nick Ruffilo: .. but we could resolve if it will work for audiobooks, but maybe other profiles for different uses of WP…

Ivan Herman: +1 to Garth

Laurent Le Meur: I’m not against the ISO standard as a base, but there are several items to discuss. the ISO 21320 spec only prohibits some characters — the OCF original prohibits other characters — so it’s not 100% compatible. In the ISO standard, there is a table that says that digital signatures is not allowed…
… but is not described in the OCF. It won’t be enough for a packaging mechanism, we need to specify what the name of the manifest file is — so we have some details of packaging that needs to be described that won’t be in the ISO spec. This is why in the draft I made before, I had chosen to copy the OCF spec and remove things.
… even if I make reference to the ISO spec, most of the language that is there will still be there.

Ivan Herman: First of all — accepting what Laurent had said — it will put our document/work on a more solid basis if it was based on ISO spec. It should be a starting position. Whether we want to be compatible with OCF on characters — we can go through that…
… The starting position should be the ISO — it will help in talking with TAG and others. The original reason I was on the queue is that our position goes — whatever we define here is not to define specifically and exclusively for audiobooks.
… whatever we do, we should try to be as generic as possible. If tomorrow, another profile comes up that is similar to audiobooks — manga came up — the starting position should be that the document Laurent creates is a lightweight format for publishing in general, which happens to be used by audiobooks.

Nick Ruffilo: +1

Tzviya Siegman: +1 to ISO

Laurent Le Meur: +1 to a generic packaging format for WP

Bill Kasdorf: +1 to Ivan

Wolfgang Schindler: +1 to Ivan — generic packaging format for WP

Garth Conboy: I would agree with that. I didn’t mean to imply it was only audiobooks, but that there could be more formats in the future. If we have to dream up another name, we can. We can get to what Laurent drafted by building up from the ISO spec…
… we clearly will have to have a well-known place for the manifest. I hope that we can say we are building a lightweight zip format based upon the ISO spec with additional restrictions and rules for WP

Laurent Le Meur: If agreed, I can modify the draft to reflect that…

Proposed resolution: PWG will adopt a light-weight version of Zip, based on https://www.iso.org/standard/60101.html, with some restrictions and additions for WP (Tzviya Siegman)

Tzviya Siegman: I think we should talk about if we need a stand-alone document

Ivan Herman: There are things we need to describe somewhere, so we need to have a document for this. Where you find the manifest, etc. It may only be one page but it must be there.

Ivan Herman: +1 to the proposal

Garth Conboy: +1 to proposal (too)

Wolfgang Schindler: +1 to the proposal

Dave Cramer: Just thinking about Tzviya’s comment about what we need for a document. OCF is 2 specs — there is an OCF abstract container, and then the zip container. The later includes all the ISO stuff, the former is ‘everything has to be the same folder and you have to put a container.xml here’
… not sure how we move the abstract container stuff into our spec…

Laurent Le Meur: +1 to PWP…

Laurent Le Meur: PPWP for Pragmatic PWP

Luc Audrain: +1

Tim Cole: +1

Tzviya Siegman: we do have a document — that is a shell — PWP — packaged web publications — that way we get around writing a package document. We have the information associated with packaging — anything else — but Matt might get annoyed if we change the short title.

Ivan Herman: +1 to dauwhe

Dave Cramer: My concern about putting this under PWP — will this make it feel like we’re rejecting all other attempts at the web for doing packaging?

Garth Conboy: When I typed PWP I almost typed “profile 1” but I am sympathetic to Dave’s comment. We can be clear that “this is what we’re doing now, we hope to use it in the future, but it’s not a hard decision that there won’t be another format in the future”

Ivan Herman: That’s why there was an email where we set up the limits and milestones for the upcoming year as a “lightweight packaging format”. There might be a heavyweight coming in the future, but I agree with Dave. We should be careful. I’m cautious using PWP.
… We have talked too much about it being all the solutions to the miseries of the world, so coming up with this will lead to ugly discussions.

Tzviya Siegman: +1

Laurent Le Meur: +1 to the vote

Tzviya Siegman: the document we’re talking about is very short — Light Weight Packaging Format.

Joshua Pyle: +1

Bill Kasdorf: +1

Wolfgang Schindler: +1

Mateus Teixeira: +1 to proposal

Nick Ruffilo: +1

George Kerscher: +1

Gregorio Pellegrino: +1

Resolution #3: PWG will adopt a light-weight version of Zip, based on https://www.iso.org/standard/60101.html, with some restrictions and additions for WP

Tzviya Siegman: Moving on — what are our next steps?

Laurent Le Meur: I have to modify the draft, remove everything about the characters. Replace that will reference to the ISO zip format. Rename what is PWP inside this document — we can use something like LWPF until we choose a final name. I can keep it as ocf-lite but we can rename it to something else when we chose the name..
… no one will see PWP, but next week would be good to chose a final name.

Ivan Herman: Great! A question we will have to decide is whether this document is on a Rec track or not. The ISO part makes this much easier. That means the only thing we have to test as part of the CR procedures are the ones we add — not the packaging/unpackaging. Which is very helpful.
… We will have to decide if it’s rec track or not. Personally I think it should be a rec track document.

Tzviya Siegman: I think referencing the ISO document makes it much shorter. The only things needed in our document are adjustments — so it becomes very slim.

Laurent Le Meur: but there’s no mention of font obfuscation, but still there is an issue where we have to discuss that…

Tzviya Siegman: For now, leave it out, we can add it later…

Dave Cramer: as someone who has spent too much time with the OCF spec, I hope we can write something clear about what is expected from authors and user-agents. OCF is a bit loose about what is happening with packaging

Laurent Le Meur: as a first step for next week, we should discuss which kind of template or reading system behaviour. There are many ways to specify the user agents, so I would like some input from the group on which kinds of writing we should put.

Tzviya Siegman: There will be a placeholder in the explainer — and we can work on getting the document drafted in the next few weeks

Nick Ruffilo: Subtopic: Additional issues around audiobooks and packaging

Tzviya Siegman: Any comments?

Ivan Herman: we can discuss some issues related to what Laurent is working on. There are some nice issues with nice disagreements.

Ivan Herman: The whole issue of whether the HTML landing page is allowed, required, or banned from the lightweight package. And that’s still an open issue. There is a somewhat related issue which is a bit dependent …
… if it is possible to put a table of contents directly into a manifest — which must be resolved for the document Laurent is putting together.

Tzviya Siegman: Some of these issues we were planning on discussing next week.

Dave Cramer: As I was looking through things — we don’t seem to have digested the feedback from Blackstone audio yet. I’m trying to figure out how to do that. It’s not reflected in the audio explainer at all.
… can we make issues out of some of that so we can talk about it? I’m not sure how to proceed. They have really interesting things to say.

Tzviya Siegman: Did the items ever make it into github?

Dave Cramer: I can follow up on that.

Tzviya Siegman: the overall theme was that audiobooks are simple. If we make it complex, no one will use the spec. One issue they commented on is that zip is universal, don’t go beyond zip.
… It’s a shame we don’t have Wendy and the Blackstone rep — but we can still work through some of these issues. One other request is that we try to avoid mixing formats. Meaning we avoid mixing the packaging with the concept of the book.
… files are stored as files, metadata is in manifest instead of in the audio.
… and the packaging file defines the contents, not the files it contains. I think we’re OK in that perspective. Comments?
… The area where things get dicey is that Blackstone was asking for metadata and manifest in “as simple a format as possible” avoid HTML/XML. YAML or JSON. It’s the simplest for them to process.

Dave Cramer: https://github.com/blackstoneaudio/audiobook-spec

Tzviya Siegman: Dave posted a link to their documentation. So do we do something unique for audiobooks or something serializable for everyone?

Ivan Herman: what we have is along with what Blackstone says. Sure our metadata is JSON-LD — but that’s JSON. It’s not YAML, which is a separate discussion, I don’t think it should be a big issue. I love YAML but the world is using JSON…
… we are not using XML, or HTML for metadata. It does comes back to the issues I raised — there are 3 open issues in the PWP repo. I think remembering the mail of Blackstone — we are remarkably close to what they said.

George Kerscher: We are aligned well with the Blackstone thoughts.

Garth Conboy: I agree with what Ivan said. It was a very long email, but we addressed all the high-level points, but I don’t think we should treat every sentence in the email as something we need to adhere to. If we allow TOC in HTML — there are discussions we can have… It’s not requirements, it’s suggestions.

2.1. business needs around audiobooks

Dave Cramer: My concern here is that we come through here and come up with some spec, and I take it to our audio publishers and they say: “why do I have to do all this additional work” We don’t seem to have a lot of input so far from the creators of audio content. We have a lot of people who receive audio content, but that makes me vaguely nervous.

Leslie Hulse: +1

Dave Cramer: every bit of complexity will make it harder to convince people to adopt this. “Congratulations, you now have to create JSON and these new HTML pages” I want to get direct input first.

Laurent Le Meur: I interviewed with 2 companies in France — AudioLib and Libz, we explained what we were doing, and the notion of JSON manifest. If they accept to do it, they’ll be able to add a cover, a manifest, and even able to change MP3 format for something more powerful…
… so they will be able to expose it to the web. They were very happy — but they said: “If we add JSON, will the studio have an easy-to-use editorial tool to construct a manfiest” and we said “yes as open source, it won’t be a big deal to make a small studio that will create a manifest, TOC, etc”
… with this added, they are 100% happy

Luc Audrain: +1

George Kerscher: I think the idea of having a piece of software that will help audio publishers and producers who don’t know how to use their audio tools would be absolutely great for adoption. We usually don’t produce software, but if we could build this simple interface, it would be very useful.

Leslie Hulse: I can’t speak to specifics on the work needed by our audio team, but I think it’s worth taking the initiative to solicit feedback. It’s one thing to say that the French like the approach, but if a publisher with 10k already published may not do their back catalog. We just delivered our catalog to everyone, so why make a change?

Tzviya Siegman: Sounds like we have a little bit of homework. It sounds like a spec for items going forward. We know that with things like EPUB — it can be hard to do going forward. I believe that we plan to talk more about audiobooks and open issues.
… next week is open for open issues.

Tzviya Siegman: it would be helpful if some of this discussion spilled over to the business meeting

Luc Audrain: The question about the business group on this subject — do we just need more information from the audiobook publishers? Or the technical decisions. I’m not sure what you would need to know from the business group.

Tzviya Siegman: “How challenging it would be to implement a solution” — asking the large publishers if there would be any uptake. That’s the feedback and information needed from the business group.

Luc Audrain: Some feedback — we can open the question for the next week. OK

3. TPI memberships closing

Tzviya Siegman: Today is the last meeting for TPI (transitional members from IDPF). For those who are not transitioning to membership — we will miss your participation. We look forward to working with you again in other venues. If you want to participate in other ways, contact your W3C lead. Reach out to one of the chairs if you aren’t sure.
… Thank you

4. Resolutions