[Om3] three avenues for the condition elements

[Michael Kohlhase]

Dear all,

we should make progress on this, I have made a doodle for deciding on a 
teleconference date, please give me your preferences at

http://www.doodle.com/txbc7ez6gt5ahkzm

The earlier in the week we talk the better.

Michael

Professor James Davenport wrote:
> 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
>
>
>   

-- 
----------------------------------------------------------------------
 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
 m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
----------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_kohlhase.vcf
Type: text/x-vcard
Size: 320 bytes
Desc: not available
Url : http://openmath.org/pipermail/om3/attachments/20081031/dc4fd497/attachment.vcf