[Om3] Being pragmatic about the semantics of, eg, variables and functions

[Professor James Davenport]

On Tue, March 24, 2009 5:14 pm, David Carlisle wrote:
>> So the "official" P->S will be frozen at the same time?
> yes the whole point of the pragmatic->strict stuff that it is in (and in
> many ways forms the bulk of) the specification of Content MathML in
> Chapter 4. This was thought to be preferable to the OM2 situation where
> we _said_ that OM2 and MML2 were aligned but the description of the
> alignment was in a pdf note on the OM site, with no official standing.
> In MathML3 the idea was to make it part of the specification. That has
> advantages and disdvantages as you see...
That's not quite the same thing (fortunately). If Chapter 4 is merely A
translation Prag->S (which is what I would hope) then evolving OM will let
us improve a "best efforts" translation, which would be a nice position to
be in.
>> Irrespective of this particular issue, that would be a pity, as there
>> are
>> currently, as I see it, bits of potential pragmatic (with no current use
>> cases) that I, at least,do not understand.
>
> The specifcation in the current text is in words not as runnable code
> the plan is to fill in some of the gaps to make it as defined as
> possible but given the flexibility of mathml markup if you combine
> things in interesting ways there are likely to be  still cases where the
> mapping to strict is underdefined. It may be that that gives you enough
> room for manoeuvre, or not?  However we don't want to leave too much of
> the mapping from pragmatic to strict undefined as that negates the whole
> point of the restructuring of chapter4, where the intention is to
>
> a) say via schema what's legal as mathml
Which essentially means, as I understand it, that 'condition' is either IN
or OUT, irrespective of CDs.
> b) say by mapping to strict mathml (aka openmath in mathml synax) what
>    those constructs "mean".
Which doesn't stop a "best efforts" mapping evolving as OM evolves, as
long as the evolution is upwards-compatible (and OM never deletes a
symbol, so this should be feasible).
> so wherever we leave the mapping to strict undefined we are saying that
> some construct is legal mathml but has no defined meaning. Clearly we
> don't want to do that too often.
Agreed, but there were certainly a few uses of 'condition' in MML2 that I
couldn't assign any sensible meaning to.

James Davenport
Visiting Full Professor, University of Waterloo
Otherwise:
Hebron & Medlock Professor of Information Technology and
Chairman, Powerful Computing WP, University of Bath
OpenMath Content Dictionary Editor and Programme Chair, OpenMath 2009
IMU Committee on Electronic Information and Communication