Publishing WG Telco, 2019-07-01: Future of WPUB, shape of audiobooks

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

The meeting concentrated on a single issue: what exactly is the future of the work in the Working group. The essence of the question was part of the agenda, and is simply reproduced here:

Proposed Changes to PWG

The chairs of the Publishing Working Group (PWG) and the EPUB 3 Community Group have been discussing how best to move forward with Web Publications. As the specification exists today, there is little chance of it being adopted by publishers, as it does not reflect current business needs. In spite of our best intentions, we did not gain the support of the browser vendors or the larger web community. We attempted standardization before experimentation and incubation. Clear business needs have been hard to find.

We feel the best course of action is to suspend work on web publications for now, and focus on areas where we have clearly-expressed and widely-supported business needs, such as audiobooks. We would consider resuming work on web publications, but we would need more clearly-articulated business needs, and broader participation from the web community as well as the publishing world.

So what should we do? We have a proposal:

  • Publish the existing full Web Publications spec as a Working Group Note, with the message that “there is insufficient business interest to proceed today, but we can revisit in the future.”
  • Move forward with audiobooks. But we need to decide on an approach:
    1. Most of the chairs favor using the existing audiobook spec as a foundation, incorporating the manifest and associated vocabulary from Web Publications, and possibly integrating the packaging spec. By de-emphasising the WP aspect of audiobooks, specifying the processing of the manifest could become much simpler, avoiding the complications of fetch, CORS, and so on. But this still leaves open the possibility to better integrate with existing web technologies, and perhaps even evolve to support podcasts. And if the synced media proposal for audiobooks gains traction, it could be a boon to the larger web. This could open the door to future profiles as well.
    2. EPUB could become a packaged audio format by defining audio formats as core content types, allowing them to be referenced directly from the spine without fallbacks. This provides a natural way to incorporate navigation and non-audio content in audiobooks, and takes advantage of EPUB’s existing media overlays. But there may be little interest from the industry.
  • Work with the publishing community to focus on the future of EPUB. Perhaps instead of inventing something new, we can bring EPUB closer to the web. Some of the ambitious proposals made for EPUB 3.1 could form the foundation of the EPUB 4 of the future, including the browser-friendly format, the HTML serialization, and more progress on scripting in EPUB. If the industry indeed sees a business need for a new version of EPUB, We do not yet know where that work might happen, but logistics will come later.
  • Follow the advice that we’ve received from the larger web community about incubation, about identifying gaps in the web platform and advocating for filling them rather than trying to create a grand vision from scratch.

We will spend Monday’s meeting discussing these issues. We hope to hear your thoughts about these questions in particular:

  1. Would you prefer to move forward with audiobooks as is (in a Web Context) or audiobooks in an EPUB context? We would like to hear about implementation interest from both “listening system” vendors and content creators.
  2. What are the next steps for EPUB? What comes after EPUB 3.2? Going forward, we will ask you to identify particular gaps in the EPUB specification.

The discussion was complicated (see the minutes) and questions were raised. As for the question on audiobooks, the group’s decision is to use the WP formalism (as opposed to EPUB) for the audiobook line.

Publishing WG Telco 24-06-2019: Finalizing the UCR

Publishing WG Telco 24-06-2019: Finalizing the UCR

Update on the UCR document

We worked toward finalizing the Use Cases and Requirements Document so that we can publish it. Two specific use cases were discussed:

Content Protection: The fundamental question is whether a WP will itself express information about content protection/controls or will enable other systems to do so. The editors will adjust the language of the requirement to clarify the use case.

CSS Counters: This requirement called upon CSS to cross HTML documents to increment counters in an automated way. The group agreed that this is out of scope for PWG and probably not possible and removed the use case.

Publishing WG Telco, 2019-05-03: Update on the WPUB spec, audiobook, synced media and UCR docs

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

Recent updates on the WPUB spec

Matt gave a short overview of the recent changes, which were mostly reacting on some TAG comments (reorganization of the WebIDL usage, remove ambiguities in addressing and in internationalization sections). A new version will be pushed onto /TR soon.

Audiobook FPWD

