Some specific intent examples

[davidfarmer]

This issue is to determine if we agree on some common examples of intent markup. I encourage others to describe specific examples.

Example 1: multiline expressions with a big curly brace on the left. This could be a system of equations, or it could be a "cases". For example: https://mathml-refresh.github.io/intent-lists/intent5.html#IDbracedsystemofequations

In that example, the intent is on the mo containing the left brace. I think it should either be on the outer mrow, or it should be on the mtable. (I think mrow, but I can implement whatever is better for AT.) I also think it should be a property, meaning intent=":system-of-equations", because otherwise AT has to know to treat it specially and not just say system of equations instead of reading out the contents.

Example 2: open interval, as in https://mathml-refresh.github.io/intent-lists/intent5.html#IDopen-openinvertedbracket

I think that example is good as-is. It is reasonable to expect that AT knows that open-interval is in core and that the words "from" and "to" should be added (depending on the verbosity level). If the notation had parentheses instead of reversed square brackets, the intent would be the same. We should discourage any other way of marking that intent.

Example 3: superscripts which are not powers, as in the H^2 example here: https://mathml-refresh.github.io/intent-lists/intent5.html#ID2ndCohomology I do not think either of those examples are good, because (as we discussed on a call) it is confusing for AT to say "H 2", because that hides the fact that the "2" is in a superscript (and not a subscript).

I suggest that this is reasonable: <msup><mi>H</mi><mi intent="superscript">2</mi></msup> or (which I prefer) <msup><mi>H</mi><mi intent="index">2</mi></msup> Since AT has to examine the contents of the msup, to know whether to say "squared", this markup conveys the information that the expression is not a power.

This example only works if AT knows the meaning of that intent, and that the intent value is not supposed to be pronounced literally. Should "superscript" or "index" be a property instead?

[davidfarmer]

If "index" is supposed to be a property and "transpose" is supposed to be in core (or at least self-voicing if not in core), then we could have:

<msubsup>
  <mi>M</mi>
  <mrow intent=":index">
    <mi>i</mi>
    <mi>j</mi>
  </mrow>
  <mi intent="transpose">T</mi>
</msubsup>

Except for saying "to the transpose", Mathcat does okay on that already.

I don't see how the markup get any simpler than that.

[davidcarlisle]

I'm assuming that all the MathML elements are in core a

ooh seems possible (if a little weird). What works now and doesn't require anything in core is to use sub rather than msub

<msubsup intent='transpose(sub:infix($base, $sub))'>

see https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-4dc5e6b2ea853d5abb0821f3494a7950

[davidcarlisle]

<msubsup intent="_($op($M),_at,index,$i)">

oh you are forcing the other nesting, we'd been assuming an interpretation of transpose of Mi not the transpose of M, indexed at i (although of course you need to be able to do either). Certainly we should be able to have a recommended markup without resorting to `(`

[dginev]

oh you are forcing the other nesting, we'd been assuming ...

Indeed, I mentioned the alternative nesting leads to different speech here. And that, depending on how the pieces are composed together, the resulting speech conveys a different mathematical object.

