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

Received on Wednesday, 28 May 2008 22:18:45 UTC