DPUB IG Telco, 2016-01-11: CSS Priorities, PWP Use Cases and Requirements

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

CSS Priorities’ Document

The initial document has been around for a while, but it has not changed for several months. The idea is to create a corpus of samples (photos, screen dumps, etc) to be submitted to the CSS WG. We tried to restart interest by having people submit example. The current focus is on issue 18 of the CSS WG on character alignment in tables (which needs a more elaborate control in everyday publishing). It would be good to have more input to the CSS WG by the time of their next F2F meeting (beginning of February).

Planned: PWP Use Case and Requirement document

To frame the discussion on PWP, as well as an input to a future, possible WG, the proposal is to create a more detailed Use Cases and Requirements’ document (as a bona fide IG Note, eventually). The “model” that can be followed is the similar document of the CSV On The Web Working Group, which not only listed the use cases by abstracted out a number of requirements.

As a starting point, there are a number of (old) use cases on the IG Wiki, as well as the (high level) use cases part of the current PWP draft. The IDPF BFF Use cases can also be used as input.

It is important that the UCR document would be implementation agnostic while, on the other hand, the requirements listed there should also direct the technical discussion of the PWP.

Editors for the document have been identified (Romain, Dave, Heather); the work will be conducted on github.

Admin issues on meetings

  • Next week’s meeting will be cancelled due to Martin Luther King day in the USA
  • Discussions on a possible Spring F2F meeting; binding it to the IDPF even in Chicago makes sense, but not everyone can make it and it is not clear who could host it. Issue still open, to be discussed in the coming days/weeks
Posted in Activity News | Comments Off on DPUB IG Telco, 2016-01-11: CSS Priorities, PWP Use Cases and Requirements

DPUB IG Telco, 2015-12-21: Locator Task Force

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Locator Task Force

The goal of the discussion is to set the right goals for the task force. There are two inputs:

Bill Kasdorf gave a short overview of some of the main points in the PWP document. These are:

  • It is important to keep in mind the differentiation between identifiers and locators, e.g., the locator may refer to a personal copy
    • publishers had been discussing a work identifier, and not any possible instance, this approach simplifies things
    • there may be a misunderstandable statement in the 1st note in the document on the usage of DOI-s and friends for books; that will be handled separately via an issue
  • Another notable section is the emphasis on the manifest; the group agreed that working out the details of what should appear in the manifest is one of the important goals of the task force
    • a related question is whether there is a need/goal to have a specific media type for PWP; it has been agreed that this is something to be decided later, not at this point
  • Finally the issue on “content URL”, ie, what is the URL of a constituent resource came up; it has been agreed that this is probably the fuzziest part of the current text. On the other hand, usage scenarios like shared CSS files or JavaScript libraries for PWP-s show that this issue is very important: the same resource may have different URL-s depending on where one comes from, and this must be clarified.

Subsequent discussions on the goals made it clear that the point of the first bullet is to say we are not going to create new identifier schemes but it must be emphasized that any identifier scheme adopted by the community should work with whatever PWP will have. As for fragment identifiers, while the group would try to keep away from defining new fragments for exisiting media types, it was recognized that new type of information may appear in a PWP (i.e., for the manifest) that may lead to the necessity of defining new fragment identifiers. But that is for later.

Another class of issues that came up is the issues coming up frequently in the library world. Someone may want to read “Moby Dick” and any copy of the text will do. A scholar will want to see the 1943 version. Someone may want a specific copy in a specific library. The OCLC tends to talk about the specific manifestation (the 1943 edition). But the item level is what we need to talk about. The individual copies is finer grained than the library world tends to think about. These are all using locators, which, in this case, are used as identifiers, and the question is whether we should work on how those identifiers/URL-s should be “minted”. It has been agreed that this is beyond the scope of the TF (and of PWP in general).

Finally, it has been recognized that the outcome of the work of this TF may actually be important for the ongoing IDPF EPUB 3.1 work; recommendations of this Task Force may provide a forward compatibility to EPUB 3.1 if the TF can finish its work before mid-spring 2016.

