Minutes, MathML Full meeting 6 April, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Moritz Schubotz
   - Murray Sargent
   - David Farmer
   - Patrick Ion
   - Bruce Miller
   - Bert Bos
   - Deyan Ginev

<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-regrets>
Regrets

   - Steve Noble

<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

Anything that can be closed?

NS: Glenn Gordon from Freedom Scientific (JAWS) will come to our April 13
meeting.

NS: Pinged Apple and Volker about coming to our meetings. Volker did
respond back. Let us concentrate on AT things next week.

NS: would like to give them a heads up on what our group wants to know from
them. Are there documents they should read before they come next week? NS
would like to get document suggestions from our group.

NS: There's some discussion going on about potentially changing aria live
regions. These regions support plane text. It would be better if aria live
regions supported MathML. If you are interested in this let NS know.

NS: Archive is hosting an accessibility forum on Monday, April 17. They are
expecting over 2,000 people. It is free. It will consider blindness and
deafness. There will be breakout rooms.

From Deyan Ginev to Everyone: https://accessibility2023.arxiv.org/
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-2-intent-issues-this-week->2.
Intent issues this week:
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-a-a-href-https-github-com-w3c-mathml-issues-435-do-the-of-arguments-define-a-core-quot-intent-quot-435-a->a)
Do the # of arguments define a core "intent"? 435
<https://github.com/w3c/mathml/issues/435>

NS: It takes two parameters to define an interval. If you enter three
parameters into an interval specification, then it is no longer a core
intent, and you have specified an unknown non-core thing that the AT does
not recognize.

NS: In addition to the number of arguments, there is the element something
applies to that can be used to define it as a core intent.

NS: This would be the case if you define a ray using two arrays instead of
two values. So again, I would claim that that's no longer a core intent,
and therefore it should just speak as if it's in the open as an unknown
quantity, as opposed to being an error or an attempting to say ray of this
or that.

NS: So, for example, if you put system of equations on a mn, you just
ignore it just like if you put a function on an Mn, you would just ignore
it.

BM: It is still a ray, if the arguments do not match the type of arguments
a ray expects, do not throw an error.

BM: Do not ignore it, but do not give it any special treatment.

NS: No one objected to ignoring things that do not make sense.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-b-a-href-https-github-com-w3c-mathml-issues-456-some-specific-intent-examples-456-a->b)
Some specific intent examples #456
<https://github.com/w3c/mathml/issues/456>

(Turned into function vs property discussion)

NS: I think that DF's examples started a discussion of when something was a
function or a property.

NS: Here we got into a kind of discussion of matrices. In some sense,
matrices are determinants. So, if you had a tabular determinant, you have
vertical bars around an Mtable. Question was, how do you mark this up so
you could mark it up on the mrow that's holding the vertical bars in the M
table and put determine it of dollar table and point to the table and say,
well okay, it should work that way, and then another option would be to put
on the mrow a just reference to the table.

From Deyan Ginev to Everyone: can any Core intent be turned into a hint for
AT inference by using it as a property? Consider:
x2

NS: Thank you David. And so then, you know, assume the table, knows how to
speak of, determine it, and table, other options for the table might be
matrix. It might be a system of equations. It could be cases, lots of
different ways. You can speak a table and that's kind of where it morphed
into, and I don't think we ever got any anywhere close to our resolution.

DC: Determinant is a bit different, because determinant is actually a
function.

…..

You can read this example as a determinant function or as a matrix.

….

NS: Just because mathcat does it one way, that does not mean it is correct.

….

DG: I wonder if that simplifies how we think about the duality between the
same exact value used as intent and use as property.

NS: There are two definitions of things, how do you know which one to use.
Is this a determinant or a matrix.

NS: How do you tell if something is a power or an index?

From Moritz Schubotz to Everyone: I did not catch this in the discussion do
the terms followed by : come from the same dictionaries as the terms
without :

duality intent is power or msup intent: power so it is a property and not a
function name?

DF: The index should be on (mn) and not on msup.

From Deyan Ginev to Everyone: @Moritz: they are both open-ended, so they
don't have to come from the same dictionaries. But because they are open,
one can. imagine using each value in each slot.

PI: How about people who index four vectors like tensors. c sub k to the
nth power.

BM: The word index is overloaded.

NS: An implementer will want to know if this is a square or an index. An
implementer will want to know one way to do things.

NS: I just want to make sure we don't have both ways of doing it.

PI: There is potentially a problem with things like the Einstein Summation
Convention, where you carefully have one set of indexes up and the other
down.

