Minutes: MathML Semantics Meeting, 25 June, 2020

The meeting was recorded:
https://benetech.zoom.us/rec/share/9eheaPKr3ENLT5Hn0E7_fKohNdjBX6a81nMcr6JfmEbCrT1awB6F1yr0oiNZZKTb
(Access Password: 1m&6qf^?)


Thanks to Deyan Ginev for minuting a fast paced and detailed discussion!



Attendees:

Neil Soiffer

David Carlisle

David Farmer

Bruce Miller

Patrick Ion

Louis Maher

Deyan Ginev

Steve Noble

Murray Sargent

Regrets: Sam Dooley

Discussion of proposals

https://mathml-refresh.github.io/mathml/docs/semantics-mini
https://mathml-refresh.github.io/mathml/docs/function-semantics

DC’s “not a proposal” (use “named layouts” to avoid labeling args in common
cases)

NS: let’s go through the list of problems: numeric args, ids, named args

NS: start with numeric args/paths

DC: MathML says adding mrows should be harmless, but this messes up paths

NS: If someone does canonicalization to clean up mrows, paths make that
harder

DC: Can avoid this if we know the target pattern

DC: The pattern tells us what to look for, and would know about mrows and
other stuff and skip those to find the args based on the named pattern

NS: maybe the paths should be smart in the other proposals

DG: binomial example is good.

NS: For multiple reasons, e.g. the parens may or may not be followed by a
single mrow holding the mfrac (which leads to lvl 2 or lvl 3 paths). Smart
paths may be an interesting approach.

BM: we shouldn’t be quick to dismiss mrows in smart paths, as they are
often required to hold notation name (though mini proposal can do without
them if the notation is added further up the tree)

BM: paths are OK to write for me, but near-impossible to read when someone
else provides a path example several layers deep

NS: id numbers can’t be used for copy paste, the global uniqueness
requirement creeps up in any UX flow with multiple equations

BM: DLMF’s workflow regenerates everything from scratch, so conflicts can
never occur in that flow, curious to see others

DC: nested occurrences with the same name/value need to be carefully
attended to. Uniqueness to document is tricky when you don’t have control
over document-level markup (spec itself doesn’t)

NS: we need to be careful for W3C review that we are using any HTML
attributes as per HTML’s purpose. Nesting poses challenges for selectors
with local names.

BM: selectors are not quite xpath, you probably could write them in xpath,
but you likely won’t want to pragmatically. Something “almost like id”,
would need special code to do the search, with a custom runtime engine to
perform the operation.

DC: xpath itself is fine, but you likely don’t want to use it inside the
document markup because it is huge.

DG: so how do we write binomial if we agree not to use numbered paths?
Named slots?

NS: Indeed, we can approach to fixed names vocabulary with named argument
slots (without paths)

NS: Next topic, ids. Not controversial to propose, completely standard.
Personally find them horrific due to global naming conflicts.

DG: In a work flow, copy/paste is hard and so difficult for hand
remediation.

DG: Kind of similar to using “class”

NS: Could use ‘name’, ‘arg’, or ‘class’

BM: “name” could be dangerous because scoped to form.

BM: submitting a form with MathML could be a mess if we used name. Also
avoid “href discussion”-like conflicts from the Core group discussion.

NS: arguments against using class?

BM: one has to address potential collisions with regular HTML flows that
already have class values set for the math expressions.

NS: likes the argument, you would have to add more specificity to the
values to avoid global conflicts with open-ended HTML pages

DF: similar argument can be made for id attribute, when incrementally
adding to an HTML page and having to re-check if global uniqueness is
preserved.

DC: blog articles are unique, but the summary page pulls last month’s
postings and you can’t control that markup, so you may end up having to
rename when you aggregate. So this id collision problem is already expected
in today’s incremental HTML workflows.

DC: multiple clashing ids can be handled by browsers, but seems like a poor
crutch

NS: returning to names. It looks like “name” can be ruled out due to
scoping. “Class” is problematic due to collisions with different authors.
So we may want a new name after all. Main suggestion: “arg”. DC had
suggested “operator” in conjunction.

DC: “arg” can be used with a number literal, or a string value.

BM: non-unique ids sound OK, and “arg” is a decent name.

NS: “mathid” ? others?

NS: sounds like we’re happy with “arg”

NS: we need to discuss n-ary operators. We need to be able to identify the
operators and co-highlight for accessibility, there are situations that are
more challenging (such as invisible times).

NS: intersecting the proposals seemed to reveal pointing to the operators
and args from the notation root saves on confusion and is tighter.

BM: The mini proposal (ignoring the selector details) is quite expressive
in several ways. You can specify arbitrarily complex subtrees by moving the
annotation high enough to capture the entire expression. At the limit case,
you can annotate at the <math> element for the entire expression, if it has
no usable mrow substructure at all.

NS: negative-c as opposed to minus-c is no longer flat.

BM: in n-ary arithmetic there are multiple ways to group the +/- subtrees.

NS: how do you capture all operands in a long +/- expression and have it
flat?

BM: it is a feature, not a bug, that you can annotate it both with flat
pmml markup, and deep pmml markup with the mini proposal.

BM: tries to recite path expression on call. Demonstrates how hard it is to
follow.

BM: @6(@4(@2(@1,@3),@5)@7)

NS: Not flat. Flat implies a single “+/-” operation, with everything inside
the top mrow being arguments.

DG: same precedence of infix operation, the inner structure reduces to a
delimited list (as in 1,2,3…)

NS: similarly with n-ary equals, or n-ry relations with \leq -- multiple
steps, each of which is at the same level.

BM: NS seems to be discussing different semantic interpretations, maybe?
“There should have been mrows” reduces to “somebody else should have added
proper parenthetical scoping”. It’s a question of what order do we carry
out the operations.

DC: it’s more constrained than a missing mrow, you really need the right
argument structure or you get a nonsense reading.

DC: named layout “polynomial” captures the intent of what we are discussing.

BM: “a > b > c” is “and(a>b, b>c)” with pointers to the original formula

DC: but you don’t want to read out the “and”s in a long multi-relation

BM: but you do when they differ as in “a > b \ge c …”. We should get beyond
the point of “here are the tools, the reader/author sorts it out”. We
should sort out as much as we can in the spec.

NS: Editor PoV: when writing in an editor, in the author’s mind they are
all on the same level, yet he should still be able to grab each chunk of
the larger expression.

BM: We need a new mystery operation for this n-ary polynomial, because it
isn’t plus or minus or… It would have to be specified and have a dedicated
handler.

NS: Main task for next week: find a good handle on n-ary examples, since
they have utility to be added in the spec.

BM: Always had the suspicion that the semantics for accessibility was
different from the semantics for Content MathML. Definitely different use,
e.g. you pronounce differently based on expression context, first / later
pronunciation etc. The language we have so far seems sufficient, but the
operators are beginning to look different to what one has thought of when
coming from Content MathML PoV.

NS: “transpose-of-A” vs “A transposed”.

BM: DG and I had a different conclusion. It is not the script necessarily,
but more likely one reading sounds more natural based on context (first
appearance, equation structure).

NS: Let’s focus on n-ary

DG: Only baseline infix n-ary or generalized? E.g. continued fraction =
n-ary division

NS: Good example -- can’t really point to the operator. Let’s attempt to
generalize. +/-, times, relational operators , …

NS: We have smart ids, we may have to do smart paths. Let’s continue next
week, since we’re overtime.