Operationally, a parallel series of calls will be set up for this task force.

DPUB IG Telco, 2015-12-07: Accessibility Mapping, Archiving Task Force

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

DPUB ARIA Accessibility API mapping

A mapping of the DPUB ARIA terms to Assistive technologies have just been published as a Working Draft. To provide a clearer understanding of what is this technology doing, Joseph Scheuhammer, from the ARIA WG, has joined the group to give an overview.

The roles in any of the ARIA document is a list of terms. What the API mappings do is say how the accessibility API mapping should utilize this. It functions as the layer between the HTML/SVG/etc, and the assistive technologies that part of the operating system.

The DPUB ARIA mapping includes a table with a row for each DPUB ARIA terms. The cells define how that term is mapped on the various mappings used by Windows, OS X, IOS, Linux, etc. (Android uses the Linux API, i.e., all current platforms are covered.) Each of these systems have so called accessible objects, which is a tree-structure in the accessible API. Similar to a DOM element, but not actually in the DOM. So a browser extracts (subsets) the DOM and creates a new tree item in the accessibility object tree. From there on you will have nodes in the new tree that has a role, a name, possibly a description, and a whole bunch of states and attributes. Using doc-abstract as an example: if you’re a browser running on windows, and you’re using i-accessable2, you take the string “doc-abstract” and it’ll be a “role-system grouping” in the accessibility tree and it will include a property of the accessible object for abstract. From that point on the assistive technology system takes over and produces an accessible version of the information. It is important to note that the concept and the exact structures of the accessibility trees predates the Web, hence the major differences among platforms.

There were some questions on the details of the table which should, and will be converted into issues against the document.

Some further information on the underlying technologies are at:

Archival TF

The issue of archiving came up a few weeks ago, and the group discussed the need and possible scope for an archival Task Force. There are efforts on premise in the library space. There’s an ISO standard on article versioning. We need to formulate the questions and get answers. We also need to make sure the PWP document reflects though. There are broader questions: should we strategically engage the parts of the library community that is dealing with archiving. The special library association is dealing with this area—there are preservation coalitions. Do we need to worry about archiving in our testing and demonstrations?

It was agreed that a separate task force should be set up, with has to give a more detailed scope for the task force. In general, it would be interesting to find out if archival institutions have run into technical issues—missing information— when archiving, e.g., large number of EPUB documents. What should be provided to making archiving easier? What is missing – from a technical point of view—and what is necessary—or PWP to make the job of archivers easier? If the answer is ‘nothing really’ then maybe we don’t need to do more.

A number of pointers were listed for further reference:

CSS Custom Properties Candidate Recommendation published

The Cascading Style Sheets (CSS) Working Group has published a Candidate Recommendation of CSS Custom Properties for Cascading Variables Module Level 1. This module introduces cascading variables as a new primitive value type that is accepted by all CSS properties, and custom properties for defining them.

Posted in New W3C documents | Comments Off on CSS Custom Properties Candidate Recommendation published

Digital Publishing API Mappings First Public Working Draft

The Accessible Rich Internet Applications Working Group has published a First Public Working Draft of Digital Publishing Accessibility API Mappings 1.0 (DPub-AAM). This defines how user agents map the Digital Publishing WAI-ARIA Module markup to platform accessibility APIs.

DPUB IG Telco, 2015-11-30: SW Assisted Publishing Experiment, MathJax White Paper, A11y TF

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Basic overview of service-worker based publishing