DG: discussed the problem when the property and function had the same name.

NS: When is something a property, and when is it an intent function.

NS: So, I'm not sure we have a definitive example or a definitive
conclusion, for when something's a property, and when something is a
function, but, I think, they shouldn't be both a function and a property,
unless there's a really good reason.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-3-proposed-spec-changes->3.
Proposed spec changes:
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-a-a-href-https-github-com-w3c-mathml-issues-457-quot-_-quot-as-a-function-head-needs-specification-457-a->a)
"_" as a function head needs specification #457
<https://github.com/w3c/mathml/issues/457>

NS: So we have 457, which is a discussion of the underscore as a function
head. We're all saying, Yeah, if we're going to include this, we should
probably write something down to say, pay attention to empty function
heads, because it's not just underscore. It could be *_____*hyphen __
whatever turns into an empty head.

NS: Two questions: One was, should we do something in the spec? And I think
the general answer to that was, yes, we should say something about this in
the spec, and the second one was, Do we really want to allow this? And the
answer is that NS and DC would rather not. We're okay with it, but we'd
rather not do it, because it just makes it more convenient to do something.

NS says DG is on the other side of the coin, where I think you say, yeah,
this just makes perfect sense, because what else?

NS: What does an empty function head mean! And why should you come up with
a name? And add a silent to it to do what you want.

NS: My answer would be because I want to make it inconvenient to do that.

NS: DG, do you want to know why, without a silent is a perfectly reasonable
thing.

NS: So oh, I should say, by the way, without that special case, and I know
you know a function is normally of a comma B, and when you have a blank
math cat just simply said of something comma something. And Deyan's feeling
is it shouldn't say the "of", and it shouldn't say the comma. It should
just be the same as silent.

DG: Right. So, this comes to 2 ways of looking at it. One is mathematics,
one is accessibility on the web. The disability on the web perspective is
that we should strive to have some parity with aria label or MathML 3. If
you will, where, at any point where you need an escape, hash to specify a
string.

DG: You have the opportunity, and that comes from the idea that the AT
engines are not perfect and don't have perfect coverage. The mathematical
piece of this may be more compelling here, which is that some notations are
not infix, postfix, or prefix, but are mixed, fixed.

For those cases, you need to have a way of giving a set of pieces or a list
of pieces that are just glued together without any special connectives or
special speech, and that is the current behavior of the colon silent
property and what I always originally thought ever since we had ANSI name
for concepts or literal. They have multiple pieces that are fence-like
that. Are just little presentational artifacts that are there to decorate
it, and they have to be skipped and then what's even more interesting is
that when you speak to them as the highlighted example here, with the free
r algebra on X, sometimes you rearrange the pieces of the notation and the
words to form a kind of completely disconnected from the syntactic notation
narration. So, the pieces for speech do not fit a predefined pattern, and
they do not fit the original math presentation. And yeah, for those cases,
you need to have a way of giving a set of pieces or a list of pieces that
are just glued together without any special connectives or special speech,
and that is the current behavior of the colon silent property and what I
always originally thought ever since we had ANSI name for concepts or
literal names, would be the other underscore heads, or any silent head,
because, in a way, it's language normal or natural. If you have no head for
the function, but there is a list of arguments, you will just speak the
list of arguments, and if that was allowed, that's what you would do.

NS: In general people should give a meaning to something.

NS: We do not want to say it is an empty literal that has no meaning.

DG: That is not expedient enough.

DG: If you just use _, the notation would be much simpler. good for just
getting speech out.

DC: So, you know, I think we're in agreement there. And the question might
be to say that by default a function application that doesn't have any
formatting property would be treated as function unless it's empty, in
which case it's treated as silent. Which is what the call spec exactly
says, and at the moment since last week, or something. So, it's yeah. The
function property should be assumed unless little is silent. For example,
underscore, in which case the silent property should be received.

From David Farmer to Everyone: intent=“extension: free-algebra($r,$x)”

DF: We need a core element called extension. r(x) some extension of r.
avoid write it out yourself by adding a couple of more things to core.

DF: I suggest that we need a core element called extern, like, there's
many. There's often the case that there's what appears to be functional
notation. Now, in this example they use angle brackets instead of
parentheses. But you know our parentheses. X. Is some maybe that's the
polynomial ring, or that's some extension of our and so I think there's a
few very common constructions that we can avoid. Some of these, write it
out yourself. Proposals by just adding a couple more things to core, like
the fact that something's an extension and the free algebra over the set X
is an example of an extension.

