Re: Samples from the Internet

> 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.



David

Received on Monday, 27 November 2006 14:48:14 UTC