W3C home > Mailing lists > Public > www-math@w3.org > November 2007

Re: Content MathML 3 in new working draft

From: Michael Kohlhase <m.kohlhase@jacobs-university.de>
Date: Sun, 18 Nov 2007 10:43:22 +0100
Message-ID: <4740093A.2020705@jacobs-university.de>
To: leathrum@jsu.edu
CC: www-math@w3.org

Dear Thomas,

thanks for your feedback, it is always good to see that some people are
interested in Content MathML.

Thomas E. Leathrum wrote:
> 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

This looks interesting, and I will contact you off this thread about
that as well.
> 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.
These are mostly problems that come from the fact that we have not made
much progress on the actual content dictionaries, which we are working
on right now. Therefore any actual names should be treated as very
provisional. In particular in the sensitive area of binding/application
operators like the integral and friends.
> 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"?  
Here we have to distinguish "strict CMathML" vs "pragmatic CMathML". The
former has a clear structure and a direct semantics on form of OpenMath
Objects. The latter has a much freer structure, and covers (almost) all
of what was legal in MathML2; its semantics is given in form of a
translation to strict CMathML. In strict CMathML, <bvar> is  not allowed
in an <apply>, and so <bind> has to be used. In pragmatic CMathML <bvar>
in <apply> is allowed in some cases; the expressions in question
correspond to <bind> expressions in strict CMathML.
> 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.  
We do not intend to have symbols without roles in the MathML Content
Dictionaries, whether we generally want to make the role mandatory is
still a matter of debate.
> 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."
The union example you are referring to here is a (little documented)
feature of MathML2, where we can use the <union/> symbol with two
roles.  But MathML2 also divides the functionally analogous situation
for addition and multiplication into distince symbols: <add/> and <sum/>
(and <times/> and <prod/> respectively). In strict CMathML we have
decided that we will always separate the operators into "small" and
"big" operators (following TeX nomenclature). So there should not be
much confusion.
> 2) Will the "pragmatic" form of CMML3 ultimately be deprecated in
> favor of the more verbose "canonical" form?  
No, it will not. The two variants serve distinct and legitimate
purposes. We consciously changed the names "canonical/legacy" to
"strict/pragmatic" to make this clear. Strict CMathML is more suited for
machine processing, whereas  Pragmatic CMathML is more geared towards
human readability and authorability. So in your case, I indeed guess
that pCMathML is more suitable.
> 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."  
Rather than restricting to strict CMathML as an output format I would
probably add a switch that allows to generate the respective variant.
> On the other hand, I suspect that an XSLT stylesheet (similar in some
> ways to ctop.xsl) could translate pragmatic to canonical.  
We are thinking about providing such a stylesheet as the "official
meaning mapping" for pragmatic CMathML as an appendix to the MathML3 spec.
> 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.
I personally do not think that this is a problem, but maybe you would
care to elaborate.


 Prof. Dr. Michael Kohlhase,       Office: Research 1, Room 62 
 Professor of Computer Science     Campus Ring 12, 
 School of Engineering & Science   D-28759 Bremen, Germany
 Jacobs University Bremen*         tel/fax: +49 421 200-3140/-493140
 m.kohlhase@jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
Received on Sunday, 18 November 2007 09:43:38 UTC

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