From: William F Hammond <hammond@csc.albany.edu>

Date: Wed, 28 May 2008 18:10:34 -0400

To: www-math@w3.org

Message-ID: <i7hccirsf9.fsf@hilbert.math.albany.edu>

Date: Wed, 28 May 2008 18:10:34 -0400

To: www-math@w3.org

Message-ID: <i7hccirsf9.fsf@hilbert.math.albany.edu>

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? -- BillReceived on Wednesday, 28 May 2008 22:18:45 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:40 UTC
*