What's in a name (also "reference", etc)?

[NSoiffer]

Regardless of whether we go with the template syntax or the function syntax, there is an ongoing discussion about what characters are allowed in a name. This issue is here to focus on that topic and pulls in a thread from #446 which starts at this comment.

Note: the MathML full meeting today agreed that we should pull out number as a specific terminal that uses . as the decimal separator, so that is not in question . The discussion is focused on concept-or-literal, reference, property, literal, and name (depending on the version of the spec).

To maybe summarize some comments:

• being freer with what is allowed means less errors that can be made
• for at least literals, speech engines won't know what to do with non letters/digits (e.g., U+2345 "⍅") so results could be unexpected
• reference names should be like an xml:id (without the restriction of them being unique)
• Unicode defines a regexp for "identifier names"
• any of the characters allowed (#, @, etc) are characters that can't be used for some future extension of the grammar

[brucemiller]

With regard to your second point, are

<mo>⍅</mo>
<mo intent="⍅">x</mo>

expected to be treated differently by AT? (Offhand, I'd expect the same treatment)

[brucemiller]

While I prefer permissive to restrictive, I agree that it reserving some characters for future use is a good idea. Candidates might include the categories: keyboard-top-row, punctuation, fences, quotes. To the extent those categories make sense and to the extent that they wouldn't reasonably be needed in normal mathematical phrases.

[dginev]

I'd split the issue into two sub-components:

1. property and concept are the two caregories that need name-specific considerations (:system-of-equations, binomial-coefficient). I have always been fond of dash-separated names for that as in

   IntentName  := Letter (Letter | '-' Letter)*

2. The other categories Neil enumerated may be closer to system data than natural names (such as xml:id or number formats). Bruce pointed out that reference/arg values fit closer to ids than names.

[davidfarmer]

<mo>⍅</mo> <mo intent="⍅">x</mo> expected to be treated differently by AT? (Offhand, I'd expect the same treatment)

On the call I attempted to get clarification on that point. My interpretation of the answer is that, unless there is a specific indication that AT is allowed to ignore the intent, it will always use the intent and ignore the actual content. A similar example which is likely to arise is <mo>×</mo> <mo intent="x">*</mo> Is intent="×" different than intent="times"? Maybe the first is preferred, for internationalization.

[davidcarlisle]

for at least literals, speech engines won't know what to do with non letters/digits (e.g., U+2345 "⍅") so results could be unexpected

I thought we could assume (even if it is not currently true) that core math blocks such as Mathematical Operators 22xx and perhaps Miscellaneous Technical 23xx would be "self voicing" with AT choosing a reading based on, but not necessarily equal to, the unicode name. Otherwise more or less every <mo> is going to need an intent to be read at all.

[dginev]

On the intent="⍅", do we know if the Unicode situation is expected/desired to be dramatically improved in the broader AT engines @NSoiffer ? I remembered a 2019 example that illustrated rather nicely how rocky things can get text+audio here.

Edit: Specifically, the example appears to me as a good reason to avoid "unusual" uses of Unicode in places where one might expect letters in names.

[davidfarmer]

Yes, sorry: I meant the times symbol. I thought it was by did not see that I copied the wrong character.

…

On Fri, 17 Mar 2023, David Carlisle wrote: Is intent="x" different than intent="times"? Did you mean to use an x there, not × ? as written, they are completely unrelated, the first would force a reading of "ex" the second is presumbly a core function so will be read however the system reads times. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because youcommented.[AABTULACJ4RBR4RZNHJRJ2TW4RXOJA5CNFSM6AAAAAAV5ZBZN2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSX3I4RC. gif] Message ID: ***@***.***>

[davidcarlisle]

Edit: Specifically, the example appears to me as a good reason to avoid "unusual" uses of Unicode in places where one might expect letters in names.

It's one thing to say users should avoid exotic characters and not expect <mo>&#x1FACF;</mo> (added Unicode 15, last year) gets read as "donkey", but another for the grammar to ban them.

We can not simultaneously say that that default reading of <mo> is its content, but that we can not use most characters that are used in mo as string templates because they can not be read.

Note this discussion relates mostly to the template variants. In the functional variant in the current spec we never so far allowed such characters in concept-or-literal. Although that does complicate slightly the "implied intent" for <mo>⍅</mo> as it can't simply be the content and has to be something like intent="leftwards-vane" or intent="are-you-really-using-APL"

[brucemiller]

Let me try this more explicitly: MathML's token elements can take pretty much any Unicode as content; usually a letter or math operator, but possibly an emoji or anything. I assume that an AT will produce some speech for MathML with funny characters but without intent, eg. <mo>⍅</mo>. I don't particularly care what speech.

Wouldn't we expect the same speech for <mo intent="⍅">x</mo>, whatever it is? If so, I don't see why we need to restrict it.

[dginev]

Wouldn't we expect the same speech for x, whatever it is? If so, I don't see why we need to restrict it.

As long as we don't call these concepts, yes. They appear to fall closer to the "data" realm, i.e. "character literals".

[davidcarlisle]

As long as we don't call these concepts, yes. They appear to fall closer to the "data" realm, i.e. "character literals".

we don't have any currently open grammar proposal with a "concept" clause.

The functional version from current spec has concept-or-literal which is NCNAME so does not allow math symbols (which makes it work better as a concept than a literal) or 446 has various literal in various versions allowing or no allowing symbols. Neither of the mathcat current implementations allow symbols in intent

for 446 or the current spec I'd allow more or less anything in the grammar but restrict core and open concept lists to ncname so if you use symbols (just as if you use _) you know it is a literal.

[brucemiller]

We probably will to only enter concepts that are restricted to NCNAME into a Core dictionary, or even the Open dictionary. But (in the current spec) anything not recognized as a concept is effectively a literal. And since the AT is going to have to deal with funny characters anyway (those in token content that aren't overridden by intent), I don't see much benefit in forbidding them from concept-or-literal (in its various forms).

(I see that, while I was typing, @davidcarlisle has edited his comment to say essentially the same thing, I think)

[dginev]

Not sure why we have turned legalistic, but I assume the "current spec" being referred to is at:
https://w3c.github.io/mathml/#mixing_intent_grammar

⍅ and other characters that don't conform to NCName are not grammatical in that proposal. In which case they would be delegated to some (I think currently unspecified?) "error recovery" procedure.

I have mentioned this before, but - in my opinion - the Intent syntax does not need to cover the full realm of the allowed text content of MathML's token nodes, as it has the opportunity to be a partial annotation, rather than a complete replacement for the presentation tree.

All of these are workable:

<mo>⍅</mo>
<mo intent="leftwards-vane">⍅</mo>
<mo intent="_bar_arrow_pointing_left">⍅</mo>

but using the Unicode character directly in the intent string has to be teased apart as a "character literal" / "character data" case that is voicing as per the Unicode character name (I think also referred to as "self-voicing").

If the group insists the full Unicode spec should be grammatical, that is fine by me - but let us try to separate it from concept, property and the underscore speech literals. Maybe character literals or character data fit better. I am implying adding one more case with the same kind of treatment that the current grammar gives to number.