<tzviya> Chair: Wendy

<scribe> ScribeNick: NickRuffilo

<wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-12-03-pwg.html

Wendy: First item - lets approve last week's minutes.

RESOLUTION: last week's minutes approved
...: Last week's minutes approved.

structure of wp spec & audiobooks

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

<franco> +present

Tzviya: 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: 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: I'm not sure it needs a separate repo.

Ivan: 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: 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.

<rkwright> +1 to a single repo

<laurent_> +1 for a single repo

Ivan: 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: The issue of how many repositories aside, we do need editors. (This is where people volunteer)

Wendy: I can volunteer

<wendyreid> nickruffilo: 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: 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.

<dauwhe> CSS uses Echidna

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

Ivan: That is the idea

Avneesh: 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: 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 there is a recommendation 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 nah.

Wendy: Next topic - Audiobooks

Audiobooks

...: 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.

<wendyreid> https://github.com/w3c/wpub/issues/352

<ivan> Subtopic: packaging
...: 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...

<wendyreid> http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip
...: It is a published ISO spec - so there is prescedence for this - because it is a packaging spec, and we wanted input from the group.

Tzviya: One thing I didn't catch - did you say no entry page would be required?

Wendy: It's optional

Tzviya: 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: 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: Two things - the administrative side - if there is an ISO standard, and we use that, that is fine. So there's not administrative issues there. Tzviya said what I wanted to say originally. I am a bit bothered by creating a prescendence 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.

Rick: 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.

Dave: 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: +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: 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_> Leonard's issue was void

<tzviya> https://github.com/w3c/wpub/issues/352#issuecomment-439700768
...: 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

Laurent: 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.

<Avneesh> Thanks Laurent
...: There is nothing that precludes or makes any problem with using DRM with this ISO standard
... it's only about the ZIP encryption....

Brady: 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: I didn't understand that is what you need. If you change the standard, then I'm not sure what that means. I have to check.

Brady: 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: Changing the ISO standard, that's a big no-no.

Brady: 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.

Josh: 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.

<laurent_> https://github.com/w3c/wpub/issues/352#issuecomment-439700768

Laurent: 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: You want to republish the OCF document as...?

Laurent: As an OCF-lite.

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

<dauwhe> https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html

Laurent: It's not ISO, but IDPF

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

Tzviya: 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: There was just one thing we wanted to remove, and then the question of which name we want to give to a manifest...

Avneesh: 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.

<duga> @laurent_ what was the one thing we need to remove from OCF? I didn't catch it
...: 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...

Ivan: 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.

<laurent_> @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.
...: Why we keep going back to the previous discussion - we'll have to play around with minutes - 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.

Benjamin: My concern with splitting, even into two documents, we already have a split brain - and inheretence is confused already. There have been two groups discussing. If we ship them together as the same group, we should think about how that inheretence 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

<wolfgang> s/inheretance/inheritance/

<wendyreid> nickruffilo: 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?

<wendyreid> ... 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: 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?

Josh: 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.

+1 to what josh said

Wendy: 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: 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: I've seen one proposal for how that might possibly work, but it needs more work.

Matt: 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.

<laudrain> +1 to Matt

<mateus> +1 mgarrish

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

Wendy: 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.

<ivan> +1 to Bill_Kasdorf

Bill: 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..."

<josh> +1 to Bill
...: 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: 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.

<wendyreid> https://github.com/w3c/wpub/issues/351

<ivan> subtopic: json type property

Wendy: 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.

<tzviya> https://github.com/w3c/wpub/issues/351
...: 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 permissable in WP?

Ivan: My answer is 'yes' and If I remember well, this question was specifically asked at TPAC as well. Somehow by some magic, we already have types that we use and define for ourselves, so adding new types is perfectly possible. 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, then I don't see it as a problem

<wendyreid> nickruffilo: 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"

<wendyreid> ... 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

<dkaplan3> +1 for nickruffilo's suggestion of progressive enhancement in books

<wolfgang> +1 to nickruffilo's proposal to give UAs a hook for specialized functionality based on the type of book

Laurent: 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[CUT]
... soon but not be too generic.

<ivan> +1 to laurent_

Benjamin: I have grave concern 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> +1 bigbluehat - question value of strict type taxonomies vs contextual cues

Benjamin: 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: 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: 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 displable 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

+1 to deborah

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/reops/repos/
Succeeded: s/labrynth/labyrinth/
FAILED: s/inheretance/inheritance/
Succeeded: s/possiblye/possibly/
Succeeded: s/accomodating/accommodating/
Succeeded: s/That would allow different packages.//
Present: ivan Rachel wolfgang tzviya george laudrain Yanni Teenya wendyreid dauwhe Avneesh dkaplan3 marisa JunGamo franco Bill_Kasdorf Simon_Collinson JuanCorona bigbluehat jasminemulliken mgarrish rkwright derekjackson jbuehler josh duga laurent_ CharlesL mateus BenSchroeter
Regrets: ivan
Found ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo
Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Dec/0011.html
WARNING: Could not parse date.  Unknown month name "12": 2018-12-10
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)