It was agreed on the F2F meeting to publish a FPWD for the audiobook specification. The question was whether the AudioObject is the right object type for the audio content; however, after discussions it turns out that there some minor differences that should be looked at first before deciding on using it (or not). It was agreed to publish the FPWD as is now and come back to this issue later.

The discussion on the role and usage of LinkedResource type also came up; it was decided to (re-)raise the issue with to see if it was possible to use an (updated) type at that place instead of a publishing-specific type.

Update on sync media

Marisa gave some updates on the fact that a number of question on synced media are now listed as specific issues, inviting for explicit discussions.

Update on the UCR document

Two specific use cases were discussed:

  • Escalating trust: the question was whether the corresponding use case should be kept in the list: many features are already done on the Web. On the other hand, this may not be exactly the same case for mobile apps. After discussions it was decided to keep the use case (although one of the scenarios might be misplaced here)
  • Resource mixing and CSS counters across HTML pages: describes a feature that is not possible in CSS today. In general, the problem with the use case is that it mixes a use case (continuous counters across a publication) and a possible implementation tool, i.e., CSS, and that isn’t the right way to go. On the other hand, it was agreed that the (reworded) use case should remain, even if it is not implementable on today‚Äôs Web.
Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2019-05-03: Update on the WPUB spec, audiobook, synced media and UCR docs

Publishing WG Telco, 2019-05-03: Action tracking, LPF issues

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

The group looked at open action items mostly from the group’s F2F meeting, then concentrated on issues on the lightweight packaging spec.

UA conformance

It was agreed on the F2F meeting that the LPF document would not define a significant wording for conformance but will, instead, rely on the WPUB conformance. The proposed text does that, but a stronger reference to ZIP processing may be necessary. Also, there are some issues in relation to the WPUB processing. The final formulation is delayed until the other isssues are solved.

Packaged publications vs canonical id

The issue is that the current formulation in the WP document relies on a URL that is the ‘preferred’ address for a WPUB. This requirement does not work for a packaged version of a publication which may not have such ‘preferred address’, though it may have a canonical identification (e.g., an ISBN).

After discussion the current approach is to alleviate the WPUB specification insofar as it should allow a IRI (e.g., a URN) as an identifier value, although the value SHOULD be a URL (i.e., an http address). That would work for packaged publications, too.

This will have to be discussed further; there is now a Pull Request suggesting those changes.

Publishing WG Telco, 2019-04-29: Lightweight packaging issues

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

The whole meeting was devoted to open issues around the lightweight packaging issue. Most of the issues were easy and handled right away: media type (application/lpf+zip), name of the PEP and the manifest file itself (index.html, resp. publication.json), or no signing components in the package.

The only issue discussion that turned out to be more complicated was related to the way URI/URL’s are described and referred to in the document. There was a general agreement that, instead of including a longer paragraph, a deep link to the relevant section in the WPUB document should be used. However, the issue raised some other potential issues that will need resolution:

  • What is the ‘origin’ to be used for relative URL-s, scripts, etc, for a packaged document?
  • The current manifest canonicalization algorithm turns all relative URL-s into absolute ones. This may be fine on the Web, but it is not clear for a package, in view of the previous issue.

These questions will be raised as separate issues to be discussed (maybe at the F2F next week).

Publishing WG Telco, 2019-04-15: Duration; integrity hash

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

Final issues on the duration values

While finalizing the move of duration values to the core WP documents, some specific technical questions came up. These were taken care of in the call:

  1. What is the value of a resource level “duration” value? The resolution is that it should be a number (meaning the number of seconds), and the term’s name is, for now, length.
  2. What is the value of the top-level “duration” value? The resolution is to stick to the definitions of duration.
  3. Is the duration term required? The resolution is that it is optional for a WP in general, and recommended for an audiobook.

The resolutions will be incorporated in the editors’ draft in the coming days.

File hash, a.k.a. “integrity”

It was agreed to add an optional integrity when defining a resource. The value, and its semantics, is defined by the Subresource Integrity Recommendation.

Publishing WG Telco, 2019-04-08: Supplemental Materials in Audiobooks, usage of duration

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

Should there be a TOC if supplemental materials are provided in an audio book?

