Do the # of arguments define a core "intent"?

[NSoiffer]

The guts of this question is: what is the type signature of an intent. Is there one intent named minus or are there two : one with a single argument and one that has two (or more) arguments?

This came up when @davidcarlisle added speech output to a version of the initial core list initially created by @dginev. In that initial version, there is

<mover>
 <mi>X</mi>
 <mo intent="ray">→</mo>
</mover>

However, MathCAT defined a ray intent as a two argument format based on the two points that define the ray: $\vec{AB}$. Because the example had no arguments, MathCAT generated an error message (akin to an mfrac having no children).

Is a core intent name defined by just the name? the name + #args? name + something more (isa?)? Is a no-argument form special?

If the number of arguments matter, how do define an nary intent name? Just in prose?

[dginev]

My suggestion would be to stay consistent with the Open realm and to not mix the exact argument lists with the intent value considerations.

I like thinking of each Open intent value as an "encyclopedic concept", i.e. a well-known name in the communities familiar with the subject matter.

Using an intent with a concrete number of (and order of) arguments, (with a concrete operator fixity), falls closer to describing a specific notation.

To me, the same intent value can be used in a variety of notations, at least as far as the Open terrain is concerned. And which notation was used in any particular case can be inferred from examining the presentation tree.

Ideally the Core and Open sides will try to be mostly consistent, but this remains to be worked out.

If you'd like this to be a core-only issue, maybe we should indicate this in the title? Currently it's stated quite generally.

P.S. As an implementation note for MathCAT, I think there is opportunity for "graceful degradation" where any unexpected notation can degrade to the baseline readouts expected for an Open intent. In the ray <mover> example, it looks like that would be "X with ray above", or similar.

[davidcarlisle]

I do not think this should be an error, otherwise making any later changes to the core list will be difficult (or impossible, depending on how we handle errors) I think it is OK for the list to say which arities it handles in each case, and just treat others as you would any other identifier.

I think our motivating examples have always been somewhat fluid on arity,

<mrow intent="times($x,$y)"><mi arg="x">x</m><mo>×</mo><mi arg="y">y</mi></mrow>

and

<mrow><mi>x</m><mo intent="times">×</mo><mi>y</mi></mrow>

should both be legal, and the second hasn't obviously got arity 2

Deyan suggested the presentation tree could be used to disambiguate, but I don't think that's an option. The intent is there to over-ride the default reading, if there are no $ it is well defined to ask what is the reading of ray(_wibble) without reference to any xml tree at all.

There is a more general question about error handling, Deyan alluded to this as well. It's useful to have a mode which flags an error on invalid intents (this caught lots of errors in the initial, hand written intent examples that had not previously had machine validation) but, like xml parsing, aggressive error reporting is not so useful on a web page where the person getting the error message has no way to correct the source. I should open another issue but I don 't think ray(x)should be an error at all, but the default mode for handling things that don't match the grammar say intent="))$<??" should be well defined and not cause the entire <math> to have no speech string if some subterm has an error, probably the intent attribute should be effectively removed and the surrounding elements processed as if it had no intent. or perhaps it is handled by some marker such as intent="error" to be decided but

<mfrac><mi intent="hmm)(">x</mi><mi>y</mi></mfrac>

should have a reading equivalent to

<mfrac><mi intent="something">x</mi><mi>y</mi></mfrac>

or

<mfrac><mi>x</mi><mi>y</mi></mfrac>

not (by default) reject the entire expression

I added this example to

https://mathml-refresh.github.io/intent-lists/intent3.html#IDUnexpectedarity

[dginev]

Deyan suggested the presentation tree could be used to disambiguate, but I don't think that's an option. The intent is there to over-ride the default reading, if there are no $ it is well defined to ask what is the reading of ray(_wibble) without reference to any xml tree at all.

We can certainly answer what a baseline read of ray(_wibble) is, irrespective of placement. For example, we tend to arrive at e.g. "ray of wibble" if ray were in the Open set.

That should not lead us to forbid implementers from using all available context (such as the presentation tree) when trying to build superior systems.

Consider divide used in a vertical and a horizontal notation:

<mfrac intent="divide(1, 2)">
  <mtext>wibble</mtext>
  <mtext>squibble</mtext>
</mfrac>

<mrow intent="divide(1, 2)">
  <mtext>wibble</mtext>
  <mo>÷</mo>
  <mtext>squibble</mtext>
</mrow>

If AT wanted to emit the speech "one half" for both, it certainly could. But if a system considered it more appropriate to emit "1 divided by 2" for the horizontal notation (by checking the presentation tree to see there was an infix mo and not a surrounding mfrac) - why isn't that a viable option?

