exclusive properties

[davidcarlisle]

In the recent PR on property interpretation I used wording to explain why :infix:prefix is the same as :prefix but :pause-long:unit is the same as :unit:pause-long in terms of some properties setting system-specific parameters so the fixity properties setting the same fixity parameter over-ride each other, as do :common and ;literal setting a default intent inference rule set.

@NSoiffer commented that this left "parameters" rather too undefined and suggested a defined term such as "exclusive property"

I think we can make this notion a not system specific by re-organising the core property list to say which properties are grouped in this way.
Currently it is grouped along semantic groupings which is similar but not the same, eg the fixity properties are listed as a group but under chemistry there are :chemical-equation and :chemical-formula (which are i think like :literal and :common changing the default readings, and :chemicla-element which is intended more for a single <mi>. The chemical-formual example repeats :chemical-formual multiple times, i'd hopw that you could just use it once at the top to say read the expression as chemistry.

Similarly the current Table group has mutually exclusive properties for how to read the matri (:matrix, :system-of-equations but also other table related properties such as :continued-row so the set of exclusive properties for how to read the table is left implicit.

I'd suggest to split up the the Table (and other) section into groups of exclusive properties and make that a defined term in the spec.

[NSoiffer]

It is much more likely people will want to look at options based on a category than want to know whether they are exclusive or not.

I think it makes much more sense to come up with a way of indicating that it is exclusive ("a radio button") and the group that it is part of. Mostly, it is about the elements in the same category, but not always as you pointed out with some of the table properties. However, that could be solved by splitting the table category into subgroups. It also might make sense to group some of the current categories. For example something is either a :unit or a :largeop, not both, so they can be combined along with (probably) roman-numeral and shape. If we can do that, then some comment at the top saying 'only the rightmost element in a group is used' would be a clean way of doing this.

FYI: figuring out when something is chemistry is not that easy (especially because the MathML generated for chemistry is remarkably bad). It was not my intention that it be part of :common. If you have <math intent=":common:chemical-formula"> then when applicable, a chemical formula reading is used just as if you had marked something with :unit overriding :common. So that means <math intent=":chemical-formula:common"> is the same as <math intent=":common">

One other thing: the properties listing does not specify what should be done if the property doesn't make sense. For example:

• <mn intent=':roman-numeral'>ab</mn>
• <msqrt intent=':roman-numeral'><mn>XI</mn></msqrt>

The spec says to ignore the property. That makes sense for the first one above, but should AT ignore it for the second one or inherit it?

[davidcarlisle]

@NSoiffer

<math intent=":chemical-formula:common"> is the same as <math intent=":common">

Yes that matches my expectation.

I see chemical-formula to be in the same set as common and literal which is why they overide each other, which is why i would expect normally you just need to use it once at the top to say "use chemistry rules" and don't need :chemical-formula at all levels as shown in the current example.

[davidcarlisle]

<msqrt intent=':roman-numeral'><mn>XI</mn></msqrt>

but should AT ignore it for the second one or inherit it?

looking at the entry for roman-number it says the applicability is mn so I think it should be ignored on everything else.

Note that mn may take child elements. but the property relates to reading the whole element as a Roman number not separately each child.

<mn intent=':roman-numeral'><b>X</b><i>C</i></mn>

is a styled roman number XC not the two roman numbers X and C it is not

<mn><b intent=':roman-numeral'>X</b><i intent=':roman-numeral'>C</i></mn>

properties don't inherit in that sense.

[NSoiffer]

That's a good point about the restriction to mn. I wonder if we need further restrictions. Your example is relatively simple, but given that the content can be any HTML, speaking or brailling it at as a roman number might not be possible. For example, suppose it is SVG content.

Maybe it makes sense to say it (and the other similar properties) are restricted to leaf elements that have only textual content?

[davidcarlisle]

Yes I think it's not reasonable to expect

<mn intent=':roman-numeral'>.. arbitrary SVG</mn>

to do anything reasonable, if you have such a thing and want it read as a ronam-numeral I think you'd need

<mn intent='MMXXV:roman-numeral'>.. arbitrary SVG</mn>

or

<mn intent='_M_M_X_X_V'>.. arbitrary SVG</mn>

or some such intent that did not require the element content to be parsed.