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

Hi.

I can answer why mfenced was originally introduced and why it is defined as equivalent to the mrow construct.

The mrow construct came first and was part of the earliest drafts of presentation markup.  As David noted, it is more powerful than left/right bracing constructs, accommodating posts naturally and so on.  Also, the mrow construct is much better suited to graphical editing applications, since it build up in a natural incremental way.  Left/right constructs are typically invalid until the matching fence is added.  You can address that by inserting both fences at once, i.e. using a fence template in graphical editing parlance.  But even so, the user must think ahead and pick a template first and then fill in its contents, where as the natural flow of one's thought is "(, a, over, b, ), and oh yeah make the fences stretch".   

However, there was a contingent that felt the left/right/template model was so widely established in current practice from TeX and many graphical editors that it rose to the level of an independent notational schema.  That camp also argued that it was easier to infer semantics from mfenced than having to precedence parse mrows.  The point here is that an mfenced can be enforced by DTD, whereas proper nesting of mrows to avoid fence matching ambiguity can only be enforced by convention, and lies outside the realm of XML validation.

So in the end was the compromise that both were allowed and required to be treated as equivalent.  The editor camp didn't want to be compelled to use mfenced.  The converters and semantic inference people didn't want to have to parse mrows and rely on good authoring tools to ensure proper nesting.  So now neither has to, but they do have to pay the tax of accepting the other form.  They were defined to be equivalent so that you could, if appropriate for your application, preprocess away whichever one was a hassle for you, without information loss.

If I recall correctly, the separators attribute was introduced to accommodate things like hypergeometric function notations like [a,b,c;d]  or bra-ket notations like <a|c>, and I think there were a number more like that.  I think I was the original proposer of the current syntax, and I wish I hadn't.  It was a blunder.  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.

Speaking personally, I don't think mfenced is especially closely connected with lists, Maple's behavior notwithstanding.  Both the mrow and mfenced constructs are purely presentational and will be used and abused in all kinds of ways in practice. Any attempt to infer semantics from presentation has to deal with that, unless the context is restricted in some way, e.g. by Maple, or gellmu, or MathType, etc. 

Speaking of abuse, I'd say putting in a plus for the separator in an mfenced to represent (a + b) is a fairly spectacular example.  I suspect the percentage of semantic inference engines that would get that right is small :-)  The spacing around the plus would likely be off too, but that is a minor point.

--Robert


Rober Miner
W3C Math WG co-chair
 
Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California 90802
USA
Main:   (562) 432-2920
Direct: (651) 223-2883
Fax:    (651) 292-0014
robertm@dessci.com
www.dessci.com


> -----Original Message-----
> From: www-math-request@w3.org [mailto:www-math-request@w3.org] On
> Behalf Of William F Hammond
> Sent: Wednesday, May 28, 2008 5:11 PM
> To: www-math@w3.org
> Subject: Re: mfenced as a special case of mrow -- Was: angle brackets
> in math
> 
> 
> David Carlisle writes:
> 
> > you mean in the sense of xml canonicalisation?
> 
> Yes, and I conceded that it could be dismissed.
> 
> >> in effect, mapped the mfenced to an mrow because it took the docs
> more
> >>  seriously  than I have been taking them.
> >
> > there is no semantic difference between an mfenced and its equivalent
> > mrow. The level to which a system can infer any semantics from
> > presentation mathml is an issue for that application not (directly)
> an
> > issue for mathml itself.
> 
> I'm not suggesting that the issue of such inference be addressed
> formally in MathML at this stage.
> 
> >> Presentation markup is only minimally semantic, but I am concerned
> >> about conservation of semantics to the extent possible.
> >
> > agreed.
> 
> I'm glad to hear that.
> 
> >> An mfenced represents the mathematical concept of list.  An mrow
> >> represents the concept of mathematical expression.
> >
> > disagree entirely. mfenced and mrow have the same implied semantics.
> > I'd typically use mfenced in marking up  x * (a + b)  in what sense
> > (a + b) a "list" rather than a "mathematical expression".
> >
> >> Why is it thought to be important to _define_ mfenced to be
> >> effectively an alias for profiled usage of mrow?
> >
> > It's been in the language so long it predates me being in the working
> > group, so I can only report the way it is, not the discussions that
> went
> > in to that design:-)
> 
> ** Does anyone remember? **
> 
> Absent an answer to that question, my interpretation of this as being
> directive only for browser class user agents is reasonable.
> 
> Making one xml element effectively an alias for profiled usage of
> another is so bizarre as an XML construction that it needs a clear
> rationale.
> 
> Again, let me say I'm OK with it as directions for screen rendering.
> 
> But any kid who starts typing MathML and enters
> 
>     <mrow><mi>a</mi><mi>b</mi></mrow>
> 
> and in his web browser sees
> 
>               ab
> 
> and then enters
> 
>     <mfenced><mi>a</mi><mi>b</mi></mfenced>
> 
> and sees
>              (a,b)
> 
> and then finds the three attribute names "open", "close", and
> "separators" is likely to make the inference that it's a list
> constructor.
> 
> 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)?
> 
> But I suppose this thread is rather late for version 3.  Looking ahead
> would you want to think about deprecating mfenced in version 4 and
> introducing mlist?
> 
> 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 so as to finesse the confusion
> with balancing pairs.  Or maybe introduce new variant attributes
> "Open" and "Close" whose values are symbolic rather than literal.
> 
> Is someone in a position to say whether this would be too hard for
> user agents?
> 
>                                     -- Bill
> 
> 
> 
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.24.1/1470 - Release Date:
> 5/28/2008 7:20 AM
> 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 269.24.1/1470 - Release Date: 5/28/2008 7:20 AM

Received on Thursday, 29 May 2008 04:44:17 UTC