[om] OpenMath 2

[Professor James Davenport]

A few comments written over Christmas.
James

-------------- next part --------------
OpenMath 2 Standard: Various comments by JHD
(with respect to HTML version of 11/12/2003)

1) Under "History" (1.1), it is said that Tallahassee and Eindhoven
   "endorsed drafts of this document as the current OpenMath standard."
   Suggested fix: "endorsed drafts of this document's predecessor as the
   then current OpenMath standard (version 1.1)." Possibly add: "It is
   hoped that a simialr process will lead to the endorsement of drafts of
   this document as the current OpenMath standard (version 2.0)".
2) The definition of flattening in 3.1.3 (recursive stripping) contrdicts the 
   definition under attribution in 3.2 (bottom of paragraph beginning
   "Composition", page 6), which describes (as in OM 1) flattening as
   producing a single level.
   Suggested fix: keep 3.2, for backwards compatibility, and in 3.1.3,
   replace "flattening" by "total stripping".
3) In 3.2 under binding, I do not understand the purpose of the first line
   in the two-line display:
   binding(lambda, v, (binding(lambda, z, application(times, z, z))).
   It seems to have been cut/pasted from a differnt discussion.
4) In 3.2 under attribution, paragraph beginning "attribution acts", the
   phrase "role attribution" should probably read "role annotation", or
   possibly "role annotation-attribution".
5) Definition of floating-point numbers (page 10). Bug 1 of 2 - perpetuated
   from 1.1. There needs to be a way of specifying (as discussed as nauseam
   on the mailing list) of specifying <OMF dec="NaN"/>.
   Suggested fix: Place entire existing grammar in parentheses and add:
   | "NaN" | "infinity" | "-infinity".
   It might also be worth adding the follwoing sentences (or one or other).
   Note that the OpenMath standard does not specify which NaN, or even kind
   (signalling/nonsignalling) of NaN, an IEEE-745 compliant OpenMath
   compliant system gets represented internally by <OMF dec="NaN"/>.
   Note also that an IEEE-745 compliant OpenMath compliant system is
   expected to represent <OMF dec="0.0"/> and  <OMF dec="-0.0"/> by the
   corresponding, and therefore different IEEE-754 numbers.
6) Definition of floating-point numbers (page 10). Bug 2 of 2. The
   definition of the hex encoding seems fairly opaque.
   Suggested fix:  I suggest deleting the current sentence, and starting a
   new paragraph as follows.
   The value of hex is the hexadecimal encoding (digits 0-9,A-F), using a
   least significant bit/byte ordering, of the IEEE representation of a
   floating-point number. For a normalised floating-point number, this
   would be mantissa, exponent and sign from lowest to highest bits.
   Leading or trailing 0 may not be stripped, so this would normally have
   16 hexadecimal digits.
7) Floating point number in binary (page 15). I don't believe this can be
   0.1. Possibly 0.5?
8) Character string in binary (page 15). I believe that the reference ro
   iso-859-1 should be iso-8859-1. Should be in bibliography?
9) RelaxNG Schema for CDs (page 20). Query 1 of 2. I can see a definition
   of the item Role, but no use of it. Role seems not to be mentioned in
   the Further Description in Section 5.3.2.
10) RelaxNG Schema for CDs (page 20). Query 2 of 2. Read literally, this
    seems to imply that a CDDefinition can have more than one Name.
11) 5.3.2 under examples. I quite agree, but maybe this could be expanded
    by the following example. "For example, in trancs1, the example
    $\cos(x)=\sin(x+\pi/2))$ could be under either sin or cos (or even
    both), but cannot be 'loose' in transc1".
12) Signature files. 5.4 is unclear: must all signatures files conform to
    the abstract specification and RelaxNG Schema, or only STS ones?