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…

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.

Publishing WG has published three First Public Working Drafts

(Republication of a W3C Home Page News item.)

The W3C Publishing Working Group has published three First Public Working Drafts today.

  • The Web Publications defines a collection of information that describes the structure of Web Publications such that user agents can provide user experiences well-suited to reading publications, such as sequential navigation and offline reading. This information set includes the default reading order, a list of resources, and publication-wide metadata.
  • The Packaged Web Publications defines a packaging format for combining the resources of a Web Publication [wpub] into a single portable file.
  • The Web Annotation Extensions for Web Publications extends the foundational model that has been developed in the Web Annotation Model Recommendation by adding selector types applicable to collective resources and a new model component for describing positions in text and byte streams.

The Working Group welcomes comments via the GitHub repository issues (see the respective documents’ headers for the reference of the repositories).

Publishing WG Telco, 2017-12-18: Minor change on Locator doc, ARIA, end-of-year reflections

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

Minor changes on the Locator document

As a result of a discussion on github the document has been renamed (“Web Annotation Extensions for Web Publications”). The short name and, consequently, the repository name has also changed to wpub-ann.

There were also minor additions: there was a discussion on github on the fact that the fragment ID section make sense only if it is applied to a Packaged document but, at this point, we do not have a packaging spec yet. Ie, we do not know whether the group will be in control of a relevant media type. This fact has been emphasized in an editorial note (referring to the fact that the full section may have to be removed in future).

ARIA Review

The Digital Publishing WAI-ARIA Module has just been published as Recommendation. Tzviya used the opportunity to talk a little bit of ARIA in general. ARIA (Accessibly Rich Internet Applications) was written not very long ago to bring information to any language for accessibility and assistive technologies. It can provide information to the accessibility tree (which some of us don’t know exists!): you have the HTML object model, then in parallel is an accessibility tree that is provided to accessibility applications. There are even accessibility APIs that feed into applications that need. The most important thing to be aware of is that if you don’t use ARIA, HTML has native semantics, ie, all HTML elements have an ARIA semantics. Some interesting links for ARIA in general:

What we did for DPUB Aria is that we added some richer semantics coming from the EPUB world, that was never really picked up by accessibility technologies. We then reduced that terminology down to what was more useful. Then we added prefixed-terms to ARIA (using the doc- prefix) – so that it would be distinct from the core ARIA tech. There were 20 terms that were added in that recommendation. Bottom line: we’ve extended the ARIA vocabulary with terms useful for publishers and assistive technology.

(Tzviya may organize a separate, deeper dive.)

Looking backward and forward

This was the last call of the year and at a major milestone (publishing of the FPWD-s); there were some discussion on how the group is organized, and what can be done to be more welcoming to new participants. Lots of ideas were discussed (making it clear what issues are already assigned and which one are not, document more the context of some of the issues and terminology, improve the document for newcomers, possibly organize separate welcome meetings one in a while, etc.). Other comments, proposals, etc, are welcome, using any means of communications.

One of the core statements (from Deborah Kaplan):

I think I’ve heard this reflected—it took me a while once I heard lots of wise experts with expertise—everything we do and everything we talk about touches these disparate fields. Everyone has expertise. Some have written specs, but we’re all here because we have expertise. I’ve been on both sides—guilty of being wise or feeling guilty. From this corner of field knowing something detailed (in my case, accessibility) but I may not know much about locators… We have all different kinds of expertise and it’s important to remember that just because we know one thing well, doesn’t mean we understand the important aspects of everything. And anyone with confidence questions, you’re here because you’re good at this. It’s OK to not know something, and to ask for clarification.

See also the Impostor’s syndrome😉

Happy Holidays and a Happy New Year!

Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2017-12-18: Minor change on Locator doc, ARIA, end-of-year reflections

Publishing WG Telco, 2017-12-11: PWP FPWD transitions, Locators revisited

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

Voting on FPWD transition for PWP

The Working Group has formally voted to publish the Packaged Web Publications draft as First Public Working Drafts (FPWD), provided the W3C Director gives his approval. The transition request should happen before Xmas, with an expected publication date on the 4th of January, 2018.

