Re: Updated invitation with note: MathML Refresh Meeting

Some possible things to discuss under

 > 3. Documents

Note I'm just looking here at formats and names, not actual content...


MathML4
--------
I'm assuming we call this MathML4 not MathML3 3rd edition
Mostly the current draft set up for that name, but some remnants of 
"MathML3" remain: notably in the frontmatter and in the generated schema 
file names.

Currently it is built as:

html (by chapter, no mathml)
html with diff marking (by chapter, no mathml)
xhtml (by chapter, with mathml examples)
html(5) (single file with mathml and optional mathjax rendering)
pdf (single file)


I suggest that we drop at least the xhtml version (which was originally 
needed to display mathml)  just having the html(5) version is also a 
possibility but my recommendation would be to keep the others as
(a) the build is set up and having fewer changes is good and (b) I think 
it's good to have a normative version that works in all browsers today 
rather than just browsers that have the math support that we would wish for.

Currently the source for this is xmlspec XML markup, I would suggest we 
keep this as is for now at least although it would be possible to move 
the xml closer to html so it looks less alien (eg the markup for lists 
and paragraphs exactly mirrors html, but with different element names...)

People can work on the spec with no specific tools as the build is 
automated on travis, so if you haven't got a local setup you can fork 
the repro, get travis to test any proposed changes then push them to the 
mathml-refresh/mathml repository.


mathml-web-profile
------------------

The current version is a rather quick sketch that I pulled together from 
various sources, Frédéric commented in a gh issue that it was rather 
inconsistently named (mml-redux, web profile, mathml-in-html, ...)
in different parts. I did some rationalisation of that but we need to 
pick a name.

I quite liked "mathml web profile", but I think this should be thought 
of as a self standing spec on which "full" mathml can build, rather than 
something normatively defined as a subset of full mathml. So I suspect 
that Frédéric is right and the name is wrong and something like "MathML 
Core" would be better. We should consider whether it's "MathML4 core" or 
"MathML core") to have or not have version numbers still being a 
somewhat contentious issue in html(5) related specs..

Currently this document is served as html with mathml (and svg) inline 
with TeX text as an alttext format eg

  <math id="I1.i1.p1.m1" 
alttext="\sigma_{8},\sigma_{9},\xi_{8},{3\xi_{8}},{7\xi_{8}},\sigma_{11}" 
display="inline">.....

This means that it looks fine in firefox but (to say the least) less 
fine in chrome. So..

We should decide whether the document should contain MathML in the main 
text or whether (like the MathML spec) it should avoid doing that, and 
if there are any small expressions use simple html <sub> markup, or 
(perhaps) statically convert to svg rendering while generating the 
document, or have the math as mathml but include mathjax or some other 
javascript fallback....


Currently the source for this document is essentially html as xml but 
then combined and normalised via the build script. The images are 
currently inlined as base64 encoded data but that's an artefact of the 
way the sources were pulled together, I assume we'll reconstitute the 
original image sources as needed to make editing  possible again.


Other documents
---------------
eg the css properties and mfenced polyfills, one advantage of having 
"our own" github area is that we can create and destroy git repositories 
easily as required without having to get W3C management approval to a 
new repository each time.
I'd suggest we be fairly flexible on formats here, basically go with 
whatever the person doing the work finds comfortable. (Someone might 
like to try the javascript based refspec workflow for example.)

At some point we need to start to push things towards the W3C Rec track 
but we can't do that as a community group anyway so that is somewhat 
further down the line. At that point there may be some advantages to 
merging some of these separate documents into appendices of one of the 
other documents as my experience is that there is a non-trivial amount 
of overhead in pushing a document through the W3C process, and one 
document with 2 appendices might be more manageable than three separate 
documents, each requiring a separate vote of the W3C membership to be 
published. But we can decide that much nearer the time.


Editing
---------
Access can be given to anyone who needs it directly to the 
mathml-refresh repositories (currently Frédéric and me and a robot user 
used by travis to push rebuilt specs back to the gh-pages website).

Alternatively anyone can fork the repositories and then make a pull request.
Daniel already made an edit to the web profile spec via this route see
https://github.com/mathml-refresh/mathml-web-profile/pull/1


As noted above, even if you have direct push rights, testing edits in a 
fork allows you to test things without showing up on the main 
mathml-refresh pages until you are ready, so we may want to recommend 
that as the preferred editing mechanism.




Sorry this got a bit long for just one item on the agenda:-)

David

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.