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

[Professor James Davenport]

On Tue, March 24, 2009 4:06 pm, David Carlisle wrote:
>> if MathML is such that that means <condition> is allowed anywhere in
>> strict markup since CD verification is optional
> Certainly that is the case: we need to say essentially by schema
> (relaxng, or xsd or dtd) what is and is not strict mathml.
OK - I had thought (only now) that was the case.
>
>> (*) "Rule 2" --- "Note that the order of bound variables..." (4.2.3.2 of
>> MML2) in place as the means of tying up the x in the integrand with the
>> x (or whatever) in the domain;
> more or less, although it's probably more helpful to reference the
> current draft's 4.3.3.1
Im this mail, yes. I was cutting from the paper.
>> (a) This wouldn't preclude OM developing intcond etc. later;
> Nothing MathML does constrains OpenMath, unless the OpenMath society
> chooses to keep consistent with MathML 3 as a matter of policy.
> But currently this is all open, I believe.
OK - and there are two levels of consistency. By 'intcond', I meant what
was option 3 in the binders paper, i.e. a gluing symbol. This could
therefore be in MathML3 as a csymbol, surely?
Of course, changing (or adding a new) OMBIND after MathML3 is defined
would raise much greater questions of consistency.
>> (b) Since Strict will be isomorphic to OM, these will therefore be
>> part of strict;
> No, after MathML3 is done we will go out of charter and may not have the
> charter (or the inclination) to do a MathML4 in the near future. So for
> example if (as I think it should) <bind> matches OMBIND and only allows
> one child after the qualifiers, and OpenMath later changes OMBIND as in
> your proposal to allow more than one, then in order to encode constructs
> using the new version of OMBIND in MathML3 you'll have to rewrite them
> to use the current encoding. Future changes to OM do not change MathML3.
Changes to the OM standard, agreed. Since MathML allows csymbols, changes
to the OM CDs will, surely, be part of MathML in that sense: isn't this
one of the points of the exercise.
>
>> (c) Therefore pragmatic->strict COULD be (pace David, I won't say WOULD)
>> be enhanced to use these in the future?
>
> Only if we (or someone) recharters the MathML working group to do a
> MathML4.
So the "official" P->S will be frozen at the same time?
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.

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