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 _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
