Dear Paul, let me chime in on this discussion, even though it is probably already over ... (sorry, we are starting up the semester, so I am swamped with e-mails).
Paul Libbrecht wrote: > Formal properties are subject of debate here I think. Thus far they're > pushed to the appendix in MathML-3 spec but kept core in OpenMath3. This could also be the problem of the whole thing. You (quite rightly I think base your discussoins on FMPs (or equivalently <properties> from MathML). But these are non-normative in the spec and not part of the description. So in this light, the descriptions in the MathML3 spec will only give an overview over the symbols provided by MathML3 and relegate additional questions to the CDs (and as you rightly argue CMPs and FMPs there). I think that we should see this as an opportunity to take advantage of. The <Description> elements should be self-contained and understandable for K-14 literates. The rest of the CDs will give more meaning, if the CD author can be bothered to write it down. As such, the interoperability question discussed below are at the FMP level (i.e. in the rest of the CD) and in particular not in Chapter 4 of the MathML3 spec. > James defines their usage well: > > usage of a symbol (e.g. treatment by processors) should make the > properties "stay true" > > But overall you cannot do more than what the words allow you to do if > you stick to a description only. > >> You wrote -- >>> As for the OpenMath CDs or MathML chapter 4 descriptions, I just feel >>> they need to be minimal enough to be interoperable. >> >> That sounds like a good rule, but on looking a bit deeper we need to >> pin down questions such as: >> >> - interoperable with what systems? and/or what types of system? > > MathML-content processors. > >> only exisiting systems? or plausible future systems (eg tutorial >> assistants)? > > both. > >> for each system, what is interoperable and what is not? > > non-interoperable would be something that renders the description or > formal-properties false. > >> (sub-questions): >> - what makes a symbol alone (rather than an expression) interoperable? > > a symbol is just a pointer. > >> - is it any more than (something like) its 'signature'? > > precisely, it is more in the sense it should apply the rules set-forth > in its content-dictionary: > - the description > - the formal properties > >> how strongly, or simply, typed must it be? > > completely open question to my taste... as long as no tool-set is > offered to help this. > E.g. nothing can prevent you to take the arcsine of a matrix... > Attempts at providing types exist but their implementation has been > known to be quite difficult. Is this a critique to the feasibility of > a BNF grammar as Robert wishes? Maybe. > > paul > ------------------------------------------------------------------------ > > _______________________________________________ > Om3 mailing list > [email protected] > http://openmath.org/mailman/listinfo/om3 > -- ---------------------------------------------------------------------- Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 Professor of Computer Science Campus Ring 12, School of Engineering & Science D-28759 Bremen, Germany Jacobs University Bremen* tel/fax: +49 421 200-3140/-493140 [EMAIL PROTECTED] http://kwarc.info/kohlhase skype: m.kohlhase * International University Bremen until Feb. 2007 ---------------------------------------------------------------------- _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
