The first MathML WG Core meeting will be on Monday, 28 June at 10am
Pacific, 1pm Eastern, 7pm Central European. This uses *a different zoom
invite* than the general MathML meeting. W3C members can find out zoom
details by reading the email that Bert sent to member-math
<https://lists.w3.org/Archives/Member/member-math/2021Jun/0008.html>. I
strongly suggest adding the details to your calendar if you plan to
regularly attend.

At the moment, the meetings are scheduled for the last Monday of the month
at the times indicated above. This choice is based on what the times the
MathML Refresh CG voted on. However, if these times don't work for people
interested in the core discussions, please send me email with your
preferred day/time. I will set up a doodle poll after the first meeting
with the current day/time and other suggestions.

Note: the MathML Core meetings are *not* meant for general MathML
discussions. Core meetings are meant to be tightly focused on what is the
minimal amount of MathML support needed by browsers that maintains
compatibility with full MathML and how that can be achieved. Please join if
that is something in which you are interested.

Many thanks, David.   Now working through this to catch up!

On Fri, Jun 11, 2021 at 4:04 PM David Carlisle <davidc@nag.co.uk> wrote:

>
> Stephen asked during the call for pointers to the CG's discussions on
> the intent attribute  to come up to speed for the Working Group
> discussions on the same thing,
>
> The CG GitHub (mathml-refresh)  is still operational and has several
> related discussion papers at
>
> https://mathml-refresh.github.io/discussion-papers/
>
>
> 4 of those are proposals around variants of the idea of having an
> intent=... attribute for a lighter weight version of annotating
> presentation mathml than the "parallel markup" mapping to Content MathML
> we had in MathML3, and "Intent Annotation Comparison" is a big
> comparison table of several of the variants.
>
> The minutes of the meetings are also public but the discussion papers
> are probably a better place to start...
>
> David
>
>
> *Disclaimer*
>
> The Numerical Algorithms Group Ltd is a company registered in England and
> Wales with company number 1249803. The registered office is: 30 St. Giles,
> Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice
> <https://www.nag.co.uk/content/privacy-notice> for information on how we
> process personal data and for details of how to stop or limit
> communications from us.
>
> This e-mail has been scanned for all viruses and malware, and may have
> been automatically archived by Mimecast Ltd, an innovator in Software as a
> Service (SaaS) for business.
>

Hi Neil, all,

To sprinkle in some data, here is a very brief sampling of use of the
% sign in arXiv:
https://hackmd.io/@dginev/HJYj-6Lod

I have a lot more comments on the "operator dictionary" details, but
I'm afraid every next email I send reduces the chance of others
replying :-) We can start a new thread for the technical details
there, or just discuss tomorrow.

Greetings,
Deyan

