Re: [MathML4] Deprecation/Removal of the mfenced element
Stephen Watt <[email protected]> Tue, 26 Jul 2016 08:49:04 -0400
| Newsgroups | gmane.comp.web.mathematics |
|---|---|
| Message-ID | <CALozgsh8m09oSz-gGg90p8onxuA_q5KktYeakBU+LfMOzLkYPg@mail.gmail.com> |
--001a1140913c77adb30538895351 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, no. I did not mean expanding to plain text. I meant the leaf elements would be tagged. So the example is <mrow> <mo>[</mo> <mi>a</mi> <mo>,</mo> <mi>b</mi> <mo>[</mo> <mi>f</mi> <mo>]</mo> <mi>d</mi> <mo>,</mo> <mi>e</mi> <mo>]</mo> </mrow> or "an mrow containing [a, b [ f ] d, e]" for easier discussion. I almost agree with you and David that if you put in all the mrows (by hand or by code generation) then there is no information loss between an mfenced and a 3 element mrow. We would have to require that syntactically paired operators be given as the first and last elements of a three element mrow. But do we ALWAYS want three element mrows with first and last elements being operators to be treated as mfenced is? What about [ x ) or [ + ] or, my personal favourite, - x ! Secondly, can we really rely on all mathml to put in all the grouping mrows? We don't require it so I don't think we can count on it. We also have to allow for fence separators that stretch such as < x | Q | y > or ( a | b ). In the <x | Q | y> example, we would want the bars to stretch in the quantum mechanical case, but not if we were talking about the expected value of x times the absolute value of Q times y. So we would have to have <mrow> \langle x | Q | y \rangle </mrow> vs <mrow> \langle <mrow> x <mrow> | Q |</mrow> y </mrow> \rangle </mrow> where \langle and \rangle mean the relevant unicode points and leaf tagging is implied. What is the rule? An <mrow> with the first and last elements being operators all middle operators taken as separators? This works for < x | Q | y > but not for -x - y + 3! How would you handle these cases? Stephen On Tue, Jul 26, 2016 at 3:09 AM, Fr=C3=A9d=C3=A9ric WANG <[email protected]= > wrote: > Le 26/07/2016 =C3=A0 00:00, Stephen Watt a =C3=A9crit : > > I see your point, but have to say that I am not really satisfied with > > the current spec language regarding equivalence. Mfenced can also > > give information about grouping that is lost with the mrow > > formulation, e.g. an mrow containining [a, b [ f ] d, e] may be a > > list of three things or a pair of half open intervals with an f in the > > middle. > So the only thing you are saying is that expanding to plain text without > explicit grouping implies loss of information compared to using mfenced. > That's true, but that's not my point. If you really follow the expansion > rules in MathML3 instead of using plain text then you see that nothing > is lost in your example and that the mfenced element is again useless. > > Certainly, one can write <mo>+<mrow> without proper grouping as that's > unfortunately often the case for markup generated from text > representation like TeX or ASCII. But the existence of an mfenced > element in MathML does not magically force converters or people to do > this grouping. > > > --001a1140913c77adb30538895351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Sorry, no. =C2=A0 I did not mean expanding to plain text. = =C2=A0=C2=A0<div><br></div><div>I meant the leaf elements would be tagged. = =C2=A0 So the example is=C2=A0</div><div><br></div><div><mrow> <mo= ><span style=3D"font-size:12.8px">[</mo> <mi>a</mi> &l= t;mo>,</mo> =C2=A0<mi>b</mi> <br><mo>[</mo>= ; <mi>f</mi> <mo>]</mo> <mi>d</mi> <= mo>,</mo> <br><mi>e</mi> <mo>]</mo> </m= row></span></div><div><span style=3D"font-size:12.8px"><br></span></div>= <div><span style=3D"font-size:12.8px">=C2=A0</span><span style=3D"font-size= :12.8px">or "an mrow containing=C2=A0</span><span style=3D"font-size:1= 2.8px">[a, b [ f ] d, e]" =C2=A0for easier discussion.</span><div><spa= n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size= :12.8px">I almost agree with you and David that if you put in all the mrows= (by hand or by code generation) then there is no information loss between = an mfenced and a 3 element mrow. =C2=A0=C2=A0</span></div><div><span style= =3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px= ">We would have to require that syntactically paired operators be given as = the first and last elements of a three element mrow. =C2=A0 =C2=A0But do we= ALWAYS want three element mrows with first and last elements being operato= rs to be treated as mfenced is?=C2=A0 What about [ x ) =C2=A0or [ + ] or, m= y personal favourite, =C2=A0 - x !=C2=A0</span></div><div><br></div><div><s= pan style=3D"font-size:12.8px">Secondly,</span><span style=3D"font-size:12.= 8px">=C2=A0can we really rely on all mathml =C2=A0to put in all the groupin= g mrows? =C2=A0 =C2=A0We don't require it so I don't think we can c= ount on it. =C2=A0</span></div><div><br></div><div><span style=3D"font-size= :12.8px">We also have to allow for fence separators that stretch such as = =C2=A0< x | Q | y > or =C2=A0( a | b ).=C2=A0</span><span style=3D"fo= nt-size:12.8px">=C2=A0In the <x | Q | y> example, we would want the b= ars to stretch in the quantum mechanical case, but not if we were talking a= bout the expected value of x times the absolute value of Q times y. =C2=A0 = =C2=A0 So we would have to have</span></div><div><span style=3D"font-size:1= 2.8px"><br></span></div><div><span style=3D"font-size:12.8px"><mrow> = \langle x | Q | y \rangle </mrow> =C2=A0vs</span></div><div><span sty= le=3D"font-size:12.8px">=C2=A0<mrow> \langle =C2=A0<mrow> x =C2= =A0<mrow> | Q |</mrow> y </mrow> \rangle </mrow> = =C2=A0=C2=A0</span></div><div><br></div><div>where \langle and \rangle mean= the relevant unicode points and leaf tagging is implied.</div><div><br></d= iv><div>What is the rule? =C2=A0 An <mrow> with the first and last el= ements being operators all middle operators taken as separators? =C2=A0 Thi= s works for =C2=A0< x | Q | y > =C2=A0but not for -x - y + 3!</div><d= iv><br></div><div>How would you handle these cases?</div><div><br></div><di= v>Stephen</div><div><span style=3D"font-size:12.8px"><br></span></div><div>= <br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu= ote">On Tue, Jul 26, 2016 at 3:09 AM, Fr=C3=A9d=C3=A9ric WANG <span dir=3D"= ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">fred.wang@f= ree.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class= =3D"">Le 26/07/2016 =C3=A0 00:00, Stephen Watt a =C3=A9crit :<br> > I see your point, but have to say that I am not really satisfied with<= br> > the current spec language regarding equivalence.=C2=A0 =C2=A0 =C2=A0Mf= enced can also<br> > give information about grouping that is lost with the mrow<br> > formulation, e.g. an mrow containining [a, b [ f ] d, e]=C2=A0 =C2=A0m= ay be a<br> > list of three things or a pair of half open intervals with an f in the= <br> > middle.<br> </span>So the only thing you are saying is that expanding to plain text wit= hout<br> explicit grouping implies loss of information compared to using mfenced.<br= > That's true, but that's not my point. If you really follow the expa= nsion<br> rules in MathML3 instead of using plain text then you see that nothing<br> is lost in your example and that the mfenced element is again useless.<br> <br> Certainly, one can write <mo>+<mrow> without proper grouping as= that's<br> unfortunately often the case for markup generated from text<br> representation like TeX or ASCII. But the existence of an mfenced<br> element in MathML does not magically force converters or people to do<br> this grouping.<br> <br> <br> </blockquote></div><br></div> --001a1140913c77adb30538895351--