Re: Using content-MathML for computation and analysis in Science and Engineering

On Thu, Mar 15, 2012 at 2:43 PM, David Carlisle <davidc@nag.co.uk> wrote:

> On 15/03/2012 14:24, Peter Murray-Rust wrote:
>
>> My other question is whether I can include foreign namespaces. I can
>> see things like:
>>
>> <apply><eq/><ci>atomSet</ci><**apply><cml:getatoms/><cml:**molecule
>> id="m3"/></apply>
>>
>
>
> yes and no (we do something similar in-house here at NAG because the
> given empty elements for functions in MathML don't map well to the
> content of a numerical function library) but...
>
> while using namespaces in that way is a possible extension point, it is
> not (unlike using namespaced attributes) automatically valid MathML.
> You would need to extend the schema to allow it, and generic MathML
> processors not expecting this form will give errors.
>
>
I understand. In contrast the current version  of Chemical Markup Language
(CML) allows the inclusion of other namespaces. Schema validation is of
relatively little power for chemistry and we validate using extensive XSLT
"conventions" (these also allow local conventions so that people can create
their own mixtures (chemistry is less formalized than math and the
practitioners are less conformant)).




> The pure MathML version might be
>
>
> <apply><eq/>
> <ci>atomSet</ci>
> <apply><csymbol cd="cml">getatoms</csymbol>
> <csymbol cd="cml" id="m3">molecule</csymbol>
> </apply>
>
> If you do decide that the csymbol form is too verbose and want to use
> the namespace extended schema, it would be good to have a tool (which
> could be xslt or perl or anything really) that wrote it back out using
> just the mathml namespace elements. Then generic MathML processors will
> know how to render the getatoms etc. (of course if more complicated
> rendering is appropriate that could be added too.)
>
> the csymbol mechanism is fine for us - the verbosity isn't critical. We
use dictionaries extensively (similar to your cd, but namespaced - does cd
allow a value like cd="cml:foo"? )


> The NAG extensions I mentioned above are purely in-house and we always
> convert to MathML (presentation MathML currently) for public files
> obviously for an extension aimed for public use, the tradeoffs are
> rather different.
>

We would always want to present valid MathML and do as little pre and
postprocessing as possible as our community isn't always strong on
installing glueware.

>
> David
>



-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069