Publishing WG Telco, 2018-06-18: epub:type, affordances, toc in manifest

See minutes online for a more detailed record of the discussions.


There has been some discussion at the F2F of Toronto whether this group should deal with a new version of epub:type. Based on that discussion plus some further discussion on the call, the group adopted a resolution, whereby:

Since there are no implementations of epub:type other than internal workflows (beyond those [e.g., noteref, footnote] with solid ARIA mappings), do not move forward with broad replacements for epub:type.


There were lots of discussion on the term “affordances”, ie, whether the term is right, whether it is understandable, and whether the way it is presented in the current draft (i.e., a separate section on affordances) is the cleanest way forward. After these discussion the following approach has been adopted:

  • The individual affordances should be merged with the general description of information set, each infoset item should list the features it “affords”, linking back to the UCR document
  • No new examples/use cases should come to the WP draft; instead, the UCR document should be refreshed and updated.

TOC in manifest

The question of what term to use for TOC came up. While tableOfContents was proposed, the issue on whether a TOC is necessary as a separate item in the first place in the manifest came up. Two discussion points:

  1. If there is an entry in the manifest, it has to be one of the resources, not a separate term with its own structure.
  2. Maybe we do not even need anything if we just rely on the ToC in the entry page.

Discussions follow.

Publishing WG Telco, 2018-06-11: “Cover” in the infoset, JSON terms for reading order and resources

See minutes online for a more detailed record of the discussions.


It was not finalized what the exact representation of the Infoset item “cover” would be in terms of JSON-LD and Cover for a book may or may not be an image , ie, the purely image oriented terms may not be enough, and it is also up to the author to use, a resource used elsewhere, and whether it is in the reading order.

The alternative is to use cover as part of the structural items, ie, as part of the reading order list or the list or resources. The issue there is that the <a href="StructuredValue“> (which was considered as a generic type for such usage) type may be too restrictive in so far as it can only appear as the value of some properties, and there is no way to express something like the IANA rel values.

The decision was to define an alternative, and targeted, type to replace StructuredValue, and use that for, e.g., cover. That could also be used for, e.g., privacy policy. It was agreed to define such a structure as part of a PR on github.

Proposed context

The github discussion on various issues have brought forward the necessity to have our own JSON-LD @context file: own terms for resources and reading order, setting the order sensitivity for, say, author (i.e., "author": {"@container":"@list"}), etc. The context file is at:, with the official URL at (the latter is redirected to the former for now).

Bikeshedding on terms

The result:

  • the JSON-LD term readingOrder is used for the “reading order” infoset item
  • the JSON-LD term resources is used for the “resources” infoset item

Publishing WG Telco, 2018-05-21: Closing issues (WAM, JSON usage, context), list of resources

See minutes online for a more detailed record of the discussions.

Closing some open issues

The meeting closed three major pending issues:

  1. The WP definition will not specify a browsing context, is left to implementations (see discussion);
  2. The Infoset is primarily in JSON (a separate file or in an HTML data block) though, to avoid duplication, the information may be in the HTML entry page (see discussion);
  3. The Manifest is not based on the Web Application Manifest (which may be used separately by the author of a WP), (see discussion)

List of resources

