Dear OM3 group, dear Math WG, an important issue came up over the weekend, and it is so important that we should discuss it on the mailing lists to get maximal exposure (/I am crossposting to the OM3 and member-math mailing lists since this is where the technical discussions happen; does anybody think we should also involve the general OM and public W3C-Math mailing lists?/).
*Problem*: What should the names of the content dictionaries be for the OM3/MathML3 CDs be? Up until now, we have been operating on the tacit assumption that we would just use the MathML CD group from the OpenMath CDs as a basis and keep the names from that collection, and merge the names somehow with the MathML2 token names. [[/Background: The MathML CD Group is a set of OpenMath2 CDs that was designed for MathML compatibility, but the design goal is seems to have been to allow to express the same set of mathematical objects (in a more principled way), not to make mapping simple. We are currently trying to merge information from the MathML2 spec and this CD Group to come up with a set of CDs that will be jointly endorsed by the W3C Math Group and the OpenMath Society./ /See https://svn.openmath.org/OpenMath3/cd/MathML for the current state/.]] Now that we are discussing the specifics like the eventual names of the summation operator we begin to see problems: * <sum/> is an operator that takes an expression with a bound variable as an argument in MathML2, and we would like to have <csymbol name="sum" cd="????"/> for strict MathML3 to make the strict2pragmatic mapping in MathML3 as simple as possible. * <OMS cd="arith1" name="sum"/> is an operator that takes a set of closed expressions (no bound variables) as an argument, but of course we would like to keep this behavior for backwards compatibility with OpenMath2. But sumation is not the only instance of this problem; it also applies in spirit to product, integrals, ... [[/Background: see also issues 17, 23, 24, and 25 at https://trac.kwarc.info/OM3/report/3/]] In this situation, we seem to have three options 1. we map <sum/> to <csymbol cd="sum" name="XXX"/>, where XXX != arith1, even though <plus/> is mapped to <csymbol name="plus" cd=="arith1"/>. 2. we map <sum/> to <csymbol cd="sum" name="arith1"/>, and rename the OpenMath2 <OMS cd="arith1" name="sum"/> to something else. 3. we map <sum/> to <csymbol cd="sum" name="XXX"/>, where XXX != arith1, and <plus/> is mapped to <csymbol name="plus" cd="XXX"/> and <OMS cd="arith1" name="sum"/> is renamed to <OMS cd="XXX" name="YYY"/>, where YYY=sumset or something better. All three options are not terribly attractive, in particular: 1. breaks the MathML strict2pragmatic mapping an therefore makes the deployment of content MathML3 much more difficult, but does not break backwards compability of MathML. We could say that it breaks forward compatibility if such a thing exists. 2. breaks backwards compatibility of OpenMath in an unaccepatable way 3. this option is to basically invent new CD names for all the CDs in the MathML CD Group of OpenMath2. This does not technically break backwards compatibility of OpenMath, since the MathML CD Group continues to exist, but will fragment the OpenMath code base, and thereby counteract some of the benefits that we are hoping to reap from the unification of MathML and OpenMath we are currently undertaking. I think we are facing a classic Trilemma here; maybe someone has a good idea how this problem may go away? James Davenport suggested that option 3 might be made more palatable by introducing a new kind of FMP to content dictionaries, so that we could write (assuming solution 3.) <FMP type="alias"> <OMOBJ> <OMA> <OMS cd="relation1" name="eq"/> <OMS cd="arith1" name="sum"/> <OMS cd="XXX" name="YYY"/> </OMA> </OMOBJ> </FMP> This would presumably reside in the old arith1.ocd and allow people to transparently (and maybe automatically) move over to the new joint CDs. I am hoping for creative and insightful feedback here. Michael -- ---------------------------------------------------------------------- Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 Professor of Computer Science Campus Ring 12, School of Engineering & Science D-28759 Bremen, Germany Jacobs University Bremen* tel/fax: +49 421 200-3140/-493140 [EMAIL PROTECTED] http://kwarc.info/kohlhase skype: m.kohlhase * International University Bremen until Feb. 2007 ---------------------------------------------------------------------- _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