On Wed, Jun 16, 2021 at 11:12 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
> I'll start with a general "you are correct, as always" comment and then get into the weeds.
>
> I, with help from David C, have been working on the operator dictionary for the last 1.5 years, although I haven't done anything on it for a year. However, it is substantially updated from MathML 3. David has moved the latest and greatest version to the w3c github site. There you will see that '%' comes in both an infix and postfix version. I'd like to say that I spotted that change on my own, but truthfully, I added the prefix version based on your observation. The missing postfix entry is important not just for parsing/my proposed canonicalization, it is also important so that it is displayed with the proper amount of spacing -- definitely a good catch.
>
> I will reiterate what I said a long while back, it would be really helpful to have other people look at the operator dictionary for omissions, errors, and needed deletions (many things have been removed from the version in MathML 3). Looking at github history, I see some issues (e.g., ellipsis removal) were brought to the group. I spent a lot of time looking at usage of Unicode characters that act as operators and did my best to understand how they group relative to other operators (for some, I couldn't find any paper that used them), but I'm sure there are issues. I'm particularly dubious that I have many of the postfix entries correct relative to how they should group with prefix and infix operators. E.g., should  √  bind more tightly than "!" or "%"?  I'm a bit more confident about the relative priorities of the infix operators. My focus was on the more obscure Unicode operators; perhaps I need to take a pass at more common characters since '%' was clearly overlooked.
>
> With the update, "0.15 = 15%" will parse as one expects. The same can be said for "15% x = 10", but only if there is an invisible times between the "%" and the "x". If it is there, then the postfix interpretation of "%" should be used. If it is not there, then the infix interpretation should be used (unless there is an attr specifying the "form"). Given what MathML generators do today, this is definitely problematic. The only solution I know of would be to drop the infix "%", which as you noted is used in computer languages. However, it is also used for calculator-like notations. I'm dubious we can get any stats on MathML usage of '%', but maybe you can get some about arXiv usage (although that would likely be skewed away from lower grade math where '%' for "mod" is more likely).
>
> As for default intents, I agree with you that they should only be done for level one items. I'm a little less sure about doing that only when there is a very clear preference one way or the other. Perhaps with the addition of a subject attr value, it's default becomes clear but in the absence of that context, it is not clear. In any case, getting real world data is invaluable to validate any idea.
>
> Thanks for your comments and I strongly request others to get involved also.
>
>     Neil
>
>
> On Mon, Jun 14, 2021 at 5:45 AM Deyan Ginev <deyan.ginev@gmail.com> wrote:
>>
>> Hi Neil, all,
>>
>> I assume by "operator dictionary" you're referring to:
>> https://www.w3.org/TR/MathML3/appendixc.html
>>
>> These indeed induce one grammar for math syntax. It is hard to
>> understand *which* grammar that is. Is there some testbed of supported
>> expressions/notations that it is expected to cover? Math grammars are
>> quite hard to develop and maintain, so I would be a bit anxious of
>> adopting one "officially" without a good plan.
>>
>> To draw a random example from the operator dictionary, I saw % is
>> marked as infix with priority 640. But in the expression "15% x = 10",
>> it is meant to be read "fifteen percent of x equals to ten". And not
>> "fifteen modulo x equals ten", as in programming languages, which may
>> have been the reason behind choosing the infix form. Consider also the
>> standalone "0.15 = 15%" and "15% = 150‰", to illustrate it's really
>> postfix when intending "percent" - which is the usual meaning in K-14
>> materials.
>>
>> So rather than it being a silver bullet, I think the operator
>> dictionary may need some vetting and reconsideration. The way I see
>> it, we would also have a much easier time if we do not standardize an
>> entire grammar, just because that's the highest difficulty task we can
>> set for ourselves. It is, in my experience, much harder to get right
>> than assembling long lists of concept names and notation forms.
>>
>> If I read you correctly, you agree that whichever way we enrich/infer
>> the mrows, we need to decide on a list of intents that will be
>> expected as default remediation. I think we have some clear common
>> agreement here, also with Sam's document that started fleshing these
>> out as examples
>> (https://mathml-refresh.github.io/discussion-papers/intent). For
>> example, if the exclamation mark (!) is intended to be remediated as
>> the "factorial" by default, that has to be made explicit, as well as
>> the notation where that intent is activated.
>>
>> On my end, I would offer we (try to) create something new that is very
>> narrowly described and scoped. Say by listing all mathematical
>> notations we have encountered, and then cherry-picking (and creating
>> tests for) notations we want recognized by default, from a pragmatic
>> mathematical standpoint. One working definition may be "standard
>> notations in K-14 education that have no mutual overlap". And my
>> instinct is that if we end up with very small and usable defaults,
>> they will be easier to both test against and apply in practice. But we
>> also need to develop them to a degree where the defaults meet "natural
>> expectation", which is a tension in the opposite direction of
>> simplicity. To achieve all of that, I resonated quite strongly with
>> Brian's suggestion during our last meeting - we ought to do a couple
>> of iterations of concept validation coding and demos and develop a
>> test suite. There's a real risk of making a readout worse if the
>> defaults are more often wrong than correct, and our best bet to avoid
>> that is actually check how they work on the materials we intend them
>> for, before we release them to the world.
>>
>> I also welcome more discussion, thanks for starting one!
>>
>> Greetings,
>> Deyan
>>
>>
>>
>> Deyan
>>
>> On Sun, Jun 13, 2021 at 6:09 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>> >
>> > I'm writing this email to get some discussion going outside of the meetings. Deyan is also working on this and is working on his own reasoning on this topic. The topic we have started to discuss in the meetings is MathML structure and how that might or might not work well with intents, especially for defaults.
>> >
>> > First off, if an intent is given, there is no ambiguity for the part of the structure given by the intent and the current proposal(s) make no requirements on MathML structure other than it be valid MathML. That doesn't mean that other parts of the structure (e.g, the arg="..." parts) are unambiguous. But it does mean that any software trying to come up with a "meaning" for speech (or otherwise) should not break a stated intent.
>> >
>> > The question we have begun to explore is what can we state about a default in the absence of explicit intents.
>> >
>> > Why do we care about defaults?
>> > To me, a big advantage of using intent over some alternatives like parallel markup is that using "intent" can support progressive enhancement. If we come up with some defaults, then authors only need to use 'intent' when the defaults aren't correct. So if we can figure out reasonable defaults, we can minimize the content that needs work/remediation so that it can be spoken unambiguously. Additionally, rather than require MathML generators change to use parallel markup or some other output, current output remains valid although it may not unambiguously represent author intent. The extent to which it can be disambiguated is tied to how much context is used to make the defaults. It will never be perfect without author's helping out though.
>> >
>> > My Two Cents
>> > Since this message is to provoke discussion and is not meant to be a fleshed out proposal (it's very long as it is), I'll just state my current thoughts and add a little rationale to them, but not get into the details....
>> >
>> > My feeling is that defaults should be based on a canonical parse of the MathML expression that is defined by the operator dictionary and as overridden by any attrs on the <mo> elements. This does not mean that MathML that uses "flat" mrows doesn't have a default, it just means that when parsed, it will have whatever defaults we end up giving. As an example, if an mrow has "a", "+", "5", "!" as direct children, a default for factorial would be used because the canonical form given by the operator dictionary would group the "5" and "!" in a single mrow and that would match a factorial default.
>> >
>> > By mapping expressions to a canonical parse, we can write defaults in a relatively simple manner and not require MathML writers to generate a specific representation (something Deyan's post shows doesn't happen now). It doesn't even require software that wants to apply a default to do the parse, although I think supporting all the various ways of representing a default a default would be hard without parsing. Currently the more sophisticated speech renderers do parse the input to infer intent, so using defaults fit naturally into those speech renderers.
>> >
>> > One thing the operator dictionary does not solve is operand/operand conflict (horizontal juxtaposition of operands). Typically these are either meant to be function call or multiplication (or more precisely, a multiplication-like operation), but it could be an implied plus for mixed fractions or an implied comma in something like M_{11}. How this is specified will determine a canonical parse for those cases.
>> >
>> > Another area of concern is mixing n-ary operators. We've discussed how +/- might parse, along with how a series of relational operators should be given/thought about. I think they should be flat, but reasonable people differ. Clearly something that needs further discussion before defaults can be written for them.
>> >
>> > A final area of concern is matching open/close fences. The operator dictionary has all of the fences with the same priority and I think it makes sense that a "[" can match against a ")" to form an mrow, but there might be some subtle issues that make this a poor default. Note that the French interval notation "]0, (" will not form the intended mrow structure without the author overriding the "form" for the brackets; if overridden it will parse intuitively and a default could be written for that notation.
>> >
>> > Hopefully some food for thought and that this will provoke some discussion outside of the meetings.
>> >
>> >     Neil
>> >
>> >
>> >

I'll start with a general "you are correct, as always" comment and then get
into the weeds.

I, with help from David C, have been working on the operator dictionary for
the last 1.5 years, although I haven't done anything on it for a year.
However, it is substantially updated from MathML 3. David has moved the
latest and greatest version to the w3c github site
<https://w3c.github.io/xml-entities/opdict.html>. There you will see that
'%' comes in both an infix and postfix version. I'd like to say that I
spotted that change on my own, but truthfully, I added the prefix version
based on your observation. The missing postfix entry is important not just
for parsing/my proposed canonicalization, it is also important so that it
is displayed with the proper amount of spacing -- definitely a good catch.

I will reiterate what I said a long while back, it would be *really *helpful
to have other people look at the operator dictionary for omissions, errors,
and needed deletions (many things have been removed from the version in
MathML 3). Looking at github history, I see some issues (e.g., ellipsis
removal) were brought to the group. I spent a lot of time looking at usage
of Unicode characters that act as operators and did my best to understand
how they group relative to other operators (for some, I couldn't find any
paper that used them), but I'm sure there are issues. I'm particularly
dubious that I have many of the postfix entries correct relative to how
they should group with prefix and infix operators. E.g., should  √  bind
more tightly than "!" or "%"?  I'm a bit more confident about the relative
priorities of the infix operators. My focus was on the more obscure Unicode
operators; perhaps I need to take a pass at more common characters since
'%' was clearly overlooked.

With the update, "0.15 = 15%" will parse as one expects. The same can be
said for "15% x = 10", but only if there is an invisible times between the
"%" and the "x". If it is there, then the postfix interpretation of "%"
should be used. If it is not there, then the infix interpretation should be
used (unless there is an attr specifying the "form"). Given what MathML
generators do today, this is definitely problematic. The only solution I
know of would be to drop the infix "%", which as you noted is used in
computer languages. However, it is also used for calculator-like notations.
I'm dubious we can get any stats on MathML usage of '%', but maybe you can
get some about arXiv usage (although that would likely be skewed away from
lower grade math where '%' for "mod" is more likely).

As for default intents, I agree with you that they should only be done for
level one items. I'm a little less sure about doing that only when there is
a very clear preference one way or the other. Perhaps with the addition of
a subject attr value, it's default becomes clear but in the absence of that
context, it is not clear. In any case, getting real world data is
invaluable to validate any idea.

Thanks for your comments and I strongly request others to get involved also.

    Neil


On Mon, Jun 14, 2021 at 5:45 AM Deyan Ginev <deyan.ginev@gmail.com> wrote:

> Hi Neil, all,
>
> I assume by "operator dictionary" you're referring to:
> https://www.w3.org/TR/MathML3/appendixc.html
>
> These indeed induce one grammar for math syntax. It is hard to
> understand *which* grammar that is. Is there some testbed of supported
> expressions/notations that it is expected to cover? Math grammars are
> quite hard to develop and maintain, so I would be a bit anxious of
> adopting one "officially" without a good plan.
>
> To draw a random example from the operator dictionary, I saw % is
> marked as infix with priority 640. But in the expression "15% x = 10",
> it is meant to be read "fifteen percent of x equals to ten". And not
> "fifteen modulo x equals ten", as in programming languages, which may
> have been the reason behind choosing the infix form. Consider also the
> standalone "0.15 = 15%" and "15% = 150‰", to illustrate it's really
> postfix when intending "percent" - which is the usual meaning in K-14
> materials.
>
> So rather than it being a silver bullet, I think the operator
> dictionary may need some vetting and reconsideration. The way I see
> it, we would also have a much easier time if we do not standardize an
> entire grammar, just because that's the highest difficulty task we can
> set for ourselves. It is, in my experience, much harder to get right
> than assembling long lists of concept names and notation forms.
>
> If I read you correctly, you agree that whichever way we enrich/infer
> the mrows, we need to decide on a list of intents that will be
> expected as default remediation. I think we have some clear common
> agreement here, also with Sam's document that started fleshing these
> out as examples
> (https://mathml-refresh.github.io/discussion-papers/intent). For
> example, if the exclamation mark (!) is intended to be remediated as
> the "factorial" by default, that has to be made explicit, as well as
> the notation where that intent is activated.
>
> On my end, I would offer we (try to) create something new that is very
> narrowly described and scoped. Say by listing all mathematical
> notations we have encountered, and then cherry-picking (and creating
> tests for) notations we want recognized by default, from a pragmatic
> mathematical standpoint. One working definition may be "standard
> notations in K-14 education that have no mutual overlap". And my
> instinct is that if we end up with very small and usable defaults,
> they will be easier to both test against and apply in practice. But we
> also need to develop them to a degree where the defaults meet "natural
> expectation", which is a tension in the opposite direction of
> simplicity. To achieve all of that, I resonated quite strongly with
> Brian's suggestion during our last meeting - we ought to do a couple
> of iterations of concept validation coding and demos and develop a
> test suite. There's a real risk of making a readout worse if the
> defaults are more often wrong than correct, and our best bet to avoid
> that is actually check how they work on the materials we intend them
> for, before we release them to the world.
>
> I also welcome more discussion, thanks for starting one!
>
> Greetings,
> Deyan
>
>
>
> Deyan
>
> On Sun, Jun 13, 2021 at 6:09 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
> >
> > I'm writing this email to get some discussion going outside of the
> meetings. Deyan is also working on this and is working on his own reasoning
> on this topic. The topic we have started to discuss in the meetings is
> MathML structure and how that might or might not work well with intents,
> especially for defaults.
> >
> > First off, if an intent is given, there is no ambiguity for the part of
> the structure given by the intent and the current proposal(s) make no
> requirements on MathML structure other than it be valid MathML. That
> doesn't mean that other parts of the structure (e.g, the arg="..." parts)
> are unambiguous. But it does mean that any software trying to come up with
> a "meaning" for speech (or otherwise) should not break a stated intent.
> >
> > The question we have begun to explore is what can we state about a
> default in the absence of explicit intents.
> >
> > Why do we care about defaults?
> > To me, a big advantage of using intent over some alternatives like
> parallel markup is that using "intent" can support progressive enhancement.
> If we come up with some defaults, then authors only need to use 'intent'
> when the defaults aren't correct. So if we can figure out reasonable
> defaults, we can minimize the content that needs work/remediation so that
> it can be spoken unambiguously. Additionally, rather than require MathML
> generators change to use parallel markup or some other output, current
> output remains valid although it may not unambiguously represent author
> intent. The extent to which it can be disambiguated is tied to how much
> context is used to make the defaults. It will never be perfect without
> author's helping out though.
> >
> > My Two Cents
> > Since this message is to provoke discussion and is not meant to be a
> fleshed out proposal (it's very long as it is), I'll just state my current
> thoughts and add a little rationale to them, but not get into the
> details....
> >
> > My feeling is that defaults should be based on a canonical parse of the
> MathML expression that is defined by the operator dictionary and as
> overridden by any attrs on the <mo> elements. This does not mean that
> MathML that uses "flat" mrows doesn't have a default, it just means that
> when parsed, it will have whatever defaults we end up giving. As an
> example, if an mrow has "a", "+", "5", "!" as direct children, a default
> for factorial would be used because the canonical form given by the
> operator dictionary would group the "5" and "!" in a single mrow and that
> would match a factorial default.
> >
> > By mapping expressions to a canonical parse, we can write defaults in a
> relatively simple manner and not require MathML writers to generate a
> specific representation (something Deyan's post shows doesn't happen now).
> It doesn't even require software that wants to apply a default to do the
> parse, although I think supporting all the various ways of representing a
> default a default would be hard without parsing. Currently the more
> sophisticated speech renderers do parse the input to infer intent, so using
> defaults fit naturally into those speech renderers.
> >
> > One thing the operator dictionary does not solve is operand/operand
> conflict (horizontal juxtaposition of operands). Typically these are either
> meant to be function call or multiplication (or more precisely, a
> multiplication-like operation), but it could be an implied plus for mixed
> fractions or an implied comma in something like M_{11}. How this is
> specified will determine a canonical parse for those cases.
> >
> > Another area of concern is mixing n-ary operators. We've discussed how
> +/- might parse, along with how a series of relational operators should be
> given/thought about. I think they should be flat, but reasonable people
> differ. Clearly something that needs further discussion before defaults can
> be written for them.
> >
> > A final area of concern is matching open/close fences. The operator
> dictionary has all of the fences with the same priority and I think it
> makes sense that a "[" can match against a ")" to form an mrow, but there
> might be some subtle issues that make this a poor default. Note that the
> French interval notation "]0, (" will not form the intended mrow structure
> without the author overriding the "form" for the brackets; if overridden it
> will parse intuitively and a default could be written for that notation.
> >
> > Hopefully some food for thought and that this will provoke some
> discussion outside of the meetings.
> >
> >     Neil
> >
> >
> >
>

 We meet on Thursday, 10am Pacific, 1pm Eastern, 7pm Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list for the group. The regulars for this group should have the meeting
details in their calendars.

Agenda:
1. Announcements/updates
    a) reminder to link you github account to your w3c account as per
Bert's email
    b) progress moving repos

2. Core spec -> Draft Spec
    a) progress
    b) issues from anyone?

3. Intent discussion -- defaults semantics:
    a) what defaults do we want?
    b) how do these interact with multiple ways of writing mrows/should
