Re: [MathML4] Deprecation/Removal of the mfenced element

Frédéric WANG <[email protected]> Tue, 26 Jul 2016 15:07:07 +0200
Newsgroups gmane.comp.web.mathematics
Message-ID <[email protected]>
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ISJUK0C7GNv5AUo1j8jAKWTMW8o9l51pS
Content-Type: multipart/mixed; boundary="ffqM310oGiOdLjCSuuL2SRArrdvF1tEMt"
From: =?UTF-8?B?RnLDqWTDqXJpYyBXQU5H?= <[email protected]>
To: Stephen Watt <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element
References: <[email protected]>
 <CALozgshVE0bwjs9LqsnvVNYX=b_bLjOrcM=dNX4=_7LeB0A3fA@mail.gmail.com>
 <[email protected]>
 <CALozgsh8m09oSz-gGg90p8onxuA_q5KktYeakBU+LfMOzLkYPg@mail.gmail.com>
In-Reply-To: <CALozgsh8m09oSz-gGg90p8onxuA_q5KktYeakBU+LfMOzLkYPg@mail.gmail.com>

--ffqM310oGiOdLjCSuuL2SRArrdvF1tEMt
Content-Type: multipart/alternative;
 boundary="------------1D8F511E162F536052B11B7F"

This is a multi-part message in MIME format.
--------------1D8F511E162F536052B11B7F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 26/07/2016 =C3=A0 14:49, Stephen Watt a =C3=A9crit :
> But do we ALWAYS want three element mrows with first and last elements
> being operators to be treated as mfenced is?
No, we just follow the equivalence given in the specification with mrow
& mo elements and separator & fence attributes (whose default value is
given in the operator dictionary). If you don't want to obtain this
interpretation, then you can change the grouping or use explicit
attributes to override the operator dictionary).
> 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.=20
This is a separate issue. As I said, the existence of an mfenced element
won't make people or tools magically do proper grouping. So if we don't
remove the whole <mrow>+<mo> stuff then mfenced is useless.
>
> 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>  =20
>
> 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!
Not sure I understand all of these. Again, we have the separator
properties in the operator dictionary whose default value we can
override via an explicit attribute. The stretchiness is controlled by
the strechy property, which is also given from the operator dictionary
or an explicit attribute. But actually your comment exhibit another
issue with mfenced I forgot to mention: you can not override the default
properties of its operators. On the other hand <mo> gives more flexbility=
=2E

--------------1D8F511E162F536052B11B7F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 26/07/2016 =C3=A0 14:49, Stephen Wa=
tt a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:[email protected]=
l.com"
      type=3D"cite">
      <div dir=3D"ltr"><span style=3D"font-size:12.8px">But do we ALWAYS
          want three element mrows with first and last elements being
          operators to be treated as mfenced is? <br>
        </span></div>
    </blockquote>
    No, we just follow the equivalence given in the specification with
    mrow &amp; mo elements and separator &amp; fence attributes (whose
    default value is given in the operator dictionary). If you don't
    want to obtain this interpretation, then you can change the grouping
    or use explicit attributes to override the operator dictionary).<br>
    <blockquote
cite=3D"mid:[email protected]=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><span 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 grouping mrows? =C2=A0 =C2=A0We don=
't require it
              so I don't think we can count on it.=C2=A0 <br>
            </span></div>
        </div>
      </div>
    </blockquote>
    This is a separate issue. As I said, the existence of an mfenced
    element won't make people or tools magically do proper grouping. So
    if we don't remove the whole &lt;mrow&gt;+&lt;mo&gt; stuff then
    mfenced is useless.<br>
    <blockquote
cite=3D"mid:[email protected]=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <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&lt; x | Q | y =
&gt;
              or =C2=A0( a | b ).=C2=A0</span><span style=3D"font-size:12=
=2E8px">=C2=A0In
              the &lt;x | Q | y&gt; 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. =C2=A0 =C2=A0 So we would have to have<=
/span></div>
          <div><span style=3D"font-size:12.8px"><br>
            </span></div>
          <div><span style=3D"font-size:12.8px">&lt;mrow&gt; \langle x | =
Q
              | y \rangle &lt;/mrow&gt; =C2=A0vs</span></div>
          <div><span style=3D"font-size:12.8px">=C2=A0&lt;mrow&gt; \langl=
e
              =C2=A0&lt;mrow&gt; x =C2=A0&lt;mrow&gt; | Q |&lt;/mrow&gt; =
y
              &lt;/mrow&gt; \rangle &lt;/mrow&gt; =C2=A0=C2=A0</span></di=
v>
          <div><br>
          </div>
          <div>where \langle and \rangle mean the relevant unicode
            points and leaf tagging is implied.</div>
          <div><br>
          </div>
          <div>What is the rule? =C2=A0 An &lt;mrow&gt; with the first an=
d
            last elements being operators all middle operators taken as
            separators? =C2=A0 This works for =C2=A0&lt; x | Q | y &gt; =C2=
=A0but not
            for -x - y + 3!</div>
        </div>
      </div>
    </blockquote>
    Not sure I understand all of these. Again, we have the separator
    properties in the operator dictionary whose default value we can
    override via an explicit attribute. The stretchiness is controlled
    by the strechy property, which is also given from the operator
    dictionary or an explicit attribute. But actually your comment
    exhibit another issue with mfenced I forgot to mention: you can not
    override the default properties of its operators. On the other hand
    &lt;mo&gt; gives more flexbility.<br>
  </body>
</html>

--------------1D8F511E162F536052B11B7F--

--ffqM310oGiOdLjCSuuL2SRArrdvF1tEMt--

--ISJUK0C7GNv5AUo1j8jAKWTMW8o9l51pS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXl2B7AAoJEL8nnpULUzQOmSIP/2f8ZSaY9V+YruJrYpES+pn5
uUaPPNjbGU1jmzOUmsM/W3VLfMnpV3YCgklyNlDFvfdo6l01fV51Dr6eVVPFJBOh
4MgHEYxa4ZIz5NUc1anLZk0jmpQlp3ggJrajyluqGGLeS1yxAiu4WywQkzoIUaFI
UCVc8/al5Xm2hV1wdBVfwWmUuWh33sPYxTm7WG5rqPCryuYtFg5Wtc6kmFznDdtD
dtlUbXZVV5EjODz7Wkl6vBWS45NU2cRFQcVelfDUVlapryuE7XycnrBapNdbAeY1
sGF9GZrB0oAK9BMXLkxbJRg+t0UN/P0kb20+ccL+f9yn9/fxm8O64NAgZlEeYqe+
mLvxtVK+sPAUW2Bk/l1QiHMQtmT01mES43HzxfBe71szIbRuukMnro3jpDsf4qHy
so7NQhmDeK/qtzz/rG3KlAN5r9bk8APTUxiBRLh+ulVi2Zi06dW3DsEbgJSQ2DWN
61QTiQLnylzwjCkqOUtEu03IGORr5BQ4ao63/jn/7jIaq7tPD90xN/JDj8aqBXw4
6he1rWOFBh1XCbT0Nv8TRAK2sgHT5uwm7X/UAwloBPKm+CEnPBS9qzItkhCCCJDA
QEjUsrVPdvDRG6EB2kUU7P5I0LRiECEanQBNG0sQr7zv9han4X+EghvMRhyjTSCE
Tt4muPv7DaDYuLXVx4tt
=uFnk
-----END PGP SIGNATURE-----

--ISJUK0C7GNv5AUo1j8jAKWTMW8o9l51pS--