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.

Publishing WG Telco, 2018-02-26: WAM and Affordances’ task forces

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

Affordances Task Force

A separate task force on Affordances is set up, led by Jasmine Mulliken and Mateus Teixeira. It should first propose what exactly should be in the document for each task force (see also issue 143), and then address each affordance. The Use Case document should also be considered, as well as the (major) accessibility aspects.

Note that the goal is to concentrate on the publishing specific aspects only.

WAM Task Force

A separate task force on the relationship to the WAM is set up, led by Romain Deltour and Benjamin Young. The goal is to decide what should be added/modified on the WAM to make it viable for publishing, what aspects could be reused directly, initiate discussions with the WAM editors and the corresponding Working Group, as well as with the TAG. This TF will not (yet) look into the exact serialization of the manifest, though it may morph into it later.


Publishing WG Telco, 2018-02-12: WAM Overview, lifecycles, affordances

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

Short WAM Overview

Romain Deltour gave a short overview of the WAM, see minutes for the details. One issue that came up was if and how the internal representation of the manifest can be reached by various scripts, other than the User Agent proper. This may become necessary if, at some point, an extension or any kind of script is needed to implement a WAM functionality. However, the feeling was that it may be worth postponing this step until we have a better notion of the overall picture.


Hadrien Gardeur gave an overview of the latest addition to the WP draft, concerning the manifest lifecyle. The additions were as follows

  1. A WebIDL added to the appendix representing the infoset/manifest
  2. The lifecycle itself:
    1. Discovering/obtaining the manifest
    2. Processing the manifest (e.g., interpreting the JSON content and turn it into an internal structure)
    3. As part of the previous establishing the default reading order

If the WAM is used 2.1 would essentially disappear, and 2.2 would also be reduced using the extension point of the WAM. 2.3 is publication specific and relatively complex.

There is a pending Pull Request which includes some diagrams; there was a feeling on the call that it is worth adding those.


The new draft also reorganized and has now a section renamed as “Affordances”. A new one has been added on switching to “publication mode”, which includes switching to a mode with enhancements, and also a notion akin to bookshelves. The previous affordances have been reorganized, and user setting has been added alongside progressions (the UA needs to remember where the reader is).

One issue to be decided on is how the spec would define the affordances: is it more descriptive (a bit like CSS) or closely tied to API-s like many Web Platform specs.


There were also some discussion on how the spec should be organized on long term, should is stay monolithic or separate, eg, the affordances and the manifest. This is to be discussed further.

Chris Maden has accepted to act as a “Testing” champion, and is gather information and approaches on testing.

The Synchronized Media for Publishing CG is now up, join it!

Next week (19 February) is US Holiday, no call then.

Publishing WG Telco, 2018-02-05: Core issues raised by the TAG

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

The meeting was almost entirely devoted to some fundamental questions triggered by comments by the TAG: “…is the goal of this group to make a new packaging format for specialist book reading software and devices, or is it to obtain first class support for missing book-related features in the web platform as a whole? If the latter, then it is an order of magnitude more likely to be achieved by building atop existing platform features…”.

This question started an (unfinished) discussion on how to formulate that both targets are valid, what the relationships are with the Web Application Manifest (a.k.a. WAM) and the issue whether a publication should “carry” its own script to render/display the content (a bit like a Web Application does). There are several issues with this approach: the stability of the “publication”, the complexity to develop such a script for a publisher, etc. It is also important to emphasize that even if many requirements can be done by current Web Technologies, it is also the group’s goal to ensure that creating a Web Publication is easy for publishers, whether large or small. On the other hand, the reality is that such scripts should probably be necessary for the deployment of Web Publications on the Web, at least at first; the challenge is to use them without imposing too much on the publications (e.g., dedicated reading system could ignore them).

The discussion is ongoing on the mailing list and the issues’ list…

Publishing WG Telco, 2018-01-29: Packaging

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

The meeting concentrated on the Web Packaging specification draft; Jeffrey Yasskin, the editor of that draft, was a guest at the call.

T¡e spec is now divided into two parts. The part relevant to the publishing work is describing a set of signed HTTP request/response pairs from a given origin. There is a draft of this bundling proposal with a Pull Request ready for issues and comments. At the moment, this document is being produced within the IETF framework, but it may come “back” to W3C. Several issues were discussed on the call.

The spec includes a reference to a Web Application Manifest step, which the “top” of the media bundle. Its “start URL” term is used, for example. (It must be noted that the term “manifest” is a misnomer, because WAM does not list the content of the full bundle collection.) It is not yet clear whether the package should require a Web Application Manifest, or whether a more flexible mechanism would be allowed with other types of manifests. (For example, there were discussions with the Web Performance people on their own “manifests”.) Obviously, this is an issue for publishing, too. (Note that a publication related manifest would include an index of the constituent resources, i.e., the list of the bundles.)

