From: <juanrgonzaleza@canonicalscience.com>

Date: Fri, 21 Jul 2006 02:46:46 -0700 (PDT)

Message-ID: <3030.217.124.69.236.1153475206.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Date: Fri, 21 Jul 2006 02:46:46 -0700 (PDT)

Message-ID: <3030.217.124.69.236.1153475206.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Bruce Miller wrote: > > OK, sure; set up a 3-way comparison between a CSS approach and > a MathML both with & without fonts installed; fine with me. Since fonts are now disabled, I will continue submiting some screenshots without the special MathML fonts (including MathML test suite examples). Once finished, the roundmap will be repeated now with special MathML fonts installed in Mozilla. >> It can be directly _duplicated_ as >> >> [::mrow >> [::mrow >> [::mi a] >> [::mo +] >> [::mn 3]] >> [::mo =] >> [::mi β]] > > That's interesting; it really isn't so much about MathML, but > an alternative shorthand syntax for XML itself, and would work > for _any_ xml format. CanonML is now a superset of XML [*]. Therefore you can _duplicate_ any XML that you want: OpenMath, MathML, SVG, XSL-FO, XHTML... > I often use such syntax & structures > for preparing data for XML serialization. > > Some would compare it to Lisp. Indeed, it was derived from a modification of s-expr. > And some feel the redundancy of > close tags (as opposed to a balancing "]" or ")") isn't necessary > for well-formed-ness; They'd say that's what emacs is for :> There exist technical requirements for the elimination of closing tags beyond verbosity and overheads of files size [*]. > Two questions: Why the "::" ? Is it a stand-in for namespaces? It is a notation. Details discussed at [*], including namespaces, "prefixes", multimarkup, and non-hierarchies. > Secondly: what do you do when you need attributes? > I'd suggest allowing an option something like > [mi {mathvariant=normal} a] You are proposing a direct copy of the XML attribute model. The limitations of the w3c XML attribute model and the new improved "attribute" (annotation) model were througly discussed on [*]. You can copy the XML attribute model for duplication of MathML fragments, but i prefer a more general, powerfull and elegant model for annotations based in ideas from SXML, ConciseXML, and liminal. CanonML is a highly personalizable model and even its syntax is. You can define something like above syntax if you like or others variant you can imagine [mi [:: [mathvariant normal]] a] [mi [@mathvariant=normal] a] [mi [@ [mathvariant normal]] a] Even you could define a special MathML environment and write something like [mrow [mrow [mi a] [mo +] [mn 3]] [mo =] [mi β]] or more simple still [mrow [mrow a + 3] = β] using macros a ==> [mi a]; + ==> [mo +]; 3 ==> [mn 3] However, I am defining a special environment for mathematics and science called CanonFormal (a kind of descendant of the original CanonMath discussed here, remember?). For instance, the content MathML <math xmlns:mml="http://www.w3.org/1998/Math/MathML"> <mml:apply> <mml:eq/> <mml:ci>E</mml:ci> <mml:apply> <mml:times/> <mml:ci>m</mml:ci> <mml:apply> <mml:power/> <mml:ci>c</mml:ci> <mml:cn>2</mml:cn> </mml:apply> </mml:apply> </mml:apply> </math> is entered like [$$ E = [m * [c ^ 2] ]] whereas the OpenMath code <OMOBJ> <OMA> <OMS cd="calculus1" name="int"/> <OMBIND> <OMS cd="fns1" name="lambda"/> <OMBVAR> <OMV name="x"/> </OMBVAR> <OMA> <OMS name="sin" cd="transc1"/> <OMV name="x"/> </OMA> </OMBIND> </OMA> </OMOBJ> is [$$ integral [sin x] [diff x]]. There exists another version, a bit more verbose, using the :: notation, but most of people is prefering the new $$ environment by now. > Of course, while this form is a lot more typeable than > straight xml syntax, you're still using the MathML "language" > with whatever flaws it might have. Exact! If you decide to encode MathML in a CanonML format, you recover the redundancies, ultraverbosity (specially in parallel markup), base interference in scripts and limitations on availability of structures, fences’ formating semantics, DOM and CSS difficulties, problems with entities, lack of compositionality [**], and rest of trouble. That was main reason for the development of a special environment for mathematics and science: CanonFormal. The posibility to introduce a CanonML representation of MathML or OpenMath XML data models is interesting just by backward compatibility, letting individual users and bussiness (including publishers cited by R. Miner) _the reuse of their current technical resources and databases_. I do ***not*** plan to offer either MathML or OpenMath environment for CanonML now. If a future MathML 3, 4, or 5 gots merit and gain popularity then a special MathML environment could be officially developed, but I see it unlikely. > I'm personally prefer lisp-like syntaxes to ones where > whitespace is significant, but the popularity of Python > puts me seemingly in a minority. WS rules are personalizable in CanonML approach and a Python-like indentation can be defined by users and implemented in specific environments. For instance, the SOX community could prefer something like next mrow> mrow> mi> a mo> + mn> 3 mo> = mi> β for duplicating above MathML fragment, even if you dislike so one! > > I can't quite understand all your "modifications"; > you seem to be saying that when you make the conversion > from your new input syntax to MathML that you want to > generate badly structured MathML. I would have thought > that you would want to take the opportunity to generate > good MathML, but whatever --- you can do it that way, if you like. > > In any case, I wouldn't think those modifications would apply > to the input syntax itself (unless it is just a mapping of MathML), > nor to the conversion to non-MathML formats. I added two <warnings> in previous message but a <irony> would be more effective, after reading you above. > -- > bruce.miller@nist.gov > http://math.nist.gov/~BMiller/ [*] Technical details and rationale for design options are contained in Canonical Science Today [http://canonicalscience.blogspot.com/]. More recent postings supersed old ones and even information here exposed. [**] Strotmann, Andreas. Compositionality: A Content Markup Language Design Principle. 2001 [http://www.uni-koeln.de/~a0047/publications/GKSC01.ppt] Juan R. Center for CANONICAL |SCIENCE)Received on Friday, 21 July 2006 09:47:03 UTC

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