Publishing Working Group Telco — Minutes

Date: 2019-08-12

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, George Kerscher, Simon Collinson, Luc Audrain, Dave Cramer, Matt Garrish, Rachel Comerford, Wendy Reid, Nick Ruffilo, Gregorio Pellegrino, Franco Alvarado, gregorio, Ric Wright, Garth Conboy, Avneesh Singh, Tim Cole, Joshua Pyle, Romain Deltour, Bill Kasdorf, Ben Schroeter, Brady Duga, Teenya Franklin, Laurent Le Meur

Regrets: Tzviya Siegman, Marisa DeMeglio, Kenneth Dougherty

Guests:

Chair: Wendy Reid

Scribe(s): Simon Collinson

Content:

Wendy Reid: Half the links in the minutes are in markdown format - I’ll fix that
… first order of business: approving the minutes

Wendy Reid: See Last week’s meeting minutes

Wendy Reid: silence taken as agreement

Resolution #1: last week’s minutes approved

1. web packaging workshop report

Wendy Reid: First order of business for today: Dave and Benjamin attended a web packaging workshop recently
… asked Dave to give a quick overview of results of workshop

Dave Cramer: Briefly - at the Internet Architecture Board (related to IETF)
… a lot of controversy because Google’s web packaging spec is related largely to search carousel
… Google wants newspapers and other publishers to provide content to be hosted by Google - Google to control access
… two pieces: one called origin substitution - ability to serve from a cache elsewhere, but show original URL
… v. controversial - Firefox among those objecting
… other piece is combining all resources into a single binary file
… fair amount of support for this second piece across browser ecosystem
… part of our fundamental goals - this bundle would be double clickable in a browser window
… this seems like a packaging mechanism which could work for our use cases - wouldn’t require intermediation, browser would support directly
… I spent a fair amount of time talking to Jeffrey Yasskin privately, he supported our use cases
… discussion positive, high level and interesting overall.

Ivan Herman: Two questions: is the bundling very different from the document produced by TAG many years ago?

Dave Cramer: yes, based on CBOR - contact binary object representation - rather than multi-part MIME

Ivan Herman: Why is that good?

Dave Cramer: They documented some of the reasons, but a lot is to do with streamability arguments, random access, amount of content that has to be transmitted over the wire. I’m not qualified to answer that particular question

Ivan Herman: Second question: another problem with Web Packaging is that a package is prepared to be valid for a relatively short amount of time… not so good for us

Dave Cramer: This is more to do with the signed exchanges. Jeffrey told me unsigned exchanges would give access to non-secured APIs of the web, but not secured ones
… for most of our use cases this is probably enough.
… there was also discussion of signed exchanges for the archiving case, and where signature has expired.

George Kerscher: Is this something that potentially could become a REC?

Dave Cramer: This work is not happening at W3C - confusing and strange, but the specifications are currently being developed as IETF RFCs, but from the WICG community group within the W3C
… both specs are in the IETF. The bundling spec is less mature than the signed exchanges spec.

Wendy Reid: Any other questions?

Avneesh Singh: W3C has relation with IETF, which is better than relation with WHAT WG

2. Issues

Wendy Reid: Moving on to open issues in the specs. We now have different places for issues - eg audiobooks issues are logged against audio project, etc.

2.1. Create a Vocabulary of rel attributes for extra resources

Wendy Reid: this might be confusing for a while, but we’ll manage. First issue: final issue before next draft of audio spec: vocabulary of rel attributes for extra resources

Ivan Herman: See Audio issue #7

Wendy Reid: we’re already using a rel attribute for the cover, but do we need them for supplemental content?
… based on our discussion, do we want to create a list of rel values, eg ‘booklet’ or do we want to use the IANA link relations value set?
… this list is fairly complete, has a few publication-specific things, eg ‘appendix’, ‘author’, ‘chapter’
… this could potentially cover most of our use cases. Thoughts?

Simon Collinson: silence

Wendy Reid: I expected this topic to be contentious

Ivan Herman: I don’t recall the process of adding something to the IANA list, but the cleanest way, if we’re only missing one or two, is to try and get them into that list.

Wendy Reid: Good point.

Dave Cramer: I want to express caution about these kinds of vocabularies… our experience in EPUB is that these have been a pain - hard to maintain, and I’d hope that we only add terms when there’s a behavioral necessity

Romain Deltour: +1

