- From: William F Hammond <hammond@csc.albany.edu>
- Date: Wed, 28 May 2008 14:34:16 -0400
- To: www-math@w3.org
David Carlisle <davidc@nag.co.uk> writes: >> I hope you are not saying that _any_ processor, e.g., a processor trying >> to upgrade presentation mathml to content mathml should first translate >> every mfenced to mrow in the manner described. > > Whether or not it converts one to the other, any mathml processor should > treat these two forms the same way. > mfenced is defined to be a syntactic shorthand for a particular > combination of mrow and mo. One possible way of ensuring that the two > forms are processed in the same way is to do a pre-pass that expands out > mfenced, but that isn't required (or even a testable condition, since > it's an implementation detail). Why do you see a problem with this, it's > been specified this way since the earliest drafts of mathml 1? Example 1. An xml normalizer. Surely that should not translate mfenced to mrow. OK, so one says that an xml normalizer is not a mathml processor. (But still I'm frowning.) Example 2. Get in Maple. Make a list, say [a,b,c]. Then call MathML[ExportPresentation] . I see the obvious mfenced string. But if I then call MathML[Import], there is semantic loss. Without seeing the source, I suspect that the underlying Maple code has, in effect, mapped the mfenced to an mrow because it took the docs more seriously than I have been taking them. Maybe somebody here knows. It's fine for browser-class processors. Presentation markup is only minimally semantic, but I am concerned about conservation of semantics to the extent possible. An mfenced represents the mathematical concept of list. An mrow represents the concept of mathematical expression. An expression with a single first order subexpression is essentially the same thing as that subexpression but not so for a list with a single component. Why is it thought to be important to _define_ mfenced to be effectively an alias for profiled usage of mrow? -- Bill
Received on Wednesday, 28 May 2008 18:34:53 UTC