There was a brief discussion of the implications of the recent MathML 
3.0 public draft on CellML at today's CellML meeting.

I noted that the following changes from MathML 2.0 to the canonical form 
of MathML 3.0 would be likely to affect us if we were to allow MathML 
3.0 in CellML:
1) Function applications have been separated out from bindings. For 
example, in MathML 2.0, to write a derivative you would treat diff as a 
function, but specify the bound variable:

In canonical MathML 3.0, you would write:

Of course, function applications still use apply.

2) MathML 3.0 has support for 'structure sharing'. Repeated structures 
in MathML 3.0 can be written once, and then referenced in future. This 
structure sharing happens at the MathML encoding level, and not at the 
semantic level (so the shared trees are inserted verbatim into the 
MathML expression). It is unclear where you could reference shared 
mathematical structures from in CellML (e.g. whether you could reference 
structure in maths defined in a different component, and whether you 
could import structure).

3) MathML 3.0 removes qualifiers like uplimit and lowlimit from the 
canonical part of the specification, because they are redundant with 
condition. The only problem with this is that many tools only support 
the simple uplimit / lowlimit case, and not the more general and 
complicated condition case.

e.g. the quite specific:
<lowlimit><cn cellml:units="second">0</cn></lowlimit>
<uplimit><cn cellml:units="second">5</cn></uplimit>

which might appear in, e.g. a definite integral, becomes:

  <apply><in/><ci>x</ci><apply><interval/><cn cellml:units="second">0</cn><cn 

I don't think MathML 3 offers us any immediate benefit now, but in the 
future, it may do so, as other software takes it up, and we want to be 
able to share MathML with them. This will also depend on how easy it 
turns out to be to convert between MathML 3 and MathML 2, as these 
changes are backwards incompatible.

Best regards,

cellml-discussion mailing list

Reply via email to