DPUB IG Telco, 2016-08-08: Annotation, Use cases, TPAC

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


Benjamin Young gave an overview on the status of the Web Annotation specifications (those include a model, vocabulary, and a protocol). The documents are currently in Candidate Recommendation, i.e., testing possible implementations to check whether the recommendations are error-free and consistent.

There were some discussions on the relationships with accessibility, more exactly whether the new specifications have (or not) accessibility implications. The agreement is that the documents themselves, as they do not define user interface or user agent behavior, do not have any accessibility aspect, but it is nevertheless important that implementations would avoid using, e.g., images for annotations (instead of accessible content). That, however, is not under the purview of the current testing period.

Use Case Documents update

There were some evolutions in the document, primarily in the section on manifests. There is a separate branch with a new version; in this version, manifests and packages are separated. The use cases for manifests have been cleaned up, relationships to the fundamental requirements have been added, and two new use cases have been added on how to find a manifest and whether the final manifest should be, possibly, a combination of several ones. The second requirement may lead to specification and implementation complexities, though.


The group spent some time on planning the TPAC meeting insofar as finalizing which other groups in wants to meet and on what topics exactly.

DPUB IG Telco, 2016-08-01: TPAC and Use Case Planning

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


The W3C Technical Plenary (a.k.a. TPAC) meeting is a few weeks away; the groups spent some time on identifying which other Working and/or Interest Groups we would like to meet. At present, the list includes ARIA, CSS, Web Platform, I18N, SVG; others may come up in the coming weeks. The group also had some discussion on setting up the agenda for the IG’s Face-to-Face meeting.

Use Case Document planning

To move the Use Case document forward, the group has assigned a number of sections in the document to specific persons for further editing. (See the meeting agenda for details.) The idea is to have a publishable use case document by TPAC, possibly even before…

DPUB IG Telco, 2016-07-11: Use Cases on Manifest and Metadata

See minutes online for a more detailed record of the discussions. Part of the “minutes” took place on a Google Document that was live-edited collectively.

DPUB IG Discussion on Manifests and Metadata

The group focused on the section Manifests and Metadata. The group dicussed the importance of User Agents being able to know metadata about package, its components, and their relationships.

Hiatus for the Remainder of July

The DPUB IG will be on hiatus for the remainder of the month of July. We will meet again on 1 August. Enjoy your time away.

DPUB IG Telco, 2016-06-27: Use Cases Document, joint meeting with IDPF EPUB3.1 WG BFF Task Force

See minutes online for a more detailed record of the discussions. Part of the “minutes” took place on a Google Document that was live-edited collectively. See also the minutes of the separate meeting with the IDPF EPUB3.1 WG.

DPUB IG Discussion on Use Cases Document

