On Sat, October 25, 2008 5:17 am, Michael Kohlhase wrote: > the MathML WG has to bring out the next working draft of the MathML3 recommendation and we have a code freeze on November 6. Since this is the last working draft before the "last call" stage of MathML3, it would be good to have resolved the question whether the <condition> element belongs into strict MathML or pragmatic. Therefore I would ask you to give your opinions about the resolution ASAP. I will organize a > teleconfere later in the coming week or early in the week of the 6. where we take a decision. A good idea. I apologise for the delay in not following up on the teleon of 10th - as usual I was overtaken by teaching before I had a chance to finish the follow-up - I attach the current state for what it's worth. [second thoughts - it wil probably fall foul of the length limit: I attach the LaTeX, and the PDF (which may be further updated if I get a chance today), is at http://staff.bath.ac.uk/masjhd/Conditions-JHD.pdf] > Paul Libbrecht wrote: >> (warning: this text contains unicode character) >> #1 condition element >> Basically add, in OpenMath and strict MathML, an element called condition or omcond that mimics the current condition element. >> #2 condition symbol >> Invent a new symbol called condition which would do a very similar function. >> For example, if it was called c, one would write a conditional >> function as >> λ.x,y: c(x â y, x / (x-y) ) My fundamental objection to MathML's condition, which I think applies to both #1 and #2, is that its presence affects the semantics of the surrounding objects. Indeed, I do not even no of a formal statement about how far its influence might spread: it is sufficient to inspect all the direct children of X for a condition element, or must one delve deeper? >> #3 conditional symbol variants >> For each binder-like symbol, add a variant symbol which does accept an extra argument, the condition. The function above would be written: >> λ.x,y: x â y, x / (x-y) To do this neatly, one would have to scrap the rule that OMBIND only takes one 'ordinary' child, but this, I think, is a small price to pay. Indeed, if it is felt to be too high, one could add OMBINDCOND, with two 'prdinary' children, the first as in OMBIND and the second the condition. This would rescue MK's DEFINTCOND from the objections in my attached note.
James Davenport Hebron & Medlock Professor of Information Technology Formerly RAE Coordinator and Undergraduate Director of Studies, CS Dept Lecturer on CM30070, 30078, 50209, 50123, 50199 Chairman, Powerful Computing WP, University of Bath OpenMath Content Dictionary Editor IMU Committee on Electronic Information and Communication
Conditions-JHD.tex
Description: TeX document
_______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
