From: David Carlisle <davidc@nag.co.uk>

Date: Wed, 6 Jun 2007 23:55:52 +0100

Message-Id: <200706062255.l56MtqKj024028@edinburgh.nag.co.uk>

To: r.muetzelfeldt@ed.ac.uk

Cc: www-math@w3.org

Date: Wed, 6 Jun 2007 23:55:52 +0100

Message-Id: <200706062255.l56MtqKj024028@edinburgh.nag.co.uk>

To: r.muetzelfeldt@ed.ac.uk

Cc: www-math@w3.org

I agree with Robert that csymbol is probably better than ci but that otherwise that's a good encoding. An alternative viewpoint that I picked up in a previous life working in formal systems that essentially viewed everything as a lambda expression is that 2*a+3*a^2+b+b^2 WHERE a=5+c*2, b=17-d is syntactic sugar for (lamda a b. 2*a+3*a^2+b+b^2)(5+c*2, 17-d) that is first create the anonymous function of two variables representing the bound variables in your expression, then apply that function to the two expressions which hold the definitions of the bound variables. This could be encoded directly in mathml as <apply> <lambda> <bvar><ci>a</ci></bvar> <bvar><ci>b</ci></bvar> <apply> <plus/> <!-- mathml for 2*a+3*a^2+b+b^2 --> </apply> </lambda> <apply> <plus/> <!-- mathml for 5+c*2--> </apply> <apply> <plus/> <!-- mathml for 17-d--> </apply> </apply> This has the advantage of being coded in core mathml without needing any csymbol defined operators, it has the possible disadvantages of being possibly harder to read by humans, and possibly more likely to be automatically "expanded out" by a system consuming the expression, just as <apply><plus/><mn>1</mn><mn>1</mn></apply> might not be the best encoding of the concept 1+1 if you want it to survive importing it into a CA system and not have it be seen as 2. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________Received on Wednesday, 6 June 2007 22:56:01 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:39 UTC
*