Publishing Working Group Telco — Minutes

Date: 2018-12-10

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Rachel Comerford, Wolfgang Schindler, Tzviya Siegman, George Kerscher, Luc Audrain, Yu-Wei Chang (Yanni), Teenya Franklin, Wendy Reid, Dave Cramer, Avneesh Singh, Deborah Kaplan, Marisa DeMeglio, Jun Gamou, Franco Alvarado, Bill Kasdorf, Simon Collinson, Juan Corona, Benjamin Young, Jasmine Mulliken, Matt Garrish, Ric Wright, Derek Jackson, Jeff Buehler, Joshua Pyle, Brady Duga, Laurent Le Meur, CharlesL, Mateus Teixeira, Ben Schroeter

Regrets: Ivan Herman

Guests:

Chair: Tzviya Siegman, Wendy Reid

Scribe(s): Nick Ruffilo

Content:

Wendy Reid: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-12-03-pwg.html

Wendy Reid: First item - lets approve last week’s minutes.
… Last week’s minutes approved.

Resolution #1: last week’s minutes approved

1. structure of wp spec & audiobooks

Wendy Reid: First topic - discussing the structure of web publication spec as well as audiobooks. Tzviya wrote the explainer so she will explain.

Tzviya Siegman: Over the weekend there was lots of work on the TOC. In the past few weeks we’ve simplified the web IDL and shifted focus on the minimum viable publication. We want to make a lean/simple version of the spec.
… We’re making this a simplified spec and anything that needs to be built upon will be a module. The first of these is audiobooks. It will be based on web publications, but it will be an extension.

Ivan Herman: My understanding is that there will be a separate document for audiobooks. Putting my administrators’ hat on, does this mean that we would have a separate repository with separate editors? I can set it up, but we would need editors.

Wendy Reid: I’m not sure it needs a separate repo.

Ivan Herman: The repository is, in practice, better to have it separately so it makes it easier with the publication process. It’s a practicality. More importantly, we would need editors with whom I could set up the whole thing.

Dave Cramer: I’m a bit concerned with separate repos - if issues come up in the audio work, we’ll have to hunt through several repositories. There are ways of handling this with issues.

Ric Wright: +1 to a single repo

Laurent Le Meur: +1 for a single repo

Ivan Herman: What I have to check… I don’t know how the CSS group works, but I have to check if the current auto-publishing process is something that can work by having multiple documents in a single repository. Having a repository is a separate place for the document. it doesn’t mean we have to use the issue list of that repository.
… We can use a single issue list, but having a physical 2nd repository, would make it easier longer term for publishing.

Tzviya Siegman: The issue of how many repositories aside, we do need editors. (This is where people volunteer)

Wendy Reid: I can volunteer

Nick Ruffilo: If it sounds like we’ll be creating new documents for each extension, are we then creating new repos for every extension? Could this become a lot of repos? Not a bad thing if we have a good process, but the CSS example is compelling

Ivan Herman: Fair statement. I can’t comment on the CSS working group, as they have a different publishing process. I do know that there are groups that have multiple repositories. But yes, if we add more extensions, we would need more repos.

Dave Cramer: CSS uses Echidna

George Kerscher: The overarching specification and the audiobook module - would that go to rec together and each subsequent module would go to rec?

Ivan Herman: That is the idea

Avneesh Singh: Just thinking about the formal process. Just the charter has a note about extending the specification like this. I don’t remember if there is a probation for extensions like this. I don’t want issues when we come to rec stage.

Ivan Herman: We have to talk to Ralph - and we may have to recharter. The reason why I haven’t had this discussion is because there was no such decision. We have no working-group decision of doing it. There is the whole issue around the recommendation for 3.2 We know that if we do this, that would lead to a rechartering. So if we do need a recharter for audiobooks, we should wait to see if we need it for 3.2
… waiting to do both at once would be easier if we need. We could possibly do this without a rechartering, but I’m not in a position to say yeah or nay.

Ric Wright: Going back to multiple repos and such - one of the feedback we get at readium is that it’s way too complex for newbies. They don’t know how to deal with 24 repos… In an epub 3.x along the way - those of us on the working group had difficulty. I’m concerned we’ll create a labyrinth of specs and it will be hard for people.

Joshua Pyle: I wanted to - I’m going back to the spec + module - I wanted to agree with what Rick said about being newbie friendly. I have further concerns that if we follow spec + module approach, we’re going to invariably have certain modules that get more love than others. The audiobooks module may have wonderful packaging spec that just belongs in the main document…
… things could be useful to everything. With different editors, things that were written well for one, may not make it back to the main. So we’ll end up with different modules with different degrees of completeness.

