Re: MathML-in-HTML5

> Ian Hickson said:
>
> On Wed, 4 Oct 2006 juanrgonzaleza@canonicalscience.com wrote:
>>>
>>> IMHO backwards compatibility is not just "desirable", it is absolutely
>>> and fundamentally critical. Specification authors should always make
>>> their specs backward and forward looking.
>>
>> Then why all this stuff? Since you are proposing (ups i forgot that you
>> are not proposing anything even if look that) is not backward compatible
>> with current status of MathML authoring and processing.
>
> The idea of introducing math markup to text/html documents is completely
> orthogonal from the existence of MathML markup in XML documents.
> Compatibility with current MathML authoring and processing is neither here
> nor there -- the proposal here doesn't affect it in any way.
>
>
>> You can do [various things that have been at one time or another
>> suggested] but do not call it ***mathml***
>
> Ok.
>

Ok, let me call it ‘MathTml’.

I am more pragmatic still and do not worry about different alternative
proposals trying ot obtain extra functionality in well-defined fields.
Therein, I am not against others HTML5 initiatives including <canvas> or
Web Forms.

Since we already discussed about alternative mathematics in HTML5 I see
not problem also here. My current criticism was focused on the
implementation of a so called ‘MathML’ was not MathML really. But since
you are really focused on

> The idea of introducing math markup to text/html documents is completely
> orthogonal from the existence of MathML markup in XML documents.

Then most of my previous criticism vanishes. For instance, I see no
problem on you doing a statistical analysis of the usage of MathML
entities for implementation of a subset of them, since you are _not_ doing
mathml. It would be not a surprise for me if you find zero frecuency for
many entities and then decides to avoid supporting them.

If this new approach obtains success and many mathematicians begin to
publish math in your html 5 (you asure oftens you obtained this class of
feedback) then you can wait conversors from/back CanonML.

Somewhat as I already said to Brian Jones -a program manager in Office-
that conversion between CanonML and the new 2007 format for mathematics
(OMML) is one of my priorities (several scientific comunities submit
papers in Word format today). In fact, even PRL (and other APS journal)
now begin to admit submissions in Word format.

Somewhat as I said here that if next MathML 3 is good enough and obtains a
minimal popularity between our people we will develop conversors also.

Somewhat as XML-MAIDEN approach is a crucial piece for next -non
experimental- Center’s Website. Visitors can read mathematical formulae
without plugins, special fonts or without a Mozilla browser thanks to CSS
techniques. I think that scientific and educative material would be
accesible to anyone and I am really tired of “you need IE+plugin or
FF+fonts for seeing this site”.

Once remarked this, I have some queries for your proposal.

Next MathML

<mrow><mi>a</mi><mo>+</mo><mn>2</mn></mrow>

is next mathtml in HTML5

<mrow>a + 2</mrow>

but

<mfrac><mi>b</mi><mn>5</mn></mfrac>

would be (tecnically inefficient in Mozilla)

<mfrac><mrow>b</mrow><mrow>5</mrow></mfrac>

Why not adding num and den

<mfrac><num>b</num><den>5</den></mfrac>

had been 'aproved' at the WHATWG list (even a Mozilla developer agreed was
not a bad idea)?

Moreover, is the tokenizer spaces-based just like some EXSLT functions or
XSLT templates of str:tokenize()? Is next valid?

<mrow>0.269736842105263157894<mover accent='true'>736842105263157894
&#...</mover></mrow>

or may be

<mrow>0.269736842105263157894 <mover accent='true'>736842105263157894
&#...</mover></mrow>?


Ian Hickson said:
>
> There are literally tens of millions of
> pages, for instance, that use the "xmlns" attribute on the <a> element,

What is the problem with using the xmlns attribute on <a> or <html:a>
elements in a XML approach?


Juan R.

Center for CANONICAL |SCIENCE)

Received on Thursday, 5 October 2006 08:40:18 UTC