Minutes: MathML Semantics meeting of 18 June, 2020

The meeting recording failed this week.

Big thanks to David Carlisle for the minutes this week!



Attendees:

Neil Soiffer

David Carlisle

Sam Dooley

David Farmer

Bruce Miller

Patrick Ion

Louis Maher

Akashdeep Bansal

Deyan Ginev

Steve Noble

Murray Sargent

Accessibility Primer
<https://mathml-refresh.github.io/mathml/docs/accessibility>

https://mathml-refresh.github.io/mathml/docs/accessibility


NS: Accessibility tree in DOM MathML appears in that tree, but no spec to
define that it should be. W3C has WG looking at this.  Some attributes in
MathML are transferred to AT and some are not (with no clear logic to which
are dropped). The primer is meant to inform people in that group of the
differences between math and text, and hence why math needs different
treatment.

MS: covering a lot of areas even Chemistry at the end

NS: There are working groups looking at Chemistry so wanted to keep that
prominent

PI: It will need more examples, It isn’t just chemistry that has math-like
layout math formulas,

that appears in many technology areas.

SD: aim is to concentrate on answering the question “why is math
accessibility different to text accessibility” to an audience familiar with
the latter.

NS: didn’t want to make it too long.

MS: I don’t think it’s too long, should probably define acronyms such as AT
since it aims to be a primer.

BM: if original target was explaining math to people familiar with AT, it
also useful for people with people familiar with math but less familiar AT

DF: could have chemistry example nearer the beginning

DF: seem more repeatedly say why you are not using content mathml.

DC: it’s not the content mathml that is verbose, it is the parallel markup

Abstracting markup patterns
<https://mathml-refresh.github.io/mathml/docs/layout-semantics>

https://mathml-refresh.github.io/mathml/docs/layout-semantics

BM: evolved so that the notation has become a mechanism to specify where
the implied operator and its arguments are in the presentation. So a
mapping from presentation to something “content like” if not exactly
content mathml.

BM: the meaning attribute separate, see long list of examples

BM: “Bad and Ugly” section highlights the tricky examples where some design
help is needed to produce reasonable markup.. Eg cases with multiple
scripts, presentation mathml ofen nested according to visual layout
unrelated to semantics,  (x bar) sub i  but semantically the bar operator
over (x sub i).

NS: one good thing about recent revision is that notation is now described
as pointing at the operator, and meaning may be in different places,
depending on the notation, this solves one issue we had with mathrole,
where it was often not clear where to add the attribute.

PI: Separating layout schema from the semantic meaning remains a good
thing, and provides

flexibility that Neil has pointed out.

NS: might need a special notation where you call out that the nesting is
different

SD: some hope with careful authoring that the semantic of (say) an overbar
is implied by the markup used, and you do not need to reference external
definitions

NS: need good markup (esp mrow structure) we may need to define canonical
mathml, perhaps a library or at least spec for how well structured mathml
should be constructed.

BM: Tried to be as forgiving as possible but sometimes you really need the
mrow.

MS: missing an example for n-ary expressions. Mrow with first child msubsup

BM: if you look at the examples, the cases where notation= is on the

 mrow the mrow is really needed, even if it could be dropped without
affecting the layout

PI: there are examples where operator is in subscript rather than
superscript, so may need notation schema for sub and super in all
combinations

NS: could combine sub operator and sup operator into a script operator

BM: DG had also suggested these could be combined but complications with
msubsup

DG: in content mathml always <apply> op …, so even a generic pointer to the
operator would go a long way, you don’t need to distinguish sub and super
scripts or other layout.

SD: we have tried to go down the path of enumerating layout schemata
before, and anyone making tools from content to presentation alway sleeves
some cases unhandled. Are we trying to over-specify the possible notations.

DG: If we want to simplify mathml we shouldn’t specify too much but leave
it open to users arxiv almost every paper defines new notation. A simple
generic pointer to the main operator already gets a long way.  Just need to
specify (perhaps via id) the operator and its arguments, do not need to
restrict/enumerate the possible layouts

NS: are you proposing a notation lambda function. Could avoid problems with
global ids by having something like arg=1,2,3,4 to mark the arguments of
the specified operator.

NS: are we having simple defaults eg just for msup, or more fine tuned
defaults eg ^T defaulting to transpose.

BM: not sure it needs to be a new attribute, but what is the mechanism to
specify the argument, but how do we point to the children, xpath, ids, ..?

NS: what direction to work on for next meetings? I like the idea of generic
arguments

MS: I’d like to see more defaults as K1-12 doesn’t need much of this, and
would like to see something for n-ary

SD: can we rename the meaning attribute (to something)

[PI: I suggest doubling the ‘m’ to ‘mmeaning’ (math meaning, of course)]

NS: Could you (BM, DC, DG, ..) add something on naming the arguments to the
existing document?

BM: It could be added, but need to decide what the mechanism for pointing
is, we can then describe the named notations as shorthand for the generic
ones

BM:  Will get together with DG and make a suggestion or list of
alternatives for the general layout possibility (name or xpath or …)

PI: It is exactly the subject of the last sentence of your current draft.

DC: I’ll try to write up some examples where the arguments are labelled so
you don’t have to have some language like xpath to find them.


Meeting next week at same time.