Dave Cramer: people like labelling these things from a metadata perspective, but is a reading system going to do something different based on this rel value if it’s a booklet vs appendix vs colophon vs etc. etc.
… I hope that the need comes up for the vocabulary, rather than defining one first and hoping that it’s used

Wendy Reid: I lean on the side of Dave, because we’re in the early days of this sort of content… it might not even get used.
… or if we open it up, it might get used too specifically

Ivan Herman: It’s probably fine to postpone this issue - don’t close and forget, leave it open for now, but follow what Dave says
… we should see if there’s a need for it, then go down the IANA path
… if we record that in the issue then postpone resolution, that’s fine.

Wendy Reid: Any opposition to postponing?

Laurent Le Meur: ok for postponing

Luc Audrain: +1 to postpone

Proposed resolution: Postpone discussion of Audiobooks #7 (Rel values) until we receive more feedback (Wendy Reid)

Romain Deltour: +1

Ivan Herman: +1

Garth Conboy: +1

Nick Ruffilo: +1

Tim Cole: +1

Bill Kasdorf: +1

Laurent Le Meur: +1

Dave Cramer: +1

Simon Collinson: +1

Joshua Pyle: +1

Ben Schroeter: +1

Rachel Comerford: +1

Resolution #2: Postpone discussion of Audiobooks #7 (Rel values) until we receive more feedback

2.2. Metadata rendering “hints” from epub we should consider for manifests

Ivan Herman: See Manifest issue #21

Wendy Reid: Next issue, moving into publication manifest issues (pulled from WP):
… from Brady, looking at some of the things from EPUB which we might want to consider still using in manifest
… mostly related to page direction – flow, layout, spreads, viewport, linearity, etc.
… there was some suggestion to drop linear and viewport, but the rest

Ivan Herman: To explain the history, when we created the new repo for the manifest, Matt and I transferred a number of old issues across that were relevant
… this is one of those. It may be that it’s not relevant, but that’s how it ended up here.

Dave Cramer: I think as a general principle we should not describe rendering in metadata. The web has a whole language for rendering - I think especially assuming in advance that the EPUB FXL concept of ‘displaying two independent viewports side by side in a particular relationship’ is something that we should not bring to web publications
… I would hope we would say that we’re not going to do rendering in metadata, and leave it at that

Garth Conboy: I disagree with Dave… moving forward we have to figure out how to support FXL - this is clearly irrelevant for audiobooks, so this is a long term defer

Matt Garrish: I agree on deferring generally all of this metadata stuff - the one that interests me here is the page progression direction… there’s no means of establishing that when going from document to document… it might come into play with HTML. That’s maybe the only one we should consider now
… until we have stronger cases for the others, let’s defer

Brady Duga: I’m fine deferring, but wanted to point out these aren’t all FXL.
… page progression direction is the one thing that has no other way of being displayed - CSS is within single documents, nobody has figured out how to implement that across documents

Luc Audrain: +1 to brady

Brady Duga: these are widely used things in EPUBs today which have to somehow get into web publications

Wendy Reid: I’m in strong agreement re: page progression
… because audiobooks have some text in them, we do need this for audiobooks, since we might have a Japanese audiobook with JP-language text attachments

Ivan Herman: There is a direction property in the spec right now which could play this role

Romain Deltour: Agreeing that page progression is not covered by CSS currently, but that’s because CSS is not about a collection of documents - we can’t magically fix by adding this value to manifest - needs more work, including collaborating with CSS working group and others - might need to work with community group on this, rather than arbitrarily picking values

Garth Conboy: I don’t have a strong position, but for audiobooks we do have the ancillary resources. Romain, do you disagree that we need page progression for figuring that out?

Romain Deltour: I’m not familiar enough with the audiobook use case to answer that. Let me think about it.

Garth Conboy: I’m completely willing to think about nothing but audiobooks in this context… an argument could be made that you need to know the order in which to page through ancillary resources

Ivan Herman: I disagree with Romain. What we have is the manifest, it doesn’t say anything about rendering as such… we don’t dictate any way of rendering, it’s just information - we don’t say how a title should be displayed either
… the fact of having the base direction as part of the manifest is perfectly fine. I don’t think that’s on a collision course with CSS
… today we don’t do anything with these documents (??), we know that, but the information is useful for reading systems.

George Kerscher: A reminder that in order to pass accessibility APA, we need a mechanism for providing text transcripts, those need progression information