Ivan Herman: The alternative is to have a huge document that would include all the various modules. If we put together all in one document. Being an editor of the core document, I know it’s difficult to manage. It’s already a pretty sizable document. If we add 2-3 other modules, it’s a monster.
… forget a separate repo, but having a single document, it becomes unmanageable and unreadable.

Alan Stearns: AFAIK there are no issues with the W3C auto-publishing process on one repo versus multiple repos (the CSSWG auto-publishes from a single repo). One benefit for a single repo is more finely-grained notifications - you can sign up for (or sign out of) notifications for each repo. With a mono-repo you have to organize issues on separate documents using labels, and there’s no way in the GitHub UI to say, “notify me just for these labels.” We manage this haphazardly in the CSSWG by also having an issue title convention and some people filter email notifications based on that. One benefit for a mono-repo is that you can easily move issues from one document to another, and/or discuss issues that cover more than one document.
(Ivan Herman: Added this IRC comment from Alan with his permission.)

2. Audiobooks

Wendy Reid: The Audiobooks taskforce met a couple weeks ago to discuss the next challenges as a group. One of the first is the discussion of packaging. It’s important UC for us. One of the big issues is a lack of a good distribution model.

2.1. packaging

Wendy Reid: https://github.com/w3c/wpub/issues/352

Wendy Reid: A very high-level summary: we would do something OCF light - a zipped archive, the manifest is present and has a well-known location. There is an optional entry page. Resources should be listed, and there would need to be a dedicated media-type. The proposal, because it’s not the same as OCF for an epub…

Wendy Reid: http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip

Wendy Reid: It is a published ISO spec—so there is precedence for this—because it is a packaging spec, and we wanted input from the group.

Tzviya Siegman: One thing I didn’t catch — did you say no entry page would be required?

Wendy Reid: It’s optional

Tzviya Siegman: If we’re building on the WP spec, even if it’s not necessary for audiobooks, it’s a must for the core spec — so maybe we need to have it anyway. So maybe it’s just something that comes with WP

Wendy Reid: That’s possible. We discussed it because there was some idea that a packaged audiobook, in the distribution model, would not use the entry page. So why include a file that wouldn’t be used. But arguable — it’s there if needed, but if not read, no big deal.

Ivan Herman: Two things. The administrative point: if there is an ISO standard, and we use that, that is fine. So there’s not administrative issues there. The substantial point: Tzviya said what I wanted to say originally. I am a bit bothered by creating a precedence where the module becomes different from our core.
… To drop a requirement we have bothers me. That means if I have an audiobook, and for some reason I want to unpack it and put it on my website, it’s no longer a web publication. It also binds to the open issue about whether the TOC will be possible in JSON LD or not. If that issue is decided against…
… then the HTML page could also be the TOC - so it has a specific use as well. Not just a placeholder. I’m more inclined to do that then let modules go their own way.

Dave Cramer: This is a working group of the WWW consortium. One of the fundamental principles is that web publications have a URL, and when you resolve that URL, you get an HTML. That’s the foundation of webiness and what we do. So I agree with Tzviya and Ivan.

Avneesh Singh: +1 to the previous comments. Packaging and unpackaging should not be affecting the document. The second piece is regarding OCF. There was originally strong objections to it because of DRM. Are we going to address this?

Wendy Reid: The objections I recall - there was only one major issue and it was relating to the fact that this would disallow encryption - the way we have it. The problem I have with that is that DRM is outside of our purview. There was one disagreement about this particular issue around encryption.

Laurent Le Meur: Leonard’s issue was void

Wendy Reid: Leonard noted that it doesn’t address well-known file naming, disallows encryption, and dig-sig, which would prevent tamper detection. Instead the proposal was to make changes to OCF, or use adobe’s UCF

Tzviya Siegman: https://github.com/w3c/wpub/issues/352#issuecomment-439700768

Laurent Le Meur: Just to say that in the ISO standard, the only encryption that is available is the ZIP encryption. There has nothing to do with global DRM, there is no issue outside of the W3C to use some encryption method to use with this.
… There is nothing that precludes or makes any problem with using DRM with this ISO standard
… it’s only about the ZIP encryption….

Avneesh Singh: Thanks Laurent

Brady Duga: My question goes back to something Ivan talked about referencing an ISO standard. it’s fine to reference it, but we can’t just do that. We’ll have to make modifications because we can’t take OCF as is… Can we do that?

