MathML full meeting notes, 16/7/19

*Next meeting will be in three weeks: 6 Aug*.

Thanks to Charles for scribing. The meeting was recorded and can be heard
here:
https://benetech.zoom.us/recording/share/P-OEZzjxr_R_sdABFzDT9QWw6aQzC6PpxcZ3jpnovx-wIumekTziMw


Participants: Neil S., Charles L., Steve N., Sam D., David C, David F.,
Murray S

Regrets: Patrick I.
Brief status report on core working group's progress

NS:  Making progress on a number of technical issues. Focus is now on CSS
related issues such as border margins (collapsible etc.) and what elements
interact with what CSS properties
TPAC meeting F2F? (Sept in Japan)

NS: CSS F2F meeting at TPAC Sept.  Want to get to the point where we can
ask questions to the CSS WG.  E. g., what will we do about fonts and their
issues. Generic Fonts (serif / sans serif) maybe there should be a generic
font “math”

NS: Is anyone going to TPAC?

Charles will be going.  Neil to Link Charles with Brian.
Full Spec issues (#108 <https://github.com/mathml-refresh/mathml/issues/108>
)Process & final formats

Core Spec - Work in progress, details are getting nailed down, what the
format of the spec, and what will we do about the full spec?

David has done a great job on XML processing, and generating lots of
formats at the end of the process.  Moving it into a different format which
is easier to edit.

Issue # 108.

David: MathML since been in xml, and xlt spec/query and is very old.  The
MathML pipeline is customized heavily. XML is not popular anymore, and
Browsers implementers hate xml so they don’t like to look at this xml
spec.  Alternative ReSpec HTML version of final. BikeShed is the other
options. ReSpec is most common.

Charles: W3C uses ReSpec for all specifications as far as I know.

David: I suggest we move to this, otherwise it comes down to me.  One big
thing over the time back to 98, the W3C specification has changed, all the
frontmatter boilerplate it just updates itself with reSpec and keeps it
uptodate.  Big savings. Originally 2 pdf version, HTML version + MathML
etc. People want only one version. I think one file/one version would be
ideal. There is a link to the issue on Github with this big change
<https://davidcarlisle.github.io/mathml/>.

Neil, you mentioned we would give up a few things other than multiple
versions.

David: we could still use XML pipeline for those (unicode to xml
characters) most outsourced dictionary is generated from that.  Generate
separate html which could get pulled into reSpec. I don’t think there is
that much, and old pipeline could pull out examples as well.  Makes keeping
spec much simpler.

Open Math is a similar spec / pipeline and there is an open issue with
creating pdf is broken and I don’t want the MathML pipeline to break.

Neil: I think this is a no brainer and to use reSpec since everyone is
using that.  If it does change others will also have to switch as well.
What is the end format? 1 is a single html doc, other is broken up by
chapters.

David: you can do it either way.  HTML 5 single spec so you can search
easily.

Neil: anyone object to moving to reSpec?

No.

Neil: anyone object to a single file?

No

What do we generate from final format (pdf, html with MathML or images) pdf
doesn’t make sense anymore for a web spec.

Do we want to generate side by side with MathML with images.

Frederic thought that wasn’t a good idea.  Usually w3c specs only use
images.

David: it is easily changeable. You can have them all rendered or all not
rendered.

reSpec could do it, you have the MathML there it's not a big deal to do
either way.

Neil: It’s sometimes nice having MathML rendered live so you can see how
well your browser works, but doesn’t seem appropriate for spec. I vote for
keeping MathML live examples out of it.

David: we could have a notes document with all the live MathML examples
separate.  SVG spec has links to the SVG real examples. Some of the
examples also have links.

Neil: I like the idea at top of spec linking to the image with MathML
examples.

David: we can always have multiple branches in GitHub.

Neil: inline MathML rendering or just images in spec?

Consensus: use images in the spec.

Core Spec, vs. Full Spec.  how to keep them so they don’t drift apart.

David: we need to separate in full spec a web platform implementation from
others.  You would make the core spec and rendering normative.

Core Spec CSS down to pixel rendering, but not true for full spec. If
someone renderers mfrac a little differently than core, we don’t want to
disallow that.

Neil: agree, full spec is not pixel perfect representation, that is defined
in core.

Core: has maybe ~80% of full for presentation MathML, but in Full Spec may
have some concepts that isn’t in Core.

If everything is in Core, in full spec mfrac or mn and we need to support
non-core implementations.

Neil: Sounds like we do need to duplicate some of what’s in in core.

David: stretchy chars on non web platform is more relaxed,

Neil: What about algorithms: there is an algorithm on how to stretch chars
(you figure out the size of the stretchy characters.)

Script level, script size multiplier (still in core) maybe one way is to
resolve this if you want to find out algorithmic details, go to the core
spec.  Have core include an algorithm not tied to css.

David: You can reference to core 1 or be vague in full.

Neil: Writing a higher level description, I would like to see Full
shrinking.

David: to shrink the full spec wondering splitting the whole thing into
spec and have all non-normative into a separate notes document.  Historical
information to the Notes.

Neil: I don’t think you would want to take out all the non-normative out,
bibliographies, and stuff about the document itself etc.

David: chapter 1&2 & 5 there is an awful lot that can be moved out.

Neil: chapter 7 is another section which could be moved out.


David: most of chapter 6 as well.  One way to quickly get a smaller spec.

Murray: size of spec isn’t that important, I don’t see it being an issue.

David: the review process is one case, and if you want someone to implement
it, it’s a big ask to read the entire spec.

Neil: how big core is what really matters from a browsers prospective.

David: it can be that core gets accepted and MathML not get accepted.

Steve: what is rational in splitting into core instead of a full spec like
HTML or SVG.

Neil: core is not a subset of MathML you can use css styling, there are
things that are hard to do and use polyfills by core.  Shadow dom may be
used. The split is that browser manufacturers would only use this spec.

Neil: most of html5 is now fully implemented by all browsers and they are
looking at stability by freezing it as is

Sam: how to maintain presentation / content without having to have
crosslinks like described in chapter 5.  I like David’s approach to full
spec, if anything doesn’t fit into the full it can moved into a notes
version.

Does anyone object to reorganize the full spec with a notes separate
document.

No.

Neil: I will help you David in separating the full / notes document.

David: reSpec includes smaller things like chapters, it can be split up
separate files that isn’t a problem.

Neil: should have David merge changes into the repository.

Charles: separate into multiple files

Neil: start with chapters into separate files and if we need to break it up
more we can do that.

Sam: How do I get this?

David: just clone the repo and edit the html files, respec is pulled in
with the index.html file.

Charles: in reSpec there is a lot of templates to create warnings, editor
notes, notes etc.

David: I will just need github id in order to editing rights.

Neil: Running out of time. I will make Murray’s agenda item the first thing
next meeting.  6 weeks between meetings this time; should switch back to
monthly. Let's have a meeting in 3 weeks (6th of August)?  Objections?

No.

Charles set up a meeting.  Murry’s topic first then semantics.