- From: Thomas E. Leathrum <leathrum@jsu.edu>
- Date: Thu, 15 Nov 2007 10:50:34 -0600
- To: www-math@w3.org
I am particularly interested in the material in the working drafts for MathML3 regarding Content MathML. To get some idea of my interests, take a look at the following links (the first is an article in MAA's Journal of Online Math and its Applications): http://www.maa.org/joma/Volume7/Leathrum/index.xml http://cs.jsu.edu/mcis/faculty/leathrum/mathtrans/mathtrans.xml Before I ask my questions, let me say first that the October working draft is *much* better than the April working draft. There are still a few formatting issues (such as the section numbering in Appendix C) and a few apparent inconsistencies (e.g. the example in Section 4.2.7 Qualifiers uses an "intexp" operator, but C.3.4(1-4) give only "int," "defint,", "defintset," and "intalg" -- perhaps the "intexp" should be "intalg"?), but far fewer such things than in the earlier version. I understand that these are drafts -- such problems will need to be worked out before the document becomes a recommendation, but there are more important things to worry about right now. But for the purposes of being prepared to bring my translator software up to CMML3 standards when the working draft is finished, I have two important questions: 1) Will there be a precise decision procedure for deciding whether to use "apply" or "bind"? Do you use "bind" whenever there is a "bvar", or is there a fixed set of operators (e.g. "int," "forall") that will require "bind"? The material about symbol roles specified in the content dictionaries (Section 4.5.4) indicate that operators can take either the binder role or the application role, but not both -- and yet, specifying no role implies that the operator can be used either way. Having a fixed set of operators that require "bind" seems problematic to me, since some operators (e.g. "union") would seem to make sense either way. On the other hand, requiring "bind" whenever there is a "bvar" would lead pretty quickly to some nonsensical code as well, when a "bvar" is applied to an operator that doesn't support it -- if the outer environment is still "apply," the "bvar" can be safely ignored, but not so if using "bind." 2) Will the "pragmatic" form of CMML3 ultimately be deprecated in favor of the more verbose "canonical" form? For my software, the "pragmatic" form would be the more realistic way to handle the source syntax for the translator, but I could add some code (or some sort of external association similar to the content dictionaries) to make sure the output is "canonical." On the other hand, I suspect that an XSLT stylesheet (similar in some ways to ctop.xsl) could translate pragmatic to canonical. However, relevant to the first question, the pragmatic form uses "apply" as in CMML2 in places where the canonical form would require "bind," which for my purposes just muddies the waters even more. Regards, Tom Leathrum MCIS Dept. Jacksonville State Univ.
Received on Friday, 16 November 2007 14:46:34 UTC