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

Le 26/07/2016 à 14:49, Stephen Watt a écrit :
> 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. 
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>   
>
> 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.