Dave Cramer gave an overview, with screen sharing, of an experiment of a minor proof-of-concept approach (originally created by Jake Archibald) for what a simple PWP reader based on Service Workers (SW) could do. As an example, a (first chapter of Moby Dick)(https://dauwhe.github.io/epub-zero/acme-publishing/MobyDick/html/c001.html) is loaded into the browser, that publication as a whole can be taken off line (via a dedicated button), i.e., the same publication can be read while off line, too. (This works in Chrome, for the moment.) The “magic” is done via a script running service workers which is responsible for the local caching. The same module can also be used to produce and/or read a “package” (at the moment it is zip).

The site contains some examples, including a scholarly article (running MathJax).

The exact goals of the experiment will have to be described (a discussion on email should follow), and this would also focus on some specific questions that should be solved in future. A major goal here is to figure out how to make a file/folder format that works well, that can lead to a more comprehensive PWP solution.

MathJax white paper

Peter Krautzberger gave an overview on a white paper that MathJax plans to publish soon. The background is that MathJax itself is pretty old. In 2010 was version 1.0 and design started a year before that. They’ve been facing a problem that they need to revamp the internals, but the internal plumbing hasn’t changed much.

Originally, in 2009 and 2010, the goal was to help move math. Browsers weren’t supporting it because no one was using it, and users were not using it because browsers were not supporting it, etc… However, about 5 years later it hasn’t really moved. The choice is either (a) go for a full polyfill approach or (b) to really make use of the advances the browser have made and map everything on top of HTML, CSS, and SVG. Because (a) would not really solve the efficiency issue today, the direction planned is to go for (b). Doing things with grid layout is a good place to start, and it’s the direction they’re working towards.

The discussion at the call was concentrating on the accessibility issue, how this approach would affect it, etc. There may be some proposals coming up on how to use ARIA, CSS, and how these standards (and possibly a next version of MathML) should be adapted to handle accessibility. It has been agreed that this group is in a good position to initiate such an activity, if a clear set of requirements and proposals are on the table.

Accessibility TF

Charles LaPierre reported on the work of the TF. They made an overview of WCAG regarding the relevancy of WCAG to Digital Publishing. All of the concerns of WCAG are relevant, but there are also a number of issues in Digital Publishing that should be addressed more. These (as listed in the current draft): page numbering, drop caps, position/location of text, indication of text, nouns, layouts, influences, deeply nested headings, semantic list-heads, skipability, escapability, diagram models, appendix, and also needed but being addressed elsewhere: notes & footnotes (aria), and annotations.

The TF plans to publish a draft and, eventually, an IG Note, in cooperation with he relevant WAI group.

New PWP Draft Published

One of the results of the busy TPAC F2F meeting of the DPUB IG Interest Group (see the separate reports on TPAC for the first and second F2F days), the group just published a new version of the Portable Web Publications for the Open Web Platform (PWP) draft. This draft incorporates the discussions at the F2F meeting.

As a reminder: the PWP document describes a future vision on the relationships of Digital Publishing and the Open Web Platform. The vision can be summarized as:

Our vision for Portable Web Publications is to define a class of documents on the Web that would be part of the Digital Publishing ecosystem but would also be fully native citizens of the Open Web Platform. In this vision, the current format- and workflow-level separation between offline/portable and online (Web) document publishing is diminished to zero. These are merely two dynamic manifestations of the same publication: content authored with online use as the primary mode can easily be saved by the user for offline reading in portable document form. Content authored primarily for use as a portable document can be put online, without any need for refactoring the content. Publishers can choose to utilize either or both of these publishing modes, and users can choose either or both of these consumption modes. Essential features flow seamlessly between online and offline modes; examples include cross-references, user annotations, access to online databases, as well as licensing and rights management.

The group already had lots of discussions on this vision, and published a first version of the PWP draft before the TPAC F2F meeting. That version already included a series of terms establishing the notion of Portable Web Documents and also outlined an draft architecture for PWP readers based on Service Workers. The major changes of the new draft (beyond editorial changes) include a better description of that architecture, a reinforced view and role for manifests and, mainly, a completely re-written section on addressing and identification.

The updated section makes a difference between the role of identifiers (e.g., ISBN, DOI, etc.) and locators (or addresses) on the Web, typically an HTTP(S) URL. While the former is a stable identification of the publication, the latter may change when, e.g., the publication is copied, made private, etc. Defining identifiers is beyond the scope of the Interest Group (and indeed of W3C in general); the goal is to further specify the usage patterns around locators, i.e., URL-s. The section looks at the issue of what an HTTP GET would return for such a URL, and what the URL structure of the constituent resources are (remember that a Web Publication being defined as a set of Web Resources with its own identity). All these notions will need further refinements (and the IG has recently set up a task force to look into the details) but the new draft gives a better direction to explore.

As always, issues and comments are welcome on the new document. The preferred way is to use the github issue tracker but, alternatively, mails can be sent to the IG’s mailing list.

DPUB IG Telco, 2015-11-23: PWP Locator task force, planning on PWP Work

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

PWP Locator Task Force

Following the discussions on PWP identifiers last week a task force has been set up, led by Bill Kasdorff. There were some discussions on the call as for the goals of the task force (this has to be cleaned up), but the general ideas are:

  • The task force should concentrate on locators (as opposed to identifiers) both for the PWP level as well as on the individual resources’ level
    ** I.e., dealing with identifiers (ISBN-s of different sort, ISTC work, DOI-s, etc) is out of scope, as well as the issues around fragment identifiers, hence also the name of the task force
  • The task force should dig into the addressing/identifier work described in the PWP document, should flesh out the details, possibly have some mock-up implementation, and identify if and what of this work would require a targeted Recommendation/Standardization work (either at W3C, or at IDPF, or in a joint group)
  • The task force should also provide input to the IDPF EPUB3.1 work, which is looking at a “browser friendly manifestation” of EPUB. The goal of EPUB3.1 work, in this respect, would be to be forward compatible with an eventual PWP work

There were also some technical discussion, emphasizing the fact that a PWP can be a collection of very different resources from all over the place, where the order of the resource access (reading) can be different from one PWP to the other even if they share resources. The locator structure should make this possible (e.g., via a manifest).

Planning PWP Work

There is a need for a more generic planning on where the PWP work ought to be going. The terminology-state-identifier-locator discussion has resulted in a more stable bases, and the task force on locators will dig into the details. What else? Ideas that came up:

  • Looking at the library and archiving community. A focussed work will be pursued to see what specific needs that community may have and whether what is in the PWP document is adequate or not, whether it has to be extended, etc.
  • The presentation control issue needs further work
  • Other issues listed in the PWP draft should also be checked.
  • Some sort of a proof-of-concept implementation is necessary to identify the necessary missing bits

For the last issue: Dave Cramer has recently created a simple mock-up based on the earlier discussion with, and work of Jake Archibald. (The repo of Dave is also available for cloning.) This is a tremendous start, and it has been agreed that Dave would give a more detailed overview on what is happening there on one of the next calls.


The Interest Group has agreed to publish the next version of the PWP document as a formal Interest Group Draft. Should be out on Thursday the 26th.

The group has been reminded on the need of having better CSS examples, and some further ideas did come up.

DPUB IG Telco, 2015-11-16: CSSWG examples, DPUB-AAM, PWP Identifiers

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Note that we experienced telco problems which cut some of the discussions a bit short and slightly chaotic…

CSS WG Examples

As agreed on the last call, the IG is supposed to collect CSS examples on typesetting issues the community has. This is an ongoing effort; participants were reminded on this. Some new volunteers came forward on the call.


The ARIA technology has two parts

  • The definition of the ARIA terms proper for which, in the digital domain, there is now a (soon to be updated) working draft
  • Mapping of the ARIA terms on the various Assistive Technology Interfaces available today; this makes it possible to use the aria terms with those technologies.

Richard Schwerdtfeger has edited a draft for the mapping of the DPUB ARIA terms. That should be complement of the DPUB ARIA term specifications themselves. The DPUB IG was asked to approve the publication of that draft (formally done by the ARIA Working Group). The approval was voted on at the meeting.

PWP Identifiers

Ivan Herman gave an overview of some of the proposed changes on the PWP draft. The new, proposed draft introduces changes based on the various discussions at the Sapporo F2F meeting.

Some of the proposed changes are minor: reinforcing the importance of manifests, or raising issues on how files on the local file systems should be handled by service workers. The major changes relate to the role and usage of identifiers, based on the specific session at the meeting (introduced by a slide set for the discussion). There are several aspects listed below; it has been agreed to provide more comments and issues on the draft and try to publish a new, official draft soon.

What type of identifiers do we have

The previous discussions included references to the fact that identifiers may have several usages (the work, a particular copy, a particular edition, etc.) and each would have to have several identifiers. However, it was also emphasized that the DPUB IG, or a future formal PWP specification, cannot decide on these issues. On the other hand, a clear locator, to uniquely ‘find’ a PWP on the Web, is essential. The proposal is therefore to include, in the document both an identifier and a locator; the identifier is stable, can be any kind of URN (i.e., can be a DOI, an ISBN, etc.), whereas a locator should be unique, and should be a HTTP(S) reference on the Web. Subsequent discussions made it clear that (a) the two URI-s may coincide and (b) it may be possible to have several identifiers. The PWP level metadata may include some extra relationships (e.g., on provenance) between those two URI-s, but, at this moment, those are not specified.

If one dereferences the canonical URL, what is returned?

Essentially, a manifest: either directly, or via <link> element or a LINK: header in the HTTP return. The role of the manifest, beyond containing additional metadata, is to “represent” the PWP as a whole.

What is the URL of the constituent Resources within a PWP

The URL of the PWP as a whole establishes some sort of a “context” for URLs. Ie, if the URL of the PWP is http://example.com/2, then the constituents may be http://example.com/2/index.html. Ie, everything is interpreted with the scope of URL as the base.

This is a simple approach, though the Resources may be spread over the Web, so this may not be enough. An idea is to have some sort of a mapping within the manifest to map this view onto “real” URI-s in that case

What about fragments?

Fragments should not be defined by and for PWP. With this approach, the fragment identifiers are “simply” those that are defined by the community at large for the specific media type.

Cooperation with the IDPF EPUB 3.1 effort on identifiers

The EPUB 3.1 effort also looks at the issue of identifiers in a possible approach of “forward compatibility” with en eye on PWP. Details of this should be discussed. To be picked up on future meetings.

DPUB IG Telco, 2015-11-09: DPUB-ARIA Update, CSS WG examples, POM

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)


