DPUB IG Telco, 2015-06-29: Annotations, CSS, minor white paper changes

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

Update on the Annotation WG

Ivan Herman gave an update on the progress in the Annotation WG.

The group started with an input document provided by the Open Annotation Community Group. They had a specification for a data model, i.e., how to store annotations, what their structure is, etc. Their specification has been essentially re-published as a Working Draft, and we are continuing work on it. The biggest difference is that the CG document had all its example in the Turtle language, whereas the WG's document includes both Turtle and JSON-LD. This is because, while the CG was strongly Linked Data oriented, i.e., Turtle was fine, the WG's target is at Web Developers who feel more comfortable with JSON.

Next step is to transfer annotations through the network; for that, the Web Annotation Protocol has been developed. This document is in a fairly good shape, it will be published as a WD soon. It is actually a specialization of an existing W3C Recommendation, called Linked Data Protocol (LDP) which is good, because there are already implementation that can be reused, for example.

The final piece, soon to be an official Draft, is the RangeFinder API. This is a (JavaScript) API specification to find ranges of text or DOM nodes in a document, i.e., to be able to "anchor" of finding a text that may not have its own @id attribute, whose context may change, etc. This document is an API, i.e., aimed at developers; however, as part of the group's goals we will also discuss a 'serialization' of that, i.e., a possibility to define a URI (more exactly, a fragment identifier) using the RangeFinder concepts.

There are also some other issues that may be discussed in the group, though the work has not really started yet. This includes a possible Client side API (i.e., an API whereby Javascript developers could handle annotations on a higher level, hiding the details of the data model), or a HTML based serialization. The latter could be used in a client to add such elements into the DOM tree; since it's in terms of the DOM, it can be styled easily in general—which is probably something very useful. Whether that would use existing HTML elements, or whether it would require an extension to HTML is still to be discussed.

There are some overlaps between the DPUB IG's and the Annotation WG's membership, which is a good thing.

It was noted that the annotation WG's further use cases could also be very useful for this group, and more regular contacts would be good.

CSS Prioritization

Dave Cramer has begun a spreadsheet listing some of the CSS features that are important for the Publishing Community and that are not fully covered by the CSS work. (There is also a textual version which will, eventually, possibly merge with the latinreq document.) Eventually, this document should be communicated with the CSS Working Group to synchronize the needs and priorities. The group (and everybody) is encouraged providing comments, adding their wish lists, etc, to this document.

A question arose around footnotes and why they are not of a higher priorities; but the problem is that there is no real consensus within the digital publishing community on what the optimal approach handling those would be, i.e., how that should reflected in CSS. There were also discussion on how to include MathML related features into the document; there are clearly missing features (like aligning equations vertically on a specific character).

There was a longer discussion on the discrepancy between browsers and reading systems on the level of control they provide to end users in terms of styling (fonts, character size, etc). CSS had the notion of user stylesheet, which pretty much disappeared from browsers, and it is also not sure that is the right level of control; further discussion is needed on how that would translate into CSS.

It was also agreed that the document should strictly separate those features that do exist in a CSS spec, but are poorly implemented, from those features that don't exist in specification (and should). It was agreed that the table would be extended accordingly (e.g., looking at what XSL-FO has, or what systems like Antenna House implements for publishers).

Finally the issue of efficiency was also addressed (like, e.g., the blog on the subject) that is indeed a problem, although it is difficult to see what this Interest Group or indeed the CSS WG could do about it.

Small changes on the white paper

Ivan Herman also reported that the draft version of the EPUB+WEB have been updated to reflect a recent discussion on caching and resulting architectural principles; it would be good to get the relevant section reviewed as soon as possible, because the changes may have effects on the new charter, too.