Need to add user selection attributes

[MurrayIII]

Some assistive technology (AT) programs use MathML or OMML as conduits for generating math speech and braille from math-enabled apps. In addition, they would like to use these formats for editing math text as well as speaking it and displaying it on refreshable braille displays. To this end, the formats need selection attributes that identify where the user selection is or should be within the MathML or OMML. These selection attributes are intended for accessibility purposes; MathML/OMML in copy, paste, and files ordinarily wouldn’t contain such attributes.

The post MathML and OMML User Selection Attributes describes this is some detail. The applet UnicodeMathML implements the selection attributes with slightly different names: "selanchor" and "selfocus", which correspond to the selection object in the browser DOM. If the selection is degenerate, i.e., an insertion point, only the selanchor attribute is written.

[dginev]

How does this need relate to the existing "W3C Web Annotation Data Model", specification, concretely its Selectors ?

https://www.w3.org/TR/annotation-model/#selectors

[davidcarlisle]

As there can (typically) only be one selection active in a document it seems slighty strained to add this as an attribute, as including MathML with such an attribute in a document is problematic, does the default selection move to that math, what if two mathml fragments have such an attribute?

For a specific editing app that is maintaining its internal state anyway, so only has one active selection at all times, and only exposing this in transient mathml for passing to a braille display or whatever, it's not an issue.

If there is a way to specify a point in the MathML, the focus can be passed separately referencing those points without eeding to constantly add and remove explicit attributes.

As @dginev indicated w3c selectors could do this, or xpath, or @NSoiffer commented on the call that in a similar context MathCAT arranges that every element has an id so you can select any point (via id and character offset) without needing to modify the MathML, so without issues involving storing spurious selection ranges in mathml saved between sessions.

That said, I can see that for a specific editing application as demonstrated with UnicodeMathML It's convenient just to mark the selection without having to generate some path selection to identify that point, and normally its just ephemeral data passed on to the braille display or similar. So I don't think the attribute use there is unreasonable, but I think (at least at the current state of the standardisation process for mathML) this should be seen as application-specific attributes. they could use data-xxx names to be explicitly extension attributes but ifthe MathMl is never stored using these attributes the MathML using them will never be validated anyway so even without the data- prefix I think they are fine.