Dave Cramer: Are we assuming that all ebook ancillary content will be paginated?

Wendy Reid: No

Romain Deltour: To clarify: the primary concern is to avoid any conflict with the web. As long as we stay in the audiobook context, I guess we can do innovative things. But here it’s really about rendering web content, so we should either use existing mechanisms or talk with the groups which define them
… there are questions re: pagination in ancillary content… but do we really need this information? I’m failing to see the real use case here
… rephrasing the issue or making a clearer use case might be appropriate
… if we are to enter the realm of rendering, then we should make a very strong case for anything we do on our own

Brady Duga: Building on what Romain and Dave said - it’s not clear to me that we know how the ancillary content is going to actually be used by reading systems. George made a comment about transcripts, but I don’t know if the reading system needs to know the progression direction - it might just display text on the screen
… I don’t know how this information will be used. We’re trying to cover every possible use of every possible content… we should wait to see how it’s used… I’m not planning to glue the ancillary content together into something like an ebook (not a product announcement, just something I don’t imagine doing)
… I can see there’s a reason we could want this, but it doesn’t seem to me like that’s sufficient to get into the really difficult discussions around CSS before we discover the use cases

Ivan Herman: We have two terms in languages in the document which set the language and the direction. I realise that reading the text can be a problem. The current manifest defines language and base direction for the manifest textual items and the publication as a whole.
… we may want to remove the reference to the publication and refer to the manifest’s textual terms only

Wendy Reid: We don’t want to add the text direction property to our metadata, at least not just yet
… I think we want to keep in the language and direction properties as they are… if reading systems use them, that’s their decision. But during implementation, we should be keeping in contact with implementors to see what they want to do with this ancillary content
… do they need additional information to render it, do they want to infer themselves, do they have a better idea for how we do it
… happy to postpone until we have more opinions on this point.
… we could send this to the publishing community group and ask them to find a solution

Ivan Herman: Do we want to remove references to the direction and language of publication from the manifest? That’s what we need to decide

Wendy Reid: I don’t think we should remove them
… In-language is kind of important for a reading system or user agent to make inferences
… I’m adding the postpone label to this issue.

2.3. Should the Canonical Identifier be a URL?

Ivan Herman: See Manifest issue #3

Wendy Reid: Next issue has already been closed - Pub-Manifest: Should the Canonical Identifier be a URL?

Matt Garrish: We had a few things that were still pretty Web-Pubby - need people to read over and see if anything in there still seems too closely tied to Web Publications

3. Publication Manifest draft

Wendy Reid: Publication Manifest editors’ draft

Wendy Reid: Please look over the publication manifest draft ; just take off your Web Publications hat and think of this purely as a manifest
… so, look over the manifest, remember it’s not just Web Publications, but something other groups and publications types can use as basis for other profiles (including audiobooks), but it isn’t just for audiobooks. If something is missing related to audiobooks, that’s ok
… there are also several issues currently set as ‘to be closed’ - please review, I’ll send a list this week before closing.
… if you look at the comments, they’re mostly settled. We just never closed them

4. TPAC in one month

Wendy Reid: See Future agenda page

Wendy Reid: last topic: we’re one month out from TPAC. We don’t have a settled agenda yet, and only three items on the agenda item requests
… one of the major items, and this will probably take a morning or a whole day, we do need to set the audiobooks implementation and test plan
… as we get ready to move to CR
… the other two items - we have been approached by W3C management, as they had a productive conversation with Amazon, who would like to attend our meeting
… Wendy and Rachel working with Amazon folks to define mini-agenda - discussion about how we can work together
… looking to understand what they’re interested in, as well as tell them what we’re working on

Wendy Reid: we should also give some time to the community group - maybe to talk about page progression - a bit of exploration

Ivan Herman: We plan to go to CR after the meeting, end of Sep/beginning of Oct. That includes primarily the audiobook and manifest documents as they stand
… one thing to remember: once the document is in CR, we are not supposed to make any major changes
… when we go to a new round of publication, everybody should try to find some time to go through the document with (??) and do one last round of review to find anything which needs to be changed
… everyone should spend some time reading the documents before publication.

Wendy Reid: Please add things you’d like to include on the agenda, and we’ll fill out times from next week
… That’s it - talk again next week. Exciting because there will be some updated drafts of some documents.

5. Resolutions