It is a big design motivation for intent to keep it a "partial annotation" scheme. The flip side of that coin is that AT systems should be allowed (but not required) to collect any missing information from the other available facets of MathML. I have tried to make a distinction between the two by calling the simpler approach a "baseline readout", but I am still fishing for the right words for the "perfect readout" considerations.

I agree with David C's comments on error handling. We likely need some text on suggested recovery strategies. So far I am fond of

• unknown notations are treated as baseline Open expressions
• malformed expressions have their intent attribute fully dropped.

So for:

<mfrac><mi intent="hmm)(">x</mi><mi>y</mi></mfrac>

I'd revert to:

<mfrac><mi>x</mi><mi>y</mi></mfrac>

We could do better if our discussions on introducing a self-reference marker move forward. If we had a $this that pointed to the current node, a malformed expression could fall back to something like:

intent="malformed-intent-error($this)"

for any node.

[davidcarlisle]

@dginev wrote

That should not lead us to forbid implementers from using all available context (such as the presentation tree) when trying to build superior systems.

I think implementations should be free to implement a larger list of "known intents" than the core list, so build superior systems in that way.

But I don't think the presentation tree can be used here. Authors should be able to specify an intent that differs from the intent guessed from the layout without the system deciding to be superior and re-using the layout.

We could do better if our discussions on introducing a self-reference marker move forward. If we had a $this that pointed to the current node, a malformed expression could fall back to something like:

intent="malformed-intent-error($this)"

for any node.

