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

I also like the "mfenced". Vertical stretchies with <mo> are difficult to
understand from the point of view of someone who uses a formula editor.
What people understands when editing is that an open and close parenthesis
grows according to what's inside. Thus, for people who do editors, the
preferred feature is the mfenced.

There is also a VERY important aspect which is BACKWARD COMPATIBILITY.
There are plenty of formulas that use mfenced. Both Microsoft Word and
WIRIS (I'm not able to test MathType at this moment) use the mfenced tag
for stretchy parenthesis.

Losing backward compatibility will result that a lot of formulas stop
working. This would yield a lack of trust on the MathML specification.
Please do not commit that mistake!

Dani



-----Original Message-----
From: William F Hammond [mailto:whammond@albany.edu] On Behalf Of William
F Hammond
Sent: martes, 26 de julio de 2016 20:09
To: www-math@w3.org
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element


I have always liked "mfenced".

I think it is useful in catching translations from well-designed LaTeX
profiles.

I think it is useful to preserve as much semantic information as might be
reasonably found, or at least derived by standard inference, in a
well-designed LaTeX profile.  Toward this end I think it will be good to
be able to continue making a distinction between the two concepts that
might in a computer algebra system be called "expression sequence", on the
one hand, and "list", on the other.

I have always argued against the strict equivalence.  Less harm would be
done simply by relaxing that lousy standard than by pulling mfenced.  I
have mostly kept quiet my complaints about processing decisions in the
MathML world, e.g., <mo>, based on CDATA values, in effect, using CDATA as
SDATA.  Really, such practice breaks the paradigm of XML.
In many cases my response to the loss of SDATA is to provide empty,
sometimes defined-empty elements, to replace what might otherwise have
been SDATA.  The gain with this is that element content may contain markup
whereas attribute values may not.

In that direction another approach would be to deprecate the "open",
"close", and "separators" attributes in favor of new elements that replace
them.  That is, provide an mfenced head, e.g., <mfhead>, and provide
empty-element names for things allowed as openers, closers, and
separators, which are allowed as children of <mfhead>.  The members of the
list could then be simply the children of <mfenced> that follow <mfhead>,
with the presence of <mfhead>.

I will read more carefully through FW's long list of processing concerns
in a few weeks.

In the end, the design of an XML markup is about the organization of
processing.  This requires time for thought and experimentation.

                                    -- Bill

Received on Tuesday, 26 July 2016 19:11:56 UTC