W3C home > Mailing lists > Public > public-digipub-ig@w3.org > September 2015

Meeting Minutes 2015-09-21

From: Ivan Herman <ivan@w3.org>
Date: Tue, 22 Sep 2015 07:27:40 +0200
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Message-Id: <D794CC9B-3BEC-4E29-BB98-AD5D3AEC6B1B@w3.org>
To: W3C Digital Publishing IG <public-digipub-ig@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:12 UTC