Publishing Working Group F2F, Day 2 — Minutes

Date: 2018-05-31

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brady Duga, Reinaldo Ferraz, Wendy Reid, Luc Audrain, Joshua Pyle, Dave Cramer, Avneesh Singh, Benjamin Young, Marisa DeMeglio, Rick Johnson, Leonard Rosenthol, George Kerscher, Tzviya Siegman, Rachel Comerford, Garth Conboy, Ben Walters, Romain Deltour, Zheng Xu, David Stroup, Charles LaPierre, Ben Dugas, David Wood

On the phone:: Jun Gamou, Deborah Kaplan, Chris Maden, Ric Wright, Hadrien Gardeur, Jeff Buehler, Jean Kaplansky, Tim Cole

Guests: Kroner the Wonderful Guide Dog

Chair: Tzviya Siegman, Garth Conboy

Scribe(s): Brady Duga, Ben Walters, Leonard Rosenthol, Benjamin Young, Wendy Reid, Zheng Xu

Image of the WG around the meeting table

(See further images of the meeting, thanks to Ben Dugas, Kobo.)

Content:

Ivan Herman: Some remarks before we start
… there is a new column in the wiki for where we got yesterday
… please cross check to make sure it is correct (AI for all)

Ivan Herman: https://github.com/w3c/wpub/wiki/Descriptive-Infoset-Properties-vs.-Schema.org-table

Tzviya Siegman: This will be Monday’s agenda item

1. Affordances and use cases

Tzviya Siegman: some of know what affordances mean
… some prefer functionality as a word
… basically, what should a UA do when it sees things from our spec
… ties in to use cases, which provide stories of what we want to happen
… make sure use cases represent what we need
… and make sure affordances issues we have are up to date
… Make sure everyone has an assignment to write an affordance section
… George and Avneesh can help with templates/writing

Ivan Herman: to help Matt, if there are no problems, put it in a pull request

Tzviya Siegman: Will send out a recording on Respec training session
… Need to address UA vs document requirements/expectations

Tzviya Siegman: https://github.com/w3c/wpub/labels/topic%3Aaffordances

Tzviya Siegman: https://w3c.github.io/wpub/#wp-affordances

Benjamin Young: Use cases are a story of what tasks we want to do
… affordances are the things in a document that allow those stories to happen
… Mugs afford holding things.

Benjamin Young: see mugs: https://en.wikipedia.org/wiki/Affordance

1.1. bookshelf

Tzviya Siegman: Let’s look at github
… look at issue 134
… dependencies, requirements, examples, and how to test for each affordance
… assigning AIs to people (going through the issues)

Tzviya Siegman: https://github.com/w3c/wpub/issues/134#issuecomment-385011630

Tzviya Siegman: bookshelf is afforded by our spec, but will not write a bookshelf spec

Benjamin Young: But we can afford things that will help (e.g. cover)

Wendy Reid: Don’t tell us what to do with the bookshelf

Tzviya Siegman: Consensus: close the issue?

David Wood: Should we have a resolution that says we commit to providing this stuff as part of the spec?

Wendy Reid: We need enough information to provide a shelf (eg series)

Tzviya Siegman: can we say we will provide metadata for shelves, and the UA can do whatever we want with it

Proposed resolution: minimal metadata required for a shelf system to present a publication are: identifier and title OR cover? (Benjamin Young)

Leonard Rosenthol: Remove section 7.2

Proposed resolution: minimal metadata required for a shelf system to present a publication are: identifier and title OR cover; remove Section 7.2 (Benjamin Young)

Rick Johnson: We are saying we will supply something. Are we saying this is the only way?

Ivan Herman: +1

Tzviya Siegman: +1

Rachel Comerford: +1

Garth Conboy: +1

Benjamin Young: +1

Luc Audrain: +1

Charles LaPierre: +1

Joshua Pyle: +1

Marisa DeMeglio: +1

Benjamin Young: There will be more metadata, but there should be minimal info available.

Wendy Reid: +1

Brady Duga: +1

David Stroup: +1

Jun Gamou: +1

Romain Deltour: +1

Ben Walters: +1

Leonard Rosenthol: +1

David Wood: +1

Deborah Kaplan: +1

Rick Johnson: +1

Reinaldo Ferraz: +1

Resolution #1: minimal metadata required for a shelf system to present a publication are: identifier and title OR cover. Remove Section 7.2

1.2. reading state

Garth Conboy: https://github.com/w3c/wpub/issues/145

Wendy Reid: Is this local or remote?

Garth Conboy: What are we saying? Is this in scope?

Benjamin Young: Saving state on a web page means knowing scroll location
… Then it is up to the UA to remember that state
… in a WP, there is a way to get to resource X, and remember where we are in that resource (scroll location? Page? etc)

Tzviya Siegman: Need to have information for what authors need to do, and what UA need to do with it

Ivan Herman: And need the minimal information (most important)

Wendy Reid: Have to make reading state a possibility, but up to UA to decide if local or remote, etc

Wendy Reid: Will write this issue [yay!]

Benjamin Young: For this case, one thing we might need is reading direction (or maybe not)

George Kerscher: When wp are updated, can we say anything about ids on elements? Or will they just always be trashed?

Benjamin Young: What does keeping them around afford?
… Return to anchor?

George Kerscher: Yes. Having ids that don’t change would help the industry.

Benjamin Young: +1 to assigning things and solving them async

Rachel Comerford: Let’s just assign here, not discuss in detail here

Ivan Herman: #145 assigned to Wendy

1.3. moving forward and backward

Garth Conboy: https://github.com/w3c/wpub/issues/144

Rachel Comerford: Rachel: I’ll take 144 https://github.com/w3c/wpub/issues/144

Benjamin Young: dauwhe and bigbluehat can take 144

Ivan Herman: #144 assigned to Benjamin and Dave Cramer

1.4. filtered navigation/reading experience

Deborah Kaplan: What is the schedule one these?

Garth Conboy: https://github.com/w3c/wpub/issues/140

Tzviya Siegman: Will discuss that shortly

Tzviya Siegman: Close issue 140?

Benjamin Young: If we know what is navigable that affords the ability to navigate to it

Marisa DeMeglio: Do we need more than just 1 view of the TOC?

Avneesh Singh: propose closing the item just assigned to clapierre

Ivan Herman: #140 assigned to Marisa

1.5. paging” through a publication

Ivan Herman: https://github.com/w3c/wpub/issues/137

Leonard Rosenthol: propose closing issue 137

Tzviya Siegman: This is already in the draft

Rachel Comerford: Important for education, can’t just dismiss it

Leonard Rosenthol: UA can paginate or not

Garth Conboy: This is just UA paginating the content

Rachel Comerford: The use case for EDU which is real pages is in this section (use cases)

Ivan Herman: The real question is, pagination is important, UAs will do it how they want, but does the info set have everything the UA needs to do it?

Garth Conboy: We have spine, we have html, that can be paginated
… This issue is about UA paginating, we should close and make a new issue for going back to real pages

Tzviya Siegman: Page numbering != page layout (css)
… still need page numbering affordance

Joshua Pyle: Would like this issue
… Will say no more here. Will put it in github.

