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

Date: Mon, 27 Nov 2006 14:48:04 GMT

Message-Id: <200611271448.kAREm4qF028588@edinburgh.nag.co.uk>

To: juanrgonzaleza@canonicalscience.com

Cc: www-math@w3.org

Date: Mon, 27 Nov 2006 14:48:04 GMT

Message-Id: <200611271448.kAREm4qF028588@edinburgh.nag.co.uk>

To: juanrgonzaleza@canonicalscience.com

Cc: www-math@w3.org

> For instance how can <csymbol> be intended to denote symbols with an > _external_ definition if the definition location doesn't matter at the > same time. perhaps we have a prior agreement that if you send me <csymbol>C02AHF</csymbol> that I'll calculate the roots of a quadratic, If you send the expression to another system, then most other systems just get to know it's some function defined externally, but that is still useful information, compared to just using C02AHF as a variable name, as would happen with ci. You could perhaps add http://www.nag.co.uk/numeric/FL/manual/xhtml/C02/c02ahf.xml as a definition URL to give other people an indication as to where that function is defined, but another mathml system is unlikely to be able to interpret that page. > I am just curious, what is the difference between > > <sin/> > > <csymbol > definitionURL="http://www.w3.org/TR/MathML2/appendixc.html#cedef.sin > ">sin</csymbol> > > <ci definitionURL="http://www.w3.org/TR/MathML2/appendixc.html#cedef.sin > ">sin</ci> they probably are all intended to denote the same function, so one answer to your question is "no difference", but any MathML system has knowledge that the first one denotes the sin function, whereas unless the system can read and interpret english html text (unlikely) or special case URI references to appendix C of the spec (possible) a system will not autmatically know that the second and third denote the sin function. It will know that the second one is intended to denote _some_ symbol with an external definition. So the operational behaviour of the three expressions may be different. The MathML spec says very little about operational behaviour though. In all these cases, it may be that a mathml system just basically records the fact that some function called sin is being referenced. MathML does not, itself, mandate that a system actually has the computational ability to compute with that function. > What about next? > > <apply><ci>diff</ci> arguments</apply> > > <apply><csymbol>diff</csymbol> arguments</apply> > > <apply><diff/> arguments</apply> this is exactly the same as the <sin/> case above. If you are writing mathml, then if your identifier denotes a symbol with a fixed external definition, use csymbol, unless you also need to target MathMl1 readers, in which case use ci. If your identifier denotes an object without a fixed external definition use ci. If you are reading MathML, then how you treat ci and csymbol depends a lot on what you are doing. It may make sense to treat them identically, or it may be that if you don't understand the definitionurl on a ci you treat it as a generic identifier, but if you don't understand the definition url on csymbol you treat it as some kind of "unknown function" error if that makes sense in the target application. OpenMath has OMV (variables) and OMS (symbols) and when switching between openmath and content mathml (which is largely just a matter of syntax rather than underlying model changes) it's natural to map OMV to ci and OMS to either one of the predefined MathML elements, or to a csymbol with an appropriate definitionURI depending on whether the OpenMath symbol corresponds to one of the core MathML elements. But not all Content MathML is defined to easily round trip via OpenMath, and the distinction between what's defined and what's not is vague and the best course of action depends on local circumstances. MathMl is intentionally not proscriptive here. If you have some Content MathML using csymbol with definitionURL pointing at definitions on Maple, and you want to read it into mathematica, what's the best course of action? a) generate an error, saying you don't understand the expression b) import the expression, leaving the symbols as undefined variables which can perhaps be defined later by the user supplying appropriate definitions in the new system. c) import the expression, but flagging the problematic identifiers with some kind of error state indicating that they should be defined, but are not. What's best depends on what you are trying to do. DavidReceived on Monday, 27 November 2006 14:48:14 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:59 GMT
*