hmm interesting agenda item for the call this week.....

I must say on first impression I'm not keen, the big table makes it hard to quickly scan each element, I thought the formal tables introducing each element were a feature really.

If for example you compare the adjacent sections for inverse and lambda

https://w3c.github.io/mathml/#contm_inverse

https://w3c.github.io/mathml/#contm_lambda

the content row in the table immediately tells you that the first is empty (used with <apply/>) and the second is a container taking <bvar> and qualifiers.

In the version in this PR I think that's a lot less clear in chapter 4, it's implicit in the text and the examples but no single unified form that you can pick out while scanning over the chapter unless you go down to appendix F and then you only have syntax entries without the background context.

It's rather common for element descriptions to have such a table per element eg

svg 2 has a blue syntax box for each element (eg switch here)

https://www.w3.org/TR/SVG/struct.html#SwitchElement

and html has a similar box for element definitions eg for hr here

https://html.spec.whatwg.org/#the-hr-element

With the transform to strict moved, the OM symbols rows in the current tables are a little bit out of context, and could probably be collected as here maybe just to a table in the transform appendix rather than a whole new appendix, but the content model and attribute rows seem to me to be the fundamental definition of the syntax which should be in the main definition.

The big table seems unwieldy. Maybe it is better to break it into chunks like "basic arithmetic", "trig functions", and a few others.

I don't think the SVG examples are at all analogies because here we have ~130 elements (if memory serves) and SVG is maybe 10-20. HTML has more, but there isn't the commonality that the content elements (such as the trig functions) have. I think the spec is clearly when someone can see more in one place. Having said that, I'm not going to say the current table has the right entries or is organized properly... but I'm not saying it isn't.

The big table seems unwieldy. Maybe it is better to break it into chunks like "basic arithmetic", "trig functions", and a few others.

hmm It was in chunks like that already:-)

I don't think the SVG examples are at all analogies because here we have ~130 elements (if memory serves) and SVG is maybe 10-20. HTML has more, but there isn't the commonality that the content elements (such as the trig functions) have. I think the spec is clearly when someone can see more in one place. Having said that, I'm not going to say the current table has the right entries or is organized properly... but I'm not saying it isn't.

Chaper 4 already coalesces trig functions in to one table (it could do more eg hyperbolic and inverse are structurally the same)
also we don't currently merge eg all the set functions, union, subset etc.

Actually if we can find a way to move the OM symbol mapping to chapter F, each of the tables can effectively collapse to a single row with just the operator class. For example looking at <lt/>

https://w3c.github.io/mathml/#contm_lt

Once you know it is of class nary-reln you know the other rows as it is an empty element and when used with apply it takes bvarq and domainq qualifiers.

I kinda liike the idea of combining things into a single table, even if large, but there are some problems to sort out. I think the emptiness of some elements could be brought out by having putting "empty" (maybe italic?) into the content column. (of course, it's the mixed model of apply vs containers that I don't much like about non-strict in the first place).

The symbols column seems a little lost without more context. However, I would rather the idea of an equivalent csymbol would have more emphasis, rather than hiding that column somewhere else. (And of course with reservations about being tied to OpenMath).

Closing as agreed in the call on 2022-05-05, the main proposal here, a new appendix F with a combined operator table has been incorporated into the parallel PR #325