Deborah Kaplan: request we stop using the word pagination.

Benjamin Young: +1 to dkaplan3’s request for nuance in language about pagination

Tzviya Siegman: +1 to dkaplan3

Deborah Kaplan: should explicitly state what it means

Ivan Herman: +1 to dkaplan3

Marisa DeMeglio: +1 dkaplan3

Ivan Herman: #137 assigned to Josh

1.6. inclusion of data

Garth Conboy: https://github.com/w3c/wpub/issues/135

Tzviya Siegman: issue 135
… already proposed to close. Let’s do it!
… Vote to close

Joshua Pyle: +1

Ivan Herman: Propose: closing #135

Leonard Rosenthol: +1

Garth Conboy: +1

Wendy Reid: +1

Ben Walters: +1

Charles LaPierre: +1

Rachel Comerford: +1

Reinaldo Ferraz: +1

Benjamin Young: If data is included, can it be directly navigated to? Are we restricting by type?

Leonard Rosenthol: Resource list might want something to say what the resource is intended for

Ivan Herman: This will come up when we discuss structure later
… we need to add a way to specify the role, type, etc
… so we need an affordance

David Wood: Published documents are where data goes to die
… How do we cite, use, etc, published data?

Deborah Kaplan: Data management in scholarly publications is a massive problem that will not be solved by WPs, though.

David Wood: Suggest not closing this

Charles LaPierre: Size of the data may also be a factor here along with type.

George Kerscher: This issue impacts a11y
… eg chemistry formulas that can be manipulated

Ivan Herman: #135 assigned to David Wood, Benjamin, and Josh

1.7. Alternative modalities

Ivan Herman: https://github.com/w3c/wpub/issues/133

Tzviya Siegman: Alternative modalities issue
… enable audio books, graphic books, mixed media
… could have 2 in 1 (picture book with audio)

Garth Conboy: in the real world, audiobooks are whatever you get (hard drives, etc)
… But this is about multiple renditions, let’s not address it here

Ivan Herman: Still don’t understand what 133 says

Marisa DeMeglio: Having multiple media types [?] at the same time

Dave Cramer: Can an item in the default reading order be an audio file?

Dave Cramer: UA have proscribed behavior for dealing with raw audio files

Ivan Herman: Can we just require the entry point be html, and let the current standards handle the rest?

Dave Cramer: https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media

Avneesh Singh: This overlaps with 135
… need navigable audio

Benjamin Young: There is a text version, there is an audio version, etc, this is chapter 1

Garth Conboy: That is multiple renditions, let’s not do it

George Kerscher: Does this item deal with TTS?

Ivan Herman: Not really, since html already provides that affordance

Ivan Herman: #133 assigned to Marisa and Dave Cramer

1.8. Personalization

Tzviya Siegman: Issue 138. This has been beaten to death
… propose we close it

Garth Conboy: Close: https://github.com/w3c/wpub/issues/138

Avneesh Singh: Back to page numbers - are we splitting?

Tzviya Siegman: The assignee will split it

1.9. TOC without leaving the resource

Ivan Herman: https://github.com/w3c/wpub/issues/146

Tzviya Siegman: Issue 146
… thinks this is already accomplished
… but still need spec text

George Kerscher: Doesn’t understand scope of TOC? Authored? UA generated?

Tzviya Siegman: Generally authored, but could be generated, but always needs to be available

George Kerscher: Will TOC be required?

Ivan Herman: It is in the basic infoset

George Kerscher: Required?

Ivan Herman: No.

Tzviya Siegman: Thinks TOC should be required

George Kerscher: Is there just one TOC?

Joshua Pyle: Not happy there is a nav and manifest toc

Ivan Herman: Yes, there is a mechanism whose aim is that a TOC appear only once

Ivan Herman: #146 assigned to Tzviya

1.10. Search

Tzviya Siegman: Issue 149, search

Ivan Herman: https://github.com/w3c/wpub/issues/149

Benjamin Young: Search as a service, and an affordance
… what do we need to know as a publication to enable search?
… What is navigable? etc

Ivan Herman: Search in UA and search somewhere else on the web
… need to separate these two. Search service is out of scope.
… we need to look at local UA search

Deborah Kaplan: tzviya +1

Tzviya Siegman: Who wants this item?

Leonard Rosenthol: Will take it

Ivan Herman: #149 assigned to Leonard

2. Structural properties

Tzviya Siegman: https://w3c.github.io/wpub/#infoset-structure

Ivan Herman: For structural properties, we have two different categories of issues. Structural properties under different headings are links to various types of resources.
… Before we discuss the details of these lists, we need to talk about how we reference these types of resources. A simple URL may not be enough, and we need to define how we handle these links in general.

Leonard Rosenthol: what is table of contents in this context?

Tzviya Siegman: TOC is the primary method of navigation for most users, generally left to the author or publisher to define

2.1. General format of links in the manifest

Ivan Herman: the first question–how do I represent external links in json manifest? Do we need to require a media type? Do we need additional metadata like required/not, etc.?

Dave Cramer: "spine": [ "a.html", "b.html", "c.html", "d.html", "e.html" ]

Dave Cramer: {"href": "c001.html", "type": "text/html", "title": "Chapter 1"},

Benjamin Young: or more completely "spine": [ {"href": "c001.html", "type": "text/html", "title": "Chapter 1"}, {"href": "c002.html", "type": "text/html", "title": "Chapter 2"}]

Dave Cramer: pasted above are a few possible serializations of resource links, either simple, or with additional metadata. I don’t want to reflexively take on the complexity of EPUB where we have to look up mime types for every resource type that does not benefit the author.
… I want to avoid making the simple case that complex. For cases like Moby dick, repeating mimetype more than 100 times is not great

Tzviya Siegman: we need to take into consideration things like CSV files. Is it too hard for a machine to understand that .CSV is a CSV?

Brady Duga: I have no intention of using the media type for primary cases. There may be cases where we need the media type to skip things like images.

Benjamin Young: What would you expect with this URL: https://github.com/BigBlueHat/this-is-not-a.pdf ?

Benjamin Young: these lists need to afford some functionality for users. The model for the web is that the browser only cares about things like types when it tries to render the actual content. It doesn’t guess from the URL or anything provided by the user.
… there are additional things like type=”text/csv” where a browser can be informed in advance of more information. Browsers will still render the format detected after following the link, even if it’s different than the type declared in the link.

Joshua Pyle: I have a dream of a single file web publication. Originally, web pages were linear simple entities with an ordered hierarchy… I hope that that for simple cases, I can tag the HTML to support features like navigation without having to create external resources, repeat structural data, etc.

Ivan Herman: Right now, we can do a one file publication (by putting the data in a script element in the page). My proposal for links from the manifest is that references can either to be a URL directly as a string or an object that may contain additional metadata about the link.
… we can work out details about whether we use various rel/extended vocabularies for specific features like cover or privacy policy, but we need a mixture of simple and complex references to enable these scenarios.

Dave Cramer: "spine": [ "a.html", { "href": "b.html", "media-type": "text/html", "rel": "toc" }, "c.html", "d.html", "e.html" ],