yes agreed, something like that. (if we don't drop it entirely)

[dginev]

I think implementations should be free to implement a larger list of "known intents" than the core list, so build superior systems in that way.

I agree with that as well.

Authors should be able to specify an intent that differs from the intent guessed from the layout without the system deciding to be superior and re-using the layout.

Right, but that mixes two aspects. How the pieces of an expression fit together (i.e. the notation) is a separate aspect than which concept we are narrating (i.e. the intent value).

To me the use of a certain intent value stands for an author indicating to AT which concept was meant, not which concrete speech string was desired. For speech overrides, I prefer the underscore mechanism, as in intent="_wibble-ray" or intent="_one-half". There is no room for consulting further context when the intent attribute contains a single underscore value (it's equivalent to an alttext or aria-label attribute).

Starting with the annotated concept and then using the presentation tree to infer how the pieces of its notation can be spoken together does not void the original annotation. Rather, it helps make the chosen speech for it more natural (as the annotation was partial, by design).

The group has chosen to invest in @hints as an alternative vehicle for this - where the burden is placed back on the annotator - so I think there was wider agreement that a single intent value can participate in a variety of notations, and by extension - a variety of generated speech patterns.

[davidcarlisle]

so I think there was wider agreement that a single intent value can participate in a variety of notations,

Yes.

I think if for whatever reason I want $\sqrt[3]{x}$ as a new notation for $\frac{x}{3}$ then I should be able to use

<mroot intent="divide($n,$d)"> and <mfrac intent="divide($n,$d)"> and be assured the content
<mi arg="n">x</m><mn arg="d">3</mn>
will be read the same way.

[davidcarlisle]

@dginev

Starting with the annotated concept and then using the presentation tree to infer how the pieces of its notation can be spoken together does not void the original annotation.

although If I understand you correctly, I suspect I agree with this requirement.

examples from another thread, I really want to annotate mtable as "matrix" or "system of equations" or...

Currently if you have

<mtable intent="matrix"

it gets read as "matrix" and the array content is lost. I think you are suggesting that would only happen for _matrix and for a core value (or any no _ value?) the system should be free to see the table layout and do something sensible. I don't think that's do-able in general, but I do want to be able to request that when needed, which gets us back to:

<mtable intent="matrix($this)" or <mtable intent="matrix(*)" or whatever we decide, meaning
handle this mtable with the knowledge it's a matrix of values, not an aligned set of equations.

[NSoiffer]

I think implementations should be free to implement a larger list of "known intents" than the core list, so build superior systems in that way.

I agree with that as well.

That could lead to trouble. Flashback to some pivotal point in mathematics history where a brilliant PhD is being written and it used intent="dc-notation($x). But some clever AT developer who isn't aware of that PhD and its impending Fields Medal thinks there's a great notation for "direct current" and adds a known intent for that. It's not listed anywhere other than maybe some hard to find documentation on the product, but probably just buried in code. That brilliant PhD reads as intended in some AT and very wrongly in this clever AT. I think that's a big problem.

That leads me to an idea that @dginev mentioned, but didn't suggest as a formalization: "require" (via convention) open intent names to begin with _. This then avoids the problem of name conflicts with someone adding something as a "core" intent and then accidentally usurping an open intent. I could go with the alternative of core names always starting with _. This makes them stand out more: _divide, _ray_, ... There is some HTML precedence for user-names starting with _ (in our case) in that data- is a special convention for non-spec names. Requiring a prefix data- or open- seems too intrusive, but _ isn't as that is a signal this should be spoken literally. [Or does it -- should it be translated to other languages if possible?]

[davidcarlisle]

I'm not keen on distinguishing the core list, I don't think it can be stable, just like the operator dictionary. Like the operator dictionary you can go <mo>U+whatever</mo> and if that character is in the system specific dictionary it may get modfied space, if not it doesn't. same here. If I have a tex to mml convertor I want to generate reasonable looking intents, and if experience shows an intent occurs often and would benefit from custom handling a system reading the intents should be able to do that. And if that seems a good thing it could be in the next iteration of the core list.

We need to make up an initial core list to get things started, but we can't be complete.

[NSoiffer]

Some replies:

1. This is probably "core-only" as it involves a conflict with an existing definition. I've updated the title.
2. Re "graceful degradation": I like seeing errors upfront rather than trying to spot them in the output. But I think I'm a minority, so I agree that the right thing is probably just to ignore an intent anytime there is an error: bad syntax, wrong number of args, reference to a non existing arg, etc(?). I could maybe add the words "intent error" to help authors, but that's likely less desirable for users.
3. Re: "using the presentation tree". For core, yes. For non-core: no. For core, supposedly AT knows about the meaning of the 'intent' so it can craft the speech, but for non-core, it can't know it (by definition). A open "compose" intent might mean many different things. There is no way to know what that is without resorting to some definition somewhere (which we don't do). The only thing it can do is slavishly follow what the author said to do (which I claim is made easier for the author/authoring software by having hints).

[NSoiffer]

I'm not keen on distinguishing the core list, I don't think it can be stable, just like the operator dictionary.

My proposal is one of conventions (as is true in HTML). You can generate intent='foo@postfix($arg)' and no error will happen. It may or may not speak as you intended because there may be a definition in core and AT does it thing. If you generate intent='_foo@postfix($arg)' , then you can be assured it will speak as "arg foo".

Note to @dginev: if we leave off hints, then there is a big difference between being supported or not supported for common cases: intent='foo@postfix($arg)' vs. intent='_($arg, foo)'. Another reason to like the suggestion (yes, this is confermation bias :-).

So there is certainly no harm in doing what you are doing now using a core-like name syntax (under my proposal). You might need to update your names as we come up with specific core names, but that's true whether we go with my suggestion or not.

[davidcarlisle]

On Wed, 22 Feb 2023 at 00:56, NSoiffer ***@***.***> wrote: Some replies: 1. This is probably "core-only" as it involves a conflict with an existing definition. I've updated the title. 2. Re "graceful degradation": I like seeing errors upfront rather than trying to spot them in the output. But I think I'm a minority, so I agree that the right thing is probably just to ignore an intent anytime there is an error: bad syntax, wrong number of args, reference to a non existing arg, etc(?). I could maybe add the words "intent error" to help authors, but that's likely less desirable for users.

Yes I prefer xml's fatal error handling when processing my own doc, and I appreciated mathcat catching multiple errors in my hand crafted intents, so I wouldn't want to lose that possibility, but once it gets in to an html page with an html parser that accepts literally any string and parses it somehow, it's going to seem odd to have errors flagged reading intent. David Message ID: ***@***.***>

…

[davidcarlisle]

On Wed, 22 Feb 2023 at 01:09, NSoiffer ***@***.***> wrote: I'm not keen on distinguishing the core list, I don't think it can be stable, just like the operator dictionary. My proposal is one of conventions (as is true in HTML). You can generate ***@***.***($arg)' and no error will happen. It may or may not speak as you intended because there may be a definition in core and AT does it thing. If you generate ***@***.***($arg)' , then you can be assured it will speak as "arg foo".

yes OK I think we more or less say that already, that `_` names won't be in core (or the system, list) and so will be spoken as-is. Message ID: ***@***.***>

…

[NSoiffer]

yes OK I think we more or less say that already, that _ names won't be in
core (or the system, list) and so will be spoken as-is.

Good point -- I had forgotten it says that. But the spec doesn't say the opposite: that "concept names" should be only for core concepts that are defined (elsewhere?). Maybe that is implied, but it would be good to be explicit.

I am a little concerned about something like:

intent='_(_the, range, _from, $a, _to, $b)

which I think has been proposed a number of times. It doesn't end up doing what you might think...

I think @dginev had a clever algorithm to try and reconstruct the concept/meaning for this kind of string-like notation where it avoids the connective words and comes up with range($a, $b). However, what happens if range is a core intent with args? range in the above is an intent, but a malformed one (it should have args), so the whole intent is wrong and gets chucked out/read as if there is no intent by AT (as per the earlier discussion).

A simple solution is to modify what's used by DG's algorithm. Maybe __range, _-range, _range_, or _Range.

[brucemiller]

@NSoiffer I don't quite see how requiring a _ prefix on non-core concepts helps with the case you've mentioned. The clever AT developer can just as easily misinterpret _dc-notation as dc-notation. It seems as if you're trying to make a single switch distinguish between 3 cases:

• core concept
• non-core concept, possibly in an open dictionary
• arbitrary phrase
  But the 1st two are already distinguished by whether the term is in the (current) core dictionary.

[davidcarlisle]

so the whole intent is wrong and gets chucked out/read as if there is no intent

I don't think it should do that: the core list should inlcude arity and use of the name with unexpected arity should be like any other non-core use, not an error.

[dginev]

But the spec doesn't say the opposite: that "concept names" should be only for core concepts that are defined (elsewhere?). Maybe that is implied, but it would be good to be explicit.

@NSoiffer If you are attempting to completely axe the Open list, why not be explicit about your intention? That is the ultimate effect of such a proposal, where the underscore-based speech overrides (akin to alttext and aria-label in behavior) become impossible to tell apart from intended "encyclopedic concept names".

Even if you personally are not interested in implementing support for the Open terrain, I again remind that it is exactly that terrain that motivates my participation in the group. Why take away my opportunity to do meaningful work with higher mathematics?

What distinguishes Core from Open is the inclusion of a vetted list of values that will be endorsed by the MathML 4 specification, which will define Core. Open is any concept that is not included in that list. Is that not sufficient?

[NSoiffer]

[Replying to @brucemiller's comment on why I want to say open intents should start with _]

I'm trying to make using open names safe so they don't collide now or in the future with core names. By "requiring" (by convention) that they start with _ and that core names never start with _, collisions can't happen. This is analogous to what the powers that be decided for "open" attributes in HTML: they are supposed to start with data- so they don't collide with additional attributes that get introduced in the future. A similar things was done for CSS with the prefix "--". What is the downside to this?

But the spec doesn't say the opposite: that "concept names" should be only for core concepts that are defined (elsewhere?). Maybe that is implied, but it would be good to be explicit.

@NSoiffer If you are attempting to completely axe the Open list, why not be explicit about your intention? That is the ultimate effect of such a proposal, where the underscore-based speech overrides (akin to alttext and aria-label in behavior) become impossible to tell apart from intended "encyclopedic concept names".

What I was referring to is this part of the spec:

Names starting with "_" (U+00F5) are always considered to be literal names, and should never be in an Intent Concept Dictionary.

I take "Intent Concept Dictionary" to mean the core intent names. Maybe that distinction needs to be explicit because I do think it makes sense to have a unofficial open dictionary that might change everyday. But that dictionary doesn't belong in the spec other than maybe as informative text that points to a W3C note that explains the goals of an open list. That might then point to some suggested location to gather the list.

By "opposite" I meant names that don't start with "_" should only be names that are in a core list for the reasons listed above.

To be absolutely clear: the names chosen for open intents are the ones that will be spoken unless @silent is used. So there is in fact some restrictions on what names are chosen for open intents. But within that restriction, I would hope that they do represent some concept because they would otherwise be rather pointless. Indeed, I'm a big fan of the warning in the spec about using _ as a head in the spec.

To emphasize my support for the open list... I want the core list to be small to ease implementation burden. That means I strongly support an open list that avoids using literal text as much as possible. That's why I feel that hints are essential. Without them, either the open list intents read poorly in many cases or people have to write out what they want spoken using literal text. The hints don't solve reading all notations appropriately (e.g., "...to...from...of"), but they go a long way in that direction.

[davidcarlisle]

[Replying to @brucemiller's comment on why I want to say open intents should start with _]

I'm trying to make using open names safe so they don't collide now or in the future with core names.

I'm not sure that is possible or desirable. If I use intent="rabbit" and that gets added to core, it may get a custom reading or may get translated but nothing impossibly bad will happen.

By "requiring" (by convention) that they start with _ and that core names never start with _, collisions can't happen. This is analogous to what the powers that be decided for "open" attributes in HTML: they are supposed to start with data- so they don't collide with additional attributes that get introduced in the future. A similar things was done for CSS with the prefix "--". What is the downside to this?

in html, data- attributes are supposed to be document local with no external def (so like _ names) other specs adding attributes for general use, aria, microformats, .... define normal attributes (like open list).

What I was referring to is this part of the spec:

Names starting with "_" (U+00F5) are always considered to be literal names, and should never be in an Intent Concept Dictionary.

I take "Intent Concept Dictionary" to mean the core intent names. Maybe that distinction needs to be explicit because I do think it makes sense to have a unofficial open dictionary that might change everyday. But that dictionary doesn't belong in the spec other than maybe as informative text that points to a W3C note that explains the goals of an open list. That might then point to some suggested location to gather the list

I think the intention of the current wording is that intent="_rabbit" is document-local literal that should be spoken as-is and intent="rabbit" is a concept name that should be spoken as-is if not known but may be translated or subject to special handling if known. So it's not (yet) in core but if a system knowledgable about pets chooses the text string 🐇 so be it.

By "opposite" I meant names that don't start with "_" should only be names that are in a core list for the reasons listed above.

Core is too restrictive, there is no way to get a reasonable list at first iteration, we should aim for a conservative core list which is a baseline "systems should support at least these names".

To be absolutely clear: the names chosen for open intents are the ones that will be spoken unless @silent is used. So there is in fact some restrictions on what names are chosen for open intents. But within that restriction, I would hope that they do represent some concept because they would otherwise be rather pointless. Indeed, I'm a big fan of the warning in the spec about using _ as a head in the spec.

I don't think that should be the case. I think names not in the system's concept list should be spoken as-is, and that list should include all of core.

For example mathCAT has rules handling determinant . If in the end determinant is not in core, perhaps because we need core names to be in at least two systems and mathcat is alone, then I don't think you should remove the rules for determinant or make documents use _determinant they will just get better readings in one system. If later more systems add a rule for determinant we can add it to core to say all systems should have such a rule.

To emphasize my support for the open list... I want the core list to be small to ease implementation burden. That means I strongly support an open list that avoids using literal text as much as possible. That's why I feel that hints are essential. Without them, either the open list intents read poorly in many cases or people have to write out what they want spoken using literal text. The hints don't solve reading all notations appropriately (e.g., "...to...from...of"), but they go a long way in that direction.

agreed with that.

[dginev]

To emphasize my support for the open list...

Great to have this as a consensus point, thanks.

I am aligned with @davidcarlisle's reply on why we still need Open and Core values to look the same.

That's why I feel that hints are essential. Without them, either the open list intents read poorly in many cases or people have to write out what they want spoken using literal text.

• or the presentation tree is consulted, which contains the inked fixity information, which often overlaps the @hint information.
• or certain remediators and developers naturally prefer using literal pieces, as the @hints only cover standard fixity information
  • which isn't sufficient for e.g. the free algebra spec example here, or any other Open mixfix notation. A @mixfix hint is not theoretically possible (there is no standard order of the pieces to lean on, guessing remains).
• or the intent annotations are placed with the right granularity, so that the fixity is already assumed from the legacy MathML 3 readouts.
  • e.g.

     <mn>1</mn>
     <mo intent="strict-equality">===<mo>
     <mn>1</mn>

  • will have the operator spoken infix with no further help needed
  • but it would still need a language override to enforce say a specifically conjugated verb form as with "_strictly-equals", until ATs add full support for the concept name.
  • to me this type of error is a minor flaw, and respectively a minor upgrade, for the thousands of Open concept names. Conjugating and declining language forms depends on context, so we can't really solve that problem from the symbolic layer.
    • E.g. _strictly_equal (plural) vs _strictly_equals (singular), and in other languages we have gendered forms, e.g. _стриктно-равен (m, singular, lang:bg), _стриктно-равна (f, singular, lang:bg), _стриктно-равно (n, singular, lang:bg), _стриктно-равни (all genders, plural, lang:bg).
      • My example is linguistically even trickier, since we didn't create a verb out of our "equality" in Bulgarian, the short form is only an adjective (as in "equal participation"). We allow eliding the declined "be" verb ("be equal") in math, but if we really had to have it, my example is now:
      • _е-стриктно-равен (m, singular, lang:bg), _е-стриктно-равна (f, singular, lang:bg), _е-стриктно-равно (n, singular, lang:bg), _са-стриктно-равни (all genders, plural, lang:bg).

To me hints are just one approach to provide fixity information. Some seem to like them, others want to abstain from using them, in favor of other techniques.

[davidcarlisle]

As @dginev will no doubt have guessed I agree with his comments apart from

or the presentation tree is consulted, which contains the inked fixity information, which often overlaps the @hint information.

Using the presentation tree is viable by pushing the intents down as you show with infix intent="strict-equality" but if it is used as intent="strict-equality($a,$b) on the parent then assuming it isn't in the system's list of concepts, you will get a prefix reading unless you add @infix. If the system does document an extended concept list that includes this, it can of course read it any way it specifies.

[dginev]

If the system does document an extended concept list that includes this, it can of course read it any way it specifies.

Right. So we can restrict what I stated with "on a case-by-case basis" - that seems sensible. Namely:

Or, on a case-by-case basis, the presentation tree is consulted, which contains the inked fixity information.

[davidcarlisle]

I don't think it should ever consult the layout,. A system can read core equals($a, $b) as a equals b or a is equal to b or whatever it specifes and it should be able to do the same if it has strict-equality in its list, but the basic principle that the intent over-rides the presentation remains.

[dginev]

So when you said "it can of course read it any way it specifies", you were exempting the specification of "narrate the intent expression following the fixity observed in the presentation tree of the node holding the intent attribute"?

If I were writing an AT (or were forking an existing open-source AT system to enhance it for arXiv), I would be partial to that approach, on a case-by-case basis, for Open values I have vetted.

Edit: improved technical wording

[davidcarlisle]

given that ultimately we want the system to be free to use any words in any language, we obviously can't have any enforcable rules that prevent that. But I would say that we should make it clear that systems "SHOULD NOT" (https://www.rfc-editor.org/rfc/rfc8174) do that. If the system can read $a$ and $b it should read strict-equality ($a,$b) in some system specific way irrespective of the markup it is annotating,

Actually that may be too strong, a motivation for adding */$self is to let the system see the markup and read the table layout, but that is a special opt-in, not a general access to use the layout.

[dginev]

I don't think the strict "SHOULD NOT" is consistent with the goals of a "partial annotation".

I would prefer a "SHOULD" that specifies a baseline narration uses only the intent annotation, on a node with intent set.

[davidcarlisle]

I think it is reasonable to have a design aim that an author has the expectation that elements with the same intent are read the same way. You have suggested before that we change that, which is not impossible but I haven't seen much consensus for such a change. (Actually the current spec is sufficiently sketchy that anything is possible, but that's just the state of the text). But sure, saying a system SHOULD use the intent alone is almost the same as saying it SHOULD NOT not do that. Either would work, when we come to fine editing of the spec wording we need to worry about any edge cases where they differ. We are nowhere near that yet, just setting out the basic models how this is intended to work.

[davidfarmer]

A specific instance I am thinking about looks like a × b This could mean multiplication, or cross product, or direct product, or ... My first question: should the intent go on the × , or should it go on the mrow, or is either acceptable? I like the idea of putting it on the × , and more generally I like the idea of putting the intent as deep in the tree as possible. But suppose for one meaning of × , the standard pronunciation is something like "the direct product of a and b ". My second question: when words are supposed to be spoken before the " a ", is it expected that the AT looks past the " a " to see the intent on the × so that the whole expression is pronounced correctly? It is better for me if I know that it is okay to put the intent on the × in all cases.

[davidcarlisle]

My first question: should the intent go on the × , or should it go
on the mrow, or is either acceptable?

either acceptable but not equivalent.

My second question: when words are supposed to be spoken before
the " a ", is it expected that the AT looks past the " a " to see
the intent on the × so that the whole expression is pronounced
correctly?

for a concept name in core (so definitely times and perhaps cross-product a system can have such rules. You can see what mathcat does currently with the rows around

https://mathml-refresh.github.io/intent-lists/intent2.html#id5

which have both forms

[davidcarlisle]

@davidfarmer better example extracted from your list

https://mathml-refresh.github.io/intent-lists/intent1.html#id5

showing mathcat's reading of cross product with intent on the mrow or on the mo

[brucemiller]

Given

<mrow> <mi>a</mi> <mo intent="foo">*</mo> <mi>b</mi> </mrow>

we might reasonably expect AT to simply read off the mrow children as "a foo b"; it never really needs to consider whether foo is infix or not.

Given

<mrow intent="foo@infix($a,$b)"> <mi arg="a">a</mi> <mo>*</mo> <mi arg="b">b</mi> </mrow>

we might also expect "a foo b" because AT was told to treat foo as infix.

Finally, given

<mrow intent="foo($a,$b)"> <mi arg="a">a</mi> <mo>*</mo> <mi arg="b">b</mi> </mrow>

we probably should expect "foo of a and b" (or similar), unless it knows something about "foo" from outside sources. I think it is slightly absurd to expect AT to guess that the * has anything to do with "foo" and thus infer infix; and equally absurd to forbid it from trying.

If there's anyone I failed to insult, I apologize.

[dginev]

I think it is slightly absurd to expect AT to guess that the * has anything to do with "foo"

If you think inferring infix fixity from an mi mo mi children pattern is absurd, you'll find ChatGPT outright obscene.

(raw screenshot, I typed this in as an experiment for this reply just now)

Note that mi mo mi is a straightforward pattern-match, no AI needed.

[NSoiffer]

@dginev: I'm a little surprised that with the vast arXiv archive that has so many "interesting" notations, you are advocating that AT can figure out that an author wants a reading different from what is implied by the intent. Maybe bra-ket notation is an example. The | is not an infix operator, but a separator. It is a shortened || formed by joining the <bra| and |ket> together. This is over my pay grade, so maybe I have this wrong for bra-ket notation. If so, consider it a new (open) notation I just made up. Yes, this is different from just a*b, but it's not that different. Even with the vast wealth of processing power that chatgpt has, it gets it wrong:

Given that authors have a simple method for specifying they want an infix reading, I agree with @davidcarlisle that a "SHOULD NOT" is appropriate.

[NSoiffer]

@davidcarlisle wrote:

@davidfarmer better example extracted from your list

https://mathml-refresh.github.io/intent-lists/intent1.html#id5

showing mathcat's reading of cross product with intent on the mrow or on the mo

You could also show it with a hint to get the infix reading:

<mrow intent="$prod@infix($x,$y)">
  <mi arg="x">x</mi>
  <mo arg="prod" intent="cross-product">⨯</mo>
  <mi arg="y">y</mi>
</mrow>

I know you have shied away from using hints, but given the current discussion, I think showing hints would be useful. They work in MathCAT.

I know you

[dginev]

@NSoiffer I am advocating for the spec allowing to use the available information in the markup (the presentation tree is already there). If any individual AT vendor does not want to do so, that is fine.

The spec saying that all vendors "SHOULD NOT" use the available information goes against the "partial annotation" aspect of Intent.

P.S. ChatGPT isn't as robust as symbolic approaches, clearly. I am not saying it can solve everything over arXiv today. It also wasn't the point, as matching the mi mo mi, mi mo, mo mi patterns over a pre-vetted Open intent value is just a regular symbolic enhancement.

That said:

[brucemiller]

I did not say it was absurd to infer, I said it was absurd to expect AT to infer.

[davidcarlisle]

You could also show it with a hint to get the infix reading:

Yes I'm gradually starting to add hint examples in list3 where I have a dedicated column for this, I'll try to add more

[davidcarlisle]

@dginev

If you think inferring infix fixity from an mi mo mi children pattern is absurd,

It's not that it's absurd or impossible, it just would be wrong to over-ride the supplied intent in that way.

If I have

<mrow intent="rabbit(1,2)"><mn>3</mn><mo>+</mo><mn>4</mn></mrow>

then it really does not matter that a system could infer this is an infix operation between 3 and 4, it should read it as rabbit of 1 and 2 as the intent is there to provide a reading apparently unrelated to the content. Suggesting that the intent should use the layout seems completely at odds with the design of the system and I can't see how it could be added in any reasonable way.

What is of course possible, and close to your chatgpt examples (and current mathcat behaviour), is to use the layout to infer default intents, so default readings, when none is given.

<mrow><mn>3</mn><mo>+</mo><mn>4</mn></mrow>

The system is of course now free to infer this is an infx operation and effectively default to

<mrow intent="plus@infix(3,4)"><mn>3</mn><mo>+</mo><mn>4</mn></mrow>

[dginev]

@davidcarlisle If we assume you are right about your examples, and I am right about my examples, the next question is whether intent is a spec that is more appropriate for annotating rabbit(1,2) or strict-equality($a,$b).

If your point hinges on the intent value being completely unrelated to the underlying presentation, I don't think we are working on the same problem domain. My premise is a "partial annotation" for disambiguating a (mathematically meaningful) presentation MathML tree. Not an escape hatch for hiding unrelated concepts over those trees.

I liked the middle ground we reached a few comments earlier. If the spec text allows AT to have freedom to do case-by-case enhancements for the Open values, beyond the "baseline narration", that will be sufficient. Each system can exercise discretion as to when it wants to do so (e.g. some may decide to check if strict-equality was presented as infix) and when it doesn't (e.g. some may decide to avoid checks for rabbit).

[NSoiffer]

Unless you write some AT, I don't think any AT will do the kind of checking you want... nor do I think it should for any beast not in core (rabbit, dog, or strict-equality) because (sorry for repeating what has been said many times) the author might not want that. I know you don't like hints, but the simple solution (again, apologies for repeating what has been said many times) is to write it as strict-equality@infix($a,$b) if you want the infix reading.

I have a feeling that David C and I have something in mind and you have something else in mind so that the solutions we are each proposing are based on these different idea. Hence, we are each missing the other's point. Hopefully that will get cleared up at the meeting when there is much higher bandwidth.

[davidcarlisle]

If your point hinges on the intent value being completely unrelated to the underlying presentation,

No, that is not the point at all. intent is to allow authors to guide readings for cases when the required reading can not be inferred from the presentation. Perhaps rabbit is a function defined earlier meaning addition in the prime field $\mathbb{F}_2$ and I wanted 1+2 read as rabbit 3 4 for some didactic purpose.

I liked the middle ground we reached a few comments earlier.

we agreed that the system "should not" over-ride the intent, or as you preferred to say it "should" use the intent. Either way it means that while we can't have a testable requirement, the intention of the spec is that it works as in my example.

My premise is a "partial annotation" for disambiguating a (mathematically meaningful) presentation MathML tree.

Exactly that yes. Partial annotation means that you only need to annotate parts of the tree. Not that the annotations may be ignored in the parts that are annotated.

[dginev]

• an "override" implies a "complete parallel annotation"
• a "supplement" implies a "partial annotation"

To me using the fixity information in the presentation tree "supplements" the intent annotation, rather than "overriding" or "ignoring" it, especially for Open values.

But of course that is impossible to reconcile with a world view where every rabbit(1,2) stands for an author explicitly requesting a @function readout. Not where I am at. The function readout is a "baseline narration" in my view, where AT is allowed to improve upon that level of support, on a case-by-case basis, without being in contradiction to the Intent annotation.

[davidcarlisle]

@NSoiffer

You could also show it with a hint to get the infix reading:

Done, see column 6 (dark green) at

https://mathml-refresh.github.io/intent-lists/intent3.html#IDvectimeshints

column 2 shows it with no intent, column 4 with intent but no hint, column 6 shows mathcat readings with three different hints applied

[davidcarlisle]

section 5.1.2 currently says

When comparing the literal concept name in the intent attribute with entries in the intent lists, the comparison should be ascii-case-insensitive and also normalize "_" (U+00F5) and "." (U+002E) to "-" (U+002D). If the speech hints are not being used and the literal concept name is being read then each of -, _ and . should be read as an inter-word space.

I think we could expand something like.

When comparing the literal concept name in the intent attribute with entries in the intent lists, the comparison should be ASCII case-insensitive and also normalize "_" (U+00F5) and "." (U+002E) to "-" (U+002D). x

The intent processor may only have rules that match an intent name when used with a specific number of arguments. If the intent name is used with an unexpected number of arguments no error should be raised but the system may fall back to its behavior for unknown names and just use the intent name.

If the speech rules are not being used and the literal concept name is being read then each of -, _ and . should be read as an inter-word space.

Apart from the middle paragraph saying the existing ray(x) example should not be an error, I changed "speech hint" to "speech rule". I think "speech hint" (in the sense of the column of the spreadsheet) was not a bad name, but now invites confusion with @ hints "rule" may not be the best word to use...

[davidcarlisle]

Returning to the question asked in the issue description

Is a core intent name defined by just the name? the name + #args? name + something more (isa?)? Is a no-argument form special?

I think a name known to the system (which should include all core names) should be handled for all arities. So mathcat may know ray and have special rules when it has two arguments. However it should not reject 1 or 0 argument uses. If it has no specific rules it should treat it like any other unknown name and read as a literal name.

Which basically is a suggestion that the draft spec is modified as suggested in the previous comment.

[brucemiller]

I think the basic question has been resolved (as @davidcarlisle suggests) that a core concept is treated specially only when it has the expected number of arguments; otherwise it's just an unknown concept. Thus this issue is closable.

[NSoiffer]

Agree.