Minutes: MathML Full Meeting

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Bruce Miller
   - Dennis Müller
   - Bert Bos
   - Patrick Ion
   - Stephen Watt
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Cary Supalo

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

   - Paul Libbrecht
   - 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: gave a talk on accessibility yesterday to a Zoom meeting of NISO
(national information standard organization) with at least 160 participants
(several may watch on the same paid ticket)
<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-intent-properties-ordering-amp-references>a)
Intent Properties: ordering & references

#449 <https://github.com/w3c/mathml/issues/449>

NS: He started discussing ordering properties. When you have many
properties, which properties come first? If properties disagree, how do you
settle those disagreements? What about complex function heads?

NS: discussed several styles of specifying derivatives. This led to complex
function intent heads which led to many errors.

[The examples are in the discussion under #454
<https://github.com/w3c/mathml/issues/454> ]

NS: wanted to flatten the heads.

DC: did not want to flatten the heads.

BM: Is the problem that it is unclear to know what to say with complex
heads, or is it difficult to recognize the structure of the intent heads?

From here on, many examples were discussed in detail.

NS: discussed his pattern matching methods.

DC: said that an AT programmer might find some thing tedious whereas the
MathML readers would find them natural.

NS: There is still the issue of how to think about this, whether it is
process in a bottom-up manner, or a top-down direction.

NS: The consensus is then that complex function heads makes sense, and we
should allow them, and that this discussion should refocus itself to the
original opening of what does it mean when you reference these things, And
how the properties merge?

BM: It also goes so far as to say that if we're allowing complex heads,
then we allow references to avoid replicating a lot of complex stuff.

BM: We still have to decide how to proceed through references and
properties.

NS: We also need to decide what to do with conflicting properties.

DC: hoped the action would be system dependent.

DC: Should we decide to look for certain properties or start the properties
in the order they are in.

DC: You do not want to have an order of looking.

DC: If they are on the same term, what happens is property specific.

NS: What should be happening is undefined if they conflict.

DC You do not want an error.

DG: We do not want to invent cascading property sheets where we define
classes of properties such as the fixity class, that cascades in this way,
and another class in a different way.

DG: But I wanted to bring the practical example, where, like a real-world
example, I can imagine, conflict will occur, not by design, but by
accident. An example of this is if you have a macro system in something
like TeX, which adds property information, and then you for some reason
decide, to combine or compose together macros on 2 different levels, and
one may decide to override the arguments. So, a macro may add a property to
an argument. So if you have the quality, you can say both left hand, side
and right hand side for this Macro are going to be integers for this
equality, and then the inner Macro may say this is actually a natural
number and then you get an argument that is annotated with both natural
number and integer, so in the case where they don't conflict, you just say
both we have to decide if we're going to admit to the world that there are
cases where they do conflict, and if we have fixity, I guess we have to
admit that they conflict, and the outer context is the one that is meant.

NS: We must consider the parent-child relationship, or the sibling
relationship.

NS: So for Lewis's benefit the example has an emerald with a prefix, and
then the child which gets referenced has a infix and postfix.

BM: In an example: we have conflicting infixes and post fixes. Fixity was
confused.

There was detailed discussion over the fixity of an expression.

NS: It doesn't matter what the dollar OP refers to.

DC: We haven't really specified how dollar OP get expanded, or whether it
ever gets expanded and that's part of the problem.

There was more example specific discussion on fixity and its effect out to
the end of a branch.

NS: Find out what happens on a leaf and send it back up the branch.

NS: Fixity must be mentioned on a place where it makes sense.

NS: We began discussing expressions that could be treated as a system of
equations or a matrix. The intents could guide this interpretation.

NS: So as in the fixity case I would say it the fixity has to be mentioned
at a point where it makes sense. The same thing would be for the properties
of matrices or systems of equations have to be mentioned at a place that
makes sense.

DG: Let us move to an example that is not wrong. This example was an error.
Let us move on.

DG: If there's ever a conflict, it's an error.

DG: Do you have an error to be raised? So, we fix and post.

DG: If you have a matrix or a system of equations then let the system
decide which it is.

DC: So, do you pronounce this as a 2 by 2 matrix, or 2 cases, or 2
equations.

DC: Equation one, equation 2. So, it's the way that I mean what currently
the situation in mathcat is, it does a really good job of guessing what you
mean.

DG: So, if you have a table that does not have any property, it will have a
default table readout.

DC: So, what the situation is that actually, the best reading is usually
obtained by not putting intent on anything.

NS: But you can't rely on that.

MS: should AT know about form?

NS: AT now knows about form.

BM: is there an expectation of a fixity hint on a stray leaf node? Should
it have any significance?

We had more discussion on examples.

NS: Yeah. So, I mean, it is a good question to ask whether form should
somehow override AT or should AT know about form, and it not interact with
intent?

….

DG: I was thinking how to answer this actually and if it's not prefix, but
it's a property such as binary relation that describes the operator to me.
It's obvious that it would be usable and useful to not ignore it, but keep
it, and on request, pronounce it as an accessible description.

….

DG: Are the fixity properties so special that they have their own
behaviors? Is fixity different from other properties Where I can remain
agnostic, since I don't want to. I would personally resolve this with using
underscores.

….

Discussion concerning mrows and pop-ups.

….

BM Discussed if a popup belongs to a binary or to a $op.

DC: We cannot put properties on intents.

…..

From Deyan Ginev to Everyone:

NS: sees the head as how to talk about the entire row.

We had a discussion about mouse-generated popups.

DC: So, of the 3 forms of intent, we only allow properties on 2 of them.

NS: point of intent is how we speak something. Any properties of speaking
apply to the properties of that thing.

….

NS: The intent is how you speak.

DG: I have a counterpoint, which is, that if you have an empty intent that
only has a property, the only thing this property is annotating is the
current element, and your perspective is indeed correct. The moment you
have an intent expression, that expression has pieces, and the moment you
start annotating the pieces of the expression, it is not obvious and to
some it may be confusing that you would annotate one piece, and imply that
to be part of the whole so to me it would be a little bit clearer if you
take this property, that applies to the whole emerald and move it in front
of everything else. So, you would just start it with Colin. Silence, and
then you open a parenthesis and put everything else inside and then it will
be clear that the first property is to the outer elements, because when
it's on the "r" it really looks as if it's annotating the "r" in terms of
syntax, so that the syntax does not convey that.

….

NS: I'm claiming any properties on the head apply to the parent element.

….

Ns: what are the real-life cases we are trying to treat. What terms were
affected by a prefix?

There was a discussion concerning prefixes and mrows, and more discussion
on the effect of fixity on a nested structure.

….

NS: It just goes back to what DG says: why are we discussing complications
when we don't actually have used cases?

NS: So, is there something that you have a complex head that you need to
specify a property of?

DC: When we allow things by reference, we don't allow it expanded. It gets
very hard to say what the reference means.

DC: In a perfect world, you could expand all this out and read the intent
value that I need.

DF: When you expand a thing out, do you not lose information? DC: no.

DF: By expanding it out, I mean you make one giant long, intense string.

DC: What you lose by doing a giant long, intense thing with doesn't have
references Is you lose the navigation. If you remove the things, to the
reference of, the first parts as opposed to just expanding.

BM: It sure would simplify the ability of how we talk about these things
If, if the effect of reference was simple: copy the expanded intent in like
a macro?

BM: The reference allows us to have navigation. And so that's a good thing.
But in terms of understanding how the speech is generated, if we could
ignore the whole question of references by just embedding the intent, that
would sure simplify our understanding and figuring out how to properly
apply intents.

DG: We have legacy examples to guide our intent efforts.

NS: There should be defaults other than legacy mode.

NS: Discussed substituting values into children then trying to analyze the
result. It was difficult.

NS: I just didn't see heads that referenced arguments as making a lot of
sense.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-b-must-core-intent-work-as-a-literal-expression->b)
Must core intent work as a literal expression?

#455 <https://github.com/w3c/mathml/issues/455>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-c-references-in-a-function-head>c)
references in a function head

#454 <https://github.com/w3c/mathml/issues/454>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.2-0#cp-md-0-3-stepping-back-is-quot-intent-quot-usage-clear-yet-if-not-what-are-the-major-questions-disagreements->3.
Stepping back: is "intent" usage clear yet? If not, what are the major
questions/disagreements?

Parent child relationship.

How do we process things.

How do properties work.

There was a proposal for a Colon equals syntax.

NS: And that was like the way URLs are done. So, there's probably software
that parses something like that.

NS: It sounds like we have 2 things to focus on this week, which is the
parent-child relationship, and the colon = syntax.

DF: So, I think the thing I would like to resolve is, are we going to allow
the notation to guide what type of property it is like?

NS: We have one more two-hour session next week. We need to get some
resolution on what intent is about so that we can move towards CR.