operator dictionary be used for a canonical form?
    c) real world data?
    d) tests for implementations?

On 14/06/2021 13:45, Deyan Ginev wrote:
> Hi Neil, all,
>
> I assume by "operator dictionary" you're referring to:
> https://www.w3.org/TR/MathML3/appendixc.html


Note that the operator dictionary (with modified styling and content) is 
in the draft spec for mathml-core at


https://w3c.github.io/mathml-core/#operator-dictionary


The simplified version in core only has the parts needed for a browser 
rendering so drops the priority and other attributes (although the data 
is still in the unicode.xml source)


David

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
30 St. Giles, Oxford, OX1 3LE, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. 

On 14/06/2021 13:45, Deyan Ginev wrote:
> Hi Neil, all,
>
> I assume by "operator dictionary" you're referring to:
> https://www.w3.org/TR/MathML3/appendixc.html
>
> These indeed induce one grammar for math syntax. It is hard to
> understand *which* grammar that is. Is there some testbed of supported
> expressions/notations that it is expected to cover? Math grammars are
> quite hard to develop and maintain, so I would be a bit anxious of
> adopting one "officially" without a good plan.
>
> To draw a random example from the operator dictionary, I saw % is
> marked as infix with priority 640. But in the expression "15% x = 10",
> it is meant to be read "fifteen percent of x equals to ten". And not
> "fifteen modulo x equals ten", as in programming languages, which may
> have been the reason behind choosing the infix form. Consider also the
> standalone "0.15 = 15%" and "15% = 150‰", to illustrate it's really
> postfix when intending "percent" - which is the usual meaning in K-14
> materials.


Note that the form attribute (the green columns) there is part of the 
_input matching_ so that is telling you if you have an infix % then it 
should get 3mu spacing either side.

If the % is not in infix position then it tells you nothing so "0.15 = 
15%" for example. Also if  15% x =10 were marked up with enough mrows so 
<mrow>15%</mrow>... the % would end up in postfix position and get no 
additional space.  Of course the issue that generators don't always add 
enough mrows complicates things, but I wanted to clarify that the 
operator dictionary entry is specifying how to space an infix % not 
saying that % should be infix.



>
> So rather than it being a silver bullet, I think the operator
> dictionary may need some vetting and reconsideration.


Oh sure yes every time we look at that we change something

