# [MathML4] Deprecation/Removal of the mfenced element

15 messages
Open this post in threaded view
|

## [MathML4] Deprecation/Removal of the mfenced element

Open this post in threaded view
|

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

 Hmm. I like . It's an element that says up front what it means. is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element that maps neatly into . The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl.   Our products can generate and input MathML using instead of , but parsing similar to that used for the math linear format is used to convert to .   Murray
Open this post in threaded view
|

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

Open this post in threaded view
|

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

 In reply to this post by Murray Sargent Le 25/07/2016 à 20:39, Murray Sargent a écrit : Hmm. I like . It's an element that says up front what it means. is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element that maps neatly into . The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl.   Our products can generate and input MathML using instead of , but parsing similar to that used for the math linear format is used to convert to . As I see, this is an internal implementation details for the Microsoft Word / LineServices that does not need to be exposed to the Web or handled everywhere. You already have import/export features between MathML to OfficeMath including between / and so I don't see how it helps to have an element when you have to handle the general case anyway. MathML is centered around mrow and mo elements with a dictionary of properties. Whether or not it is a good idea is a separate discussion, but it's a core feature of MathML and is unlikely to be changed in the future. That implies that you must implement these general cases anyway and so mfenced or Office's n-ary elements are duplicate features that do not bring anything new but pain for implementers. I would really be curious to hear progress from the Edge developers regarding the implementation of MathML. I'm dubious that the design of mfenced (renderer text provided in attributes, parsing needed to expand the element, duplicate of mrow+mo) make them happy. -- Frédéric Wang  signature.asc (836 bytes) Download Attachment
Open this post in threaded view
|

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

 In reply to this post by Stephen Watt-3 Le 26/07/2016 à 00:00, Stephen Watt a écrit : > 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 + 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. signature.asc (836 bytes) Download Attachment
Open this post in threaded view
|

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

 On 26/07/2016 08:09, Frédéric WANG wrote: > Certainly, one can write + 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. Yes I agree with Frédéric here that as long as you put all the mrow back in, there is no loss of information in expanding out mfenced. Speaking personally, for this and for the msqrt suggestion (and I suspect others to follow:-) I don't really have a problem if as a browser rendering environment we end up specifying some more minimalist profile of MathML that provides all the rendering functionality needed with less duplication in the markup possibilities. People who are generating mathml and want the markup to closely follow the underlying dom and rendering trees (perhaps to ease interactive behaviour such as selecting subterms) would want to stick to that profile. People wanting to generate (or render existing) MathML 2 and 3 style markup could be provided with a very lightweight javascript that expands out mfenced and does whatever else is needed. This means that mfenced<->mrow/mo equivalence is moved out of the core rendering engines into user javascript space which, if it helps get mathml into the core rendering engines, isn't too high a price to pay, I think. Such a javascript would be at the same level as the original asciimathml   javascript for example, something that takes a specified user input syntax and modifies the DOM to the mathml elements supported on the platform. (The same can of course be done with content mathml) which means that these aspects are not browser specific and the same transformation code can be used across browsers, and just used at the option of the page author if they reference the appropriate code. David ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________
Open this post in threaded view
|

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

Open this post in threaded view
|

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

 In reply to this post by Frédéric WANG Sorry, no.   I did not mean expanding to plain text.   I meant the leaf elements would be tagged.   So the example is  [ a ,  b [ f ] d , e ]  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 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 \langle x | Q | y \rangle  vs  \langle   x   | Q | y \rangle   where \langle and \rangle mean the relevant unicode points and leaf tagging is implied.What is the rule?   An 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?StephenOn Tue, Jul 26, 2016 at 3:09 AM, Frédéric WANG wrote:Le 26/07/2016 à 00:00, Stephen Watt a écrit : > 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 + 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.
Open this post in threaded view
|