Dave Cramer: +1 to Ivan

Leonard Rosenthol: in the spirit of using elements of schema.org whenever applicable, there are some existing schemas that may apply to resource lists/files, etc. pasted here.

Leonard Rosenthol: http://schema.org/StructuredValue

Leonard Rosenthol: http://schema.org/fileFormat

Zheng Xu: just to clarify: TOC is not reading order, and things like media type is less important for TOC, more important for the core reading order. For example, we use metadata about resources to determine how to load resources–to include MathJax, for example
… media types can be helpful for cases where UAs need to understand content types without loading all of that content

Luc Audrain: For accessibility, we need a real navigation list which is not the same as visual content.
… book content comes in the form of multiple HTML files, in contrast with scholarly publications. Whether or not this is required for performance, this is how content is created, and being able to represent that in metadata is necessary.

Benjamin Young: mixing flat strings and JSON objects in the same arrays makes parsing difficult.
… we should require the most minimal set of data possible. When something like a TOC can be reasonably inferred from a reading order, we shouldn’t require publications to specify the TOC separately.
… we should map these decisions to use cases and affordances whenever possible so that future reviewers and implementers can understand how these types of data should be used.

Dave Cramer: “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.”

Ivan Herman: If I have a choice between making authors and authoring tools or UAs more complex, I choose to make UAs more complex if it makes the life of authors easier.

Proposed resolution: URLs in the “manifest” can be represented as either JSON strings or objects, where the string is interpreted directly as a URL. A list of URLs can thus be represented by an array of either strings or objects. (Dave Cramer)

George Kerscher: have we defined the starting position for reading a publication?

Tzviya Siegman: not yet

Ivan Herman: we can explore whether schema.org vocabularies apply to this or not

Benjamin Young: I’m concerned that we’re creating a hypermedia format, there may be unexplored implications with JSON-LD, etc

Dave Cramer: https://github.com/dauwhe/html-first/wiki/WPUB-examples#

Ivan Herman: to clarify, this discussion and proposal are about a list of “stuff”/resources. We’ll talk about specific lists like the reading order separately.

Garth Conboy: “What Dave is on the board: “stuff”: [ "a.html", { "href": "b.html", "media-type": "text/html", "rel": "toc" }, "c.html", "d.html", "e.html" ]

Benjamin Young: if we limit this to the reading order and it doesn’t take on things like title attributes, it’s ok. There may be implications to complexity beyond parsing to mix objects and simple strings. Things like identity can become complex.
… so, I want to see clear affordances that explain the requirements for these data

Marisa DeMeglio: we have a lot of additional considerations around accessibility once we talk about how these lists are used, but that’s later. Mixing objects and strings in lists like this seems to be common in various other places that JSON is used.

Ivan Herman: +1

George Kerscher: is there a reason not to require objects in all cases?

Leonard Rosenthol: +1 to garth

Joshua Pyle: +1 to JSON

Garth Conboy: +1

Charles LaPierre: +1

Luc Audrain: +1

Dave Cramer: +1

Benjamin Young: -0 (in favor of moving on)

Tzviya Siegman: +1

David Wood: +1

Zheng Xu: +1

Wendy Reid: +1

Reinaldo Ferraz: +1

David Stroup: +1

Romain Deltour: +0 / +1 (for the same reasons as marisa)

Marisa DeMeglio: +1 depending on where this gets used

Garth Conboy: various people would be unhappy, particularly those people trying to create the simplest web publications.

Resolution #2: URLs in the “manifest” can be represented as either JSON strings or objects, where the string is interpreted directly as a URL. A list of URLs can thus be represented by an array of either strings or objects.

2.2. Default Reading Order and TOC

Dave Cramer: the fundamental thing we need for a WP is a default reading order which affords navigation through a web publication, and it’s the most fundamental piece of the web publications spec.
… there needs to be a mechanism to determine the next and previous resources to render. There are other alternatives in the world that haven’t be used too widely like
… a resource list in a manifest is a clear way to do this
… browsers can recover from situations where metadata may be incorrect. For example, if a list says that a resource is HTML, but the item served to the UA is a jpeg, the UA will rendered a jpeg.

