Digital Publishing Interest Group Teleconference

<trackbot> Date: 21 September 2015

<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html

<tzviya> chair: tzviya

<scribe> scribenick: dauwhe

<tzviya> http://www.w3.org/2015/09/14-dpub-minutes.html

tzviya: first item: approving minutes

<Ralph> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html

tzviya: any comments on minutes?
... minutes approved
... we've invited Daniel Glazman to talk about...

DPUB API-s

glazou: I am the implentor of a WYSIWYG editor
... only native epub2/3 editor
... which led me to discover some complications in spec
... the very low-level code you have to write to access the package

<astearns> http://bluegriffon.org/

glazou: if you want to add metadata, for example
... you have to follow a chain of IDs and IDREFs
... so I want to hide that complexity behind some APIs

<tzviya> http://www.bluegriffon-epubedition.com/

glazou: to open, validate, add files to package
... delete files, change metadata
... the code you have to write now to do this is huge
... and I think this has hindered the adoption of EPUB3
... if we had an EPUB object model with an open-source object model
... and a polyfill
... right now everyone has to implement everything from scratch
... so an object model for EPUB, or more generally electronic books
... would be a good thing
... I can elaborate, but this is the summary

tzviya: I have a question
... this group has been talking about shifting the digital publication model towards models available on the open web
... are you thinking about EPUB package?

glazou: I want something more general
... that would work for HTML in ZIP, for example
... I want to hide the complexity of the package, of epub
... hide the complexity of whatever is implemented
... the object model could be mapped to whatever the implementation is

tzviya: I like that idea

<Bill_Kasdorf> +1

clapierre: I was wondering about a11y features of bluegriffon
... can you add aria-roles and accessibility features

glazou: yes I can

lrosenth: I think the idea is very good
... especially if it's not package-format-specific
... the question is where's the boundary?
... is this an API or an object model for any type of publication?
... or just OWP publications?
... I'm trying to understand the boundaries

glazou: think of that object model in two layers
... the first level is the visible API layer
... the second layer underneath is the system layer where you call the guts of the package
... my primary goal now is EPUB3

<Bill_Kasdorf> +1 to the two layered strategy

glazou: but that second layer could be different for different implementations epub2, mobi, whatever
... it's doable

lrosenth: all the examples you gave are variants of the same thing, for example PDF
... do you envision that same object model could apply to something completely different
... or does it only apply to OWP resources bundled together

glazou: I think it could be open to absolutely everything
... it's just a question of writing a layer that's between the PDF and the API
... in theory, yes.
... the lower level would have to be rewritten for every format you want to reach
... think of it as a "publication object model"

ivan: coming back to EPUB
... how does this API deal with other object models, like HTML
... how are these combined?

glazou: I don't understand the Q

ivan: I understand that from your API I reach a specific resource in the package, for example HTML5
... do you try to parse the HTML with your stuff?

glazou: I've not completely written this
... imagine you open a package and get list of resources and fetch one
... if it's HTML, what you retrieve is the HTML DOM
... if you want reach it as a file, you just need another set of API
... it's not really a file system
... the idea is to as soon as you can fall back to existing DOM APIs you do so

mgylling: just to be clear
... I thought I heard you say an API for reading and writing
... this is for reading systems as well as authoring tools?

glazou: absolutely
... add stuff, delete stuff, change stuff...
... thing of all the things you do to a DOM tree
... you should be able to do all those things to a publication package

<Bill_Kasdorf> Also +1 to always referring to what we are talking about as "a publication package."

mgylling: one issue on the reading side is the Readium foundation
... they have a read-only API
... would be interesting to compare your proposal to what Readium has

lrosenth: focused on a JS-based API model
... do you think this could extend to a REST model or other languages

glazou: I mentioned JS because this is obvious and immediate usage
... clearly JS is not my sole focus
... should be buildable in C++
... a REST API should be possible in an ideal world

lrosenth: are you designing it around JS or a generic object model?

glazou: the latter. I'm writing Web IDLs, not JS
... it's a lot of work but wanted to talk to people before investing lots of time

tzviya: this is very much in line with what we've been working on lately
... like our requirements for packaging web apps
... the concepts work very well together
... what the next step is is a good question

glazou: I started writing Web IDLs
... it's a lot of effort
... having a place to discuss this with people would be good
... I'm a newcomer to world of dpub
... I could miss things, make bad design choice
... having discussion would be good

tzviya: are you on EPUB31 mailing list?

glazou: I am

<Ralph> [I wonder to what extent Markus and other EPUB architects have been thinking of an object model in the background]

