# Re: MathML2 2nd WD (long)

• From: Andreas Strotmann <strotman@nu.cs.fsu.edu>
• Date: Mon, 10 Jan 2000 17:12:52 -0500 (EST)
• To: David Carlisle <davidc@nag.co.uk>
• Message-ID: <Pine.GSO.4.10.10001101644360.18646-100000@xi.cs.fsu.edu>
Thanks for the draft!  The second draft already removed some of the errors
I found before I could post them (good job!), but here are some more

--  Andreas Strotmann
=====================================================================

Comments on MathML 2.0 Draft 2

-- 2.1.4: change "quantifier" to "qualifier" in the following:

"A number of functions and operations require one or more quantifiers to
be
well-defined. For example, in addition to an integrand, a definite
integral must specify the limits of integration and the bound variable.
For this reason, there are  several qualifier schemata such as bvar and
lowlimit. They are used with operators such as diff and int. "

-- 4.2.1.2:   garbled sentence(s):

"The most common operations and functions such as <plus/> and <sin/> have
been predefined explicitly as empty elements (see section section 4.4 [The
Content Markup Elements] attributes, and by changing these attributes, the
author can record that a different sort of algebraic operation is
intended. "

-- chapter 4:  can constants like pi or e be defined by csymbol, or only
functions or operators?

-- 4.2.4.1 int: are multiple <bvar>s allowed in <int>?  My guess is, yes.
If so, change

"The bvar schema signifies the variable of integration."

In the same paragraph, it is not an error if the interval schema has two
children; hence rephrase the final sentence.

-- 4.2.4.1 min,max:  the following unique property of min/max is a
singularly bad idea and should be removed:

"min, max
The min and max functions accept a bvar schema in cases where the max or min is being taken over a set
of values specified by a condition schema together with an expression to be evaluated on that set. The
min and max functions are unique in that they provide the only context in which the bvar element is optional
when using a condition; if a condition element containing a single variable is given by itself following a
min or max operator, the variable is implicitly assumed to be bound, and the expression to be maximized or
minimized is assumed to be the identity. The min and max elements may also be applied to a list of values in
which case no qualifier schemata are used. For examples of all three usages, see section 4.4.3.4 [<max/>
and <min/>]. "

--  because the following example is a bad idea (note that both B and C
are, formally, variables!!!):

"<apply><max/>
<condition>
<apply><and/>
<apply><in/><ci>x</ci><ci type="set">B</ci></apply>
<apply><notin/><ci>x</ci><ci type="set">C</ci></apply>
</apply>
</condition>
</apply>"

-- If you're interested, I wrote a short (unpublished) critique of a
similar construct in KIF this spring which shows in great detail how bad
an idea it is.  I'm not sure whether or not it would be good style for me
to post that paper here in toto, but I'll be glad to send it to those who

-- 4.2.5:  I don't know if the following makes much sense.  Boolean
functions can appear anywhere that functions can appear, so the following
should be true for <sin/> as much as for <lt/>:

" It is an error to enclose a relation in an element other than apply or
reln."

-- 4.2.6:   reln is depracated:

"A condition element contains a single child which is typically a reln
element, but may also be an apply or a set
element. The apply element is allowed so that several relations can be
combined by applying logical operators."

-- 4.2.6.1:   the following should do without the <condition>, I think,
though that's probably just a stylistic question.  The idea is that MML
describes a condition as being similar to the left-hand side of
an implication, and in these cases the right-hand side of the implication
is missing.  A rendering rule might say, for example, that conditions are
displayed on the left of a colon character, and the argument on its right,
which is a common way to render these in Germany.

"The following encodes there exists x such that x^5 < 3'.

"<apply><exists/>
<bvar><ci> x </ci></bvar>
<condition>
<apply><lt/>
<apply>
<power/>
<ci>x</ci>
<cn>5</cn>
</apply>
<cn>3</cn>
</apply>
</condition>
</apply>"

-- 4.2.2.1/4.4.1.1 Highschool textbooks commonly use float notation for
rational numbers (some examples are given in the MathML recommendation).
Is there an easy way to do this in MathML?  Can one give an FP
representation of a rational number with <ci type="rational>?  How about a
repeated fraction(term?)?

-- 4.4.1.2    The following contradicts 4.2.2.1 cn (complex or real or no
default).

" The ci element is used to name an identifier in a MathML expression (for
example a variable). Such names are
used to identify mathematical objects. By default they are assumed to
represent complex scalars."

