Allow intent attribute on content mathml

[davidcarlisle]

In a PR comment

https://github.com/w3c/mathml/pull/286#discussion_r825372756

@brucemiller asks if intent= should be allowed in content,

I'm tempted to say it should, basically be allowed everywhere cd is allowed (including in the grammar for strict content)

In MathML2 we had inline in the spec an "openmath-light" appendix giving some kind of semantic meaning to each content element. The "Content Element Definitions" appendix: https://www.w3.org/TR/MathML2/appendixc.html

Maintaining that was a lot of work and being in the published rec meant it wasn't extensible once published.

So in MathML3 we "outsourced" this to OpenMath which was under active (funded) development at the time and provided a general framework for recording these sorts of definitions. So in MathML3 the meaning of Content MathML was expressed by rewriting to the simplified strict grammar and then linking each csymbol with an OpenMath symbol.

For intent we will need something similar: we have the basic intent grammar which ultimately requires giving meaning to the terminal literals, currently these are by reference to the spreadsheet https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit?usp=sharing But we have a plan to set up some more structured view of these.

We could use OpenMath again to ground intent terms, but I suspect we will want a lighter weight system that is easier to update (or we could use wikipdia or whatever)

Once that system is in place I don't see any reason not to allow it on csymbol.

Taking the canonical superscript-meaning-power example:

If <msup intent="power" references whatever dictionary we have to say this means power, then it would make sense for <apply><csymbol intent="power">power</csymbol> to reference the same thing rather than (as now) Strict content mathml requiring <apply><csymbol cd="arith1" name="power">power</csymbol> with some additional specificaion somewhere that relates the intent attribute dictionary to the core openmath cd group that covers content mathml.

So... I'd propose we allow intent wherever we allow cd to allow the use of this alternative mechanism to ground the meaning of content mathml.

We could take the further step of changing the rewrite rules to use intent rather than cd so <apply><sin/> rewrites to <apply><csymbol intent="sin">sin</csymbol> raher than <apply><csymbol cd="transc1" name="sin">sin</csymbol> which would bring things back in-house and remove the normative dependency on OpenMath, but we don't have to decide to do that before deciding whether to allow intent.

[NSoiffer]

Nevertheless, it would be interesting to know if there are compelling use cases where Content MathML would find it's way into AT, and whether the intent attribute (as currently formulated) would add any value over what's already encoded in the Content.

Something as simply as <apply> <plus/> ... </apply> needs to somehow be translated to speech or mapped to something in the core list if appropriate. Perhaps that is done by a some defaults. However one can certainly imagine that the names used in an OpenMath CD don't match the names in core list. Or that for those names that don't map to core, the names were not chosen based on how they were meant to be spoken.

[brucemiller]

So, part of the rationale is that for intent to be usable on out-of-core elements like mstack, we have to assert that intent should be visible on "unknown MathML" elements, and thus pretty much anywhere? OK.

[davidcarlisle]

On the call on 2022-08-11 the working group resolved with no objections to make the change suggested by this issue. It was noted that Deyan may have spoken against had he been there but we went through the comments here and there was a clear consenus to apply this change for the FPWD.