Re: mfenced as a special case of mrow -- Was: angle brackets in math

As I've said before, I think that presentation mathml trees should match
the tree structure of actual mathematics to the extent possible within
the scope of what we been understanding as presentation.

David Carlisle wrote on Wed., May 28 (and Robert Miner also wrote
in this thread but here I'm responding to David's message):

>> Then there's the name of that third attribute.  If things like "+",
>> "*", and "&invisibletimes;" are suitable there, why isn't the name of
>> third attribute "operators" and why isn't the default value of
>> "separators" "&invisibletimes;" (which is the default separator in
>> chalk-talk)?
>
> No you shouldn't use + as the separator but I routinely mark up 
> 1 + (2 + 3) 
> as
>
> mrow
>   mn 1
>   mo +
>   mfenced separators=""
>    mn 2
>    mo +
>    mn 3
>
> or equivalently
>
> mrow
>   mn 1
>   mo +
>   mfenced 
>     mrow
>       mn 2
>       mo +
>       mn 3

OK, I think Robert, you, and I agree that it's an abuse of the attribute
"separators" to use it other than for operators that are separators.

Note that in the second example the number of children of mfenced
changes from three to one.  The second example with one child is
preferable precisely because there are no separators.

A close reading of the version 3 draft from April at section 3.3.8.2
has this (consistent with your examples):

    ... If there are no separator characters provided but some are
    needed, for example if separators=" " or "" and there is more
    than one argument, then no separator elements are inserted at
    all -- ...

(Here "argument" means "child"; perhaps the spec should say "child".)

This clause in the draft (carried over from version 2, I think) is
somewhat at variance with the idea that the attribute "separators"
should only be used for separation of the children of mfenced.

I think it would be better for conservation of structural semantics
and also it would be more intuitive if separators="" were equivalent
to &invisibleComma;, but I notice Robert's point in regard to some DOM
implementations:

    It's awkward to have a microsyntax for the attribute value,
    and there is no good way to say separators="" since one cannot
    tell from some DOM implementations whether the attribute is
    unset or it is set to "".  I think these cases are all handled
    better by the mrow notation.

So I think  1 + (2 + 3)  should be represented by
    mrow
      mn 1
      mo +
      mfenced 
        mrow
          mn 2
          mo +
          mn 3

in strong preference to using separators="".

>> But I still think it _might_ be possible to break slightly from the
>> past and take advantage of mfenced's "open" and "close" for service in
>> the role of LaTeX's \leftX...\rightY

> mapping to \left  \right was probably the intuition behind adding mfenced
> in the first place (although the mathml model of stretching to the size
> of the parent mrow is strictly more powerful than the TeX/mfenced model
> of stretching to the size of the enclosed expression.
>
>> so as to finesse the confusion with balancing pairs.
> ?

In reference to the mess with U-2329 vs. U-27E8 as values for mfenced's
"open", I had suggested the possibility of bringing up a new attribute
"Open" (that would supersede "open" when both are present for processors
understanding both and) that would take symbolic string values like, for
example, "leftParenthesis", "leftBrace", "leftSquarBracket", "leftAngleBracket",
"leftVerticalBar", ...  The idea is to get beyond some of the overloading
of cdata in MathML.

                                    -- Bill

Received on Saturday, 31 May 2008 19:21:48 UTC