From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 1 May 2006 07:06:24 -0700 (PDT)

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

To: <www-math@w3.org>

Date: Mon, 1 May 2006 07:06:24 -0700 (PDT)

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

To: <www-math@w3.org>

Neil Soiffer wrote: > Please see > http://www.unicode.org/versions/Unicode4.0.0/ch16.pdf > for a full description. Here is an excerpt about "Aliases" > > <blockquote> > Aliases > An alias (preceded by =) is an alternate name for a character. > Characters may have several aliases, and aliases for different > characters are not guaranteed to be unique. Aliases are > informative and may be updated.... > </blockquote> Just I said [http://lists.w3.org/Archives/Public/www-math/2006Apr/0083.html] <blockquote> But if you ask if 0307 may be interpreted *always* as Newtonian derivative, the reply is not. This is reason that Unicode standard says that alias may be useful alternative choices but at the same time warning us that alias is informative and may be updated in future Unicode standards. </blockquote> I already said that alias was informative. Note also offered an explanation of why. >> Are you sure that Unicode is just a "rendering technique"? > > Please read what was written. I said that *precomposed characters* are a rendering technique. Are you sure that Unicode *precomposed characters* are just a rendering technique? >>> This is one person's opinion, not what ISO-12083 says. As >>> far as I could see, 12083 is silent on the matter. >>> While it is informative to get another opinion on this, >>> implying that this is what 12083 says is false (at least as >>> far as I could see in 12083's math section). >> >> Implying that this is what 12083 says? Where? > > Again, you misread what I wrote. I was merely clarifying what you quoted as being one person's opinion, not what was contained in the 12083. Would be interesting see exactly in what part of the previous link the author was saying that comment on Unicode "was contained in the 12083." > Of course the MathML committee members knew that 12083 was > developed years before MathML. Which may do more difficult to understand some design options taken by the committee. > People in the working group were very aware of its strengths > and weaknesses and MathML was developed with feedback from > users of 12083 (ie, publishers) as to what to avoid. Let me doubt this please, in my opinion presentational MathML 2.0 is a poor copy of ISO 12083. > I realize that English is not your first language; before you > resort to insulting remarks about the intelligence of others, It was no my intention. But if you feel better, please let me add I consider to myself to be not clever. One can see couple of mistakes and errors I did in [http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html] for instance. > 12083 has "embellishments", which can be used for diacritical > marks in the same way that <mover> can be used for > diacritical. > My comment was that 12083 is silent on the matter which I > raised -- ie, whether a character should be used or whether an > embellishment should be used. In my opinion ISO 12083 relies on ISO 8879 (1986) for Diacritical Marks Seeing the general character of entities in ISO 8879 Most are accents, more breve, caron, cedilla, dieresis, etc. and seeing that there is not double dot I suspect that are left to textual purposes. However, I suspect that in future revision of ISOs we will be increasing usage of specific mathematical international standard Unicode ranges. Which would be preferred over specific non-standard markup as <mover> and <munder>. > There are a lot of generalities here which about problems with > <mover> and <munder>. Rather than misinterpret what you mean > to say, could you please clarify "the well-known difficulties, > weakness and error designs of MathML, including > incompatibilities with CSS and DOM and all that without > review real support of MathML in browsers". Please list the > specifics with respect to <mover> and <munder> (to which your > comment applies). Sorry but Sun would burn all its combustible before ;-) Some ideas. Firefox does not pass many official tests of the MathML test suite. Something so simple as <math style="color:blue"> <mn>2</mn> </math> is not passed, one would recover the same error in a more general construct with mover or munder. Using a more general Unicode approach I could easily implement that effect via a CSS rule. Similar thoughts apply to official test <mn style="font-size:24pt; font-weight:bold">2</mn> and several other tests like mstyleAminscript1 et cetera. My firefox browser does not pass the munder1 and munder2 test, but I think that Unicode is not designed for munder2. I do not find satisfactory rendering of accents in the accent test suite. We also talked at this mailing list about the introduction of base inside, the ineffective double markup, and of the needed changes in <mover> and <munder> for can be fully incorporated in browsers rendering engine. All that was explcitely listed in previous postings. Moreover, Unicode is designed for on and off web usage. Printing of MathML is far from good and some people is transformating it to TeX before printing. The support of MathML in browsers is minimal and this is because difficulties for implementation. However, something so old as ISO 12083 was implemented in Opera browser with minimal changes in original 12083 (which was not designed for web!!!!). Maybe you would think carefully why MathML, *specifically designed for web*, is being rejected for implementation in Opera browser (as was rejected in MSIE and others). It is also know that MathML specification is easily abused. We saw examples of this. White Lynx listed examples of abused <mover> I will list examples of MathML output for q-dot and renderings via Mathematica 5.2. It is a disaster. That is avoided using Unicode. I repeat again that Unicode is a standard whereas MathML is not and we would prefer more general "markup" over specific one. > This is both a red-herring and wrong. > Red herring: Presentation MathML is meant to be used for mathematical > notation. It is not meant to be used to construct linguistic > modifications of characters...as several people have already replied. > Nor is it meant for writing chemical formulas (another area where you > misapplied MathML and used it as evidence MathML is flawed). Hum! i) Unicode is able to differentiate diaresis from double dots and all that. MathML <mover> and <munder> say nothing. ii) Argument claiming for what was designed presentation MathML forgets that content Markup is not popular. Most of tools and all browsers focus on presentation MathML. By forcing usage of <mover> and <munder> we are forcing ambiguous coding because content MathML will be not used for disambiguating. iii) It is interesting see that MathML is not designed for chemical formulas. Several points about this. a) From descci.com I obtained <blockquote> WebEQ Interactive math on the web Design Science WebEQ™ Developers Suite is a comprehensive toolkit for building web pages that include interactive math. The world's leading e-learning companies, content developers and education portals are using WebEQ to create web-based learning environments that help educators engage students in math and science on the web. Because WebEQ is based on Java and MathML technology, solutions you develop will be platform- and browser-independent. </blockquote> The Features page says "Expanded editor preferences, including new support for chemistry notation". Please explain there to your readers/users that MathML is not designed for chemical notation. b) I thought that x + y = xy was math (Boole algebra). I thought that Na + Cl = NaCl was math also and that is just chemistry if I said that Na and Cl are. Somewhat as E=mc^2 is math but E=mc^2 is physics if you explain that E is energy m is mass... m can be negative in pure math, E=mc^2 is "equal" to y=ax^2 but m in physics is not negative... c) Please note that next fragment <blockquote> In different presentational contexts, the multiplication operator might be invisible " H e", or rendered as the spoken word "times". Generally, many different presentations are possible depending on the context and style preferences of the author or reader. Thus, given " H e" out of context it may be impossible to decide if this is the name of a chemical or a mathematical product of two variables H and e. </blockquote> in "4.1.1 The Intent of Content Markup" [http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter4.html] may be confusing for readers. d) Here [http://chem2.chem.ncsu.edu/~hennesse/Experiment_29.xml] MathML is being used for "for writing chemical formulas" And also in ASCIIMath page here [http://math.chapman.edu/cgi-bin/mathxml.pl?ASCIIMath_Comments_and_Suggestions] The situation in last page is still poor because a trick is used for rendering roman tokens. Please take the time for personally aware to that entire people that MathML was not designed "for writing chemical formulas" and they are "misusing" it. e) When I mean the use of MathML for rendering simple chemical formulae I mean similar thought to expressed by Digital Archive of Journal Articles National Center for Biotechnology Information (NCBI) National Library of Medicine (NLM) here [http://dtd.nlm.nih.gov/tag-library/2.0/n-2r30.html] f) I also find interesting to see as The American Physical Society writing the formula for water using TeX, whereas apparently MathML is not thought for that. > Wrong: Unicode's "COMBINING DIAERESIS" (308) has several > aliases, one of which is "double derivative". So if you > feel the informative alias as "double derivate" is a good use > of the code point, you have lost the distinction between > the two. If however, you use it as a diaeresis and use > <mover> to represent the mathematical meaning, then you > have distinguished between the two usages. I doubt that you can find ambiguities on the aliases of 0308; in mathematical usage it can be interpreted as double derivative. No, you cannot use 0308 for diaresis as you are claiming because the code for diaresis is 00A8!!! I repeat again that Unicode is able to distinguish usages but MathML <mover> cannot. By using <mover> the tool has absolutely no idea that I am encoding and one recover all errors and difficulties cited previously. > > Neil Soiffer > Senior Scientist > Design Science, Inc. > neils@dessci.com > www.dessci.com > ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~ Juan R. Center for CANONICAL |SCIENCE)Received on Monday, 1 May 2006 14:06:34 UTC

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