This question has been raised in Issue #408. Having a clear place to find those materials is important (e.g., for accessibility purposes if they provide a textual transcript). The discussion was around whether supplemental materials (e.g., PDF booklet) in an audiobook should be added in a TOC or whether it should be part of the usual resources’ structure labeled with a particular rel value. There is no formal resolution yet.

Should duration be part of the general WPUB draft

The current audiobook uses the duration term from It does it for an individual (audio) resource as well as for the whole book. However, there is nothing in that definition which would be audio specific; the same attribute could also be used for, e.g., video resource as well.

Another issue was what exactly the role is of the book level information. Current readers usually calculate that value; they do not trust the author/publisher data for accuracy. On the other hand, that value may have an important role in user-friendliness; e.g., it would inform the “reader” (i.e., listener) how long that book is.

Two outcomes of the discussion:

  • It was decided to move the duration term into the general WPUB draft as one of the generic terms for linked resources
  • An alternative for book level data could be the timeRequired term, that seems to be looser in its requirement, and may very well be enough for the purpose of that information. To be discussed further.
Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2019-04-08: Supplemental Materials in Audiobooks, usage of duration

Publishing WG Telco, 2019-04-01: New WPUB document structure, audiobook profile draft

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

New WPUB Document Structure

The WPUB Draft has been restructured to fulfill a series of past resolutions.

  • Part I: the manifest, its structure, its lifecyle (canonicalization, final checkings, etc). The terms are now more precisely categorized, and the canonicalization is defined in terms of these categories, instead of referring to the terms explicitly. Profiles may add their own terms and provide extra processing steps if needed.
  • Part II: the Web Publication Profile, describing the PEP, the way to obtain a manifest, the possible extraction of some metadata items (i.e., title) from a the PEP.
  • Part III: how to define new profiles

The group has agreed to re-publish the official W3C Draft with this version.

Audiobook profile draft

The first Editor’s draft for the Audiobook profile is now available, and the group discussed some immediate issues (to be incorporated into the ED). The main features discussed:

  • The reading order of an audiobook MUST incude audio files only. Other possible resources (cover page, etc) may be present in the resources’ list, but not in the reading order.
  • There is now a duration property. There were discussions around this property:
    • There is a duration term for the book as a whole as well as for individual resources
    • There was no consensus whether the duration for the book as a whole should be REQUIRED or not; a new issue will be raised for that
    • The term may be useful for other media objects like video, ie, the property should probably be defined in general (ie, part of the WPUB document). However, usage of the terms for the book as a whole may be restricted to audio (or video) books.

Discussions will continue with the evolution of this new draft.

Posted in Activity News, Meeting reports | Comments Off on Publishing WG Telco, 2019-04-01: New WPUB document structure, audiobook profile draft

Publishing WG Telco, 2019-03-25: Some use cases

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

Implementations and UCR

Some entries from the UCR document were discussed to see what type of implementation issues it would raise and how it would work with the current draft:

  • UC #86: is about page numbers and how they are displayed/located. There were several implementation scenarii, but the current pagelist feature in the draft is present and the author/implementation can use it. It becomes more complicated if that list is not present, and implementations may decide to search the content for special triggers (e.g., role=doc-pagebreak). An issue should be opened to describe the behavior in more details.
  • UC #93: adjusting the contrasts if, for example, one is reading in the sun. This is closely related to CSS issues and behavior, and touches upon operating system features as well; it should not be a solely WPUB discussion (although WPUB brings this requirement to the fore)
  • UC #40: reading order. This is a basic feature on current reading system, but not necessarily on the Web. A best practice and minimal behavior should be described for this.


The group also closed a longstanding issue (Issue #376) which got to an agreement on the issue list itself.

There were also some F2F planning.

Publishing WG Telco, 2019-03-18: Issue management

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

A large number of leftover old issues were discussed and closed (see minutes for details). The only issue that had a longer discussion was:

Only allow embedded manifests

(Is issue 327.)

It was recognized that various security issues are better taken care of with embedded manifests, which is also the favored choice by processors. On the other hand, the audiobook discussion has already led to the resolution whereby they would need a separate manifest for audiobooks. The decision is to make the requirement of an embedded manifest a SHOULD (rather than a MUST).