Minutes: MathML Full WG 2 Mar, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - David Farmer
   - Steve Noble
   - Bert Bos
   - Bruce Miller
   - Paul Libbrecht
   - Murray Sargent
   - Moritz Schubotz
   - Deyan Ginev

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

NS: Are there any updates for the full spec?

DC: There was a discussion about having scriptsize handled by the CSS group.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-2-hints-and-properties-details-merging-multiples-etc->2.
Hints (@) and properties (:) details/merging/multiples, etc. (

#436 <https://github.com/w3c/mathml/issues/436>, #440
<https://github.com/w3c/mathml/issues/440>, others?)

NS: DG's rejection of hints is that hints only cover common cases. Use a
silent head and put out regular text.

NS: DG values being able to generate content from the presentation layer.

DG: So the usefulness of the underscore notation to me is that this way we
have parity with aria label.

DG: The reason I don't like to use hints is that for the cases I see a need
for them, the information is in the presentation tree, and I like the
simple functional, basic intents.

DG: There is a problem with super script and sub script. He preferred to
use the presentation tree.

NS: If something's in core, there's really no point in using the hints,
because core knows what it's supposed to do.

NS: Hints make open usable.

NS: Hints make open usable because hints can tell AT how to speak things
that AT knows nothing about.

NS: What do you feel should be part of the spec? Could we replace the
somewhat complex syntax we have with strings?

DG: So we all agree that this document is nice to have around. We will make
it a non-normative thing. It is handy for people who want to have an easy
set that is mappable to content.

NS: What if this document did not map to content, but mapped to our
functional intent notation.

NS: Here is an algorithm to go from the underscore to the functional intent
notation.

NS: If we had this mapping, then we just go to a much simpler spec.

NS: We could have a simple spec.

DC: It would fit the current spec to map it to intent more than content. I
mean this underscore business is how to sneak a template, to string, into a
functional syntax.

NS: Get rid of the functional syntax and just go to strings.

NS; Go to a string with templates and brackets.

LM: Many of these sentences referred to expressions that were being screen
shared.

DC: This is core. Having this basically forces you to write in English.

NS: Since you can extract a tree from this, if you need to do a
translation, go back to the tree and you would know how to speak it.

DC: Believes in hints for core.

From Deyan Ginev to Everyone: "[factorial] of $x" "$x factorial"

MOS: I just wanted to say that I generally like to have this underscore
notation to differentiate between real things that are corresponding to
some content and some decorators.

NS: The spec has concepts and literals. Literals begin with underscores.
Things that do not begin with underscores are concept names. Literals are
just words, and you can ignore them.

NS: Should we keep this functional notation, or should we think about this
other with no notion of mappings to a functional notation.

MOS: I'm a big fan of the functional notation. I'm happy as long as there
is some translation to content, I can work with that.

LM: Does fixity only mean prefix, infix and postfix?

NS: it is more than prefix, infix, and postfix.

DG: says fixity has many other meanings.

NS: there can be randomness which you cannot describe with a hint.

BM: Are "@" hints useful? Just say plus when you get to plus. The plus can
be on the mrow or further down on the mo. It is better to put it down on
the mo. This would make infix useless.

BM: For power, people want to say X squared or X cubed.

From Deyan Ginev to Everyone: " $x to the third [power] " -- bad

From Deyan Ginev to Everyone: power(x,3) -- good

From Deyan Ginev to Everyone: But what about: " x to the [3] [power] "

NS: It sounds like people do not want to give up functional notation.
Eliminating the functional notation would simplify the spec.

NS: DG can recover his content, which he needs to work with to make the
stuff he wants to do.

NS: needs the hints to speak things accurately, otherwise he just reads the
string.

DC: Having underscores in the middle of a function sort of works but is not
good.

MUS: likes simplicity. For power, you want AT to know if it is an index or
really power. You do not need the flexibility to say squared. Just use the
standard superscript pronunciation.

FD: It is the AT's job to see how verbose it is and offer that to the
reader. People want to hear cross and not cross product. Cross product is
good intent but the AT must be able to call it cross. If the reader chooses
a terse form of output, then the AT should honor that choice.

NS: For open, will we allow the terse form of output?

DG: You should not think of me as a content user. Think of me as an open
user, because I'm trying to think of archive with intense annotations.

DG: We should have a great open experience, but not at the expense of core
and should have a great core experience, but not at the expense of open.

NS: If someone defines a new notation, people always shorten things down,
so AT should also want to shorten things down. How can you tell AT that
this is a short form?

DG: But if you want to do a new mathematical concept that has no support,
and has no chance of gaining support for several years, adding an
underscore can give you a clean narration.

DG: We should have a list where people can put their short forms. People
can direct the AT to look at the short forms list if they wish.

DG: Another option is to put the short form in the syntax.

NS: Where do we stand. Should we be pursuing the notion of going to a
linear syntax and getting rid of functional notation?

DC: We should investigate it. BM agreed.

PL did not agree.

NS: Ask who thought functional syntax was the proper way to go.

The linear syntax option won.

People thought that we should investigate the notion of going to a linear
syntax and getting rid of functional notation.

NS: We should create a specific issue for this, and think about what it
would be and how we want to do it.

NS: Hints might become irrelevant, so I will not talk about merging hints
and properties.

DC: This is a reset if we go that way.

NS: Well, no. You could imagine you give the name, the concept name and
give a colon after it.

NS: We have not talked about multiple properties. How would this work?

BM: Where it goes in an intent at this point is a little bit fuzzy. Some
identifiers or construct might get a property of matrix, or also
tridiagonal matrix, or whatever various kinds of things are interesting to
someone.

BM: If the AT knows what a matrix, but not a tridiagonal matrix, is, it can
use the matrix idea to generate speech. What is a little fuzzier is where
it would take unknown properties and put them either in a tool tip or
optionally say them if you clicked in some button fashion, then it might
simply present all of them.

NS: What happens if units conflict; that is, someone gives a metric and an
imperial unit specification.

BM: Garbage in, garbage out.

BM: The AT should say both. It would also say that the units conflict if
the AT knows that.

DC: You do not need to worry much about a conflict list.

Ns: What AT decides to do is OK. You cannot say you can have only one
property per element.

DG: He thinks that multiple properties is good for experimentation.

*ACTION* DG: What they wanted to say is that I think we can copy the aria
describedby behavior when it comes to narration. It's very simple. The idea
being that when you narrate this as the accessible description of the
nodes, you go from left to right, and you read them in the order they were
given. This makes things clear. NS: Does this change in a RTL language? DG
will check this.

NS: Is beginning to believe in multiple ones.

NS: We've had a number of names for these, and I've always sort of like
slashes for properties.

*Consensus*: NS: Do people want to call them something else besides
properties? No.

DC: Properties are internal flags that we want to tweak. They tell the at
process to do something.

NS: Properties allow us to do something with say "mouse over", and, the AT
might say, this is a complex number.

From Deyan Ginev to Everyone: There is a great example for "accessible
description" properties in issue #441

NS: Do we need JavaScript to allow this functionality, or maybe a browser
extension to turn it on?

DG: There is a very nice use pattern where you can fix a bug if you use the
silent property where you try out your expression.

DG: So, what you would do is you would start going through your
presentation MathML tree and you'll find that there's a silent notation on
one of the nodes. And if you had that in the accessible description, you
could find it using the existing browser AT supports. So, you don't need to
have a special editor implemented, a special feature and how to find silent
notes.

NS: There's a way to navigate the expression essentially character by
character may be word by word. And so, you know, even though it may say
absolute value of X when you navigate by character, you are going to hear
vertical bar X vertical bar. And I think that's a really important way to
get around something someone has silenced.

NS: Braille does not follow intent, braille outputs what is printed. Intent
does not affect Braille because Braille ignores it.

MUS: Going character by character is necessary for editing.

NS: I don't think there's anything special for silent that needs to be
implemented, just because if it's displayed, AT has a way to navigate it
and hear it, every little bit of it.

NS: We were going to talk about merging hints and properties. But since
hints may not actually be there if we went with the string-like structured
strings, I'm not sure it's useful to talk about them now.

NS: What is another big issue?

NS: We can discuss if spacing is part of the grammar.

NS: Whether spacing is part of the grammar or not, and it's still relevant
to if we go to a linear string because we're still having some syntax like
the dollar arc, and maybe the colon syntax for properties. And I still
don't like spaces between those things there.

DC: took out spaces in certain cases after the colon.

DG: Who are the spaces for. We have a space-free syntax now.

NS: If two implementations read the same document, they should come up with
the same structure.

NS: The spec should say more about how spacing is handled so that everyone
does not do something different on the same material.

DG: What is the issue with spacing?

DC: The public spec explicitly does not mention spaces. Ignore spaces. You
could have spaces around decimal points and between a minus and its number.
This would create problems.

Allowing spaces around periods would be silly. Do not allow spaces in the
middle of a name.

DG: Do not allow spaces between tokens.

BM: Ignoring spaces everywhere is a massive error thing to do.

NS: is Open to where we allow spaces.

DC: If you have a lot of periods and commas, you may need spaces.

NS: You can't get rid of all the spaces, because some processing tool
somewhere along the line will insert a new line character, or will insert
something that's white space, at a position that seems reasonable to it.

BM: Because otherwise, it wouldn't be a valid expression. Anyway, I think
you want to allow spaces for readability.

NS: Is "$ arg1" reasonable?

BM: You should just ignore the space; otherwise, if they write that, and we
don't allow it in the grammar, then the grammar has to say, Well, this is
an invalid intent expression.

BM: The implementation could be: step one, remove all the spaces, Then Step
two, parse it.

DG: It is easy to take any number of spaces and normalize them to a single
space. "$ word" would be invalid. you need the space to terminate a name.
you could allow spaces here.

DC You do not want two spaces. normalize the spaces down to one space. How
do you get structure out of it?

NS: There's this proposal of using brackets around a word that is a concept
name.

DG: We guarantee that names beginning with underscores are not known.

DC: Underscores are for names that are not known to the core.

BM: You do not look up words starting with underscores in dictionaries.

DC: A literal is a name that is not known to the application. It says this
in a spec. a concept is something that is known by the system you are using.

BM: There is potentially a very big difference between a literal and an
unknown concept which depends entirely on what people make with the open
dictionary.

BM: If there's no open dictionary, they're the same.

DC: A concept name is a name that matches a word in a content dictionary.

DC: If we throw away the grammar, we're going to have to throw away
everything.

DC: Using underscores in the middle of a string seems weird to me.

NS: I think that you know that would be a disadvantage of this Linear
string is that there's no way to say whether the literal is an argument.

LM: Can you summarize the current issue? What are you trying to decide?

NS: Do we throw out this functional syntax and go to a linear string or not?

NS: Do we throw out functional syntax or go to a functional string.

DG: We make the property the official name is our accomplishment.