Are intents needed in intent-core for "self-describing" things?

[NSoiffer]

Currently there are named intents for trig functions like sin and for other things like log/ln.

We don't mark <mn>4</mn> with intent='4' nor do we mark <mi>x</mi> with intent='variable-x'. My feeling is that an element that is self-describing such as <mi>sin</mi>doesn't need a named intent.

To argue the other side slightly, there are less common names that are used such as tg or tang for tangent. In those cases, having a named intent would be useful since these less common names wouldn't need to be known by all programs to mean tangent. I don't know how many trig functions this applies to. I don't think it is true for log/ln.

[davidcarlisle]

I'm not clear what you mean by "needed" here? Presumably(?) <mn intent=4">4</mn> is not wrong, just a default intent made explicit, and presumably(?) the default intent for <mrow><mi>foobar</mi><mo>&af;</mo><mi>x</mi></mrow> would be <mi intent="foobar">foobar</mi>

[dginev]

We've so far at least expressed the group sentiment that:

"Any common K-14 Western education syntax that doesn't have obvious ambiguity could have a default for optimal accessibility, without explicit annotation."

From this perspective, yes we have to have sine in the Core level, so that we can point to that entry and anchor a "default rule" for it. I'm quite convinced unless we make the list of defaults transparently enumerated for everyone to see (and agree on), each AT implementation will have a subtly different set of supposedly-Core defaults.

---

Maybe we should create a few new labels and categorize the different issues around intent. This one appears specific to defaults, which I'd mentally file under intent-defaults, while the other recent issue Neil opened was under intent-values.

---

There are also some assumptions Neil has to make explicit about the "canonical" nature of these fragments he's claiming don't need annotation, since - and I have hundreds of documents exhibiting this - current generators can instead create flat character-level MathML:

  <mi>s</mi><mi>i</mi><mi>n</mi><mi>θ</mi>

for $sin θ$, and the equally bad

<mi>s</mi><mi>i</mi><mi>n</mi><mi>h</mi><mi>θ</mi>

for $sinh θ$. Take a look at equations 1-5 on page 5 of astro-ph/0410182, to seed one example.

So, to get to a shared practical understanding of how the intent mechanism operates, maybe we also need a dedicated list of the "requirements on presentation markup" on which the defaulting mechanism is to operate over.

[NSoiffer]

This was discussed at the WG today. I raised the question of why we need "plus", "greater-than", etc., since they are self-describing when used on mo. There are thousands of such symbols, and these include script variants and alphabetic variants.

I believe that there was a majority feeling that a separate table for these names would be good. There is still much to be decided such as how one decides what goes where.

My suggestion (not brought up in the meeting): any core intent that would be typically used on a leaf tag (mi, mo, mn, mtext) would be in this separate table as these are typically self-describing. A likely exception to this would be some symbols such as ℝ which can have very different spoken forms from their underlying character. Not exceptions would be things like "+" and "α" where the spoken form only differs in brevity from their Unicode description.

Note: I feel that "plus" as a nary-operator does not belong in the core names because it adds nothing to how an mrow would be spoken. One could of course use "plus" on an mrow, but its use should be consider an "open" name and hence pronounced in some default manner.

[NSoiffer]

WG agreed don't need to be in core. But it would be useful to have table to remind AT that they need to deal with sin, csc, etc.