RE: Suggestion about generators of MathML code

Juan,

Your proposal for attributes to record the generator, and 'profile'
seems like a good one to me.  I think many people would find it useful.
I have added it to the list of things to consider for MathML 3.

Specifying the values for the 'profile' will take some thought. From
your examples, I can see your general idea, but I can imagine that
attribute recording a number of different things.  In particular, your
"TeX-annotation" example seems like it would be redundant with the the
annotation itself, since that <annotation> element would have a encoding
attribute.  Would you like to say more about your ideas on that?  

Thanks for the constructive suggestion.

--Robert

Robert Miner
Director, New Product Development
W3C Math Working Group co-chair

Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California  90802
USA
Tel:  (651) 223-2883
Fax:  (651) 292-0014
robertm@dessci.com
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor,
TexAide ~

 

> -----Original Message-----
> From: www-math-request@w3.org 
> [mailto:www-math-request@w3.org] On Behalf Of 
> juanrgonzaleza@canonicalscience.com
> Sent: Thursday, July 27, 2006 6:00 AM
> To: www-math@w3.org
> Subject: Suggestion about generators of MathML code
> 
> 
> MathML was developed to facilitate the transfer and re-use of 
> mathematical
> content between applications.
> 
> However, since each tool generates|understands completely 
> different code
> we cannot develop a generic parser receiving content MathML code from
> several authors using different software.
> 
> The problem increase with feedback. Take authors J send us fragment of
> content MathML next is checked or simbolically evaluated and output
> returned to J. Depending of the MathML software J is using, 
> she|he will be
> able to open the content or no.
> 
> I could develop an one-to-one tool comparison and generate 
> specific XSLT
> templates for each MathML fragment. This is highly expensive and time
> consuming but the main problem is that do not work with multiauthored
> docs, containing content MathML fragments from different 
> tools. Since each
> fragment is not identified, templates cannot be applied 
> because rules are
> tool specific. for instance in some cases we wait eliminate 
> <mi> in others
> we wait introduce extra <mi>, etc.
> 
> Even the simple examples introduced in
> 
> [http://lists.w3.org/Archives/Public/www-math/2006Jul/0114.html]
> 
> 1) a + b
> 
> 2) sin &pi;
> 
> 3) -5
> 
> 4) &int; sin &omega; d&omega;
> 
> 5) 3/4
> 
> 6) sqrt(x)/(y^2 -1)
> 
> 7) -x
> 
> 8) &int;_a^b &omega; d&omega;
> 
> 9) x >> 0
> 
> 10) <p>My favourite Greek letter is &beta;</p>
> 
> 11) x_i = 5
> 
> 12) {}^7log x
> 
> 13) (x+3)^2
> 
> 14) a/b; a=3, b=4
> 
> 15) 123/456
> 
> are parsed with great difficulty. Take the first example, i would wait
> something like
> 
> <math>
>   <apply><plus/>
>     <ci>a</ci>
>     <ci>b</ci>
>   <apply>
> </math>
> 
> transforming it to Scheme (+ a b) for symbolic evaluation, 
> but oops i got
> error because the file i received from HERMES generated the s-expr
> 
> (+ <mi>a</mi> <mi>b</mi>)
> 
> All of above examples are extracted from current sites on 
> MathML. Next is
> of interest to the Center
> 
> 16) (&partial;&rho; / &partial;t) = L &rho; + &epsilon;(&rho 
> - &rho;_0)
> 
> The RG-1 can work in the research of suitable relativistic 
> expressions for
> the L superoperator (Sch-KG, Dirac, or R-QFT propagators are 
> plain wrong
> since compact support for wavefunctions is not maintained -the current
> research tendency is to obtain propagators are cuadratic in momenta-).
> 
> RG-2 can work in the research of generalizations of Abe 
> kernels for the
> Zubarev term &epsilon;(&rho - &rho;_0) [*].
> 
> If RG-1 and RG-2 are using different MathML software the 
> communication can
> be difficult or even impossible.
> 
> Proposal]
> 
> Use an attribute informating of the profile and other informing of the
> generator. For instance
> 
> <math generator="HERMES" profile="normal">
>   ...
> </math>
> 
> and i would apply special XSLT to the nodes generating the 
> desired (+ a b).
> 
> <math generator="ConText" profile="TeX-annotation">
>   ...
> </math>
> 
> and i would apply special XSLT to the nodes introducing 
> 'lacking' <mi> and
> <msub>.
> 
> [*]
> [http://www.scielo.br/scielo.php?pid=S0103-97332005000400017&s
cript=sci_arttext].
> No MathML, GIFs.
> 
> Juan R.
> 
> Center for CANONICAL |SCIENCE)
> 
> 
> 
> 
>

Received on Friday, 28 July 2006 14:29:24 UTC