There was a separate discussion on whether an exhaustive resource list is required to create a Web Publication (see github issue #198). One of the core problems around the issue is to define exactly what “offlineable” vs. “packageable” means, and whether WP-s should “disallow” these features or not. The separate question is what other areas are affected by the presence (or not) of this information set item.

The discussion will continue on the F2F meeting next week.

Publishing WG Telco, 2018-05-07: Scholarly Publishing UC, Browsing context

See minutes online for a more detailed record of the discussions.

Use Cases of Scholarly Publishing

Josh Pyle and Nick Ruffilo have begun to go through the UCR document (inherited from the DPUB IG) to review and refresh it for WG use. One particular area is Scholarly publishing. The overall impression on the UCR document, with regard to this branch of publishing, that some aspects are not emphasized enough: the importance of fidelity of content (mathematical formulae, chemical diagrams, etc), the fact that content is usually stored on the publisher’s site and not necessary downloaded like a book, issues around control of content, etc. One effect on the WP is that, whereas “offline” possibility is very important for Scholarly publishing, packaging less so (“offline” may be temporary, bound to one system, etc, whereas a PWP is not necessarily).

Work is onging.

Browsing Context for WP

An (older) issue 104 looks at the problem of “browsing context”:

“A browsing context is an environment in which Document objects are presented to the user.”

The question is whether a WP introduces its own context or whether it should simply rely on the context provided by the “landing page”. Noting that if WP defined its own “publishing” context, many aspects related to security, how content is acquired, etc, should be redefined. On the other hand a WP has its own “boundaries” in terms documents that are part of it, user interface/personalizations, etc, that may touch on this issue.

(The meeting ended a bit abruptly, because the telco system unexpectedly closed, the discussion is ongoing on issue 104.)

Publishing WG Telco, 2018-04-30: Affordances’ task force; Gaps from classic EPUB

See minutes online for a more detailed record of the discussions.

Affordances TF

The task force had a telco (see minutes), and established a template to describe individual affordances in the document (to be put on the wiki soon) and some affordances have begun to be formulated using the template.

Gaps from “classic” EPUB

A first set of “missing” entries have been listed in Hadrien’s comments. The main focus of the discussion on the call was what do we really need at this point: the various data in EPUB are spread in different places, and it was agreed that what we need is to identify what is missing in the infoset, without making decisions on how these items are implemented in HTML headers or Manifest items. It was agreed that the current list will be recast into a number of separate issues that are infoset related.

Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2018-04-30: Affordances’ task force; Gaps from classic EPUB

Publishing WG Telco, 2018-04-16: Review of WG’s Goals

See minutes online for a more detailed record of the discussions.

The meeting concentrated on one topic only, namely to help setting crisper goals to the overall work of the WG, in view of experiences from within the WG’s work, and also from the larger environment, e.g., the discussions at Pulishing@W3C leading to the work on EPUB 3.2.

The essence of the discussions items are perfectly summarized in a note sent to the WG before the call, no use of repeating here; overall, the note has been considered very positively during the call.

(On a related note, the blog on EPUB 3,2 by Dave Cramer, is also relevant to the WG’s discussion.)

Publishing WG Telco, 2018-04-09: F2F meeting planning

See minutes online for a more detailed record of the discussions.

F2F meeting planning

The meeting was short, because lots of people were on vacations. There is now a list of topics in the preliminary agenda of the upcoming F2F meeting. The main area of planned work are

  • Impact of the EPUB 3.2 work on the work of this Working group
    • also issues around the proper replacement of epub:type, for example
  • Finalize the information set, making the definitions more crisp
  • Hopefully a decision on the WAM vs. non-WAM issue for the manifest
  • Affordances’ task force results
  • Implementation/deployment strategies and its effect on the document
  • Report of the audio-sync CG plans and work
  • Packaging: what are the final infoset items needed for PWP (as opposed to WP only)
  • Homework for the months ahead

These items will be put into specific time slots in the coming days.

Publishing WG Telco, 2018-03-26: EPUB3.2 Update, Task force reports

See minutes online for a more detailed record of the discussions.

EPUB 3.2

This is just an FYI, as far as this WG is concerned.

The EPUB3 CG has put forward a proposal for an EPUB 3.2; (see previous overview for further details). This is now accepted by the Business Group and the work goes ahead in the Community Group. Interested parties should look at the github issues. There were some discussion on the call on how this information should be presented to publishers and how that work might affect the work on WPs. It has been agreed to add this item to the upcoming F2F meeting in Toronto.

Task forces

Small reports on the two major task forces’ work. (Last few weeks were conference heavy, meaning that the TF’s had some hiatus in their work.)

WAM task force

The TF has a call and set up a github “project”, with a triage of the accumulated and relevant issues. Some of the issues will be discussed further and may lead, eventually, to explicit issues to the WAM editors, others are set to be handled elsewhere (in another group or in this group). Next step is to look at the individual issues to formulate the right questions.

(See separate meeting minutes.)

Affordances’ task force

A separate document has been created to plan the work and there was a separate meeting setting up the goals of the work. The main issue is to establish the work to be done in general.

The main work is to establish what has to be said for each affordance in the final document. There is a separate issue that ended up with a more specific proposal; to be discussed further.

(See separate meeting minutes.)


  • There were conference repors on ebookcraft and CSUN
  • The list of possible agenda item for the coming F2F meeting is now online
  • No meeting next week due to Easter/Passover

Publishing WG Telco, 2018-03-05: DPUB ARIA, extensions, EPUB 3.2

See minutes online for a more detailed record of the discussions.

DPUB ARIA; general extensions

DPUB ARIA 2.0 is on the WG’s charter, but there were discussions considering what it actually means to be in the ARIA spec, and which EPUB vocabulary terms are relevant. We may not have any additions for DPUB-ARIA, other than errata; the decision might be to “simply” issue a DPUB-ARIA 1.1 version with the errata handled, and not go further.

The real issue is how to handle more general terms (e.g., those using epub:type in EPUB); those do not really fit well with the ARIA model. E.g., titles are elements that more definitely belong in HTML—it’s a non-structural label, at least how we have done it in EPUB (it’s not the title of the publication).

There was a longer discussion on how to react when, for suggestions like list head/caption/title, the reaction is “here is a polyfill, provide uptake”. In case of, say, accessibility related possible extensions this approach does not work, people invest only when there is a standard. There was some discussions on how to solve the different viewpoints: provide standard elements that people can use vs. the caution of browser engine creators to pick up too many incoming request. The answer may be to provide standard custom elements for communities, but that is still to be discussed further…

EPUB 3.2

This is just an FYI, as far as this WG is concerned.

The EPUB3 CG has put forward a proposal for an EPUB 3.2. The idea is to replace EPUB 3.1 by removing features that result in a backward incompatibility with EPUB 3.0. 3.2 would include the new features of 3.1 that does not create problems. EPUB 3.2 could also be put into an ISO standardization process.

At the moment, this is a proposal for the Publishing Business Group, which should decide on this within about 10 days. If it is accepted, the EPUB3 CG will work out and provide a new specification in the form of a CG Report.