Re: Finished Editing The April 14 Minutes

On Fri, Apr 15, 2022 at 8:07 AM David Carlisle <davidc@nag.co.uk> wrote:
>
> On 14/04/2022 21:46, Louis Maher wrote:
>
> Hello,
>
>
>
> I have finished editing the April 14, 2022, intent meeting minutes.
>
>
> Sorry I couldn't be there this week.
>
>
> Just some comments on one section of the notes
>
> NS: We will not make a formal commitment to do this until DC can come back next week.
>
> I think it's important that the xml syntax for each entry is explicit in the main entry for the element.
>
> You need to know that set takes content, but  plus is empty, and that tendso has a type attribute
>
>
>
> DG: likes the compact form using descriptive paragraphs instead of tables.
>
> there are no  tables re-written as  paragraphs in Sam's draft? the tables are removed/moved, leaving the existing text.
>

Hi David,

We are now running a small risk of fine-tuning our minutes for the
week over the mailing list. Looking at your comments, I think behind
each of them is an opportunity to bookkeep a little better what was
stated in the meeting.

Quoting myself from memory, I volunteered an opinion when Neil
explicitly prompted me for one:
"I quite like the table (implied: and its new location), and the
direction of refactoring that further simplifies the text. Good work,
Sam!"

>
> MOS: Pragmatic MathML is not used often and perhaps it should be deprecated.
>
> "pragmatic" MathML isn't a defined term, but I assume you mean Content MathML that is not valid Strict Content?
>
> Actually apart from technical descriptions of mapping to OpenMath, I am not aware of any system that supports Content MathML that only supports the Strict subset.

Right. My recollection of that exchange was that Moritz had a specific
point which I can anchor in "4.4" of MathML 3:
https://www.w3.org/TR/MathML3/chapter4.html#contm.opel

Moritz raised the question whether elements named after "specific
operators and constants" should be getting deprecated in favor of
using "Intent" names instead. I believe he also did that in an attempt
to illustrate how having both can cause confusion to external readers
who are not aware of our group discussions.

>
> I did a quick search this morning for content mathml, none of which just supported Strict Content. I do not see any justification to deprecate the non strict part of Content MathML. Certainly that isn't an option in this WG which has a charter explicitly to make no changes to Content MathML (although we can change the specification layout of course)

Right, the majority position in the call was that we should follow the
charter and avoid major revisions to Content MathML in this iteration,
including any far-reaching deprecations.

I've now also started to more clearly express my own desire to do a
major revision of the Content chapter in the next iteration, i.e. for
MathML 5. It will take a very substantial amount of work to do well,
maintain continuity, identify and address the actual unmet
community+application needs, etc. Which is why I don't think we should
start this at all right now. And deprecating a large chunk of chapter
4 would definitely be "starting something" on those lines.

>
> I'll put a list at the end.
>
>
> DG: symbolic python is using something called content MathML two.  Content MathML may not be very inviting and has not been accepted.
>
> I tried to find this, but was not sure what you mean here, isn't this simply Content MathML, referencing MathML2?

Yes, this was a simple reference to Content MathML 2 on my part.

I brought up a curious observation from the symbolic ecosystem, which
is that sympy has a Content export which still points to Content
MathML 2. It is very specifically here:
https://github.com/sympy/sympy/blob/89722e3a0d3c0b45145a42c19db51851396f093c/sympy/printing/mathml.py#L127-L131

I speculated that this is the kind of evidence one could examine to
decide if mainstream symbolic systems are - or aren't - actively
keeping up with newer spec changes to MathML. I got a very healthy
reply that we should have more CAS representatives in the group
meetings when we decide to seriously re-examine this, which I very
much agree with.

Apologies on my part, I should have gone through the minutes and
double-checked at least the entries with my name in them.

>
>
> ----
>
> Chapter 4 has always been a been a bit unwieldy: listing each element twice, first ordering by syntactic structure, (4.3 in the current draft) then again by mathematical area (4.4 in the current draft).
>
> We tried to avoid some of the duplication in MathML3, with mixed success.
>
> At my fork I reduce it a bit more, putting the syntax tables in 4.3 with just a reference to them in the entries in 4.4.
>
> https://davidcarlisle.github.io/mathml/#contm_plus
>
> But I am actually favouring a more radical re-organisation, removing 4.4 altogether and moving the element descriptions in to 4.3.
>
> this would allow eg the arithmetic operators to be treated like the trig functions and all listed together, but would need to be re-ordered by syntax, so list all the binary infix, then all the unary operators etc so, as for sin/cos/tan, all the elements in a given section share the same syntax so can share the same description, and just have a sample example of one or two of them.
>

Sounds worth trying, the more compact we can make it without losing
information, the easier it will be to newcomers.

Interesting list at the bottom. The MathML.jl one is particularly
curious to me personally, and it seems its author is considering
MathML in the use case of systems biology, and the SBML format in
particular:
https://synonym.caltech.edu/documents/specifications/level-3/version-1/math/

I am curious to learn more about what SBML-based systems that leverage
MathML today are already out there, if anyone is aware of some - feel
free to send me a link.

Greetings,
Deyan

>
> David
>
>
> # python libraries
>
> http://mathdom.sourceforge.net/
>
>
> # Java Libraries
>
> http://www.eteks.com/jeks/en/doc/com/eteks/parser/MathMLInterpreter.html
>
> https://www2.ph.ed.ac.uk/snuggletex/UpConversionExampleFragment?input=%5Csin%5Ccos%20x#ex-cmathml
>
> # Julia Libraries
>
> https://github.com/SciML/MathML.jl/blob/main/README.md
>
>
> # TeX systems (Context)
> http://www.pragma-ade.nl/general/manuals/mmlprime.pdf
>
> # other XML Vocabularies
>
> ## CellML
>
> http://models.cellml.org/w/alberto/CorriasPurkinje/@@rawfile/69be71f74a2e4d13b05699cfad76974bf050787f/purkinje_model.cellml
>
>
> # Books
>
> https://www.google.co.uk/books/edition/XSLT_Cookbook/XhJHgaQCtuMC?hl=en&gbpv=1&pg=PA136&printsec=frontcover
>
> https://www.google.co.uk/books/edition/Dynamic_Web_Programming_and_HTML5/3kjYQHxHc7cC?hl=en&gbpv=1&pg=PA557&printsec=frontcover
>
> https://www.google.co.uk/books/edition/Computer_Algebra_Handbook/PaPoCAAAQBAJ?hl=en&gbpv=1&pg=PA156&printsec=frontcover
>
> https://www.google.co.uk/books/edition/Intelligent_Interactive_Multimedia_Syste/hJVKo9eWHnAC?hl=en&gbpv=1&pg=PA270&printsec=frontcover
>
> https://www.google.co.uk/books/edition/Handbook_of_Dynamic_System_Modeling/cM-eFv1m3BoC?hl=en&gbpv=1&pg=SA1-PA6&printsec=frontcover
>
>
>
>
> Disclaimer
>
> The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.
>
> This e-mail has been scanned for all viruses and malware by Microsoft Exchange Online (EOP)

Received on Friday, 15 April 2022 13:18:01 UTC