tzviya: we're having this kind of discussion there, too

glazou: my problem is that we should go quite fast
... an OM to be designed should take 18 months max
... it will pass quite quickly

<Bill_Kasdorf> Fast is good for this, because it's foundational for other specs and implementations

glazou: the more I look at the market the more we're limited by the lack of such a framework on a stable OM
... I think it's a market enabler

lrosenth: I think it's a good idea
... my biggest comment would be that this object model needs to align with work on identification
... whatever work we do in this area is done by same group or in close collaboration

glazou: my only goal is to make that happen and I'll work with anyone, W3C, IDPF, wherever

ivan: putting on w3c hat
... what's next step?
... having discussion based on more specific document would be great
... I think this group is the right forum
... don't want to argue whether the final development it's here or IDPF

glazou: I have a question
... this group is not tailored to published specs

ivan: initial discussion stays informal
... with new charter we can do proof-of-concept spec
... but won't be REC
... if it should be REC then we must go down WG route
... my suggestion would be to write a note published by DPUB
... explaining why an OM would be good
... and suggesting ways to reach a REC
... I think it's a joint effort between IDPF and W3C
... higher-level objects are IDPF
... but objects to be retrieved are DOM nodes
... let's not get into "cuisine" of where/how it gets done
... tzviya and mgylling are the chairs, they can decide if this is the place to publish a note
... I'd go further, and publish a skeleton of the interface
... whatever it is, we'll have to convince people to devote time and energy to a WG

glazou: I can start that

<lrosenth> POM works for me...

glazou: I can start that document, but what would be the title? Publications Object Model?

ivan: we've had a hundred-email discussion on terminology

<Ralph> "curated document object model" - cdom ;)

tzviya: we haven't talked about portable object model :)

mgylling: it's apple not potato

<glazou> ;-)

mgylling: I almost forgot
... Ivan covered it
... we need to get IPDF implementors a way to be involved
... maybe it's a CG

glazou: I have no religion about that
... whatever works

ivan: let's not worry
... let's get a document and then see where it goes

tzviya: OK
... we are at the half-hour
... we'll try to get something started
... we can tie in some loose ends... packaging, glossary, etc

ivan: each word is a hundred emails ;)

tzviya: as soon as glazou said publication object model it sounded good

<lrosenth> +1 on POM

<pbelfanti> +1 on POM

<Bill_Kasdorf> +1 but I prefer "Publication" to "Publishing"

<pbelfanti> As long as we don't get sued by Apple:-)

<Bill_Kasdorf> It is also promoted as a healthy thing a la "POM Wonderful"

tzviya: any more comments?

everyone: silence

tzviya: thanks glazou!

<Bill_Kasdorf> Seriously I like the pomegranate metaphor because it

<Bill_Kasdorf> 'because it's a package with lots of little things in it

tzviya: I forgot to introduce my collage John Pedersen

John_Pedersen: I've been involved in developing our schemas in Wiley
... we're getting involved in all things digital

tzviya: OK
... John is particularly interested in Math

John_Pedersen: it is my background, I was a math professor

tzviya: Peter, we'll turn it over to you

pkra: I hope I figured them out :)
... where should we start?
... should I recap?

MathML discussions II

mgylling: yes please

pkra: the most obv. question is where is this coming from
... most critical one is that browser dev for MathML support has stalled in the past years
... has never been driven by browser vendors but by unpaid volunteers
... this is the base problem
... we have MathML but not implementation
... 2nd problem is MathML is in maintenance mode
... Math WG is up for rechartering
... maintenance mode would have some consequence
... the 3rd issue is new tools for Math on web

<pkra> ... new features in MathJAX, ability to convert MathML into something that looks good

<Ralph> 14-Sep MathML discussion (part 1)

pkra: pre-render into HTML or SVG
... so you have good rendering but not actual MathML in the page
... other tools like KaTeX that don't even use MathML and go to LaTex ways
... or tools like PDF.js that just convert something into HTML
... my personal perspective:
... browser development is not working out
... we see no interest
... this is a huge issue
... 2nd assumption is how MathML should be realized in browsers
... for me that means HTML+CSS
... in the aughts it was a black box for rendering
... some people think it should be in a separate renderer
... at end of call last week, Ivan asked what I would do if I could do anything
... the key problem is that browser vendors don't care
... which has tech and personal connotation
... they're not involved in Math WG
... haven't given input to spec
... fundamentally there's no interest
... so we have to make them interested
... there are areas that we can make them interested
... typographic detail and reliability
... if math layout was implemented you'd get better typography
... odd way to get there
... large areas are shared
... multiscript, sub/superscript and pre/post
... fancy borders
... lots of math is just fancy borders
... there's layout and semantics
... on layout end, there's interest from Houdini that we might pursue
... on the semantic side, there's the big glaring hole of the ARIA spec
... which has just one "Math" role
... and there seems to be some interest from ARIA
... since renderers can't rely on MathML
... you want to expose underlying semantics
... one more thing
... ivan asked why browsers don't care
... MathML is a top-down solution
... it assumes you want to solve fundamental problems before you want to help your layout along