>   The way I see
> it, we would also have a much easier time if we do not standardize an
> entire grammar, just because that's the highest difficulty task we can
> set for ourselves. It is, in my experience, much harder to get right
> than assembling long lists of concept names and notation forms.
>
> If I read you correctly, you agree that whichever way we enrich/infer
> the mrows, we need to decide on a list of intents that will be
> expected as default remediation. I think we have some clear common
> agreement here, also with Sam's document that started fleshing these
> out as examples
> (https://mathml-refresh.github.io/discussion-papers/intent). For
> example, if the exclamation mark (!) is intended to be remediated as
> the "factorial" by default, that has to be made explicit, as well as
> the notation where that intent is activated.



Yes the operator dictionary lists ! as postfix with a high priority 
which formally only tells you what to do if it is last in its mrow.  You 
also want to infer that ! is postfix even if there are no mrows and you 
just have 3!+2!=8 but the operator dictionary in mathml3 doesn't really 
tell you that, although the priorities together with the grouping rule at

https://www.w3.org/TR/MathML3/chapter3.html#id.3.3.1.3.2


does tell you that the generator should have added more mrow and not 
left ! and + at the same level.

>
> On my end, I would offer we (try to) create something new that is very
> narrowly described and scoped. Say by listing all mathematical
> notations we have encountered, and then cherry-picking (and creating
> tests for) notations we want recognized by default, from a pragmatic
> mathematical standpoint. One working definition may be "standard
> notations in K-14 education that have no mutual overlap". And my
> instinct is that if we end up with very small and usable defaults,
> they will be easier to both test against and apply in practice. But we
> also need to develop them to a degree where the defaults meet "natural
> expectation", which is a tension in the opposite direction of
> simplicity. To achieve all of that, I resonated quite strongly with
> Brian's suggestion during our last meeting - we ought to do a couple
> of iterations of concept validation coding and demos and develop a
> test suite. There's a real risk of making a readout worse if the
> defaults are more often wrong than correct, and our best bet to avoid
> that is actually check how they work on the materials we intend them
> for, before we release them to the world.


This sounds like a good plan....

>
> I also welcome more discussion, thanks for starting one!
>
> Greetings,
> Deyan
>
>
>
> Deyan
>
> On Sun, Jun 13, 2021 at 6:09 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>> I'm writing this email to get some discussion going outside of the meetings. Deyan is also working on this and is working on his own reasoning on this topic. The topic we have started to discuss in the meetings is MathML structure and how that might or might not work well with intents, especially for defaults.
>>
>> First off, if an intent is given, there is no ambiguity for the part of the structure given by the intent and the current proposal(s) make no requirements on MathML structure other than it be valid MathML. That doesn't mean that other parts of the structure (e.g, the arg="..." parts) are unambiguous. But it does mean that any software trying to come up with a "meaning" for speech (or otherwise) should not break a stated intent.
>>
>> The question we have begun to explore is what can we state about a default in the absence of explicit intents.
>>
>> Why do we care about defaults?
>> To me, a big advantage of using intent over some alternatives like parallel markup is that using "intent" can support progressive enhancement. If we come up with some defaults, then authors only need to use 'intent' when the defaults aren't correct. So if we can figure out reasonable defaults, we can minimize the content that needs work/remediation so that it can be spoken unambiguously. Additionally, rather than require MathML generators change to use parallel markup or some other output, current output remains valid although it may not unambiguously represent author intent. The extent to which it can be disambiguated is tied to how much context is used to make the defaults. It will never be perfect without author's helping out though.
>>
>> My Two Cents
>> Since this message is to provoke discussion and is not meant to be a fleshed out proposal (it's very long as it is), I'll just state my current thoughts and add a little rationale to them, but not get into the details....
>>
>> My feeling is that defaults should be based on a canonical parse of the MathML expression that is defined by the operator dictionary and as overridden by any attrs on the <mo> elements. This does not mean that MathML that uses "flat" mrows doesn't have a default, it just means that when parsed, it will have whatever defaults we end up giving. As an example, if an mrow has "a", "+", "5", "!" as direct children, a default for factorial would be used because the canonical form given by the operator dictionary would group the "5" and "!" in a single mrow and that would match a factorial default.
>>
>> By mapping expressions to a canonical parse, we can write defaults in a relatively simple manner and not require MathML writers to generate a specific representation (something Deyan's post shows doesn't happen now). It doesn't even require software that wants to apply a default to do the parse, although I think supporting all the various ways of representing a default a default would be hard without parsing. Currently the more sophisticated speech renderers do parse the input to infer intent, so using defaults fit naturally into those speech renderers.
>>
>> One thing the operator dictionary does not solve is operand/operand conflict (horizontal juxtaposition of operands). Typically these are either meant to be function call or multiplication (or more precisely, a multiplication-like operation), but it could be an implied plus for mixed fractions or an implied comma in something like M_{11}. How this is specified will determine a canonical parse for those cases.
>>
>> Another area of concern is mixing n-ary operators. We've discussed how +/- might parse, along with how a series of relational operators should be given/thought about. I think they should be flat, but reasonable people differ. Clearly something that needs further discussion before defaults can be written for them.
>>
>> A final area of concern is matching open/close fences. The operator dictionary has all of the fences with the same priority and I think it makes sense that a "[" can match against a ")" to form an mrow, but there might be some subtle issues that make this a poor default. Note that the French interval notation "]0, (" will not form the intended mrow structure without the author overriding the "form" for the brackets; if overridden it will parse intuitively and a default could be written for that notation.
>>
>> Hopefully some food for thought and that this will provoke some discussion outside of the meetings.
>>
>>      Neil
>>
>>
>>

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
30 St. Giles, Oxford, OX1 3LE, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. 

Issues
------
* w3c/html-aam (+0/-0/💬2)
  1 issues received 2 new comments:
  - #330 Mappings for body and html don't seem to match reality (2 by mcking65, scottaohara)
    https://github.com/w3c/html-aam/issues/330 [Agenda] 

* w3c/htmlwg (+0/-0/💬1)
  1 issues received 1 new comments:
  - #7 Location of WG homepage (1 by siusin)
    https://github.com/w3c/htmlwg/issues/7 

* whatwg/html (+6/-4/💬35)
  6 issues created:
  - Web compat: don't run async scripts between adjacent sync <script>s (by zcorpan)
    https://github.com/whatwg/html/issues/6761 [topic: parser] [topic: script] 
  - How should timers account for system sleep/suspend? (by shaseley)
    https://github.com/whatwg/html/issues/6759 
  - Additional definitions exports for Pointer Events (by plehegar)
    https://github.com/whatwg/html/issues/6758 [anchor permanence] [editorial] 
  - Adding more links to task sources (by marcoscaceres)
    https://github.com/whatwg/html/issues/6756 
  - Synchronous web crypto API (by DemiMarie)
    https://github.com/whatwg/html/issues/6754 
  - Hi (by hotdeth)
    https://github.com/whatwg/html/issues/6749 

  15 issues received 35 new comments:
  - #6761 Web compat: don't run async scripts between adjacent sync <script>s (4 by hsivonen, richard-townsend-arm, zcorpan)
    https://github.com/whatwg/html/issues/6761 [topic: parser] [topic: script] 
  - #6758 Additional definitions exports for Pointer Events (1 by domenic)
    https://github.com/whatwg/html/issues/6758 [anchor permanence] [editorial] 
  - #6756 Adding more links to task sources (3 by domenic, marcoscaceres)
    https://github.com/whatwg/html/issues/6756 
  - #6754 Synchronous web crypto API (2 by DemiMarie, domenic)
    https://github.com/whatwg/html/issues/6754 
  - #6746 Meta viewport parsing compatability (2 by domenic, josepharhar)
    https://github.com/whatwg/html/issues/6746 
  - #6711 [Suggestion] Add constants for SVG, and MathML namespaces (2 by Jamesernator, annevk)
    https://github.com/whatwg/html/issues/6711 
  - #6664 Upcoming HTML standard issue triage meeting on 6/3/2021 (4 by domenic, mfreed7, past)
    https://github.com/whatwg/html/issues/6664 [agenda+] 
  - #6628 Contiguous window.name leads to weirdness (1 by jakearchibald)
    https://github.com/whatwg/html/issues/6628 [topic: history] 
  - #6003 Removing plugins? (4 by domenic, rniwa)
    https://github.com/whatwg/html/issues/6003 [agenda+] [removal/deprecation] [topic: embed and object] 
  - #5872 Standardize a popup's condition and UI opened by window.open (4 by arai-a, domenic, mfreed7, michaelwasserman)
    https://github.com/whatwg/html/issues/5872 [agenda+] [interop] [topic: browsing context] 
  - #5791 Opt-in for `<select>` customizability  (1 by zcorpan)
    https://github.com/whatwg/html/issues/5791 [topic: forms] 
  - #3699 It is unclear how directionality should be inherited into Shadow DOM (1 by MyidShin)
    https://github.com/whatwg/html/issues/3699 [agenda+] [i18n-alreq] [i18n-hlreq] [i18n-tracker] [topic: shadow] 
  - #3174 Proposal - add aria property to the HTMLElement (just like dataset) (1 by domenic)
    https://github.com/whatwg/html/issues/3174 [accessibility] [addition/proposal] 
  - #2271 Make custom attribute rules consistent with custom element name rules (1 by zcorpan)
    https://github.com/whatwg/html/issues/2271 [addition/proposal] [needs implementer interest] [topic: custom elements] 
  - #1013 Introduce pointer to <script> element in module scripts (4 by d3x0r, rniwa, samthor)
    https://github.com/whatwg/html/issues/1013 [addition/proposal] [topic: script] 

  4 issues closed:
  - [Suggestion] Add constants for SVG, and MathML namespaces https://github.com/whatwg/html/issues/6711 
  - Synchronous web crypto API https://github.com/whatwg/html/issues/6754 
  - Proposal - add aria property to the HTMLElement (just like dataset) https://github.com/whatwg/html/issues/3174 [accessibility] [addition/proposal] 
  - Meta viewport parsing compatability https://github.com/whatwg/html/issues/6746 

* whatwg/dom (+3/-1/💬21)
  3 issues created:
  - Allow for filtering events in "once" handlers (by Jamesernator)
    https://github.com/whatwg/dom/issues/990 
  - Suggestion: `Node.insertAfter(newNode, referenceNode)` (by isiahmeadows)
    https://github.com/whatwg/dom/issues/986 
  - element.getAttributeNames() spec doesn't match wpt and browsers (by josepharhar)
    https://github.com/whatwg/dom/issues/985 

  5 issues received 21 new comments:
  - #990 Allow for filtering events in "once" handlers (2 by annevk, jakearchibald)
    https://github.com/whatwg/dom/issues/990 [addition/proposal] [needs implementer interest] [topic: events] 
  - #986 Suggestion: `Node.insertAfter(newNode, referenceNode)` (13 by WebReflection, annevk, isiahmeadows, rniwa, smaug----)
    https://github.com/whatwg/dom/issues/986 [addition/proposal] [needs implementer interest] [topic: nodes] 
  - #985 element.getAttributeNames() spec doesn't match wpt and browsers (4 by Ms2ger, josepharhar, sideshowbarker)
    https://github.com/whatwg/dom/issues/985 
  - #984 Require "abort algorithms" to not throw? (1 by annevk)
    https://github.com/whatwg/dom/issues/984 [topic: aborting] 
  - #544 Improving ergonomics of events with Observable (1 by Jamesernator)
    https://github.com/whatwg/dom/issues/544 [addition/proposal] [needs implementer interest] [topic: events] 

  1 issues closed:
  - element.getAttributeNames() spec doesn't match wpt and browsers https://github.com/whatwg/dom/issues/985 



Pull requests
-------------
* w3c/webcomponents (+2/-0/💬0)
  2 pull requests submitted:
  - Fix css-modules-v1-explainer.md (by tomayac)
    https://github.com/WICG/webcomponents/pull/932 
  - Update CSS modules explainer to include addition of import assertions (by dandclark)
    https://github.com/WICG/webcomponents/pull/931 

* whatwg/html (+11/-7/💬27)
  11 pull requests submitted:
  - Add roundRect to CanvasRenderingContext2D path (by mysteryDate)
    https://github.com/whatwg/html/pull/6765 
  - willReadFrequently for CanvasRenderingContext2D (by mysteryDate)
    https://github.com/whatwg/html/pull/6764 
  - CanvasFilter objects as input to CanvasRenderingContext2D.filter attribute (by mysteryDate)
    https://github.com/whatwg/html/pull/6763 
  - Meta: markup a variety of IDL definitions as such (by dontcallmedom)
    https://github.com/whatwg/html/pull/6762 
  - Always replace initial blank (by Sameera786)
    https://github.com/whatwg/html/pull/6760 
  - Meta: mark definitions of constructors and some method and attributes as such (by dontcallmedom)
    https://github.com/whatwg/html/pull/6757 
  - Meta: Mark definitions of selectors as such (by dontcallmedom)
    https://github.com/whatwg/html/pull/6755 
  - Meta: mark up definitions of attribute values as such (by dontcallmedom)
    https://github.com/whatwg/html/pull/6753 
  - Meta: mark up definitions of element attributes as such (by dontcallmedom)
    https://github.com/whatwg/html/pull/6752 
  - Meta: mark up definitions inside IDL fragments (by dontcallmedom)
    https://github.com/whatwg/html/pull/6751 
  - Align element definitions with markup conventions (by dontcallmedom)
    https://github.com/whatwg/html/pull/6750 

  11 pull requests received 27 new comments:
  - #6760 Always replace initial blank (2 by Sameera786, domenic)
    https://github.com/whatwg/html/pull/6760 [spam] 
  - #6755 Meta: Mark definitions of selectors as such (3 by domenic, dontcallmedom, tabatkins)
    https://github.com/whatwg/html/pull/6755 
  - #6753 Meta: mark up definitions of attribute values as such (1 by dontcallmedom)
    https://github.com/whatwg/html/pull/6753 
  - #6752 Meta: mark up definitions of element attributes as such (2 by domenic, dontcallmedom)
    https://github.com/whatwg/html/pull/6752 
  - #6748 Remove <head> requirement for <meta name=referrer> (3 by dergoegge, domenic)
    https://github.com/whatwg/html/pull/6748 [impacts documentation] [normative change] 
  - #6745 Make text/plugin/media/ua-inline no-quirks documents (2 by domenic, mfreed7)
    https://github.com/whatwg/html/pull/6745 
  - #6638 Add `credentialless` value to COEP (HTML spec) (2 by ArthurSonzogni, domenic)
    https://github.com/whatwg/html/pull/6638 
  - #6569 Define <meta media>. Fixes #6495. (8 by beaufortfrancois, domenic, hober, tomayac)
    https://github.com/whatwg/html/pull/6569 [addition/proposal] [document conformance] [normative change] [topic: style] 
  - #6466 Expand <details> for find-in-page and element fragments (2 by josepharhar)
    https://github.com/whatwg/html/pull/6466 [agenda+] [needs tests] 
  - #6315 Session history rewrite (1 by jakearchibald)
    https://github.com/whatwg/html/pull/6315 [topic: history] 
  - #5957 Set dfn-type on definitions in IDL fragments (1 by dontcallmedom)
    https://github.com/whatwg/html/pull/5957 [meta] 

  7 pull requests merged:
  - Meta: mark up definitions of attribute values as such
    https://github.com/whatwg/html/pull/6753 
  - Meta: mark up definitions of element attributes as such
    https://github.com/whatwg/html/pull/6752 
  - Meta: Mark definitions of selectors as such
    https://github.com/whatwg/html/pull/6755 
  - Meta: mark up definitions inside IDL fragments
    https://github.com/whatwg/html/pull/6751 
  - Remove <head> requirement for <meta name=referrer>
    https://github.com/whatwg/html/pull/6748 [impacts documentation] [normative change] 
  - Set dfn-type on definitions in IDL fragments
    https://github.com/whatwg/html/pull/5957 [meta] 
  - Align element definitions with markup conventions
    https://github.com/whatwg/html/pull/6750 

* whatwg/dom (+1/-0/💬0)
  1 pull requests submitted:
  - Add "mode locked" flag to Document, plus an algorithm to use it (by mfreed7)
    https://github.com/whatwg/dom/pull/989 


Repositories tracked by this digest:
-----------------------------------
* https://github.com/w3c/html-aam
* https://github.com/w3c/html-aria
* https://github.com/w3c/html-extensions
* https://github.com/w3c/htmlwg
* https://github.com/w3c/webcomponents
* https://github.com/whatwg/html
* https://github.com/whatwg/dom


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Hi Neil, all,

I assume by "operator dictionary" you're referring to:
https://www.w3.org/TR/MathML3/appendixc.html

These indeed induce one grammar for math syntax. It is hard to
understand *which* grammar that is. Is there some testbed of supported
expressions/notations that it is expected to cover? Math grammars are
quite hard to develop and maintain, so I would be a bit anxious of
adopting one "officially" without a good plan.

To draw a random example from the operator dictionary, I saw % is
marked as infix with priority 640. But in the expression "15% x = 10",
it is meant to be read "fifteen percent of x equals to ten". And not
"fifteen modulo x equals ten", as in programming languages, which may
have been the reason behind choosing the infix form. Consider also the
standalone "0.15 = 15%" and "15% = 150‰", to illustrate it's really
postfix when intending "percent" - which is the usual meaning in K-14
materials.

So rather than it being a silver bullet, I think the operator
dictionary may need some vetting and reconsideration. The way I see
it, we would also have a much easier time if we do not standardize an
entire grammar, just because that's the highest difficulty task we can
set for ourselves. It is, in my experience, much harder to get right
than assembling long lists of concept names and notation forms.

If I read you correctly, you agree that whichever way we enrich/infer
the mrows, we need to decide on a list of intents that will be
expected as default remediation. I think we have some clear common
agreement here, also with Sam's document that started fleshing these
out as examples
(https://mathml-refresh.github.io/discussion-papers/intent). For
example, if the exclamation mark (!) is intended to be remediated as
the "factorial" by default, that has to be made explicit, as well as
the notation where that intent is activated.

On my end, I would offer we (try to) create something new that is very
narrowly described and scoped. Say by listing all mathematical
notations we have encountered, and then cherry-picking (and creating
tests for) notations we want recognized by default, from a pragmatic
mathematical standpoint. One working definition may be "standard
notations in K-14 education that have no mutual overlap". And my
instinct is that if we end up with very small and usable defaults,
they will be easier to both test against and apply in practice. But we
also need to develop them to a degree where the defaults meet "natural
expectation", which is a tension in the opposite direction of
simplicity. To achieve all of that, I resonated quite strongly with
Brian's suggestion during our last meeting - we ought to do a couple
of iterations of concept validation coding and demos and develop a
test suite. There's a real risk of making a readout worse if the
defaults are more often wrong than correct, and our best bet to avoid
that is actually check how they work on the materials we intend them
for, before we release them to the world.

I also welcome more discussion, thanks for starting one!

Greetings,
Deyan



Deyan

On Sun, Jun 13, 2021 at 6:09 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
> I'm writing this email to get some discussion going outside of the meetings. Deyan is also working on this and is working on his own reasoning on this topic. The topic we have started to discuss in the meetings is MathML structure and how that might or might not work well with intents, especially for defaults.
>
> First off, if an intent is given, there is no ambiguity for the part of the structure given by the intent and the current proposal(s) make no requirements on MathML structure other than it be valid MathML. That doesn't mean that other parts of the structure (e.g, the arg="..." parts) are unambiguous. But it does mean that any software trying to come up with a "meaning" for speech (or otherwise) should not break a stated intent.
>
> The question we have begun to explore is what can we state about a default in the absence of explicit intents.
>
> Why do we care about defaults?
> To me, a big advantage of using intent over some alternatives like parallel markup is that using "intent" can support progressive enhancement. If we come up with some defaults, then authors only need to use 'intent' when the defaults aren't correct. So if we can figure out reasonable defaults, we can minimize the content that needs work/remediation so that it can be spoken unambiguously. Additionally, rather than require MathML generators change to use parallel markup or some other output, current output remains valid although it may not unambiguously represent author intent. The extent to which it can be disambiguated is tied to how much context is used to make the defaults. It will never be perfect without author's helping out though.
>
> My Two Cents
> Since this message is to provoke discussion and is not meant to be a fleshed out proposal (it's very long as it is), I'll just state my current thoughts and add a little rationale to them, but not get into the details....
>
> My feeling is that defaults should be based on a canonical parse of the MathML expression that is defined by the operator dictionary and as overridden by any attrs on the <mo> elements. This does not mean that MathML that uses "flat" mrows doesn't have a default, it just means that when parsed, it will have whatever defaults we end up giving. As an example, if an mrow has "a", "+", "5", "!" as direct children, a default for factorial would be used because the canonical form given by the operator dictionary would group the "5" and "!" in a single mrow and that would match a factorial default.
>
> By mapping expressions to a canonical parse, we can write defaults in a relatively simple manner and not require MathML writers to generate a specific representation (something Deyan's post shows doesn't happen now). It doesn't even require software that wants to apply a default to do the parse, although I think supporting all the various ways of representing a default a default would be hard without parsing. Currently the more sophisticated speech renderers do parse the input to infer intent, so using defaults fit naturally into those speech renderers.
>
> One thing the operator dictionary does not solve is operand/operand conflict (horizontal juxtaposition of operands). Typically these are either meant to be function call or multiplication (or more precisely, a multiplication-like operation), but it could be an implied plus for mixed fractions or an implied comma in something like M_{11}. How this is specified will determine a canonical parse for those cases.
>
> Another area of concern is mixing n-ary operators. We've discussed how +/- might parse, along with how a series of relational operators should be given/thought about. I think they should be flat, but reasonable people differ. Clearly something that needs further discussion before defaults can be written for them.
>
> A final area of concern is matching open/close fences. The operator dictionary has all of the fences with the same priority and I think it makes sense that a "[" can match against a ")" to form an mrow, but there might be some subtle issues that make this a poor default. Note that the French interval notation "]0, (" will not form the intended mrow structure without the author overriding the "form" for the brackets; if overridden it will parse intuitively and a default could be written for that notation.
>
> Hopefully some food for thought and that this will provoke some discussion outside of the meetings.
>
>     Neil
>
>
>

I'm writing this email to get some discussion going outside of the
meetings. Deyan is also working on this and is working on his own reasoning
on this topic <https://hackmd.io/@dginev/Bk4Zf9B9O>. The topic we have
started to discuss in the meetings is MathML structure and how that might
or might not work well with intents, especially for defaults.

First off, if an intent is given, there is no ambiguity for the part of the
structure given by the intent and the current proposal(s) make no
requirements on MathML structure other than it be valid MathML. That
doesn't mean that other parts of the structure (e.g, the arg="..." parts)
are unambiguous. But it does mean that any software trying to come up with
a "meaning" for speech (or otherwise) should not break a stated intent.

The question we have begun to explore is what can we state about a default
in the absence of explicit intents.

*Why do we care about defaults?*
To me, a big advantage of using intent over some alternatives like parallel
markup is that using "intent" can support *progressive enhancement*. If we
come up with some defaults, then authors only need to use 'intent' when the
defaults aren't correct. So if we can figure out reasonable defaults, we
can minimize the content that needs work/remediation so that it can be
spoken unambiguously. Additionally, rather than require MathML generators
change to use parallel markup or some other output, current output remains
valid although it may not unambiguously represent author intent. The extent
to which it can be disambiguated is tied to how much context is used to
make the defaults. It will never be perfect without author's helping out
though.

*My Two Cents*
Since this message is to provoke discussion and is not meant to be a
fleshed out proposal (it's very long as it is), I'll just state my current
thoughts and add a little rationale to them, but not get into the
details....

My feeling is that defaults should be based on a canonical parse of the
MathML expression that is defined by the operator dictionary and as
overridden by any attrs on the <mo> elements. This does not mean that
MathML that uses "flat" mrows doesn't have a default, it just means that
when parsed, it will have whatever defaults we end up giving. As an
example, if an mrow has "a", "+", "5", "!" as direct children, a default
for factorial would be used because the canonical form given by the
operator dictionary would group the "5" and "!" in a single mrow and that
would match a factorial default.

By mapping expressions to a canonical parse, we can write defaults in a
relatively simple manner and not require MathML writers to generate a
specific representation (something Deyan's post shows doesn't happen now).
It doesn't even require software that wants to apply a default to do the
parse, although I think supporting all the various ways of representing a
default a default would be hard without parsing. Currently the more
sophisticated speech renderers do parse the input to infer intent, so using
defaults fit naturally into those speech renderers.

One thing the operator dictionary does not solve is operand/operand
conflict (horizontal juxtaposition of operands). Typically these are either
meant to be function call or multiplication (or more precisely, a
multiplication-like operation), but it could be an implied plus for mixed
fractions or an implied comma in something like M_{11}. How this is
specified will determine a canonical parse for those cases.

Another area of concern is mixing n-ary operators. We've discussed how +/-
might parse, along with how a series of relational operators should be
given/thought about. I think they should be flat, but reasonable people
differ. Clearly something that needs further discussion before defaults can
be written for them.

A final area of concern is matching open/close fences. The operator
dictionary has all of the fences with the same priority and I think it
makes sense that a "[" can match against a ")" to form an mrow, but there
might be some subtle issues that make this a poor default. Note that the
French interval notation "]0, (" will not form the intended mrow structure
without the author overriding the "form" for the brackets; if overridden it
will parse intuitively and a default could be written for that notation.

Hopefully some food for thought and that this will provoke some discussion
outside of the meetings.

    Neil

Stephen asked during the call for pointers to the CG's discussions on 
the intent attribute  to come up to speed for the Working Group 
discussions on the same thing,

The CG GitHub (mathml-refresh)  is still operational and has several 
related discussion papers at

https://mathml-refresh.github.io/discussion-papers/


4 of those are proposals around variants of the idea of having an 
intent=... attribute for a lighter weight version of annotating 
presentation mathml than the "parallel markup" mapping to Content MathML 
we had in MathML3, and "Intent Annotation Comparison" is a big 
comparison table of several of the variants.

The minutes of the meetings are also public but the discussion papers 
are probably a better place to start...

David

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
30 St. Giles, Oxford, OX1 3LE, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. 

 Attendees:

   - Bert Bos
   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Paul Libbrecht
   - Louis Maher
   - Steve Noble
   - Murray Sargent
   - Cary Supalo
   - Neil Soiffer
   - Moritz Schubotz
   - Christopher Comninel
   - Brian Kardell
   - Laurence Zaysser
   - Stephen Watt
   - Charles LaPierre

Regrets:

   - Bruce Miller

Thanks to Louis for once again taking notes.
Announcements/updates

BB: Moved mathml core to W3C. BB: will send email instructions on how to
fully authorize your Github account for write access.

https://github.com/w3c/mathml-core https://github.com/w3c/mathml

Proposed: We move the mathml-core to FPWD, cleaning up whatever sorts of
minor things would be involved in that process. The editors will remain in
place for now, David will do the work of transitioning it.

RESOLVED.

We introduced ourselves to our new members.
Continue discussion on CSS and intents

Neil: We were talking about proper structures, but I can't recall where we
left off.
PL: I think we agreed that CSS selectors were entirely insufficient.
Whether CSS was used or not was, I think strongly put in question. In
general CSS is used by many people and we're not necessarily trying to make
things converge..

The current stance is probably that CSS can enrich default intents so that
they can be applied by some algorithm just the same way the default intents
are (by inferring on content or by applying only to well structured content
or...)

NS: If you are matching, what structure are you matching aginst.

DG: Showed an example of a single expression containing the presentation
MathML for: "x is in the open interval from zero to one and y is in the
open interval from negative one to zero". In various pMML flavors generated
by different tools today.

PL: Is expression navigation (LHS/RHS of equality, individual parts of a
fraction...) important for accessibility?

NS: There have been studies that say that you can retain about seven words
when something is read to you. For anything bigger you need navigation.

NS: topics for next week. We need to review the core spec; should do that
before the meeting and we can discuss any issues that aren't editorial
(send those to David).
What do we require for structure (mrows, etc) for intents to be usable

DG: A new draft of a working note on "canonical mrows" at
https://hackmd.io/@dginev/Bk4Zf9B9O . Still needs additional thinking, but
has some discussion on

   1. current presentation MathML trees from different authoring tools on
   the same running example.
   2. various XPath incantations for selectors with which a "default
   notations dictionary" could specify "implied intent", e.g. for K-12
   educational notations.

DG: We ran out of time, so we only discussed the currently produced
presentation MathML trees. I am not actually *advocating* for the defaults,
I am *investigating* possible avenues for them. Is there a subset of
notations where we have no ambiguity, but still have 80/20 "Good"
remediation for free? Should the specification impose a canonical
presentation tree to get us there?

DG: As an aside, it is good that the explicit intent values we discussed in
2020 allow to remediate all flavors of today's presentation MathML, by
simply targeting the "lowest common ancestor".

  (see MathUI at http://www.cicm-conference.org/2021)

--------
## 13th MathUI Workshop 2021
## Mathematical User Interaction

----------------------------------------

at the Conference on Intelligent Computer Mathematics Timisoara, Romania 
(online) one day between (tba.) July 26 - 31, 2021

------------------------------

please redistribute

SCOPE
--------
MathUI is an international workshop for discussing HOW USERS CAN BE BEST 
SUPPORTED WHEN INTERACTING WITH MATHEMATICAL CONTENT, i.e., 
doing/learning/searching for/viewing/... mathematics using a digital 
device.

Use cases range from professional mathematicians trying to proof a new 
theorem up to non-math oriented people trying to understand the math 
formula used for calculating interest rates.

* What do we know about interactions between users and math?
* Which mathematical services can be offered and can they be 
meaningfully combined?
* How is mathematics for which purpose best represented?
* What specifically math-oriented support or platforms are needed?
* How can we exploit best practices wrt. mathematics for better 
math-user interactions?

--------
We invite all topics, that care for the use of mathematics
on computers and how the user experience can be improved, to be
discussed in the workshop.
TOPICS include:
   - user-requirements for math interfaces
   - presentation formats
   - mobile-devices powered mathematics
   - cultural differences in practices of mathematical languages
   - didactically sensible scenarios of use
   - spreadsheets as mathematical interfaces
   - graphs as mathematical interfaces
   - manipulations of mathematical expressions

This workshop follows a successful series of workshops held at
the Conferences on Intelligent Computer Mathematics;
it features presentations of brand new ideas in papers selected by
a thorough review process, wide space for discussions, as well as a
software demonstration session.

SUBMISSIONS
------------------
DEADLINE: Continuous submission until July 14th 2021
CONTRIBUTION: 4 - 12 pages
FORMAT: PDF file, Optionally illustrated by supplementary media  such as 
video recordings or access to demos
METHOD OF SUBMISSION: Submission at easyChair 
(https://easychair.org/conferences/?conf=cicm2021): select   author 
role, select the "new submission" tab, and choose MathUI.

The submissions will be reviewed by the programme committee
whose comments and recommendations will be sent back by July 21th
requesting a final version (4 - 12 pages) no later than July 25th.


PC COMMITTEE

- Andrea Kohlhase (organizer), Neu-Ulm University of Applied Sciences
- Paul Libbrecht, IUBH University of Applied Sciences
- Marco Pollanen, Trent University
- Moritz Schubotz, FIZ Karlsruhe - Leibniz Institute for Information 
Infrastructure


For inquiries please contact  Andrea Kohlhase, Andrea.Kohlhase@hnu.de

HOPE TO SEE YOU AT MathUI'21! 😃

 We meet on Thursday, 10am Pacific, 1pm Eastern, 7pm Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list for the group. The regulars for this group should have the meeting
details in their calendars.

Agenda:
1. Announcements/updates
2. Continue discussion on CSS and intents
3. What do we require for structure (mrows, etc) for intents to be usable?

 Attendees:

   - Bert Bos
   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Paul Libbrecht
   - Louis Maher
   - Bruce Miller
   - Steve Noble
   - Murray Sargent
   - Cary Supalo
   - Neil Soiffer
   - Moritz Schubotz
   - Christopher Comninel
   - Brian Kardell
   - Laurence Zaysser

Regrets:

   - Stephen Watt

Thanks to Louis for once again taking notes.
Announcements/updatesother announcements

CS: talked about the ISLAND conference (at https://islandconference.org/ ).
He is looking for talks.
Make a decision regarding location of github (CG's or W3C or some
combination)

DC: Has repositories from the old math group, and from other efforts. Where
do we put the current efforts?

NS: Keep separate repositories. Where will the polyfills go? Perhaps leave
them where they are.

NS: We will publish notes. Where do they go?

BK: What happens when a note grows larger than a note?

BB: Says store them in W3C.

DC: Move the current CG MathML to the W3C.

Proposal A

Move mathml-refresh mathml repo to w3c (to keep issues) (this requires
Bert's admin access)

Make directory for mathml-full then make new directories copying in the
other CG as sub directories

Proposal B

Just move mathml-core to w3c as a separate repository

BK: We want only a small number of repositories.

NS: Store notes, polyfills and discussions.

RESOLVED:

Change the owner of mathml-refresh/mathml-core to W3C as its own repo
w3c/mathml-core Change owner of mathml-refresh/mathml to W3C replacing the
existing w3c/mathml Keep w3c/xml-entities unchanged and retire the
duplicate copy under mathml-refresh.

In the future we wil create another 'catch-all' repo to move important
notes, polyfills and discussions.
Intents and CSS (email from Paul that starts the thread; document with his
ideas)

PL: Make CSS deal with intent.

Difficult to get people to help with pronunciations from other languages.
People will contribute work if they can check the work immediately. CSS can
provide styles. There should be a way to put intents with CSS.

PL: Discussed is e-mail example. From Paul Libbrecht to Everyone:
https://mathmlmuses.netlify.app/intents-as-css-styles/

LZ: From a publishing perspective, it is important a CSS proposal does not
become expensive to produce. Hand-annotating MathML is not viable.
Customizing CSS as a requirement to authors is not viable. A light-weight
solution would really be the only adoptable one.

NS: HTML is ment for semantics and CSS is meant for styling and
presentation.

NS: You must add a class to make this work.

BM: If the authoring system can add something semantically oriented then
you can have a user style sheet for a specific language. The abstract
concept certainly has value, even if CSS may be an odd fit.

DG: A good perspective away from the word "semantics" is "meaningful use in
the domain of application". CSS class names, such as "progress-bar" in
Bootstrap components, carry all kinds of implied UI behaviours to frontend
developers, and often anchor the frontend JS code. The intent attribute
could provide a similar service to AT.

DG: The path for actually using the specification for producing an
accessible outcome is loosely 1) how to author MathML with intent
annotations, 2) the exact representation details of the intent attribute
values and 3) obtaining narration strings from the deposited annotations.
Paul's proposal seems to be a first study in the last piece, where we could
need some user stylesheets to customize e.g. speech synthesis. The "Initial
list of intent" spreadsheet has multiple examples of "speech hints", also
in this direction, but DG doesn't know what would be a best practice for
serving them in applications.

NS: If AT can not see CSS, then we can't use it.

NS: Continue this discussion next week. As with the other proposal, DG's
observation about mrow's is pertinent here.
Questions For Later Discussions

DF: Does cut and paste contain intent information? The answer will impact
several proposals. (MathML attribute should be copied all but... when does
it copy... Only MS Word does it well and does not contain intents).

DG: Writing requirements for mrows. Should there be a difference made in
authoring tools? Should we have standards that would allow the mrows to be
accessible by using default rules.

Hello Neil, Deyan and all,

On 27 May 2021, at 8:58, Neil Soiffer wrote:

> I agree with much of what Deyan mentions. I do see a copy/paste bug:
>
> .set {
>     mathintent-mo-mid: "$1 given $2";
>   }
>
> You mean "such that" in this case, right?

- that was an error: thanks, this is fixed

>
> What I don't see is what the connection between the $n and the MathML
> referenced. Using the conditional probability example because it is 
> shorter:
>
>   <mrow class="conditional-prob">
>     <mo>P</mo>
>     <mo>(</mo>
>     <mi>A</mi>
>     <mo>|</mo>
>     <mi>B</mi>
>     <mo>)</mo>
>   </mrow>
>
> The CSS match is on the mrow. I would normally think that $1 refers to 
> the
> first child, but that's not right here (FYI: the 'P' should be an <mi> 
> and
> there should be an <mo> with &#x2061 [function apply] in it that 
> follows
> the 'P'). I think maybe you mean it refers to the first <mi>, but the
> argument could easily be a number or a complicated expression, so that
> can't be it. In the intent proposal, the arguments get marked with 
> "arg"
> attrs. Perhaps the RHS of the css rule needs to include CSS selectors?

That’s the question of the selector language (i.e. how to interpret 
$1, $2, …): this is a problem we currently have with all intents, even 
those explicit in attributes I think.
Yes, it is difficult to solve

> Whereas using attrs can be repetitive, it does keep the intent in one
> place. If one were using a WYSIWYG editor that allowed the user to 
> specify
> what they mean, how would copy/paste out of that editor convey both 
> the
> MathML (with a class attr) and the CSS? It seems to me that a CSS-like
> approach only works if the entire document, including the math, is
> generated from the source. Definitely a possibility, but also IMHO a
> limitation.

As said here and there, this is not a problem in the current browser 
landscape: it is trivial for a DOM sub-tree loaded by a browser to 
enrich attributes so that the style element of the `mrow` named by the 
class carries the extra property (that is just “style resolution based 
on class-names”). I’ve tried to explain it a bit deeper in the 
second paragraph of [challenges and 
hopes](https://mathmlmuses.netlify.app/intents-as-css-styles/#challenges-&-hopes) 
(starting from “However, CSS inheritance”).

What’s difficult is to apply “$1 given $2” to the A, pipe, and B 
elements by either using what’s in the style element or what’s in 
the table of default intents. I haven’t resolved this and, as Deyan 
noted, this is not solved by the spec or the table of all default 
intents. Maybe we can leave it to some implementations…

> My gut feel is that using class/CSS is wrong in principle. CSS is 
> meant to
> style something, not add semantics. Using it to change the way you 
> speak it
> such as "J sub 1" vs "J 1" seems appropriate, but using CSS to change 
> the
> meaning of the 'J' to be a Bessel function seems wrong. Although HTML 
> is
> not perfect about it, the point is that the meaning is conveyed by the
> markup; class doesn't count in that sense (ARIA could have used it, 
> but
> instead felt a separate @role was appropriate).

As for the feeling that CSS is not for intents. I fully disagree: CSS is 
as much semantics carrying when it says that a given paragraph should be 
displayed big as it is semantics to indicate that a given paragraph 
should be displayed or not using a print-media or using an accessibility 
tool.

I’m afraid, the word semantics should be banned here…

> I suspect others share your enthusiasm for CSS, so this is a very good
> topic for a call. Perhaps some more email discussion will help further
> refine your ideas before discussing them on a call...


On 28 May 2021, at 18:11, Brian Kardell wrote:

> Perhaps it would be a good idea to file an issue in the repo on
> https://github.com/w3c/mathml/issues so that we don't lose visibility 
> into
> history here?

The list archive has it already.
I would expect that the issues are more with decided directions…


Paul


> On Mon, May 24, 2021 at 11:06 AM Deyan Ginev <deyan.ginev@gmail.com> 
> wrote:
>
>> Hi Paul, all,
>>
>> Now that Paul has updated his examples, I took the time to see what
>> his level 3 list complaint was, and added the notation. Emailing to
>> all as an encouragement to add future examples to the list directly.
>>
>> So. The list already had "free-product" added, and my encyclopedia
>> index didn't contain the amalgamated variant of it, likely since
>> wikipedia doesn't have a standalone page for that. I did a quick
>> search + cursory reading and found that there are three rough 
>> synonyms
>> for the same notation - "amalgamated-product",
>> "amalgamated-free-product" and "free-product-with-amalgamation".
>>
>> So I added in an entry with a name and two aliases, the source links
>> from my search, and the nice subscripted infix * operator. I also
>> added the speech hint I found in a phd thesis (though maybe there are
>> better ones?) of:  "amalgamated product of $1 and $3 with $2
>> amalgamated".
>>
>> And now, 5 minutes later, it's in the list and one can imagine it
>> spoken by an AT tool. Relatively painless I would hope.
>>
>> I'll keep this email short, so no CSS comments for now, just this 
>> level 3
>> note.
>>
>> Greetings,
>> Deyan
>>
>> On Tue, May 11, 2021 at 3:47 PM Deyan Ginev <deyan.ginev@gmail.com> 
>> wrote:
>>>
>>> Hi Paul, all,
>>>
>>> Thanks for the quick CSS writeup! It's still a little difficult to
>>> follow, and can benefit from a fully worked out minimal example 
>>> (with
>>> an explicit MathML tree and CSS rules as per your preferences).
>>>
>>> That aside, there are multiple open questions, most pressingly:
>>>
>>> 1. How can we set up the Math and CSS working groups on a solid 
>>> common
>>> footing where **any** constructive collaboration can take place?
>>> 2. Followed by the secondary complication that MathML has been
>>> possible to use in the past without a strict dependence on CSS, so
>>> introducing one for the AT component will also have wider ecosystem
>>> considerations.
>>>
>>> ---
>>>
>>> If (and that's a big if) those can be productively addressed, the
>>> technical considerations about a "selector language for math
>>> notations" are also non-trivial / interesting. Traditionally this 
>>> has
>>> required a full-blown grammar (e.g. CFG) to do well, since we have a
>>> lot of contextual interplay - balancing fences, repeated delimiters,
>>> n-ary infix operators, and even recognizing full-blown subtrees with
>>> holes (e.g. Leibniz's notation, falling factorial, Prüfer group, 
>>> ...).
>>> Present day CSS is very ill-equipped to do these kinds of 
>>> selections.
>>> I'll also pose this technical challenge to our prior topic of
>>> discussing "subject area" rule sets. For these conceptual "subject
>>> definition sets" one also needs such a selection mechanism for
>>> targeting notational primitives.
>>>
>>> Annotating every single MathML node with an intent attribute clearly
>>> feels redundant and verbose, but I think it is a very solid baseline
>>> for what is allowable by the spec. Similarly to how you don't have 
>>> to
>>> add a CSS "style" attribute to every HTML node, but if you really
>>> wanted to - you could. What you lose in verbosity you gain in AT
>>> runtime simplicity - you don't need any advanced lookup/logic when 
>>> the
>>> intent is already spelled out. How you get the annotations on the 
>>> tree
>>> is then a burden shifted to the authoring tools / remediating 
>>> author.
>>> And some tools are very well-equipped for this kind of thing, have
>>> pre-existing macro/palette interfaces, grammar capabilities, etc.
>>>
>>> I don't think the fully verbose variant is the best we can do, but 
>>> it
>>> definitely seems like the right "flat" target. For a browser 
>>> analogy,
>>> the inspector tools for CSS have a "Rules" (or "Styles") and
>>> "Computed" tabs, where the "Computed" one contains all fully
>>> flattened/instantiated rules, derived from all CSS rules applicable 
>>> to
>>> the node inspected. The big question is whether we can achieve this
>>> model with the level of technical work we're prepared to invest 
>>> here.
>>>
>>> Thanks for investigating the CSS angle,
>>> Deyan
>>>
>>> P.S. GMail had flagged the original email as "spam" for me, for some
>>> unknowable reason, so there is a chance the original post had a
>>> limited audience.
>>>
>>> On Wed, May 5, 2021 at 6:01 AM Paul Libbrecht <paul@hoplahup.net> 
>>> wrote:
>>>>
>>>> Hello community,
>>>>
>>>> We discussed in the last group call that CSS could possibly play a
>> role to support the intent attribute. I’ve sketched a few thoughts 
>> inside
>> this page in the form of a “what if…”:
>>>> https://mathmlmuses.netlify.app/intents-as-css-styles/
>>>>
>>>> … and got surprised in writing that this seems desirable…
>>>>
>>>> Thanks for thoughts.
>>>>
>>>> Paul
>>>>
>>>> On 2 May 2021, at 3:31, Neil Soiffer wrote in Minutes of the call 
>>>> 29
>> April 2021:
>>>>
>>>> NS: A.T. does  not see CSS information. It just sees the MathML. 
>>>> You
>> may not be able to globally change speech behavior with CSS 
>> technology.
>>>>
>>>> NS: Should we say that the A.T. must look at CSS as well as MathML?
>> (this is often not the case or not doable thus far)
>>
>>

We meet on Thursday, 10am Pacific, 1pm Eastern, 7pm Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list for the group. The regulars for this group should have the meeting
details in their calendars.

Agenda:
1. Announcements/updates
2. Make a decision regarding location of github (CG's or W3C or some
combination)
3. Intents and CSS (email from Paul that starts the thread
<https://lists.w3.org/Archives/Public/public-mathml4/2021May/0001.html>;
document
with his ideas <https://mathmlmuses.netlify.app/intents-as-css-styles/>)

    Neil

 Attendees:

   - Bert Bos
   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Paul Libbrecht
   - Louis Maher
   - Bruce Miller
   - Steve Noble
   - Murray Sargent
   - Cary Supalo
   - Neil Soiffer
   - Moritz Schubotz
   - Christopher Comninel
   - Brian Kardell

Regrets:

   - Laurence Zaysser

Thanks to Louis for once again taking notes.
Announcements/updatescryptpad

PL: has submitted an accessibility bug report for CryptPad.

LM: How do we store the minutes?

NS: We will have one CryptPad file to write the minutes, and NS: will then
send the minutes to email.
other announcements

   -

   DG: HackMD replied in 10 days with new support for real-deal MathML
   markup in their editor, which now gets preserved into the HTML preview.
   Impressive! This means one can now write TeX equations and see them
   rendered via mathjax OR MathML directly (with the intent attributes added
   even).
   -

   DG: We learned how to put math in CryptPad during the meeting - a
   "triple backtick mathjax" annotation
   -

   BB: A colleague of mine mentioned another shared editor:
   https://demo.hedgedoc.org/features because it supports math (via
   MathJax) and graphviz for diagrams. Don’t know about its a11y.
   -

   BB: … and if we want to use IRC again: IRC can now put math in minutes
   as well. BB added latexml to RRSAgent/scribe.perl :-)

Review charter and make plans

We will review the charter and look at the non-core work we promised to do
(the core sub working group will look at the core parts), update thoughts
on those, and figure out when and who will be working on the parts that
need work

NS: reviewed our deliverables in the charter. He suggested people to handle
the deliverables.

NS: We will not consider core issues. A separate group will handle that.

NS: We must right tests for our features that we introduce.

NS: Do we port older tests for our intent features?
Deliverables (from spec)

   -

   MathML Spec first WD (Oct 2021)[Neil, David C, Bruce]
   -

   Test suites and implementation reports for the specification. (PL may
   help)
   -

   Analysis of mathematical notation usage in world-wide writing systems,
   including but not limited to non-LTR writing systems. (PL may help, DG can
   help with cyrillic languages, Moritz Statistics from Wikipedia)
   -

   MathML Accessibility Technique Notes. [Steve, Neil, Murray, Chris, Cary]
   -

   Guides on annotating Presentation MathML for accessibility and search.
   [Steve, Neil, Murray, Chris, Cary]
   -

   A living catalog for annotations beyond those defined in a MathML 4
   recommendation. [DG, Moritz]
   -

   Sample code that converts default "intent" values to explicit "intent"
   values in Presentation MathML. [SD, DG, Neil]
   -

   At least one TeX-to-MathML converter that incorporates
   accessibility/searchability annotations in its MathML output. [DF, DG,
   Murray]
   -

   Code to convert Content MathML to Presentation MathML with accessibility
   and searchability annotations. [SD, DC, Moritz]
   -

   Sample code for conversion of annotated Presentation MathML to an
   external form such as speech and/or Content MathML. [SD, DG, Neil, Murray,
   Moritz]

NS: DC: and PL: discussed adding clipboard applications.

NS: no action items for us except to talk to browser producers.

PL: should liaising with other groups be in the charter?

BM: perhaps we should not change the spec until we find out why the
browsers have not implemented the clipboard?

PL: and BC: may have this discussion with browser writers.

NS: discuss first draft of spec for MathML 4. Revise spec 3. Consider
eliminating informational chapters from spec 3.

NS: discussed structure of github. Set up a W3C branch in github for
publishing.

DC: reviewed the current github MathML structure.

NS: has sent out several WG recruiting emails.

NS: move our spec-like things to the W3C branch of  github . DC: is not in
favor of this because history might be lost. DC: will do the github design.

BB: there is a tool that collects issues from working groups to look for
open issues. He will investigate this tool.

NS: we will postpone this decision for a week.

NS: asks people to add their names to the minutes to work on the
deliverables.
Note on using cryptpad for math
Paul: Math formulæ in Cryptpad code?
Display math can be entered by typing
```mathjax
\frac{1}{\sqrt{x+2}+3}

See the Markdown guide of Cryptpad
<https://cryptpad.fr/code/#/2/code/view/VJtytDV8tsmlGx0GlR02azrp51A8cl8ivifXf6GQ9RA/>
(lots of other features are there).

Perhaps it would be a good idea to file an issue in the repo on
https://github.com/w3c/mathml/issues so that we don't lose visibility into
history here?

On Thu, May 27, 2021 at 2:59 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> I agree with much of what Deyan mentions. I do see a copy/paste bug:
>
> .set {
>     mathintent-mo-mid: "$1 given $2";
>   }
>
> You mean "such that" in this case, right?
>
> What I don't see is what the connection between the $n and the MathML
> referenced. Using the conditional probability example because it is shorter:
>
>   <mrow class="conditional-prob">
>     <mo>P</mo>
>     <mo>(</mo>
>     <mi>A</mi>
>     <mo>|</mo>
>     <mi>B</mi>
>     <mo>)</mo>
>   </mrow>
>
> The CSS match is on the mrow. I would normally think that $1 refers to the
> first child, but that's not right here (FYI: the 'P' should be an <mi> and
> there should be an <mo> with &#x2061 [function apply] in it that follows
> the 'P'). I think maybe you mean it refers to the first <mi>, but the
> argument could easily be a number or a complicated expression, so that
> can't be it. In the intent proposal, the arguments get marked with "arg"
> attrs. Perhaps the RHS of the css rule needs to include CSS selectors?
>
> Whereas using attrs can be repetitive, it does keep the intent in one
> place. If one were using a WYSIWYG editor that allowed the user to specify
> what they mean, how would copy/paste out of that editor convey both the
> MathML (with a class attr) and the CSS? It seems to me that a CSS-like
> approach only works if the entire document, including the math, is
> generated from the source. Definitely a possibility, but also IMHO a
> limitation.
>
> My gut feel is that using class/CSS is wrong in principle. CSS is meant to
> style something, not add semantics. Using it to change the way you speak it
> such as "J sub 1" vs "J 1" seems appropriate, but using CSS to change the
> meaning of the 'J' to be a Bessel function seems wrong. Although HTML is
> not perfect about it, the point is that the meaning is conveyed by the
> markup; class doesn't count in that sense (ARIA could have used it, but
> instead felt a separate @role was appropriate).
>
> I suspect others share your enthusiasm for CSS, so this is a very good
> topic for a call. Perhaps some more email discussion will help further
> refine your ideas before discussing them on a call...
>
>     Neil
>
> On Mon, May 24, 2021 at 11:06 AM Deyan Ginev <deyan.ginev@gmail.com>
> wrote:
>
>> Hi Paul, all,
>>
>> Now that Paul has updated his examples, I took the time to see what
>> his level 3 list complaint was, and added the notation. Emailing to
>> all as an encouragement to add future examples to the list directly.
>>
>> So. The list already had "free-product" added, and my encyclopedia
>> index didn't contain the amalgamated variant of it, likely since
>> wikipedia doesn't have a standalone page for that. I did a quick
>> search + cursory reading and found that there are three rough synonyms
>> for the same notation - "amalgamated-product",
>> "amalgamated-free-product" and "free-product-with-amalgamation".
>>
>> So I added in an entry with a name and two aliases, the source links
>> from my search, and the nice subscripted infix * operator. I also
>> added the speech hint I found in a phd thesis (though maybe there are
>> better ones?) of:  "amalgamated product of $1 and $3 with $2
>> amalgamated".
>>
>> And now, 5 minutes later, it's in the list and one can imagine it
>> spoken by an AT tool. Relatively painless I would hope.
>>
>> I'll keep this email short, so no CSS comments for now, just this level 3
>> note.
>>
>> Greetings,
>> Deyan
>>
>> On Tue, May 11, 2021 at 3:47 PM Deyan Ginev <deyan.ginev@gmail.com>
>> wrote:
>> >
>> > Hi Paul, all,
>> >
>> > Thanks for the quick CSS writeup! It's still a little difficult to
>> > follow, and can benefit from a fully worked out minimal example (with
>> > an explicit MathML tree and CSS rules as per your preferences).
>> >
>> > That aside, there are multiple open questions, most pressingly:
>> >
>> > 1. How can we set up the Math and CSS working groups on a solid common
>> > footing where **any** constructive collaboration can take place?
>> > 2. Followed by the secondary complication that MathML has been
>> > possible to use in the past without a strict dependence on CSS, so
>> > introducing one for the AT component will also have wider ecosystem
>> > considerations.
>> >
>> > ---
>> >
>> > If (and that's a big if) those can be productively addressed, the
>> > technical considerations about a "selector language for math
>> > notations" are also non-trivial / interesting. Traditionally this has
>> > required a full-blown grammar (e.g. CFG) to do well, since we have a
>> > lot of contextual interplay - balancing fences, repeated delimiters,
>> > n-ary infix operators, and even recognizing full-blown subtrees with
>> > holes (e.g. Leibniz's notation, falling factorial, Prüfer group, ...).
>> > Present day CSS is very ill-equipped to do these kinds of selections.
>> > I'll also pose this technical challenge to our prior topic of
>> > discussing "subject area" rule sets. For these conceptual "subject
>> > definition sets" one also needs such a selection mechanism for
>> > targeting notational primitives.
>> >
>> > Annotating every single MathML node with an intent attribute clearly
>> > feels redundant and verbose, but I think it is a very solid baseline
>> > for what is allowable by the spec. Similarly to how you don't have to
>> > add a CSS "style" attribute to every HTML node, but if you really
>> > wanted to - you could. What you lose in verbosity you gain in AT
>> > runtime simplicity - you don't need any advanced lookup/logic when the
>> > intent is already spelled out. How you get the annotations on the tree
>> > is then a burden shifted to the authoring tools / remediating author.
>> > And some tools are very well-equipped for this kind of thing, have
>> > pre-existing macro/palette interfaces, grammar capabilities, etc.
>> >
>> > I don't think the fully verbose variant is the best we can do, but it
>> > definitely seems like the right "flat" target. For a browser analogy,
>> > the inspector tools for CSS have a "Rules" (or "Styles") and
>> > "Computed" tabs, where the "Computed" one contains all fully
>> > flattened/instantiated rules, derived from all CSS rules applicable to
>> > the node inspected. The big question is whether we can achieve this
>> > model with the level of technical work we're prepared to invest here.
>> >
>> > Thanks for investigating the CSS angle,
>> > Deyan
>> >
>> > P.S. GMail had flagged the original email as "spam" for me, for some
>> > unknowable reason, so there is a chance the original post had a
>> > limited audience.
>> >
>> > On Wed, May 5, 2021 at 6:01 AM Paul Libbrecht <paul@hoplahup.net>
>> wrote:
>> > >
>> > > Hello community,
>> > >
>> > > We discussed in the last group call that CSS could possibly play a
>> role to support the intent attribute. I’ve sketched a few thoughts inside
>> this page in the form of a “what if…”:
>> > > https://mathmlmuses.netlify.app/intents-as-css-styles/
>> > >
>> > > … and got surprised in writing that this seems desirable…
>> > >
>> > > Thanks for thoughts.
>> > >
>> > > Paul
>> > >
>> > > On 2 May 2021, at 3:31, Neil Soiffer wrote in Minutes of the call 29
>> April 2021:
>> > >
>> > > NS: A.T. does  not see CSS information. It just sees the MathML. You
>> may not be able to globally change speech behavior with CSS technology.
>> > >
>> > > NS: Should we say that the A.T. must look at CSS as well as MathML?
>> (this is often not the case or not doable thus far)
>>
>>

-- 
Brian Kardell :: @briankardell :: bkardell.com