[Prev][Next][Index][Thread]
some proposals on MathML
Hi,
I like the new MathML proposal very much!
Still, I'd like to make a few proposals:
- re: 4.3.3.2 General Attributes
"The class and style attribute are intended for compatibility
with Cascading Style Sheets"
I believe that the id attribute should also be added for the same
reason as and in much the same way that HTML 4.0 introduced it (see
http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 :
"The id attribute has several roles in HTML:
*As a style sheet selector.
*As a target anchor for hypertext links.
*As a means to reference a particular element from a script.
*As the name of a declared OBJECT element.
*For general purpose processing by user agents (e.g. for
identifying fields when extracting data from HTML pages into
a database, translating HTML documents into other formats, etc.).
). Furthermore, the id attribute is slated to become part of
OpenMath.
- The lang attribute may also be useful to add generally. Consider
the examples <cn> fourty-two </cn>, <cn> zweiundvierzig </cn>,
<cn> 42 </cn>, and <cn> XLII </cn> :-) Note also that the German
and the US rendering of a long division example in a textbook would
look extremely different, but their MathML representations should
ideally be identical except for the lang attribute. Note also that
a MathML object embedded in a HTML 4 document using the <OBJECT>
element should pass through the lang attribute "passed" by the
enclosing <OBJECT> element to any elements embedded within the
MathML object, if only as a courtesy.
Or is this attribute a universal ingredient of XML markup anyway?
- Have you considered adding HTML 4.0's <OBJECT> element to MathML?
It would be very useful as one of the arguments to a <semantics>
element: MathML would in this scenario be used to describe the
semantics of a web resource referenced by the <OBJECT> element,
adding considerable value to that external object. Besides, it
would provide a much needed interface for including non-MathML info
within a MathML document.
- For compatibility to OpenMath, please allow
<apply> <int/>
<apply> <lambda/> <ci> x </ci>
<apply> <sin> <ci> x </ci>
</apply>
</apply>
</apply>
as content markup for \int \sin x \d x . This corresponds to
OpenMath's choice of a more semantically oriented representation of
integration.
The intention is that, in the absence of a <bvar> qualifier, if the
argument element for <int/> is a lambda element, the variable bound
by that lambda will act as a replacement for the missing <bvar>
element, i.e. the above example is equivalent to
<apply> <int/>
<apply> <sin> <ci> x </ci>
</apply>
<bvar> <ci> x </ci> </bvar>
</apply>
In fact, it would be very nice if the macro mechanism envisaged for a
future draft of MathML were to allow specifying that, semantically
speaking, the former representation is the macro expansion of the
latter.
- Please also reconsider the relative order of the qualifiers defined
in 4.2.3.4 (lowlimit uplimit bvar degree logbase). In particular, I
would argue that the limit qualifiers should go at the end of this
list as they are semantically most losely associated with the
operators that allow them as arguments. As I have argued earlier,
the logical structure of a definite integral is either
(int ((sin x) dx) (interval lowlimit uplimit))
or
(definite (int (sin x) dx) (interval lowlimit uplimit)) ,
"binding" the bvar more closely to the int's argument than all other
qualifiers. With a re-arranged order of qualifiers, one could at
least argue that a qualifier introduces a logical bracketing as
follows:
{<apply>{{{ <int/> arg <bvar>x</bvar>} <qual2>..</qual2>}...}</apply>
(which would of course have to be mentioned in the document).
- I'm still missing the following very basic ingredients:
<compose/> (usually printed as a small circle infix operator)
<identity/> (printed as id )
as in
<relation> <eq/>
<apply>
<compose/>
<sin/>
<apply> <inverse/> <sin/> </apply>
</apply>
<identity/>
</relation>
- What is the reason for not including the two standard <quant>ifiers,
<forall/> and <exists/>?
Perhaps this would be a reasonable representation:
<quant>
<forall/>
<ci type=complex> x </ci>
<relation>
<eq/>
<apply>
<plus/>
<apply>
<power>
<apply>
<sin/>
<ci type=real> x </ci>
</apply>
<cn> 2 </cn>
</apply>
<apply>
<power>
<apply>
<cos/>
<ci type=real> x </ci>
</apply>
<cn> 2 </cn>
</apply>
</apply>
</relation>
</quant>
Note the new <quant> element in analogy with the new <relation>
element, only for (generalized) quantifiers.
Incidentally, one might then want to consider grouping the <lambda>
construct with the quantifiers, that is to have
<quant> <lambda/> <ci> x </ci> <ci> x </ci> </quant>
instead of
<lambda> <ci> x </ci> <ci> x </ci> </lambda>
<quant> elements would all follow the same semantic construction
pattern as the lambda element currently does; its arguments are
variables bound by the quantifier, except for the final element which
is the scope of these variables.
- the logical operators not, and, or, xor, (equiv is definitely
missing here!) are not declared as relations in 4.2.4 Relations.
"implies" is, so I assume that these omissions were unintended.
- may I propose a "units=" attribute for the <cn> and <ci> elements
or some other mechanism for specifying units (physical, monetary,
or otherwise)?
In high school textbooks you will often find questions that give
numbers in terms of certain units, and not all numbers in the same
units either (e.g. a geometry question may involve the lenght of
the thumb and the distance between eye and thumb in inches, give the
height of an object at a distance in feet, and ask for the distance to
that object in miles).
Possible values of the units attribute may or may not be included in
the MathML definition, but the list should definitely be extensible.
It may be better to do this by introducing a qualifier element <unit>
instead that <cn> and <ci> may take, or by introducing a general
purpose <unit> element whose first argument would represent the
quantity and whose first element would represent the unit expression
(km/sec^2, say, in MathML markup).
This would greatly improve the utility of MathML in the rest of the
sciences, and even more outside the sciences, I would think.
Best regards,
Andreas Strotmann
PS: please add me to the mailing list. Thanks!
Follow-Ups: