PWG Takes Toronto

Minutes are published at https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-05-30-pwg.html and https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-05-31-pwg.html.

The Publishing Working Group gathered in Toronto, Ontario for a 2-day face to face meeting at the Kobo office. This was Kobo's first time hosting a working group meeting, and they did a great job. Thanks especially to Wendy Reid who organized hotel discounts, restaurant reservations, conference rooms, and many other tiny details. She also learned to scribe :).

Our main goal for the meeting was to get the WP Draft and GitHub repo into a position such that we will be able to release an updated draft within about one month. We made a lot of decisions about both major and minor issues that are getting us closer to Web Publications.

Replacing epub:type

Tzviya Siegman offered a history of the IDPF's namespaced epub:type structural semantics vocabulary. Many key terms have shifted to DPUB-ARIA. We asked participants to offer information about how epub:type is used today. There were a few examples of uses for internal workflows, such as providing meaningful information about book structure for repurposing content. The implementors in the room made it pretty clear that the only terms in the very long list that they look at are toc, landmarks, pagebreak, pagelist, footnote, and noteref. Consensus is that DPUB-ARIA covers use cases that are beyond internal workflows, but there is a need for education about how to correctly implement ARIA.

Infoset

We reached consensus the minimum infoset. Luc Audrain reviewed the information set as it stands in the current draft, and we agreed that this is a good starting point. We have agreed that we will work in JSON-LD with schema.org as a starting point. We concluded that it is not necessary to list an exhaustive set of resources to define the bounds of the publication, which is defined by the default reading order. We will add a section about boundary determination to the spec. While it is very important to address privacy concerns in our specs, including a privacy policy in the minimum infoset will accomplish nothing. David Wood will add language to the specification regarding privacy and what a UA is expected to do when it encounters a privacy policy.

Manifest Serialization

We have long divided our manifest into descriptive and structural properties. We chose to focus on schema.org for descriptive properties. Using schema.org brings us to the decision to opt for JSON-LD. We discussed specifics of expressing metadata as schema.org properties using a table that Ivan Herman drafted. We will review similar work at Readium, Wiley, and the ScholarlyHTML Community Group to come up with recommendations. There was extensive discussion about topics such as how to ensure accessibility in a cover expressed as JSON-LD. There was much discussion about direction of metadata, titles, and other details to be discussed with the schema.org CG.

Affordances and Use Cases

Benjamin Young explained, "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." We agreed that we will provide information that allows for affordances, but we will not document such affordances. An example of this is the information of this is specifying the metadata required for a bookshelf but not specify how to create a bookshelf. We then moved through the open issues on Affordances in GitHub and assigned them to members. Each person will use the existing template from the Affordances task force and provide language to add to the specification by 15 June.

Structural Properties

We agreed that 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.

Default Reading Order and TOC

There was extensive discussion about whether the current spec language is clear enough about default reading order and whether it is better and/or good enough for both humans and machines. We eventually resolved that:

• The reading order must be detectable
• If the publication is made up of more than one file, the reading order will be JSON-encoded
• TOC SHOULD be present
• TOC MUST have role=doc-toc and be listed in manifest
• TOC MAY be any element with a doc-toc (in the rec example it is a <section>). It is preferred that this is applied to the  <nav> element.
• TOC may be pointed to from <nav> in landing page

(I may have gotten some of these details wrong.) Significant details to come as we work on the spec.

PWP/EPUB 4

We began the discussion asking what the differences in an infoset for PWP as opposed to WP might be. We drifted to a discussion of whether PWP is necessary as a standalone specification if EPUB 4 is simply a packaged WP. To be determined still is whether the packaging format will be the Web Packaging Format in incubation or some other format, such as a simple zip.

We ended the day assigning issues to individuals and planning to revise our documentation over the coming weeks. Thanks to all who traveled and participated, especially Kobo and their glorious doughnuts.

Publishing Working Group at the Kobo office