on "strict" MathML

While I believe that the idea of defining a "strict" MathML is an
excellent one, I also suspect that the current draft does not properly
reflect the ideas behind the current design of MathML-Content.

MathML2r2 incorporated a major concerted effort to ensure that its
Content-MathML part (in particular, bvar, domainofapplication and
condition qualifiers) was as general and as consistent as we could make
them. Looking back through the archive of www-math, it appears that I
triggered this effort with two long lists of suggested corrections (for
Chapters 2&4:
http://lists.w3.org/Archives/Public/www-math/2003May/0030.html, for
Appendix C:
http://lists.w3.org/Archives/Public/www-math/2003May/0036.html) and an
accompanying rationale and design idea
(http://lists.w3.org/Archives/Public/www-math/2003May/0042.html). A
month later, Stan Devitt reported to www-math that intensive discussions
had taken place within the working group, and submitted a formal
response to the suggested corrections on the list. Intensive discussions
continued for months, as far as I recall, both within the working group,
on the mailing list, and between Stan and myself, until we were
satisfied with the result, MathML2r2 - Content.

It is my understanding that there are no plans for major changes to that
result, except that a "strict" MathML 3 Content subset is to be defined
that is semantically equivalent to it in well-defined ways. This
formalized subset is to play a major role in an effort to unify
MathML-Content and OpenMath, if I understand correctly.

I just submitted a paper to the OpenMath Workshop
(http://www.ualberta.ca/~strotman/publications/omw2009-as.pdf is a
draft) that attempts an analysis of the assumptions and principles that
shaped MathML2r2 in 2003, and compares these with the current draft of a
"strict" MathML 3 - Content.

To summarize the result:
 -  the current draft does not match the intended semantics of MathML2
Content, and by implication (if I got this
    right), MathML3 Content.
 -  several corrections are suggested to fix this:
    - recognize domainofapplication as a first-class citizen of strict MML
    - do not rename apply to bind, ever
    - do not restrict the heads of apply, ever
Several alternative outlines of a strict MathML are offered and discussed.

The paper does not discuss "big" operators, but I would like to draw
attention to my 2003 suggestion of introducing an operator into MathML
that lifts a "small" to a "big" operator, regardless of whether the
small one is predefined as a symbol anywhere, or if it is a symbol at
all. I believe that it would be quite contrary to the spirit of
MathML2r2 to require "big" symbols as heads of apply, but we can discuss
this separately.

The paper does, however, offer up ways that OpenMath could evolve to
match a "strict" MathML that would follow these suggestions - basically
by adding a first-class equivalent of domainofapplication to the language.

As always, my apologies for voicing my concerns at the final hour.

Best regards,

  --  Andreas

PS: My thanks to James Davenport for urging me to offer up this analysis
for discussion on this mailing list now rather than later, and for
allowing me to put up a copy on the web.

Received on Thursday, 14 May 2009 03:21:18 UTC