lrosenth: are you suggesting that ARIA would be the direction to apply semantics to math rather than many other directions?
... why ARIA?

pkra: I'm not sure if ARIA is the right direction
... with the tools I use for math on the web
... you can't use the mroot element and use clever CSS, you must use DOM injection to build layout around it
... feels similar where you want to build button but you can't use button element, but must use ARIA role="button"
... I"m not talking about detailed semantics
... but I think there's low-hanging fruit to help a11y
... like presentation MathML-level semantics

ivan: I'd come back to presentation side
... I'm not really clear on the direction you want to propose
... current approach is that I put in my HTML5 some MathML markup
... the script just catch this stuff then does complex JS rendering
... is that correct?

pkra: yes
... I see a strong move towards doing the JS on the server rather than the client

ivan: there's a move to do all that on the server
... take that element and turn it into clever html and CSS, and that's all my client sees
... is that what you're proposing?

pkra: it's what we're facing
... developers are eager to not do MathML rendering on client

ivan: that means if I am a random user who writes HTML with math then I have to run it through a special server

pkra: it's not like the client side is going away but you can do both
... professionals can use the complex solution
... there are people that throw markdown on their web page and have JS convert it on the fly
... but we'll see more and more people doing it on server
... but then you disconnect the MathML from the output

ivan: that's where ARIA would come in

pkra: yes
... right now you could just put MathML beside rendering and hide it
... you want to expose MathML to AT
... now you have AT content not connected to visual

ivan: still concerned about client side
... they use the term "polyfill" as the tool that solves every misery of the world
... last time you remarked that MathJax? is not good at polyfilling

pkra: MathJax is not a pollyfill in the modern sense
... a polyfill should be as similar to a native implementaiton as possible
... and lay the basis for the native implementation
... for example, picturefill
... you develop spec alongside polyfill
... with MathML you could imagine this
... you could write a polyfill that creates custom elements etc
... make complicated custom element structure
... we don't work that way
... it seems like a difficult process for performance
... you don't want to expose any APIs but the DOM
... you would expect development to manipulate DOM as if it was a normal MathML implementation
... but no one is doing that

ivan: You don't think there would be interest?

pkra: I don't think it will solve the core problems

pkra: it wouldn't solve layout, just shove it into shadow DOM
... it wouldn't show us a way towards native
... make it easier for browsers to ignore
... third, it doesn't solve any of the non-JS problems
... since web components require JS

tzviya: is there a solution?

<Ayla_Stein> need to run to a meeting, thanks!

tzviya: it sounds like we're saying there are a lot of different bad solutions

pkra: we're not a polyfill because web components aren't yet available
... we've decided to ignore this
... because the real problem is to render in HTML and CSS
... let's bridge the gap and get the rendering to be easier
... have more of it done by native
... make this usable to AT
... have a way of exposing semantics
... it's like grid before grid layout, or flex before flexbox
... we need new stuff to make this possible
... just a personal opinion

lrosenth: that makes perfect sense
... my concern is that I don't want us to lose the semantics
... or redo the syntax for different people
... AT knows how to deal with MathML
... but layout doesn't know how to deal with MathML
... so let's not throw away the existing work in order to make browser vendors happy

tzviya: to flip that
... it's used on back end now
... it's used in processing
... how a11y is it in real world?
... if the browsers aren't using it, how used is it, really?
... maybe not scrapping MathML but building on it

<Bill_Kasdorf> the company I work for creates thousands of MathML expressions daily. It is used a LOT, just not in browsers.

lrosenth: you need all groups in the room--AT, renderers, semantics

ivan: this has been tried and failed for the last twenty years

<pkra> I could go on ...

tzviya: at least ARIA has browsers and AT vendors in the same room
... we're not talking about scrapping MathML

ivan: the question for me
... do we have to modify MathML to make this server-side processing more streamlined?

<pkra> +1 to dauwhe