Ivan Herman: I didn’t understand that is what you need. If you change the standard, then I’m not sure we can do that. I have to check.

Brady Duga: OCF has the signature, I suppose adding restrictions may work, but we can’t say - change the signature. Otherwise people would think it’s an epub…

Ivan Herman: Changing the ISO standard, that’s a big no-no.

Brady Duga: That’s my worry. Just because it’s an ISO standard, doesn’t mean we can reference it, unless we take it directly as OCF.

Laurent Le Meur: https://github.com/w3c/wpub/issues/352#issuecomment-439700768

Laurent Le Meur: There is also a comment about ISO standards - it is true that if the ISO standard doesn’t give us what we need - and we have to re-write it, it may be better to take the OCF document and simplify it…

Ivan Herman: You want to republish the OCF document as…?

Laurent Le Meur: As an OCF-lite.

Ivan Herman: Republishing has lots of copyright and trade issues, so it is not that simple.

Dave Cramer: https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html

Laurent Le Meur: It’s not ISO, but IDPF

Ivan Herman: That is more doable, but it would be extra work. That could be done.

Tzviya Siegman: I realize there is urgency for audiobooks, but we do plan on publishing something packaged. Yes, there is urgency, but if we’re talking about redoing OCF… if we re-write OCF, would we have different version for epubs and audiobooks?
… But we’d have issues with a new OCF?

Laurent Le Meur: There was just one thing we wanted to remove, and then the question of which name we want to give to a manifest…

Avneesh Singh: I was just thinking of how to structure thoughts… We have a proposal on how to package the audiobooks. Maybe we should handle this problem from the other side - what is the minimum features we want in packaging, and then evaluate the spec/process fits in.
… The second is regarding the extension point spec. If Audiobooks just have 1 extension point which is different from WP - Packaging, maybe we don’t need to separate the spec. We would just have one additional item then…

Brady Duga: @laurent_ what was the one thing we need to remove from OCF? I didn’t catch it

Laurent Le Meur: @duga the order of the files in the archive. There is a file which MUST be first in the OCF package, for streaming purposes, that makes no more sense.

Ivan Herman: As far as I could follow, that’s not the only thing where audiobooks have their specificities. The audiobook specification would also include additional entries in the manifest that belongs to them and not the core. It might be a relatively thin layer, but it’s not only the packaging.

Benjamin Young: My concern with splitting, even into two documents, we already have a split brain - and inheritance is confused already. There have been two groups discussing. If we ship them together as the same group, we should think about how that inheritance works - within and without the package. Who builds them, who renders them, etc. There are possibly two answers.
… I’m concerned we’ll make that worse not better

Nick Ruffilo: : bigbluehat wins comment of the day. An important question for me is are we trying to solve all of the publishing industry’s problems, or are we trying to create a web publication? … how many hoops do we go through? Would a video book have to fit into a wp, if we think about what is the best and most logical web publication we might come up with something better than thinking of what audio needs now

Tzviya Siegman: I think there are going to be some things that are unique to different types - such as audiobooks. We haven’t come up with any solutions, just problems. I’m concerned about packaging for audiobooks. we’ve decided not to make a decision on WP, but for audiobooks, we need to make a decision today.
… OCF is on shaky grounds because we need to know what the revisions on the spec are. If they are minor, then it may not be an issue, but I don’t want two different major versions of OCF. I don’t know if people are comfortable with all the differences. But - what’s wrong with ZIP, why can’t that work?

Joshua Pyle: To wrap up what Tzviya said - audiobooks needs packaging right away, so that means that web publications needs packaging right away. If an important implementation of WP (like audiobooks) needs packaging right away, I think we need to address it for all WPs.

Nick Ruffilo: +1 to what josh said

Wendy Reid: We are running out of time. It sounds like the audio TF needs to rethink the proposal and not just for audiobooks, but packaging in the webby sense. What should work for audio should also work for the web.

George Kerscher: I think that’s a good idea. We manage to shoehorn media overlays into an epub publication, so we might be able to shoehorn an audio publication into the same publication. The Audio Taskforce may want to look at that as a possible avenue.

Wendy Reid: I’ve seen one proposal for how that might possibly work, but it needs more work.

Matt Garrish: I just wanted to jump back on the things Ivan said. It’s too early to decide if different specs are needed, different repos. It’s more an exercise in ‘what is WP missing?’ Maybe bringing it back to WP - maybe it’s something the audiobook should be working up their requirements and that could become a pull request into the WP itself..
… I wouldn’t launch into new specs at this moment. I would want to focus on what it is that is needed in WP. Only if there are incompatibilities would we need different specs.