Garth Conboy: “spine (or a term to be named later)”: [ { "href": “cover.html”, "media-type": "text/html", "rel": “cover” }, “a.html", { "href": "b.html", "media-type": "text/html", "rel": "toc" }, "c.html", "d.html", "e.html" ]

Garth Conboy: this is an example of a reading order…simplified to avoid discussions around things like can a resource be an image or not.

Marisa DeMeglio: +1 rdeltour

Romain Deltour: we need to consider how the UA will expose reading order in the DOM, and how this will be abstracted to the User/UA

Dave Cramer: + ∞^∞ to Romain

Zheng Xu: +1 to DOM API

David Stroup: we need to see what user agents will do/require/etc. and talk about implementations.

Dave Cramer: there’s an existing HTML element that already represents data like this–the nav element. Perhaps defining the API on top of the resource list can account for the various types of publications/creators/etc.

Leonard Rosenthol: the DOM is the document object model, not a higher level concept that doesn’t exist today.

David Wood: +1 to leonardr

Leonard Rosenthol: it is the right thing and a logical extension of the DOM today, but it’s a big leap from what exists todya

Tzviya Siegman: we’re not able to do that

Leonard Rosenthol: if we don’t do that, it’s not clear how that information is useful and can be exposed through APIs if there isn’t a concept beyond DOM

David Wood: The reverse is even worse: If we presume that the DOM represents a super-DOM concept, then we break the model.

Zheng Xu: reading systems can create/inject APIs to represent things like reading order

Leonard Rosenthol: +1 to DavidWood!

Zheng Xu: information on things like TOC also needs to be inferred by reading systems, whether that’s simple or inferred from external resources

Garth Conboy: https://w3c.github.io/wpub/#wp-default-reading-order

Garth Conboy: the existing spec draft allows both the default reading order and navigation

Leonard Rosenthol: https://w3c.github.io/wpub/#processing-reading-order

Ivan Herman: we may simplify the existing algorithm to require that the nav/TOC be in the start page, but otherwise, we have a plan/solution

Tzviya Siegman: what’s the purpose of the API proposed by rdeltour?

Romain Deltour: to expose data like reading order in an API

Ivan Herman: it may be interesting to define this information in IDL, but we shouldn’t say that it’s part of the DOM

Romain Deltour: I think it’s important to require user agents to expose this information in APIs. The serialization of these lists is less important than the APIs that will be exposed.

Garth Conboy: serialization is the best we can really talk about now without having many browser folks around the table who can talk about APIs in the DOM/super DOM/etc.

Dave Cramer: “The WG will specify Web Publications and identify what they need the underlying Web platform to provide. “

David Wood: adding API requirements for user agents may be way beyond the scope of the WG. +1 to Ivan, and we should move the conversation away from DOM and super-DOM.

Leonard Rosenthol: we do need to describe “data structures”–a standardized way in which the material that goes into the publication is manifested conceptually in a UA so that it can be used for various affordances.

George Kerscher: beyond the default reading order, are we planning on having lists of secondary resources like CSS, etc.?

Garth Conboy: The bounds of a publication for things like online/offline are separate from the default reading list and also important for publications.

Dave Cramer: https://www.w3.org/2017/04/publ-wg-charter/

Ivan Herman: we should be careful about revisiting fundamental philosophical questions. We currently have a default reading order defined in the spec. We should move forward to define how other structural resources will be defined in the manifest.

David Wood: Our charter says, “The WG will specify Web Publications and identify what they need the underlying Web platform to provide.” My reading of UAs being out of scope hinges on my interpretation of the term “Web platform” - The Web platform does not include UAs, nor their detailed implementation requirements such as API support.

Romain Deltour: @DavidWood ok thanks. The Web Platform does include defining APIs of course, so I still think it’s in scope

Ivan Herman: We may want to extend the spec to define the algorithms to interpret each list of resources we’re describing and build a conceptual representation of that data, but not APIs.

Dave Cramer: should we discuss what we’re calling these lists?

Tzviya Siegman: not today

Tzviya Siegman: attempt to locate a table of contents in the default reading order (e.g., an HTML document with a nav element that has the role attribute value doc-toc);

Tzviya Siegman: use the titles of the resources in the default reading order;

Tzviya Siegman: calculate a table of contents using its own algorithms.

Garth Conboy: https://w3c.github.io/wpub/#wp-table-of-contents

Tzviya Siegman: question: do we like this method? do we have other ideas?

Marisa DeMeglio: The language around user agents may be backwards. I would stop short of saying that the user agent should/could derive a table of contents if not provided.

Romain Deltour: +1 to marisa

Charles LaPierre: +1 as well

Benjamin Young: Defining the TOC from the reading order is backwards, would not be accessible, and is generally bad. The opposite is not true, so it’s reasonable to derive a reading order from the more complex TOC.

Joshua Pyle: if there’s a nav element on the entry page, then that is sufficient.
… if that data can’t be found on that page, then we need things like the JSON-LD manifest to give user agents a way to find the information.
… we should be careful if we’re muddying accessibility and structural semantics. Is role=doc-toc ok for this purpose?

Marisa DeMeglio: if the reading order is “c1.html”, “c2_part1.html”, “c2_part2.html”, “c3.html” .. and the TOC is “chapter 1”, “chapter 2”, “chapter 3”, then deriving the reading order from the toc won’t work.

Tzviya Siegman: it’s acceptable in this case as long as it’s on a nav element, though check with me for all other mixes of ARIA+structural semantics

Zheng Xu: can we force the TOC to include all of the items in the reading order?
… for navigation features like scrollbar, we can use TOC to give the user an indicator of where he/she is.
… to do that well, we need all of the resources in the TOC. Can we include this requirement?

Tzviya Siegman: we can’t require this universally, but it may be a best practice

Dave Cramer: if we’re going to derive the reading order from a nav element-based TOC, all resources in the reading order do need to be specified there.

Avneesh Singh: we seem to be revisiting the same discussion we’ve had on github. Also to clarify, we did not decide on the relationship between structural and accessibility semantics in the DOM.

Proposed resolution: Delete items 2 & 3 from section 3.4.3, and modify 1 so that it is clear how to find the nav. (Brady Duga)

Hadrien Gardeur: the reason the processing sections are so complex is that we’re allowing the reading order be derived from the TOC. There’s also a big risks that UAs derive this data differently.
… there’s a risk to letting UAs guess these things given their importance

Benjamin Young: https://github.com/w3c/wpub/pull/200

George Kerscher: Reading order is the most fundamental thing for accessibility. The TOC doesn’t necessarily improve accessibility, and a badly formed TOC can make accessibility worse.

Benjamin Young: our list of requirements is really just the address based on prose in the spec. Particularly for a single page publication, nothing else is required.

Hadrien Gardeur: my take is that the reading order is a requirement from the infoset perspective, but if you don’t include it in the manifest, we can have a true fallback (not a failure mode) where the web publication URL is the only member of the reading order.

Luc Audrain: +1

Ivan Herman: +1

Tzviya Siegman: +1

Hadrien Gardeur: we should clearly separate the requirement for a reading order in the infoset from whether it’s required in the manifest

Luc Audrain: +1

Tzviya Siegman: returning to the proposal from duga…

Brady Duga: what if my start page is a cover and I don’t want to a nav element there?

Ivan Herman: in that case, put it in the manifest…the nav elements makes sense sometimes like in the case of a single page publication

Hadrien Gardeur: I think identifying where the TOC is located is similar to identifying what is a cover, what is a privacy policy, etc.

Garth Conboy: we’re saying that the actual contents of the TOC are not included in the manifest

Deborah Kaplan: index is confusing to book people

Deborah Kaplan: can it get a qualifier?

David Stroup: I need to leave so I leave you with this…manifest needs to: specify where the toc/nav is if it exists, specify the start reading page, specify the default reading order…if it does this I’m happy

Leonard Rosenthol: scribe leonardr

Garth Conboy: a few people have left but we’ll continue without them…
… but let’s spend some time trying to wrap up the issue pre-lunch. Then to a11y
… here is an attempt to come to resolution:

  • Reading order must be suss-out-able
    • JSON encoded
    • <nav> element in landing page (perhaps required to be identified from the Manifest)
    • single page publication, that’s it
  • TOC should be present
    • if present, it MUST be a <nav> element with doc-toc role
    • could be above <nav> element
    • could be pointed to from manifest

Garth Conboy: Q1. Am I correct that TOC should be present or is it required?

Marisa DeMeglio: authoring decision

Garth Conboy: should not must

Avneesh Singh: agreed, should is fine

Ivan Herman: clarification - what is the priority in the case of both? JSON first? (yes)

Luc Audrain: clarification - TOC as HTML nav element, yes?

Joshua Pyle: what about other elements with the same role?

Garth Conboy: only nav can have that role, yes?

Benjamin Young: we don’t say where to find the TOC - so where?

Garth Conboy: going deeper may diverge from consensus. The nav is in the entry page or from the manifest (JSON)

Romain Deltour: just a reminder that doc-toc doesn’t have to be on a nav, it could be a section or div, FWIW

Benjamin Young: subpoints above are “alternate storylines”

Leonard Rosenthol: dauwhe is wavering

Garth Conboy: but I thought you and ben walters to have least duplication

Garth Conboy: one nav to rule them all would be possible with this model

Dave Cramer: competing demands on complexity (or lack thereof)…current EPUB “drives me nuts - I mean it!”
… machine understanding != human understanding. So which should we focused on?

Garth Conboy: I am fine removing item #2 (derive from nav)

Leonard Rosenthol: ivan doesn’t understand dauwhe’s objection

Brady Duga: As someone who just implemented audiobooks, I wish I had had HTML ToCs

Ben Walters: earlier on we talked about the split between humans and machines, and that as a UA we want to keep it as simple as possible for them to implement to ensure consistency
… a single page as the only reading order is logical and simple - but nav just complicates everything
… it doesn’t really have the proper semantics there

Hadrien Gardeur: +1 about reducing complexity with less options

Leonard Rosenthol: ivan asks the same question again - what do you want instead?

Garth Conboy: – Reading order must be suss-out-able

Ben Walters: get rid of the nav option from garth’s options

  • Reading order must be suss-out-able
    • JSON encoded
    • single page publication, that’s it
  • TOC should be present
    • if present, it MUST be a <nav> element with doc-toc role
    • could be above <nav> element
    • could be pointed to from manifest

Garth Conboy: removes the sussing out from nav

Joshua Pyle: perfectly OK with this option

Hadrien Gardeur: +1 to what BenWaltersMS just said, same thing that I’ve proposed before

Benjamin Young: I understand the concerns with getting nav correct for this purpose, BUT the advantage of having is around random access
… for multiple modes of access, but you need labels not just values. If you need to do is somewhere, we may put too much in the JSON
… assumption is that a UA is displaying HTML from which the nav is extracted. but that may not be the case in all UAs
… maybe we can then list out where this breaks (or is more problematic)

Ivan Herman: so what do you want?

Garth Conboy: reading order is a MUST. the difference is that in one case you can “suss it out” from the nav

Ivan Herman: let’s put an end to this once and for all!

Luc Audrain: I want what I want!
… JSON is the machine readable version of the reading order. (machine processing of nav is not viable)
… this is different from the TOC
… doc-toc can also be on a section and not just the document
… and with HTML we also have a11y and other features w/o any duplication for the TOC (that are not necessarily needed for RO)

Ivan Herman: so you support second version (nav only for TOC)?

Luc Audrain: Yes

Rachel Comerford: leonardr: I also agree for the same reasons as laudrain

Rachel Comerford: …the second proposal is better

Jean Kaplansky: May be stating the obvious: a11y is dependent on a TOC to allow the user to determine RO - we need to think about the publisher’s prescribed reading order vs. the user’s chosen reading order. They are not always the same.

Romain Deltour: let’s think about what we are trying to spec. there maybe a TOC but what if the TOC doesn’t use the role? It’s not compliant?

Ivan Herman: great question - but probably a bit too early for today

Romain Deltour: we need to understand this now to understand the spec’s usefulness up front

Option No. 1

  • Reading order MUST be suss-out-able
    • JSON encoded
    • <nav> element in landing page (perhaps required to be identified from the Manifest)
    • single page publication, that’s it
  • TOC should be present
    • if present, it MUST be an element with doc-toc role
    • could be above <nav> (likely) element
    • could elsewhere pointed to from manifest

Option No. 2

  • Reading order MUST be suss-out-able
    • JSON encoded
    • single page publication, that’s it
  • TOC should be present
    • if present, it MUST be an element with doc-toc role
    • <nav> (likely) element in landing page
    • could elsewhere pointed to from manifest

Garth Conboy: i agree that we need UA and doc conformance statements and handling

Luc Audrain: Hadrien, but only one doc-toc doc

George Kerscher: real world today - I’m in a pub, I hit “H” and it takes me to the next heading and from there to the next, etc.
… I get to the end of the chapter and now hit (something) to go to the next file in the thing
… it would be great if the UA could just take me to the next H in the next document in the reading order
… so then it gets the ntext file from the RO list
… and I can always use the TOC to navigate that as well.

Garth Conboy: all correct!

Dave Cramer: I agree with rdeltour - we need to define some of this error handling early

Option No. 2

  • Reading order MUST be suss-out-able
    • JSON encoded
    • single page publication, that’s it
  • TOC should be present
    • if present, it MUST be an element with doc-toc role pointed to from manifest
    • <nav> (likely) element in landing page
    • could elsewhere

Dave Cramer: I like this option #2 much better, especially the links with nav

Proposed resolution: go with Option No. 2 for on the Toc and the Reading Order. (Ivan Herman)

Garth Conboy: (reading out option #2 above prior to vote)

Tzviya Siegman: +1

Ivan Herman: +1

Dave Cramer: do we need to say where it might believe?

Dave Cramer: +1

Garth Conboy: +1

Garth Conboy: yes but let’s start with this point first.

Rachel Comerford: +1

Romain Deltour: +0

Benjamin Young: +0

Luc Audrain: +1 to option 2

Leonard Rosenthol: +1

Ben Dugas: +1

Jeff Buehler: +0 I’m a bit uncertain on this point still.

Joshua Pyle: I think this can be made simpler…and I’ll help get it into the text

Charles LaPierre: +1

Joshua Pyle: +1

Tzviya Siegman: why are there zeros?

Ben Walters: +1

Zheng Xu: +1

Wendy Reid: +1

Romain Deltour: I don’t strictly object but I don’t think the text there is the best text (or that it is complete)

Garth Conboy: I agree - we’ll fix it in the spec

Leonard Rosenthol: <there is a debate on whether we did/should vote on them separately>

Garth Conboy: so no votes against…

Tzviya Siegman: lets tweak the text in the next week and move on to new subjects…

Hadrien Gardeur: we really need to separate these two. RO is well defined but TOC not so much
… TOC is super vague w/ many things we haven’t covered.

Garth Conboy: we know that it is vague and it needs more work. We nominate Matt to work out some more formal text

Ivan Herman: voting on general direction so we can move on, PLEASE!

Hadrien Gardeur: we are saying that TOC is only in HTML, yes?

Garth Conboy: yes

Hadrien Gardeur: but what about audio or comics, there’s no HTML
… same with entry page

Garth Conboy: I agree but I believe that this will be handled with a separate HTML+TOC (but not in reading order)
… this is why our (currently) high level framework is a good starting point

Resolution #3: go with Option No. 2 for on the Toc and the Reading Order.

Jeff Buehler: quick question. Have you specified what this RO would look like?

Garth Conboy: yes we did that before lunch with some basic JSON

Dave Cramer: "spine": [ 'a.html', 'b.html' ]

Hadrien Gardeur: since we are talking about serialization…there are many outstanding issues

Tzviya Siegman: yes, we know. future work

3. A11y & Ace & SMART

Avneesh Singh: thank you for putting this on the agenda

Romain Deltour: ACE is the compliance checker for EPUB. SMART is a web app for full a11y audit on an EPUB
… they also generate reports as well as the properties that should be added to the publication’s metadata
… Ace from January (command line tool + installer + minimal GUI to come)
… Mac, Win, Linux

Avneesh Singh: also thinking about sophisticated GUI for those that would find it useful (long term!)

Charles LaPierre: working on a wizard for publishers to make accessible epubs
… started with a web-hosted version of Ace for those that don’t want to run the CLI
… plus a “How do I do X?” type of section
… this would be your “one stop shop” for finding this type of info (also gathering from DAISY and other places)
… and there is also a way to ask questions of real people

Romain Deltour: for the record DAISY’s KB is at https://kb.daisy.org

Leonard Rosenthol: will this only be EPUB or other formats?

Charles LaPierre: we should talk about other formats, but seems reasonable

Ivan Herman: very impressive tool.

Charles LaPierre: Benetech is considering building a certification service around this work that should happen soon
… and then be able to put them in a standard location for a11y books

Luc Audrain: in France we require EPUB3 and it must pass Ace (for Hachette Livre imprints)

George Kerscher: Ace++/sophisticated interactive tool would have a lot of useful stuff for training and debugging

4. Implementation strategies

Tzviya Siegman: what are we doing with this spec? does the implementation matter?

Tzviya Siegman: we’d like to mostly brainstorm

Ivan Herman: hopefully exploring this will help frame discussions

Hadrien Gardeur: for Readium and specifically Readium-2 we already have plans for implementing whatever we create in this group
… plan is to create this for desktop apps, mobile apps, and also web apps
… outside of the Readium community, other people are interested in doing this as extensions in browsers
… this means at least 3 types of implementations: native, web apps, and web extensions
… and just to give you an idea of the implementations is
… we have a manifest which is different but pretty close
… and currently we don’t see any gap in infoset items between WPUB and our manifest
… so we’d treat them like EPUBs as a thing we can consume

George Kerscher: so, you would convert WPUB format(s) into your internal format?
… or would you move your internal file format to be the same as this

Hadrien Gardeur: that’s a good question
… I think it’s really too early to say anything about that
… one big difference, is that we want to support EPUB 2 and 3 fully
… and that means a number of items we’ve not discussed fully in this group
… media overlays, etc
… I’m not sure if we’ll be able to address them or not
… without that knowledge it’s hard to say if we can use it internally

Ben Walters: so, I can’t speak for browsers in general, but I think when implementing as an extension or whatever
… can those things use HTTP headers, etc.
… consequently, we should be careful to avoid things that might prevent anything that would prevent stuff being implemented via a Web extension

Zheng Xu: so…for Readium, how can users actually switch to Readium reader based on browsing?
… a native browser will already pick up the index or first page of the book
… and possibly go into reading mode
… how do we then move into a separate app?

Hadrien Gardeur: not sure if that was for me or the group
… but you’re right that it’s a very good question
… depending on the context, things are going to be very different
… it’s not possible for a native app to discover if there’s just a link in an HTML document
… you won’t be able to say, my native app should be able to do something about this
… that said, there are situations where this would be possible to do this
… one option to get around this is OPDS
… where you can identify the media type of the manifest
… and then open the right app for that media type

Zheng Xu: I wonder if we can define something in the specification
… that explains how to switch between the user agents
… I want to avoid experiencing it in one thing preventing someone moving to a different system
… or ideally we would enable that through some special link or something
… think there’s a tension between how to implement it and how to specify it

Hadrien Gardeur: it’s really really hard to talk about things in general, and it’d be easier to talk about certain types of UAs

Zheng Xu: right now, we’re exploring how things are different between browsers and other UAs
… but we are looking for how to define a Web Publication in the same way that can be used in both
… second question is, how do we test it?

Wendy Reid: I’ll be the first to admit that as a reading system developer, we’ve not begun to talk about how Web Publications will be used
… our expectation is that Web Publications will ultimately just like EPUB2, 3, etc.
… and we’ll just be reading stuff from their new locations in different files

Avneesh Singh: just bringing in a bigger picture.
… we started with the dream of bringing reading into the browser
… but now we seem to have moved away from this and back to reading systems

Ivan Herman: I think we want to be realistic about this
… the only way the browsers will ever look at this thing is if they have existent proof that there are enough materials that are out there
… and therefore they see it as a “big enough” market
… and might implement something that we need
… my personal feeling is the source that may be the biggest push in that direction is Scholarly Publishing
… it’s on the Web today
… and not on the ereaders today
… so it is the biggest single type of content that’s on the Web produced by publishers
… then there’s also magazines, journals, etc which are on the Web
… I believe that it’s only once that market exists that the core Web engine manufacturers will look at this stuff and care about it
… Also, we should not mix up the core Web engine manufacturers and the “browser vendors”
… as there are many browsers, but a much smaller set of actual engines
… for instance, I use Brave, but it ultimately uses Blink as it’s engine
… BenWaltersMS I don’t know if you have a different opinion

Ben Walters: in general, I think everything you said was right
… and maybe I can add a little bit more detail
… when we look at features like this, they look at similar things over time that haven’t ultimately panned out
… implementing new experiences and reading modes, is very expensive
… especially if you’re the layout mode
… or if there’s not JS API…how do you test for it?
… so, it’s absolutely right that there should be some sort of market viability
… as well as a significantly better experience than what’s providable today
… in this case, it’s absolutely not clear if this spec is for the browser or something that lives outside of it at the app level or something near it like an extension
… we’d be using things via the app and maybe using parts of the web platform depending on how we’re implementing it
… so things like CSS layout changes would ultimately dictate all the approaches
… but other things may not
… regardless, it’s a big big problem…and you’ve been thinking about it the right way

Tzviya Siegman: ivan said what I wanted to say about Scholarly Publishing
… but one thing I’m wondering is will Kobo be implementing Web Publications?

Zheng Xu: we will be implementing an in-browser reading system

Tzviya Siegman: that’s great. do we need other things in the browser to make these better? and if so how does this effect the spec?

Zheng Xu: we do have the Rakuten reading system
… it’s a totally different system than Readium
… mostly because we didn’t have a spec that was ready
… and we can support many existing affordances
… but we do have the concern about how to encourage people to use our reading system
… we don’t have a big concern about a Web reading system vs. an app reading system
… I personally like a Web reading system
… so may main concern is switching between them

Hadrien Gardeur: so, I partially want to reply to this
… the easiest thing for a UA is either a media type or a file extension
… where you can then switch to a dedicated UA based on one of those
… so, essentially this will mean that somewhere on the entry page you will have a direct link to the manifest
… and without that you won’t be able to trigger an external reading app

Dave Cramer: I’m going to channel Rachel here: what problem are we trying to solve here?
… my company makes loads of publications
… what we’ve talked about so far sounds like EPUB
… I define something, I give it to you, and you display some reading experience you control and I don’t control
… the biggest problem I have with EPUB is interop
… some of that is the diversity of attempts to build certain features
… like font customization, etc.
… so Readium actually injects font information through the publication in order to render it in a user chosen font
… things like edge-to-edge display of content likely can’t happen in an EPUB-style reading system
… but on the Web, I as the publisher/developer, am ultimately responsible for the full reading experience of the publication
… to me, that’s sort of the promise of this
… but it’s also a really really heavy burden
… especially for publishers, who tend to terrible at such things and consequently piggy back on everyone else
… my fear is that we’re instead going to just continue the EPUB situation where we instead have very very little control

Garth Conboy: I guess I’d spin everything dauwhe said, but make it all positive
… I think users don’t want custom experiences from publishers
… they actually want someone to give them a consistent, limited experience
… in the short term I think they’ll be publisher driven experiences, but when we get to EPUB4 we would end up with a more standard set of tools
… and not end up back where we were with inventing things from whole cloth
… ideally with publications living inside a reader
… and how we’re going to package them and get them into the reading systems

Tzviya Siegman: as often, I have another total different answer
… scholarly publishing doesn’t use want EPUB
… and ultimately wants all the opposite things

Joshua Pyle: tzviya said everything I wanted to say

George Kerscher: I’d think that in terms of implementation, we Daisy, would want to provide earliest possible support
… as soon as the spec stops squirming
… if this is a Web publication, I’d want to know if there is ever an expectation to open it in something besides a Web browser
… and another question is the ToC
… it may not be able to provide things like affording searching
… but it could provide a lot of other things directly in the browser
… because it’s in HTML and would just work in a native browser

Joshua Pyle: I’d like to answer dauwhe’s posing of Rachel’s question slightly different than tzviya did
… there’s a lot of things that we want
… we don’t want a piratable packaged publication
… what we really really need is a device independent, reflowable, adaptive format
… that has the credibility of the PDF
… we really really need that for Scholarly Publishing
… ideally we want it to be the same publication used through all the things
… we don’t want to make a Kindle version and a Kobo version and a Readium version
… we want to make one version for all the things

Zheng Xu: I think when it comes to implementation strategy, it might be helpful to work straight for tests
… and focus on web browsers

Ivan Herman: my feeling is today (and yesterday), we’ve made significant process
… once all our homework is done
… we’ll have a much clearer set of affordances, and what to expect from them
… we’ll have the manifest in JSON
… it may not be the final one, or a perfect one, but it can be tested and experimented with
… so, we will have homework
… but it would be really really good if in a month we could publish and actually implementable specification
… so…break

5. PWP/EPUB4

Garth Conboy: We are going to talk about PWP and EPUB4, and infoset differences
… One of the things we have in EPUB is an exhaustive manifest, and we have a reading order and resources in WP
… We have ducked defining some of the use cases
… We do not have definitions for things

George Kerscher: Labelling things as linked external or internal, would be data for packaging

Garth Conboy: What is included in a package (images, videos…), we have not defined the bounds
… Internal or external, it is either a resource or an ancillary resource (external)

George Kerscher: If you have links to external content, and list it as internal, it should be searchable in a PWP, and should be packaged

Dave Cramer: { "address": "https://example.com/publication/", "spine": [ "a.html", "https://subdomain.example.com/common", "file:///Users/cramerd/Desktop/foo.html" ] }

Garth Conboy: Agree, but it is not yet defined

Leonard Rosenthol: The author should be able to declare what resources are packaged or not (WP or PWP)

Benjamin Young: Minimal WPUB page is up-to-date with today’s conversations–assuming publication has a stated reading order: https://github.com/w3c/wpub/wiki/Minimal-WPUB

Garth Conboy: That is the open issue of defining the bounds for the use cases for offlining or cacheing

Joshua Pyle: Are we working on two or three different specs instead of one?

Garth Conboy: Yes we have different specs

Joshua Pyle: Can we separate the use case documents to reflect the different specs

Ivan Herman: Once we have a package (PWP), the question is whether the manifest has an exhaustive list or not

Dave Cramer: { "address": "https://example.com/pub/", "spine": [ "a.html", "b.html", { "href": "c.html", "package": "false" } ] }

Ivan Herman: Once I have the PWP, however it is created, do I need more information in the manifest than what the existing content (WP) provides?

Garth Conboy: Having an exhaustive list (like in EPUB) is not necessary (we are exhausted…)

Dave Cramer: This depends on the packaging format

Dave Cramer: I think the google packaging format requires both an http request and the response, which would have to be exhaustive

Ivan Herman: no, the manifest itself would not have to be exhaustive, as the packing format has its own internal “manifest”

Dave Cramer: Ivan is right as always

Leonard Rosenthol: When you package a PWP, do we believe there are any extra items required since it was a WP, specifically the list of resources
… I believe the answer is that there will likely be more items required in the manifest of a PWP
… It would not be mandated in the spec, but should a PWP require digital signing, I would expect the information about the signature to be present

Tzviya Siegman: If additional items are required, what are they? We’re here to discuss that

Benjamin Young: Are we web then package, or are we packaging or webbing it? Two different things

Benjamin Young: Google method, meant for the web but a different place, intentions are not the same (no redistribution, sharing)
… Everything has a url, requestable and retrievable, everything must be on the web.
… Can we approach it as we can package or web it?
… The package puts them all in a single place

Garth Conboy: My take on that is we need to decide whether a PWP and an EPUB4 are different animals
… An EPUB4 must be creatable without being on the web before
… It is unknown if PWP and EPUB4 are one in the same, but an EPUB4 must be makeable without content being on the web before

Dave Cramer: I’ve experimented with the google package format, the files do not need to be on the web before packaging, make headers when you make the package

Leonard Rosenthol: WP, PWP, to EPUB4, each builds on the other
… One of the difficult things about PWP and EPUB4 is that we’re trying to build them simultaneously
… We might want to backburner PWP, and build EPUB4, which will then reveal what is needed for PWP

Garth Conboy: What might fall out of that is whether PWP is needed or not (Garth agrees with Leonard!)

Zheng Xu: Resource list might be restricted in PWP, for security reasons, or if the user wants to move out of the web
… The boundary list might differ between PWP and WP
… To EPUB4, I was assuming that EPUB4 was just a different serialization

Ivan Herman: (won’t be shooting Leonard) The reason we are having this session, to try to understand apart from packaging, is there any different between a WP and the content

Ivan Herman: We have to understand, for packaged things in general, there is no difference
… We don’t need a separate spec for google packaging, they are already doing that
… There is no reason to have a separate spec if it is already taken care of
… EPUB4 would be based on the same packaging format as EPUB, or we need to specify something else?
… Are there things in the manifest we do not have that we require for the PWP?

David Wood: I believe we came to agreement that WP gives us is boundaries, PWP gives us the packaging for the boundary to take it offline
… We don’t currently require additional metadata, we can accept it and move on

Tzviya Siegman: Are you agreeing we don’t need PWP?

David Wood: Not necessarily, taking it offline infers a format

David Wood: Do we adopt, adopt and modify, do something radically different?

Garth Conboy: We’re in wait-and-see

David Wood: You can access a WP offline in a web browser, if I were to do such a thing with curl, how would I do that?

Joshua Pyle: To answer your question, I don’t think anyone thinks that WPs will work like that in a browser
… I keep coming back to “packageable”, then PWP is like an abstract class
… EPUB4 becomes a sub-class of the abstract
… Leave it up to the packagers to create the non-abstract class that inherits from PWP

Brady Duga: Let’s go back to EPUB1!

David Wood: Why did we move past EPUB1?

Zheng Xu: I think this kind of content might exist for FXL content with embedded font, it would be difficult to provide as a WP
… Publisher wouldn’t want the font file to be exposed to users
… It can only be provided by a packaged format not WP

Zheng Xu: leonardr it need to be encrypted

Benjamin Young: That is an affordance of a packaged thing
… If it’s a zip or HTMLish file, you can’t move it once it’s in a container
… Until we know what those things are, we will have a hard time picking them, or if they’re the right thing for a problem

Benjamin Young: If we define what we will do with the thing once it’s in a container, we will know why
… I would support pushing PWP out farther

Ivan Herman: Would it be acceptable for the industry community if EPUB4 would be packaged WP? Same packaging format as EPUB3
… Or are there things that require tweaking by the community?

Garth Conboy: I think it would be ok, but we could also explore removing some of the restrictions

Ivan Herman: If we take EPUB4 seriously, there is something tangible there, this is question that needs to be answered

Garth Conboy: I think it’s ok to agree on the same content not being in there, but the same packaging

George Kerscher: Is a packaged WP going to contain all negotiated content?

Ivan Herman: The way you handle the content of the zip file is the same

Garth Conboy: Making PWP would be after negotiation, not before it, I thought

Benjamin Young: the concerns of content negotiation are different than file system concerns. Jeffery’s Web Packaging format does provide the ability to express a resource named “cat” which has Content-Type headers for an HTML representation, several image format variations, and even an audio format variation those could be referenced from <a href="cat"> or <audio src="cat"> or <img src="cat"> and the Web Packaging format provides enough information for a determination of which resource to load. Whereas the filesystem must use separate names for all those–which ultimately effects the shape of the content and the choices made by the author or publisher. the filesystem has no headers, and only uses filenames and file extensions; the Web has no file names and no file extension

David Wood: Benjamin put his finger on the key affordance, can my client store and read my content offline?
… I cannot share a WP like a PDF, I can’t pass it around
… It’s a feature for many, but not everyone
… It doesn’t matter on the complexity of the packaging format, the point is that I can download a PWP and pass it around as an entity
… The recipient does not need to get it from the publisher via a url
… It’s an important affordance
… The key affordance is the ability to pass a PWP around

Tzviya Siegman: We’re trying to understand the difference between PWP and EPUB4
… I don’t see a difference in manifest

Tzviya Siegman: We’re talking about moving in the direction of going to EPUB4 (PWP being the same)

Garth Conboy: Packaging a WP is a PWP, EPUB4 goes in a zip package
… If there’s a web packaging standard, and you package a WP, it’s a PWP

Hadrien Gardeur: You mentioned dropping some of the requirements, the main issue with EPUB is that there’s a whole lot of XML stuff and is complicated
… if we go down that road, we should consider plain ZIP

Jeff Buehler: +1 to Hadriens comment

Hadrien Gardeur: That said, we also need to consider that if we do that, we’ll need a new media-type and file extension
… With what is in EPUB 3.1 and 3.2, we can use the current packaging with additional requirements (like XHTML), making an EPUB4 that is backwards compatible

Garth Conboy: Those are details that we do not have time to resolve

Ben Walters: I agree in general with the premise that if we’re doing EPUB4 we should use simplified zip
… If Chrome implements WP support, you might also want it to open EPUBs as well, otherwise I agree

Ivan Herman: Yes but, realistically I don’t see the web packaging standard being out before the end of the WG’s life
… PWP is a concept, one way of doing a PWP is to take a WP and put it in a compressed tar file (not that I propose to do so!)

Ivan Herman: In the case of EPUB4, we have an obligation in the charter

Dave Cramer: If we want to ship this, and we still want to use script, the google web packaging signing is a key piece of a packaging format

Garth Conboy: The fact that you’ve signed your scripts doesn’t make a UA more likely to run them

Ivan Herman: The signature is fine, but there’s no spec that’s widely available/understandable, it’s not reliable

romain: What’s the possibility of not delivering a deliverable in the charter?

Ivan Herman: If we have a clear reason, we don’t do it

Garth Conboy: PWP as a thing we do not worry about right now
… We do need EPUB4, it has the constituent parts of a WP, packaged in a likely less restricted zip

6. Homeworks, plans

Tzviya Siegman: we have done a lot in these couple of days, here is summary. We do assigned a lot of home work. Hope can have feedback at June 15

Ivan Herman: we would like to have a new draft in this summer.
… using the template
… Maybe josh (and others) could help with Gibhub
… the other thing is the discussion we have today about structure of manifest we can put in

Dave Cramer: will add the json structure sample into spec

Ivan Herman: we need example for each infoset item

Benjamin Young: https://github.com/w3c/wpub/wiki/Minimal-WPUB

6.1. WebIDL

Hadrien Gardeur: I don’t think webIDL is much effected by this. To make process to parse json in manifest we can do different way. Js or native implementation such as swift, kotlin can handle manifest

Tzviya Siegman: ok, we have a number of open issue now and need to be assigned

6.2. closing issues

Ivan Herman: #168 I think can be closed

Ivan Herman: since it’s moved to WAM

Tzviya Siegman: #203 assigned to DavidWood

David Wood: I need to create user cases for privacy

Ivan Herman: there is still a number of issues about infoset

Ivan Herman: #178 => BenWaltersMS

Hadrien Gardeur: when I looked at epub 3.2 and infoset, I raised some points about difference I will continue looking into it

Tzviya Siegman: #168 is about manifest I believe to be closed

Tzviya Siegman: #162, is something about ONIX, we all agree with it’s important but we don’t have an idea yet

Ivan Herman: it's there, the thing is we need to find schema.org for it

Tzviya Siegman: #157

Benjamin Young: about #157 Web doesn’t have idea about keeping things long term

Ivan Herman: what is we can solve in this working group

Benjamin Young: https://github.com/w3c/wpub/issues/157#issuecomment-393668892

Ivan Herman: we can not build things that web can not solve today. It might be good to have this list but that’s all we can do now

Benjamin Young: I am closing it, and creating a separate list: https://github.com/w3c/wpub/wiki/Beyond-Scope

Joshua Pyle: I am actually not sure that publisher can have something that never changed

Tzviya Siegman: #145 close

Ivan Herman: let’s go to old issues. #3

Garth Conboy: I think this should join last issue with Benjamin’s page

Tzviya Siegman: #125 to Benjamin’s page as well

Benjamin Young: https://github.com/w3c/wpub/issues/125

Tzviya Siegman: #78 I think we all agree with audio book is important in this industry

Wendy Reid: we need a standard for it

Ben Dugas: we need a consistency for audiobook

Dave Cramer: audiobook, I agree with we need primary resource for audio book is important

Ivan Herman: we need information that we need this for audio book

Wendy Reid: I think it’s very important. Ppl asks about what is specification about audiobook

Wendy Reid: we have experience about what publisher sending to us

Marisa DeMeglio: would you be interested in joining synchonized media communitee group?

Tzviya Siegman: https://www.w3.org/community/sync-media-pub/

Marisa DeMeglio: we defined media overlay in epub but we still want to re-look into it.
… it would be great if ppl with experience to join in

Tzviya Siegman: for #78 we need to work on what is missing in epub

Benjamin Young: https://github.com/w3c/wpub/issues/78

Tzviya Siegman: #78 => wendyreid and laudrain

Tzviya Siegman: #73

Tzviya Siegman: should we close #73?

Marisa DeMeglio: why we need modification date

Ivan Herman: it’s necessary in some case. We need to know when content is reviewed

Benjamin Young: https://w3c.github.io/wpub/#wp-mod-date

Dave Cramer: epub actually has a whole section about it

Dave Cramer: http://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-metadata-elem-identifiers-pid

Garth Conboy: we don’t trust modification date

Garth Conboy: I think it’s overspecified

Joshua Pyle: can we just use web application such as etag about it?

George Kerscher: it’s useful for publisher progress such as review and others

Garth Conboy: but it’s unuseful for reading system

Tzviya Siegman: June 15 or end of June we would like to see homework done

7. Resolutions