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
(See further images of the meeting, thanks to Ben Dugas, Kobo.)
Content:
- 1. Affordances and use cases
- 2. Structural properties
- 3. A11y & Ace & SMART
- 4. Implementation strategies
- 5. PWP/EPUB4
- 6. Homeworks, plans
- 7. Resolutions
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 withdoc-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 anav
, it could be asection
ordiv
, 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 withdoc-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:
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
- Resolution #1: minimal metadata required for a shelf system to present a publication are: identifier and title OR cover. Remove Section 7.2
- 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.
- Resolution #3: go with Option No. 2 for on the Toc and the Reading Order