The latest version of the DPUB ARIA Module Working Draft was published in July; a new version should come soon. Tzviya Siegman summarized some of the new terms that have been added since: colophon, credits, epigraph, errata. There were also discussion on noteref, glossref, etc.

There were also discussions on the ARIA mailing list on how to handle roles on links. EPUB has been doing that (‘noteref’) and it is very useful for Assistive Technologies. It is not clear, at this moment, whether @role should be used for that, or whether, for example, @rel is more appropriate. This is a decision the ARIA WG should make.

Another issue is the long term planning of the evolution of the vocabulary vs. the vocabulary currently available in EPUB (the latter is much larger). At the moment the plan is to back port the ARIA terms into EPUB and, at the same time, shrink the EPUB terms. A golden middle will have to be found. (There are some tensions with the ARIA group about how many terms we should use there.)

Overall, the IG is in favor of publishing a new WD (although the final decision is the ARIA WG’s). There is also a call for testimony from organizations that use, or plan to use, this vocabulary.

CSS WG Examples

The discussion with the CSS WG at TPAC (see the minutes of the relevant TPAC session) revealed that a more systematic set of use cases should be provided, including screen dumps, etc, to show what should be rendered and how this should be achieved through CSS. Florian (who is also part of the CSS WG) gave additional rationale for this.

There were some discussion on how to do that in practice, and what the priority for those should be. At the moment, two use cases came to the fore for a first round: table alignment (e.g., aligning table cells on, say, the fraction sign of numbers) and inline grid management for CJK languages. A wiki page will be set up to collect these and there is a general call for members of the IG (and anybody else…) to provide as many cases as possible.

Publication format for the POM CG

The Publication Object Model Community Group has been set up by Daniel Glazman, following a discussion at TPAC. That community group needs examples for various publication format beyond EPUB and PDF to have enough input to be able to define the POM API in a general way. This may include Manga and Comic formats, and also KF8. It is important to provide such information to the POM CG. (Information on Kindle’s KF8 has already been provided after the meeting.)