DPUB IG Telco, 2015-09-21: Publication Object Model, MathML

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

DPUB API

Daniel Glazman presented his ideas of an API to access contents of publishing packages (like EPUB). Daniel is implementing an EPUB3 editor (Bluegriffon). When you create a tool like that and, for example, you want to add metadata, you have to follow a chain of ID-s and IDREF-s repeatedly. The same for adding a file, delete a file, etc. The code you have to write is huge and repetitive. This may have hindered the adoption of EPUB3. If we had an EPUB object model, with an open source implementation and polyfill this would help deployment; right now everyone has to implement everything from scratch.

Although the current development is focused on EPUB, the idea is more general. It would be a two-layered approach: a general layer to access essential constituents within a publication package, and then an lower layer mapping this to EPUB, generic ZIP, MOBI, whatever else. The API would also connect to other API-s underneath: i.e., if the API gets to an HTML resource within the package, it would return a DOM tree of the HTML content. The API should not be bound to Javascript; it is currently drafted in Web IDL.

The discussions led to the agreement that an initial draft specification could be published as an IG Note by this Interest Group and, later, we can see how to gather enough interest and find the right format for a final specification, if there is an agreement to do so.

(Subsequent discussions converged towards the usage of "Publishing Object Model" or "Publication Object Model", i.e., POM, as a term to be used.)

MathML situation II.

Peter Kreutzberger, from MathJax, continued the discussion started the last week.

Based on the current situation around deployment, a better direction for implementation and deployment is emphasize the server side: an implementation would turn MathML into clever HTML+CSS, meaning that the deployment effort is more closely based on the renderers as developed by the browsers. Although client-side implementations would not disappear, but the bulk of the development would be on the server. It is not unlike the usage of markdown: although there are ways to render markdown on the client on-the-fly, many HTML pages are originally written in markdown, and then converted into HTML before publishing.

The issue is then accessibility. At present, what happens often in practice that MathML is put into the HTML page with display turned off alongside a, e.g., image displaying the mathematical equation. This is done because assistive technologies do understand MathML. The alternative is to rely on ARIA: the conversion of mathematics into HTML+CSS would also add the semantics to the ARIA framework and, therefore, again be based on technologies that browsers already deploy.

The issue of polyfilling came up, i.e., whether that approach would work. It may be possible, but makes a complicated custom element structure, and it seems to be a difficult process for performance. For polyfill, you would expect developments to manipulate the DOM as if it was a normal MathML implementation, but no one is doing that. MathJax does not do polyfill because Web Components aren't yet really available. Besides, the real problem is to render in HTML and CSS, i.e., it is better to get the rendering easier and rely on native.