largeop properties

[davidcarlisle]

This PR addresses issue w3c/mathml#482

It groups the more common largeop (Unicode n-ary or integral characters) in a style similar to the default fixity list. and now explicitly references largeop from the core property list.

Currently it is a separate section although an alternative more compressed layout could be achieved by simply adding largeop
to the default fixity section and dropping teh extra wording around it, relying on the link to largeop in the core property list for the speech templates.

largeop and the fixity properties are now all links to the core property list. this highlights the fact that nofix as cuuent lused eg for diameter https://davidcarlisle.github.io/mathml-docs/intent-core-concepts/#diameter has no definition.

I'm not sure if nofix was intended to be a meta-property implying there is no property applied or if it is intended to be a real property that can be explicitly used (in which case it should be added to core property list). Currently it makes a broken link.

In order to fit integrals in this largeop list I had to increase the arity so integral:largeop{f) is $\int f$ which means the arity one form can't be used for $\int_C$ perhaps we need two properties one that does not expect the summand/integrand so can be used on the munderover and just refer to the "embellished operator"?

[NSoiffer]

As per the meeting on Thursday with the :largeop property, I thought we were going to remove the concepts for "sum", etc., and just have the largeop property.

[davidcarlisle]

@NSoiffer having the :largeop property means we don't need list them all but as with the existing fixity properties having some common ones in core means that you can omit the property. If you need to lift the intent on to an mrow or table row you can go sum($a,$b,$f) rather than sum:largeop(($a,$b,$f) . On the other hand we could drop the entries in the main table and assert that
the new largeop list does default the largeop property for those concepts, as well as giving the characters so you are probably right that we should drop the table entries for sum and product

[NSoiffer]

Hmm. There a difference between sum($a,$b,$f) and what :largeop does, so maybe they do need to be there for placing them on an mrow. The difference is that :largeop applies to the mo and only looks to the limits on it. The $f is not considered. So these would be different and it is wrong (ok, not wrong, but pointless) to add :largeop to "sum" just as it would be to write power:array.

[davidcarlisle]

Hmm. There a difference between sum($a,$b,$f) and what :largeop does, so maybe they do need to be there for placing them on an mrow. The difference is that :largeop applies to the mo and only looks to the limits on it. The $f is not considered. So these would be different and it is wrong (ok, not wrong, but pointless) to add :largeop to "sum" just as it would be to write power:array.

The existing largeop property shows sum:largeop with arguments including teh expression, and just teh 0-arity form being used on the munderover https://w3c.github.io/mathml-docs/intent-core-properties/#prop-largeop

It is a little awkward though which is why I wrote in the opening description of this PR

perhaps we need two properties one that does not expect the summand/integrand so can be used on the munderover and just refer to the "embellished operator"?

and in mathml#482

the existing comments in the sum core entry seemed to indicate that the intent should or could go on the munderover but in the examples I added to the fork, I only managed to place it on the mrow.

perhaps sum:largeexp(...) for the expression form?

Or perhaps it's better to not try to add any of these concepts to core and just have the largeop property, designed to go on the operator, that's simpler and may be enough.