- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 22 Sep 2015 07:27:40 +0200
- To: W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Message-Id: <D794CC9B-3BEC-4E29-BB98-AD5D3AEC6B1B@w3.org>
The meeting minutes of yesterday's meeting are here:
http://www.w3.org/2015/09/21-dpub-minutes.html <http://www.w3.org/2015/09/21-dpub-minutes.html>
Text version below
Ivan
----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
[1]W3C
[1] http://www.w3.org/
Digital Publishing Interest Group Teleconference
21 Sep 2015
[2]Agenda
[2] http://www.w3.org/mid/60044b021c654e5f98268070bc5c796a@CAR-WNMBP-006.wiley.com
See also: [3]IRC log
[3] http://www.w3.org/2015/09/21-dpub-irc
Attendees
Present
Charles LaPierre, Ben De Meester, Ivan Herman, Karen
Myers, Daniel Glazman (glazou), Ralph Swick, Tzviya
Siegman, Dave Cramer (dauwhe), Leonard Rosenthol
(lrosenth), Deborah Kaplan, Markus Gylling, Peter
Krautzberger, Alan Stearns, John Pedersen, Vladimir
Levantovski, Brady Duga, Paul Belfanti, Bill Kasdorf,
Bert Bos
Regrets
Julie Morris, Mike Miller, Nick Ruffilo, Laura Fowler,
Tim Cole, Zheng Xu
Chair
Tzviya
Scribe
Dave Cramer
Contents
* [4]Topics
1. [5]DPUB API-s
2. [6]MathML discussions II
* [7]Summary of Action Items
__________________________________________________________
<trackbot> Date: 21 September 2015
<tzviya> agenda:
[8]https://lists.w3.org/Archives/Public/public-digipub-ig/2015S
ep/0138.html
[8] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html
<tzviya> chair: tzviya
<scribe> scribenick: dauwhe
<tzviya> [9]http://www.w3.org/2015/09/14-dpub-minutes.html
[9] http://www.w3.org/2015/09/14-dpub-minutes.html
tzviya: first item: approving minutes
<Ralph> agenda:
[10]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
Sep/0138.html
[10] 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> [11]http://bluegriffon.org/
[11] 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> [12]http://www.bluegriffon-epubedition.com/
[12] 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> [13]14-Sep MathML discussion (part 1)
[13] http://www.w3.org/2015/09/14-dpub-minutes.html#item01
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
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version
1.140 ([15]CVS log)
$Date: 2015/09/22 05:20:09 $
[14] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 22 September 2015 05:27:52 UTC