## 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 + 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 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 \langle x | Q | y \rangle  vs   \langle   x   | Q | y \rangle    where \langle and \rangle mean the relevant unicode points and leaf tagging is implied. What is the rule?   An 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 gives more flexbility. signature.asc (836 bytes) Download Attachment
Open this post in threaded view
|

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

 In reply to this post by Stephen Watt-3 I really just meant that either of the grouping structures (bra-ket and mean value of an absolute value) could be represented with mrow.  And that I wouldn't necessarily trust an author (or generator) to use the markup choices that you find most meaningful, or that it means what you'd want to assume it is.  They could also write -x! using mfenced. ________________________________________ From: Stephen Watt <[hidden email]> Sent: Tuesday, July 26, 2016 8:49:04 AM To: Frédéric WANG Cc: [hidden email] Subject: Re: [MathML4] Deprecation/Removal of the mfenced element Sorry, no.   I did not mean expanding to plain text. I meant the leaf elements would be tagged.   So the example is [ a ,  b [ f ] d , e ]  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 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 \langle x | Q | y \rangle  vs   \langle   x   | Q | y \rangle where \langle and \rangle mean the relevant unicode points and leaf tagging is implied. What is the rule?   An 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édéric WANG <[hidden email]> wrote: Le 26/07/2016 à 00:00, Stephen Watt a écrit : > 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 + 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.
Open this post in threaded view
|

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

Open this post in threaded view
|

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

 In reply to this post by Stephen Watt-3 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., , 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., , and provide empty-element names for things allowed as openers, closers, and separators, which are allowed as children of .  The members of the list could then be simply the children of that follow , with the presence of . 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
Open this post in threaded view
|

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

 I also like the "mfenced". Vertical stretchies with 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:[hidden email]] On Behalf Of William F Hammond Sent: martes, 26 de julio de 2016 20:09 To: [hidden email] 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., , 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., , and provide empty-element names for things allowed as openers, closers, and separators, which are allowed as children of .  The members of the list could then be simply the children of that follow , with the presence of . 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
Open this post in threaded view
|

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

 On 26/07/2016 20:11, Daniel Marques wrote: > I also like the "mfenced". Vertical stretchies with 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 > > I don't think we should remove (or even deprecate) anything but if there are features that can be omitted from a profile that makes it easier to get mathml into browsers I'm certainly open to discuss that. especially cases that could easily be polyfilled with some lightweight javascript as for mfenced->mrow conversion. If the alternative is not a "full" mathml3 implementation but rather no native implementation at all, and having to implement the entire rendering in javacript then some subset profile should I think be considered even if it complicates the story on compatibility. I think the question is what's the minimum that need to be added to a browser's core rendering code that enables a useful subset of mathml to be rendered directly and the rest via some (relatively) simple javascript support. Anyway I encourage Frédéric to keep posting suggestions, certainly there's no rush to standardise anything at this stage, but keeping track of what works in practice across webkit and gecko (and hopefully one day blink and edge) and specifying that at some point, even if that is a subset of "full" mathml would I think be a useful exercise. David ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________
Open this post in threaded view
|

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

 In reply to this post by Daniel Marques-6 Le 26/07/2016 à 21:11, Daniel Marques a écrit : I also like the "mfenced". Vertical stretchies with 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.  You can definitely use mfenced internally in a formula editor if that improves the UI. However, if that editor is not able to import/export from and to the canonical form described in the MathML recommendation then that's definitely a big flaw in that product. 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!  MathML is not implemented in Edge or Blink, so we currently have to use converters to other formats in order to display formulas in all web rendering engines. Having programs to put MathML in a canonical form for old documents before delivering to web engines is not worse in my opinion. And there is already a lack of trust in the MathML specification because not all browser vendors have shown interest in MathML until recently, because some Math WG members and contributors seemed more interested in a theoretical standard than to consider concrete feedback from web engines developers, because the current MathML specification is too vague to implement high-quality math rendering or handle subtle rendering aspects and because the official MathML test suite is not runnable in browsers' test framework in its current form. The quick work done for the past few months on WebKit and Blink at Igalia showed that by extending / cleaning up the MathML specification and rewriting the test suite, things become much easier for web engines developers to understand, implement and test and for browser vendors to accept a proposal that integrates well in their code base. The goal of the discussion is to (re?)open a constructive collaboration with people involved in the MathML specification and with web engines developers. To come back to mfenced, it has always been the source of bugs in Gecko and WebKit that have added maintenance cost. And it has been a burden during our refactoring in WebKit: we have spent and continue to spend *a lot of time* to avoid breaking the current support and this is as much time that could have been spent on working on more important aspects of the MathML implementation. So although there is no rush for removing that support, we believe it is important to report this issue so that it can be taken into account in the long term. As I said in the menclose thread, with the new layout rules in Blink it's very unlikely that WebKit's mfenced implementation can be accepted by Google reviewers and we do not plan to try it. -- Frédéric Wang  signature.asc (836 bytes) Download Attachment