Luc Audrain: +1 to Matt

Mateus Teixeira: +1 mgarrish

Laurent Le Meur: When you said the Audiobook TF should review packaging for all - they are not a packaging taskforce, so it’s not the goal.

Wendy Reid: We are the first group that needs packaging. We want to stay as close to WP as possible. So maybe we should lead the way on that. We could just add audio and packaging. I worry that it obfuscates what we’re doing.

Bill Kasdorf: I’ve always envisioned that WP is the broadest most accommodating of the specs - and it allows any packaging format that is legal in the open web platform, and more specific modules like audiobooks, epubs, etc… would just say ‘for this module, use this one…”

Joshua Pyle: +1 to Bill

Ivan Herman: +1 to Bill_Kasdorf

Bill Kasdorf: I view the modules as narrowing down the broader WP spec. I would be worried about WP making a change because audiobooks needed it, when a different module might not want what audiobooks needs.

Avneesh Singh: My direction of thinking is going in the same direction - jumping on that we want extension points. Maybe the approach should be that we keep working on single spec, and let things get mature, but until then, let the taskforces come up.

2.2. JSON-LD Type Property

Wendy Reid: https://github.com/w3c/wpub/issues/351

Wendy Reid: We have 12 minutes, and I want to address one more issue. This is for the spec at large, but we discussed with Audiobooks. it’s about JSON-type. It’s defined for book and audiobook.
… As we work with sync-media group, how would a sync-media book be different. The current solution is to use both book and audio, but would it possibly be better and clearer to use additional types for something like sync-media publication, manga, and other things that have specific use cases.
… so a user agent could make decisions. Would that be permissible in WP?

Ivan Herman: My answer is ‘yes’ and If I remember well, this question was specifically asked at TPAC as well. We already have types that we use and define for ourselves, so adding new types is perfectly possible. As discussed with Dan Brickley, if we define new types in WikiData then, somehow by magic, schema.org processors will probably handle them. It’s probably a good idea for reasons of discovery by schema.org to say that it’s clear…
… Semantically I’m not sure it’d be required to also add a type to Book explicitly, but I don’t see it as a problem

Nick Ruffilo: I think it is a good idea to have specifics, especially for dedicated reading systems, but when we think of what is the standard, a basic UA might only have support for “book” or “audiobook” … would allowing a second level give the same ability for an RS that can support it, and a basic RS can just focus on book or audiobook

Deborah Kaplan: +1 for nickruffilo’s suggestion of progressive enhancement in books

Wolfgang Schindler: +1 to nickruffilo’s proposal to give UAs a hook for specialized functionality based on the type of book

Laurent Le Meur: Agree with nick - audiobook is already a subtype of book in schema.org. We don’t have a very large set of subtypes. We know there is audiobook and visual novel (comics and image based). We have synced media (read aloud book). But we have maybe 5 subtypes. Each corresponding to a different type of user agent. It would be very easy to create 4-5 types, then use the schema.type for that. It should be soon but not be too generic.

Ivan Herman: +1 to laurent_

Benjamin Young: I have grave concern with even about 5 different user agents. There are audiobook listeners that just play audiobook. Perhaps the sub-typing is not as bad as it sounds, but there are generic browsers that browse generic web and it doesn’t care if it’s an audiobook or manga in HTML, it’s the value of the web, VS having to find the right app…

Mateus Teixeira: +1 bigbluehat - question value of strict type taxonomies vs contextual cues

Benjamin Young: I’m not sure how we marry those two, but I have concern that we might switch too heavily on this type field and get ourselves into trouble subsetting these spec.s

Avneesh Singh: This rolls back to Ivan’s comment. If there’s something unique to audiobooks, beyond packaging… The main reason is not to provide browser support, it’s for reading systems. What if there is an HTML page in the reading order… This flag/metadata will tell the reading system that it’s a collection of audiobooks, etc. Browser may ignore it, but it’s for the reading systems.

Deborah Kaplan: This is a general variant - Benjamin added to Nick’s comments - there are two competing and important issues. One is the idea of saying ‘some features will only work in X browser’ then we’re back in 2002. That is not a behavior we want. But it is also true that within publishing, there are complex use-cases.
… When we talk about WPs we want things displayable everywhere. There may be features of RS or browsers that aren’t shared, but as long as the usability and accessibility is there, all the content is available. it’s a complex negotiation. Yes, browsers may have simple functionality, as long as it’s done mindfully.

Nick Ruffilo: +1 to deborah

3. Resolutions