RE: [EXTERNAL] Semantic Markup: mrow's are needed

Isn't the point to tell developers and authors the preferred way
to write their content so that it can be interpreted unambiguously?

If someone puts out content that does not follow the recommendations,
then we are in the exact same situation as currently:  heuristics
and guesswork will attempt to figure out the meaning and then will
use that to try to pronounce correctly.  That is all an author
can expect, if they have not followed the guidelines.

If an implicit mrow really is unambiguous in a particular situation,
AND it is possible to mark up the semantics on the explicit
content, then it seems okay to leave out the mrow.  But if the lack
of an mrow leaves no good place to indicate the semantics (or, if
that causes us to be in the undesirable situation of requiring a
multiplicity of "correct" ways to mark it up), then the principles
we have discussed point to requiring the mrow.  That is, requiring it
if the author wants to follow the rules and ensure that the meaning
is unambiguous.

In Neil's example of "extra layer of mrows around the postfix
factorials" it was not clear to me if those mrow's are where the
semantic information should go.  This is the point/question I was
trying to make above:  if the unambiguous implicit mrow's are where
the semantic information should go, then we can't leave them out.

My understanding is that we are trying to specify how authors
can describe meaning, to not have too many different ways to do it,
and to not say what happens if an author chooses not to make
content that meets the accessibility guidelines.  Have I said that
correctly?


On Fri, 26 Jun 2020, Murray Sargent wrote:

> 
> I guess I’m used to parsing UnicodeMath and LaTeX and am not confused by the examples below at all. It’s easy to add the
> extra <mrow>’s if need be. Being mathematically inclined, I like succinct notations. Marking things up with lots of
> syntactic sugar that can be easily inferred seems to be a step backward and introduces complexity that can be error
> prone. If the usual operator precedence rules are to be overruled, then that’s when you need to add the extra <mrow>’s.
> And I really like implicit <mrow>’s since they are unambiguous and facilitate reading MathML.
> 
>  
> 
> In this vein, we really need to define a set of defaults that apply to K-12 math. Explicitly saying that an mfrac is an
> ordinary fraction seems crazy and error prone. Furthermore we have to handle MathML that doesn’t have any such extra
> markup and we can already do so reliably. Only non-default expressions need special markup.
> 
>  
> 
> One other idea: I think the main goal is to be able to speak math expressions correctly. Being able to compute
> non-default math expressions is a more advanced goal that’s worth pursuing but is clearly harder and shouldn’t delay our
> coming up with a set of speech hints.
> 
>  
> 
> Thanks,
> 
> Murray
> 
>  
> 
> Sent from Mail for Windows 10
> 
>  
> 
> From: Neil Soiffer
> Sent: Friday, June 26, 2020 7:40 AM
> To: public-mathml4@w3.org
> Subject: [EXTERNAL] Semantic Markup: mrow's are needed
> 
>  
> 
> We have talked a little about needing proper mrow structure in order to mark up prefix/posfix/infix operators. For
> example, the following can not be semantically marked up:
> 
> <mrow>
> 
>   <mi>m</mi>
> 
>   <mo>!</mo>
> 
>   <mi>n</mi>
> 
>   <mo>!</mo>
> 
> </mrow>
> 
>  
> 
> It needs an extra layer of mrows around the postfix factorials in the mrow.
> 
> <mrow>
> 
>   <mrow>
> 
>     <mi>m</mi>
> 
>     <mo>!</mo>
> 
>   </mrow>
> 
>   <mrow>
> 
>     <mi>n</mi>
> 
>     <mo>!</mo>
> 
>   </mrow>
> 
> </mrow>
> 
>  
> 
> Here's a case we haven't talked about: implicit mrows.
> 
> <msqrt>
> 
>   <mi>n</mi>
> 
>   <mo>!</mo>
> 
> </msqrt>
> 
>  
> 
> There is no place to markup the factorial here either. Implicit mrows don't work for semantic markup.
> 
>  
> 
> Given what MathML generators typically produce, I think this pretty much forces the need for a canonicalization tool for
> anyone wanting to hand-remediate MathML. For a tool that wants to infer the semantics, it seems necessary also.
> 
>  
> 
> More directly actionable though is what we should say in a MathML 4 specification. Specifically,
>
>  *  Should we discourage or maybe even deprecate implicit mrows?
>  *  Should we have stronger language encouraging "proper" mrow structure?
> 
>  
> 
> 
>