Certainly we should be able to have a recommended markup without resorting to _(

A dangerous certainty.

Custom ad-hoc properties can be painful in practice, since it appears hard to predict when they do or don't activate in AT, and if the composition with other partial annotations is going to produce high-quality narration (or not). In David Farmer's last example: ```xml M i j T ``` It is unspecified/unpredictable whether transpose or index have higher precedence (both in terms of what the author meant, and how AT would combine them). --- For cases in the Open realm, we need the underscore form whenever a custom connector word (or several, or custom order) is needed. One could alternatively try to invent additional tiers of clarifying markup, e.g. something new such as `index:{at}infix($x,$i)` for "$x at index $i" or `index:infix{-ed in}($x,$i)` for "$x indexed in $i", but to me it seems like we just increase the difficulty of intent for anyone not interested in Content forms. The `_()` override solves that problem with a uniform natural treatment. It's quite a big help in practice, and tends to be quicker to piece together (as the phrase suggests). --- Separately, `sub:infix(a,b)` seems artificial. Adding an infix fixity to a subscript word? If it was consistent with the general principle of `:prefix`,`:postfix`,`:infix`, this should be `:sub` or `:subscript`, likely also with `:super`/`:superscript`, so that one could preserve the concept symbol: ``` index:subscript(x,i) ``` The script words are a little bit like `:silent`, since the head remains silent, but they also carry with them a standard connector word between the (exactly) 2 arguments. This also gave me an inkling that if someone was trying to stay close to the presentation elements `:phantom` may be more appropriate than `:silent` (thanks to `mphantom`). So I am a lot more certain about using `_()` myself - it's a template form that is easy to explain, easy to learn, and lets the author write down the narration in the same linear order they already know.

[davidcarlisle]

It is unspecified/unpredictable whether transpose or index have higher precedence

yes either we specify (say) subscript binds tightly, or we can use a functional form on the msup, nesting in whichever order is needed.

For cases in the Open realm, we need the underscore form whenever a custom connector word (or several, or custom order) is needed.

It's available if someone really wishes to force a particular word order, but forcing a specific wording is a non-aim of intent so I don't think there are any cases where using _( should be the recommended markup. It's just an escape hatch for exceptional cirumstances.

Separately, sub:infix(a,b) seems artificial. Adding an infix fixity to a subscript word?

It's an infix function for indexing I chose to call sub in that example, I could have called it subscript or index or other things. It fits the general scheme for intent, I'm surprised you find it artificial.

So I am a lot more certain about using _() myself - it's a template form that is easy to explain, easy to learn, and lets the author write down the narration in the same linear order they already know.

Using a function of _ destroys the entire design of a functional expression form. If specifying exact words in exact order was really part of the design aim we would be better just to use alttext or a templated string.

[dginev]

forcing a specific wording is a non-aim of intent

Any chance this can be softened? I would like to strive for aria-label parity, and that requires the ability to override with specific words. The aim of intent should be "high quality accessible outcomes", and sometimes specific wording is the path to achieving that in the short term.

The _() is a vehicle for a partial templated string without destroying the rest of the functional expression, but rather in synergy with it.

[davidcarlisle]

Any chance this can be softened?

Not really, it's just a statement of fact that it wasn't an aim of the design. That doesn't mean the end result can't include a mechanism to specfy words, but any such mechansm even without the weird _( syntax would really be anomalous compared to the rest of the design.

If foo is in core foo($a,$b) can generate pretty much anything. If it's not in core it can generate foo of a comma b, or foo of a and b, or foo applied to a and b, or whatever else the system chooses. <mtable intent=":matrix"> means "generate something appropriate for matrices". intent is fundamentally for disambiguating the meaning enough to allow the system to generate correct speech, it simply isn't about specifying text. We can graft in a mechansm to specify text but it if it ends up being used much it means we have failed in the design as if that were really a design aim there are far more natural ways to specify text that we could have used.

[brucemiller]

I'm inclined to think that if you want to control exact speech and be like aria, you should use aria. That aria currently doesn't "see" the MathML doesn't seem like a valid reason to reinvent a second version of aria, but rather is a reason to get aria (or it's context) fixed.

[dginev]

@brucemiller We have a mandate/preference by the ARIA group to reach parity to relevant features of it in MathML itself, without resorting to ARIA, granted to us here:

https://github.com/w3c/aria/issues/1723#issuecomment-1145479520

The main unresolved discussion appears to be whether exact speech overrides are a requirement for MathML Intent or not. In my view they are.

If the group leans otherwise, MathML Intent should have a note on inter-operating with aria-label for speech overrides, or alternatively, we could make alttext a global attribute and use it akin to aria-label.

[brucemiller]

We have a mandate/preference by the ARIA to reach parity to relevant features of it in MathML itself, without resorting to ARIA, granted to us here:

I don't see a mandate for parity there, only a recognition that a MathML specific intent is necessary.

[davidcarlisle]

The main unresolved discussion appears to be whether exact speech overrides are a requirement for MathML Intent or not. In my view they are.

Certainly it is not a requirement but all versions of intent have provided this by making liberal use of the existing freedoms. Whether it is intent="just_say_this" or intent="_(_just, _say, _this)" or a combination. So I don't think there is any need for further attributes, or even an agreed position on whether this is useful to do. The facility will be there.