From: Andreas Strotmann <strotman@klein.math.fsu.edu>

Date: Wed, 28 Jan 1998 18:35:54 -0500

Message-ID: <34CFC0DA.167E@klein.math.fsu.edu>

To: www-math@w3.org

CC: strotmann@rrz.uni-koeln.de

Date: Wed, 28 Jan 1998 18:35:54 -0500

Message-ID: <34CFC0DA.167E@klein.math.fsu.edu>

To: www-math@w3.org

CC: strotmann@rrz.uni-koeln.de

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!Received on Wednesday, 28 January 1998 18:36:15 UTC

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