-- 4.4.2.1     csymbols and fns can denote operators: are these operators
allowed to take "named" arguments, too, such as <bvars> and <conditions>?

"Some operators such as diff and int make use of named' arguments. These
special arguments are elements that
appear as children of the apply element and identify parameters' such as the variable of differentiation or the
domain of integration. These elements are discussed further in section ???
Operators taking qualifiers"

I think I argued earlier that it would be a very good idea to allow at
least the bvars (with the general notion of variables bound by the
operator).  With the general meaning of conditions as representing a type
for the bvars, I'd also prefer to have these available for user-defined
operators or other operators or quantifiers not available in MathML.

-- 4.4.2.7     Shouldn't we have the basic sets in MathML (N,Z,Q,R,C)???
As it stands, the default rendering for 1 below as given in the
recommendation is incorrect since nothing allows the renderer to infer
that R stands for the reals.

"1. <condition>
<apply><in/><ci> x </ci><ci type="set"> R </ci></apply>
</condition>"

-- 4.4.2.9  should lambda allow <condition> to specify ranges of
variables?  (cf. my comment on 4.4.2.7 above)

-- 4.4.2.11  the identity function is often annotated by its domain as a
subscript.  <condition>?

-- 4.4.6.1  It's useful to mix condition elements and arguments in sets,
as in {x\in N | x < 5}  where x\in N is best seen as a <condition> and
x<5 best seen as an <apply> argument.   (The same is true for lists, 4.4.6.2.)

-- 4.4.10  Why is there no <bvar> vector or matrix constructor like a set
or a list constructor?  Example use: (for i=0..n-1,j=0..m-1, A_i= x_i^j)

-- Appendix D still uses lots of <reln>s, e.g.:

"<property> <reln><identity/>
<cn>&ImaginaryI; </cn>
<apply><root><cn>-1</cn><cn>2</cn></apply>
</reln>
</property>"

-- 5.3.3   Hey, does this mean OpenMath now has xref?  Great!  Last I knew
we had a big discussion and this was tabled.  The last OpenMath draft I
saw didn't have it, unfortunately.

" <annotation-xml encoding="OpenMath">
<OMA xref="E">
<OMS cd="logic" name="and" xref="E"/>
<OMA xref="E.1">
<OMS cd="logic" name="xor" xref="E.1.2"/>
<OMV name="a" xref="E.1.1"/>
<OMV name="b" xref="E.1.3"/>
</OMA>
<OMA xref="E.3">
<OMS cd="logic" name="xor" xref="E.3.2"/>
<OMV name="c" xref="E.3.1"/>
<OMV name="d" xref="E.3.3"/>
</OMA>
</OMA>"

-- literature references:

you may be interested in our papers,

Ladislav J. Kohout, Andreas Strotmann: "Understanding and Improving
Content Markup for the Web: from the Perspectives of Formal Linguistics,
Algebraic Logics, and Cognitive Science."  in ISIC/CIRA/ISAS 98 Joint
Conference on the Science and Technology of Intelligent Systems,
Gaithersburg, MD, 1998.

John A. Abbott, Andre van Leeuwen, Andreas Strotmann: "OpenMath:
Communicating Mathematical Information between Co-operating Agents in a
Knowledge Network". Journal of Intelligent Systems no. 3/4, 1998. [aka the
"OpenMath Objectives" paper.]

____________________________________________________________
"The act of defending any of the cardinal virtues has today
all the exhilaration of a vice." -
G.K.Chesterton: A Defense of Humilities, The Defendant, 1901
www.chesterton.org/acs/quotes.htm
`

Received on Monday, 10 January 2000 17:13:10 UTC