There were some discussions preceding the vote in view of the fact that the document is pretty much a skeleton (although the final document is not expected to be long). Indeed, at this moment it is pretty much impossible to make a decision on which packaging format the group would refer to; the path to a Web Packaging is still not clear. The group does not intend to develop a packaging spec on its own, which means that it has to wait until the situation becomes clearer. However, the document does include statements on conformance, on the definition of PWP, etc, that are independent of the details of the packaging format and, to get those issues out in the open, the FPWD does make sense. This led to the final vote.

Revisiting the Locator FPWD

Although the WG has decided on it meeting of the 4th of December to publish the FPWD for the Locator document, new discussions started on the mailing list (see the message starting the thread, but also the response of Tzviya Siegman). One issue that did come to the fore is that the previous version of the document editorially mixed up the features that the group “inherited” from the Web Annotation Model and those that are normatively developed by this group. It was decided to adopt a much more restrictive document that concentrates on the new issues only.

In the course of the discussion the name “Locator” was also criticized as not appropriate for the content. There is currently an open issue to see if a new name can be found.

Publishing WG Telco, 2017-12-04: Votes on FPWD transitions, PWP issues

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

Voting on FPWD transitions

The Working Group has formally voted to publish two documents, namely

as First Public Working Drafts (FPWD), provided the W3C Director gives his approval. The transition request should happen before Xmas, with an expected publication date on the 4th of January, 2018.

PWP Issues

Issue 9 (definition of a PWP)

The issue discussion (on GitHub) has led to the proposed definition:

A Web Publication that has been packaged into a single information resource, enabling it to be transported and stored independent of any specific address or protocol. A Packaged Web Publication is typically constructed from a published Web Publication (i.e., one that has a specific URL and is accessible via HTTP), but this is not a requirement. Similarly, it is possible to unpack a Packaged Web Publication and publish it as a Web Publication, although there are practical limitations to this (e.g., re-publishing cross-domain resources will require access to all the domains).

The WG approved this definition (for the purpose of a FPWD, i.e., it may still change)

Issue 6 (extra requirements on PWP)

The issue discussion (on GitHub) has proposed the following requirements:

  • MUST contain a WP manifest at a well-known location (e.g. manifest.json)
  • MUST contain all resources that are part of the publication (reading order + secondary resources)
  • MAY contain additional resources that are referenced by the publication (for example a metadata record in a different format)
  • MAY contain the request & response HTTP payloads for each resource

The group adopted these (for the purpose of a FPWD), but there were some disagreements on the 4th item. It has been agreed to note (and refer to from the document) in a separate issue (Issue 14), but this should not stop the publication of a FPWD.

The plan is to vote for a FPWD in the coming weeks, so that the PWP document could be published alongside the WP and the Locator drafts.

Publishing WG Telco, 2017-11-27: PWP, Locators

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


There has been work on putting together a FPWD for PWP. The current approach is to:

  • Have two major top-level sections
    1. list PWP-specific information items
    2. possible packaging solutions
  • The conformance would allow for a particular profile to conform to Part 1, but choose its own packaging format
  • The content of (1) is topic of active discussion on the repository issues’ list
  • The content of (2), at this moment, is only a list of possible alternatives, no decision can be made for now yet.

An editor’s draft is already in preparation. The goal is to request a FPWD transition before the holidays.


The Locator Document has already been discussed at TPAC. The only outstanding issue to be decided before a FPWD is what to do with fraction identifiers.

This WG cannot define such identifiers for media types outside of its control (e.g., HTML). But WP specific fragment identifiers may be proposed. The alternatives are to define such identifiers (quoting from the discussion on github):

  1. Unrefined Embedded Resource Selectors
  2. Refined & unrefined Embedded Resource Selectors
  3. Any of the 3 new Selectors which are meant to work with collective resources like WPubs and PWPubs

The consensus, on the github discussion and the call is to stick to (1). A new PR will be prepared accordingly.

FPWD publications

The chairs will put forward a proposal for a detailed schedule.