The meeting was entirely concentrating on the refinement of the Use Case and Requirement Document. The goal was twofold:

  • Find a common structure for use cases. The structure of the [Annotation Use Cases[(https://www.w3.org/TR/dpub-annotation-uc/#tagging-a-publication) document may be the pattern to follow
  • Continue “filling in” some of the use cases that, at the moment, are only a one-sentence entry in the document. After discussion it was agreed that the “fundamental” issues on why several files are used, why there is a need for an extra information on the logical sequence of document, for a separate description of the content of a publication, of for the list of “essential” resources, etc.

The next meeting on the 4th of July will be cancelled, but that is followed, on the 7th of July, by another virtual F2F where further live editing should occur.

Separate meeting with the IDPF EPUB3.1 Working Group’s BFF Task Force

The current meeting was preceded by an ad-hoc meeting between the DPUB IG and the IDPF EPUB3.1 Working Group’s BFF Task Force. The latter is looking at what it would mean if an EPUB3 document was “exploded” on the Web and interpreted directly, how to make that option more palatable to browsers, authors, etc. There is a GitHub repository reflecting the current stage of discussions, concentrating on re-thinking the manifest for such an exploded EPUB3, as well as the usage of the various auxiliary files. Obviously, there is a lot of commonalities with the PWP goals and ideas.

The meeting concentrated on presenting the work so far, essentially around manifests, to participants. It was agreed that further meetings will be necessary, and that, eventually, the work should be merged into one to avoid duplication. This also means that the DPUB IG’s UCR document should also be critically assessed from the point of view of BFF in the future.

Posted in Activity News, Meeting reports | Comments Off on DPUB IG Telco, 2016-06-27: Use Cases Document, joint meeting with IDPF EPUB3.1 WG BFF Task Force

DPUB IG Telco, 2016-06-20: CSS WG, Use Cases Document

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

Bridging with the CSS WG

This was a continuation of the discussion from last week on how to bridge with the CSS WG better. What was agreed is that there should be more active contacts with (a) reading system developers who hit the major issues themselves and are major part of the ecosystem and (b) with technical people in e-publication production who may hit issues that they have to circumvent with special code (possibly polyfills). It would also be important to find out how the features defined in XSL-FO are currently used in publishing and what difficulties are hit when those are mapped onto CSS. Two actions are planned

  1. organize a meeting with the major Reading System developers, like Google Play, iBooks, Readium, AER.IO, Bluefire, etc, to collect their input
  2. set up a (wiki) page to collect the XSL-FO experiences (eg, from Antenna House, Prince, etc) that should be mapped on CSS and what difficulties they hit

It was emphasized that real business cases are needed; an experimental implementation in a not-widely-used platform will not be convincing enough for browser manufacturers…

Use Cases’ Document Structure and Editing

The discussion (also in preparation to the upcoming Virtual F2F) was mainly on how to structure the current use case document. The example of the use cases of the archival task force was mentioned, although it was felt that the structure in that document is a little bit too complex (and also related to some sort of a workflow), so it should be somewhere in between. Also, some real “story” should be added around the individual use cases, which are often just a one sentence. It was therefore agreed that, for example in section 2.7 of the document we should all add a story around 1-2 case, and then organize the document accordingly.

What are also missing for a proper organization are

  • succinct definitions of the requirements that are referred to from the use cases
  • prioritization of the requirements

It was also noted that some requirements are mutually contradictory; these should be at least called out and, possibly, discussed and decided upon. (Part of this may be the subject of the Virtual F2F.)

DPUB IG Telco, 2016-06-13: CSS WG, priorities

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

CSS F2F meeting report

Dave Cramer gave a report of the recent CSS WG F2F meeting, that took place in San Francisco. The main point of interest for this group are:

  • Flexbox and grid. Both of these have evolved significantly. Flexbox is now in CR and grids has also evolved a lot.
  • Alt text in generated content. Generated content has been picked up again, and it will include the possibility to add “alt” text to it. Although this is still a complex issue, the goal is to improve the accessibility aspects of generated content
  • Discussions on baseline grids, to control alignment of stuff across pages and columns. This, and another feature called hanging punctuation. Both are important for, eg, CJK languages.

CSS Priorities’ document

There is a document on CSS priorities that the group has started to edit. The goal was to come up with a wish-list of things the publication community would like to be able to do but cannot do. However, it is fairly difficult to get these points onto the CSS WG’s agenda, and a simple listing of priorities will not really cut it. The problem is that the browser developers will see this as a theoretical thing, and dismiss it, unless there is someone who is trying to build something but coming up with a roadblock. What really counts and makes people think and move is people come not only with wishes, but some sort of implementations – polyfills or not – is how groups like CSS operate.

There were some discussion on the call on, e.g., how to “use” and cooperate with the Readium consortium, how to get more input, etc; the discussion will continue on subsequent calls.

DPUB IG Telco, 2016-06-06: Use case document & manifests

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

Use cases on manifests

Most of the meeting was on use cases to be gathered/documented on manifests. One of the most important issue, at that point, what the manifest is for an area like publishing. Is it a resource to be used for packaging only, or is it to be used independently on whether the publication is packed or not. (The consensus shifts towards the latter.) What is (is there?) a difference between the information in a manifest and what is commonly referred to as metadata?

The basic use case for manifests is to define what are the resources that are part of the publication. Then the discussion ended up listing a number of “information” that must be available about a publication; some of these are:

  • information on the media type of those resources (can a RS handle them), about their size (does the RS have enough memory for it)
  • reading order of the resources (at least a default reading order)
  • need to know whether the rendering is offline or online
  • need to have basic metadata, like the name and the cover image of the publication itself
  • need to have access to the resource “efficiently”, i.e., without the need to complex processing of the resource
  • need to know the rights associated to resources (is it all right to download a font)
  • need to know if there are extraneous files in the publication and what to do about that
  • need to have information on whether the resources are unaltered, whether they can be altered and under what circumstances, about the origin of the resources

etc. (The URC document’s commit right after the call has a record of that list.)

This discussion is of course ongoing. Actually, a new “virtual F2F” meeting may be organized to flesh many of the details out.

DPUB IG Telco, 2016-05-23: W3C/IDPF Plans, Web Platform WG

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

IDPF/W3C Plans

There was an announcement on the exploration of W3C and IDPF joining forces; this was discussed a bit on the call. Nick reported on a mailing list discussion, and the main question there was what the impact would be on publishing. There were some concerns around the messaging, on how these things have been decided, etc. Karen also reported on an article on CNET.

Ivan raised the issue that the current messaging does not emphasize enough the importance of the use case document that the IG is planning, and also emphasizing that the current PWP document is not necessarily a done deal as it is; the use case evolution may modify it greatly. Finally, Dave raised the issue that there were many discussions leading up to the announcement that was done in closed fora, and the final decision process should be made more in the public. The group also wondered about the possibility for further public discussions around this, including a possible Webinar.

Web Platform WG topics

Charles McCathieNeville (“chaals”), co-chair of the Web Platform WG at W3C, was the guest of the call to discuss some areas of common interest.


There is a work item in the WPWG on packaging but, at this moment, there are no real takers. Packaging is obviously of interest for the publishing community, and the question arose whether this community wants to push the current approach. The fact is that most browsers have an extension that uses zip and a manifest; i.e., that approach would get some traction, as opposed to the current proposal.

During the discussion it came to the fore that publishers currently use zip+manifest, although the current formats for manifests, as well as the specificities on zip usage, are not very Web friendly. But there is already work going on (in the IDPF EPUB WG) to update the manifest, a JSON approach, which is the current line at W3C (see the Web App Manifest, is probably o.k. for the Publishing Industry on long term. That being said, it is not clear how the current Web App Manifest can be extended for a particular community.

It has been agreed that the DPUB IG would submit issues or comments on the manifest as well as the packaging work to make its position clear.

Service Workers

The current work on PWP relies on concepts that calls for a tool like Service Workers. Dave has already experimented with this, but questions arose about the longevity of the Service Worker spec, and whether it is really something the community can rely on. It seems that Service Workers are indeed here to say, although the first implementations will probably not be optimal. But it is a safe bet to use them. (See also caniuse entries on it: Mozilla and Chrome already ship it, Microsoft has expressed interest. Not clear about Safari.)

HTML Extensions, Custom Elements (eg, the element)

Lately there were lots of discussion on the re-introduction of the element, that would certainly be of interest for the Publishing Community. What is needed today is to have clear usage data through an implementation. It was emphasized that “implementation” does not necessarily mean one of the browsers; if an EPUB reading system implemented it and used it, this would constitute a good proof of usage.

On a more general level, the issue of HTML Extensions, in particular Custom Elements, came to the fore, as well as the general approach for extensions. For Custom Elements, although it is only supported in Chrome/Opera at this point, the plan is to go ahead and others will also implement it; more generally, the approach using discussions in the HTML Incubator was emphasized as a means to bring new features into HTML.

It was agreed to have these types of meetings with the WPWG more often…

Digital Publishing and Accessibility in W3C Documents Note Published

The Digital Publishing Interest Group has published a Group Note of Digital Publishing and Accessibility in W3C Documents. This document describes how W3C guidelines (including but not limited to WCAG20, ATAG20, UAAG20, and WAI-ARIA) and their principles, guidelines, and success criteria can be applied to the needs of Digital Publishing. It provides informative guidance, but does not set requirements.

Posted in Activity News | Tagged | Comments Off on Digital Publishing and Accessibility in W3C Documents Note Published

DPUB IG Telco, 2016-05-02: F2F planning, Overview of Web Annotation

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

Accessibility Note

A (virtual) F2F meeting is planned on the 25th of May; the telco spent quite some time to plan the agenda for that meeting. The bottom line is that virtually the whole of the F2F meeting should be spent on the use case documents, addressing use cases on portability, random access, digital signatures, manifests, security, etc. Relationships to the BFF work at IDPF will also be discussed, as a straw man approach to new types of manifest. The goal will be to work on real text and significantly move the core document forward.

Notes in HTML

Tim Cole, Rob Sanderson, and Ivan Herman gave an overview of the Web Annotation Work. They gave some details on the new version of the Web Annotation Data Model document, which provides a simple approach to describe an annotation structure with a body (or several bodies), target (or targets), both enriched by provenance, license, etc, features. A rich selector mechanism is also defined to ensure a better description and access to, possibly, a part of a resource, providing a finer granularity than what is available through, eg, media fragments only.

There were some discussion on current implementation plans, as well as the timing and plans to migrate the current annotation work, as part of the IDPF documents, to this new version.

The plans for the Web Annotations are to issue a Candidate Recommendation sometimes late spring this year, and hopefully publish a Recommendation sometimes by the end of this year.