[Om3] target K14 for reading content-math spec any realistic?

[Michael Kohlhase]

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
> Om3 at openmath.org
> 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
 m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
----------------------------------------------------------------------