DG: Yeah, maybe we can wait into the core of the disagreement here, which
is to me it seems like it's a bit of an underestimation of the level of the
problem. So, I agree with David Farmer's statements. I just think that
there are not a couple of cases. I think there are hundreds of cases. The
example I have in the underscore issue. Actually, there are many
non-standard examples like this.

DG: So, all I'm asking for is, give the people the space to just say what
they're currently saying. And as they standardize you could move them
closer to the functional notation, away from underscore. To me the commit
documents are kind of living, and you can revisit them later, especially as
standards mature.

NS: The issue is, do we really need to have a special case for underscore
when you could have said _:silent, in which case there's no special case
needed to talk about what to do with n underscore.

DG: So, my perspective here is the opposite, which is once I have
underscore I can avoid silence because underscore is very general. So
rather than special case underscore, I avoid the special casing of the
fixity hints which I will not need, and that is the trade.

LM: Do you have a conclusion?

DC: No!

NS: Well, we have a conclusion that the spec needs to say something.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-b-deyan-39-s-pr->b)
Deyan's PR:

Intent Name view of literals #459 <https://github.com/w3c/mathml/issues/459>

NS: We need to say something about this.

DG: The origin of this Pr is the discussion about underscore that we just
had.

DG: There are certain ways in which we're thinking differently about some
of the pieces, which is fine, but I wanted to write down the ways I do
think about them today because I don't know if anybody else has a clear
view of what I'm seeing ahead, and this grammar is in my head pretty much
most of the time when I talk about these things. It's almost like what's in
the spec, but it has a few reorganizations.

DG: So, there are some exotic names that you can achieve with Nc.

DG: discussed concepts, literals and properties.

DG: So, this huge, infinite list of natural language, sounding phrases in
different languages that may or may not be in dictionaries if they start
with an underscore.

I call out, very explicitly, this is a language overwrite, so AT should not
try to do anything with it. Just pass it through to narration exactly the
way it was written, and that avoids any confusion about the classes of
objects.

NS: So, you do agree that we should call out the special case for the empty
names, empty function heads, and also a default that it defaults to
function. I don't remember if that's in.

DC: You could spend ages working out: Is this a concept or speech override,
and it makes no difference, because the effect for both is identical,
because almost every concept name won't be known to the application. So why
make people try to choose what we know.

NS: I like distinguishing between literals and concepts just to make it
more clear to me then.

NS: A literal is always unknown.

DF: When would I ever put an underscore? And I think my answer is when I
know or suspect it's in core, and I want to prevent AT from doing what it
usually does with that thing in core, right?

DF: That should be a rare situation.

BM: As far as current spec and pr is concerned it is the same grammar if
you say that things starting with underscores are literals. This would
change the meaning of literal to be something that starts with an
underscore.

DG: This might be felt more in higher math than in lower math.

DG: Never thought literals and unknown concepts were the same thing.

NS: I believe there are 2 changes to the grammar here.

(LM: The following conclusion is indecipherable
NS: I believe there are 2 changes to the grammar here. One is this calling
out the literals which in this case actually makes no difference to what's
accepted, as far as I can tell, and the other changes this intent with
implies that gets rid of it, gets rid of book.)

NS: So let's see, does anybody want to stand up for allowing the head to of
a function to just be a property or property list?

NS: Okay, so we agree that that change is a good one.

NS: We've discussed concept versus literal a long time.

NS: Should an intent name contain just letters, or should it include
numbers?

NS to DG: Do you want to say that intent names should contain just letters,
or do you want to say no, I should be more general?

DG: I was worried about the predictability of the AT systems, whether they
can handle mixed letters and numbers and Unicode punctuation characters.
But that's it.

DG: I'm worried about the quality of the narration if you mix numbers and
letters.

NS: I should double check the effect of mixing letters and numbers. I think
they will break it apart. What I do, and what almost everybody would likely
do, is just pass this through the speech engines. So, I'll double check a
few different speech engines.

*ACTION* NS: will check to see if the speech engines will separate letters
and numbers.

DG: I think adding numbers is a very good idea. If it can be supported.

*ACTION* DG will make the spec changes to reflect the conclusions of our
discussion around issue 459.

*ACTION* NS: So next week we'll have a focus on AT. NS will create an issue
on this.

NS: But I'd really like to be able to give the whoever is going to show up
a little bit of a summary of what we're talking about, and so they don't
walk in completely cold, and what kind of questions we have, for I know the
general question is how much work you are willing to do for this. But yeah,
I'll open up an issue.

NS: Next week's meeting will be for an hour.