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

Paul Libbrecht paul at activemath.org
Mon Sep 8 12:46:02 CEST 2008


Le 08-sept.-08 à 11:37, Chris Rowley a écrit :
> I think that you and David are suggesting fairly close criteria,

Cool. You as well?

> perhaps just a difference of what is meant by 'interoperability'.

tremble tremble...

> This also raises the question about what in a 'description' of the
> mathematical meaning, rather than of the syntax and computational
> semantics, affects interoperability.

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.  
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2203 bytes
Desc: not available
Url : http://openmath.org/pipermail/om3/attachments/20080908/0db270d2/attachment.bin 


More information about the Om3 mailing list