The spec puts a strong emphasis on signing each bundle. However, that may not always work well with a WP/PWP environment where some of the content may come from a file system without having ever been on the Web. One way of handling this could be to rely on either a file: URL or (preferably…) on a simulated environment using a locally run small server and using localhost in the URL. In both cases it is not clear how the signature could be implemented without too much hurdle on the publisher. However, it turns out that the Web Packaging spec does not mandate a signature, so there may be other approaches to ensure the authenticity of the content. To be explored.

There were also some discussions about timing of the packaging spec. The publishing WG should produce a CR in about a year; the packaging spec may lead to a final draft around this summer. So that might work out…

This was certainly not the last meeting on the subject!

(And thanks to Jeffrey Yasskin for having joined the call.)

Publishing WG Telco, 2018-01-22: DPUB ARIA, Implementations & manifest lifecycle

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


Tzviya gave a short overview of DPUB ARIA 1.0: the ARIA group (together with the DPUB IG) took the EPUB SSV terms, filtered them, and put the most useful terms in the ARIA vodabulary. DPUB ARIA 1.0 is a Rec, complete with a mapping of the terms to the accessibility engines. The question is now: do we need a 2.0? Is what exists good enough?

The subsequent discussion made it more clear that there is a difference between semantic types (body matter, back matter, indexes) and the accessibility features. ARIA is primarily for accessibility, ie, this distinction is important. In other words, there is a need for a clear a11y reason for any new terms.

Two outcomes of the discussions:

  1. There don’t seem to be a lot of items people see as compelling to add to ARIA. The community should provide feedback on this (e.g., using the separate dpub-aria repository), and the group can then decide. It may well be that DPUB-ARIA 2.0 is only a few additional features (plus errata management)
  2. There is a lack of approach for semantic information being added to a publication. This group is not chartered to provide one, but maybe a separate Community Group could be set up to explore that.

Implementations, lifecycle description

As part of the implementation review a first draft of a manifest lifecycle has been created, mostly based on the Readium Web Publication Manifest. That led to a separate discussion on github (see also issues #119 and #122). The lifecycle items was greatly inspired by the corresponding items in the Web Application Manifest (WAM) document, but it turned out to be different from the WAM. At the moment, there are some divergences between these, which must be well documented to back up any decision on the final relationship to the WAM.

A number of other issues are still to be discussed

  • how to incorporate the exact browsing context into the lifecycle management
  • what happens if a user hits a constituent resource of a WP that does not have a direct link to the manifest
  • the lifecycle draft has revealed the relative complexity of the default ordering (based on the WP draft), what to do about that

To follow…

Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2018-01-22: DPUB ARIA, Implementations & manifest lifecycle

Publishing WG Telco, 2018-01-08: Manifest encoding, prototypes, sync media

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

The group began the new year by publishing the First Public Working Drafts for WP, PWP, and Annotation extensions… A general outreach to the community should now be set up on the basis of these documents.

Manifest encoding

Hadrien Gardeur has made some early experimentations/prototypes in encoding the information set in JSON. Two experiments were done:

  1. Manifest as an extension of the Web Application Manifest, a.k.a. WAM (see Issue 118)
  2. Manifest cast into the the syntax defined by the Readium consortium’s Web Publication Manifest, a.k.a. RWPM (see Issue 119)

In both cases, a “Minimal Viable Manifest” have also been defined.

The general impressionn on #1 is that there is very little, in terms of terms, that a manifest can reuse from WAM, apart from a general encoding style. Most of the terms have to be defined for WP-s from scratch, and even some structures (like a general formulation for links) have to be defined. As was expected, the match with RWPM is way better. The question is, rather, whether the “additional” features of the WAM, in terms of installation, life cycle, security considerations, etc, can be reused as part of a WP implementation in, e.g., a browser. Extending a WAM would probably be beneficial only it that context.

This leads to the issue of WP implementation strategies…

Experimentations, prototypes

The WAM vs. RWPM, as well as all the other features mean that we need some experimentations in terms of implementations. There are a number of implementations that are based on RWPM (Readium 2 itself, but also epub.js, for example, or a tool developed at the NYPL). Atypon’s implementation is also based on Readium. We may have an experimental setup available from Norton.

At this point the group does not need full-blown implementations but, rather, prototypes that help us in setting the right decisions in technical issues like the relationship vs. WAM, the requirements regarding offlining, etc. The goal will be, therefore, to collect at these prototypes and analyze them asap.

Synchronized Media

As a followup of the discussion at TPAC on Media Overlays Marisa DeMeglio has set up a Synchronized Media Community Group to work on that subject separately. Join, if you are interested!

The group decided not to hold a telco next week, due to Martin Luther Kind day in the USA.