intents and defaults and structure

I'm writing this email to get some discussion going outside of the
meetings. Deyan is also working on this and is working on his own reasoning
on this topic <https://hackmd.io/@dginev/Bk4Zf9B9O>. The topic we have
started to discuss in the meetings is MathML structure and how that might
or might not work well with intents, especially for defaults.

First off, if an intent is given, there is no ambiguity for the part of the
structure given by the intent and the current proposal(s) make no
requirements on MathML structure other than it be valid MathML. That
doesn't mean that other parts of the structure (e.g, the arg="..." parts)
are unambiguous. But it does mean that any software trying to come up with
a "meaning" for speech (or otherwise) should not break a stated intent.

The question we have begun to explore is what can we state about a default
in the absence of explicit intents.

*Why do we care about defaults?*
To me, a big advantage of using intent over some alternatives like parallel
markup is that using "intent" can support *progressive enhancement*. If we
come up with some defaults, then authors only need to use 'intent' when the
defaults aren't correct. So if we can figure out reasonable defaults, we
can minimize the content that needs work/remediation so that it can be
spoken unambiguously. Additionally, rather than require MathML generators
change to use parallel markup or some other output, current output remains
valid although it may not unambiguously represent author intent. The extent
to which it can be disambiguated is tied to how much context is used to
make the defaults. It will never be perfect without author's helping out
though.

*My Two Cents*
Since this message is to provoke discussion and is not meant to be a
fleshed out proposal (it's very long as it is), I'll just state my current
thoughts and add a little rationale to them, but not get into the
details....

My feeling is that defaults should be based on a canonical parse of the
MathML expression that is defined by the operator dictionary and as
overridden by any attrs on the <mo> elements. This does not mean that
MathML that uses "flat" mrows doesn't have a default, it just means that
when parsed, it will have whatever defaults we end up giving. As an
example, if an mrow has "a", "+", "5", "!" as direct children, a default
for factorial would be used because the canonical form given by the
operator dictionary would group the "5" and "!" in a single mrow and that
would match a factorial default.

By mapping expressions to a canonical parse, we can write defaults in a
relatively simple manner and not require MathML writers to generate a
specific representation (something Deyan's post shows doesn't happen now).
It doesn't even require software that wants to apply a default to do the
parse, although I think supporting all the various ways of representing a
default a default would be hard without parsing. Currently the more
sophisticated speech renderers do parse the input to infer intent, so using
defaults fit naturally into those speech renderers.

One thing the operator dictionary does not solve is operand/operand
conflict (horizontal juxtaposition of operands). Typically these are either
meant to be function call or multiplication (or more precisely, a
multiplication-like operation), but it could be an implied plus for mixed
fractions or an implied comma in something like M_{11}. How this is
specified will determine a canonical parse for those cases.

Another area of concern is mixing n-ary operators. We've discussed how +/-
might parse, along with how a series of relational operators should be
given/thought about. I think they should be flat, but reasonable people
differ. Clearly something that needs further discussion before defaults can
be written for them.

A final area of concern is matching open/close fences. The operator
dictionary has all of the fences with the same priority and I think it
makes sense that a "[" can match against a ")" to form an mrow, but there
might be some subtle issues that make this a poor default. Note that the
French interval notation "]0, (" will not form the intended mrow structure
without the author overriding the "form" for the brackets; if overridden it
will parse intuitively and a default could be written for that notation.

Hopefully some food for thought and that this will provoke some discussion
outside of the meetings.

    Neil