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!

Received on Wednesday, 28 January 1998 18:36:15 UTC