Re: Profiling and certificates for MathML. Avoiding imitators

White Lynx wrote:
>
> It makes sense to have something similar in MathML, but we don't have well
> defined profiles yet, in case of MathML 2.0 there is one MathML DTD that
> allows to mix everything. Also putting two extra attributes on every math
> element is probably redundant, maybe it is better to specify it once on
> document level?

In that way, there is no posibility for mixed documents from different
authors to be properly merged.

2007 Practical case:

Authors A, B, and C generate three fragments, next united (copy pasted) by
A, who submit a single file to Canonical Science Reports. Internal
software semi-authomatically processes the input according to guidelines
G-1 and G-3.

> but still I doubt that average LaTeX user would agree to author ISO-12083
> like markup manually and making XML based math markup less verbose then
> ISO-12083 was, effectively means switching to non-XML syntax, which is not
> exactly what we need).

About average LaTeX users, well many of them are just misinformed 'thanks'
to TeX popularity. However, TeX users learn computer languages therefore
they know that $E=mc^2$ is enough for printing, but for representation
they learn e.g. E == m * c ^ 2.

The problem with XML is it is too verbose. Therefore even if thay can
understand the XML need for all those brackets they cannot type that.

> Technically it is unclear for me who should certify who and how. Tools
will be improved if there is
> requirement for better tools coming from users and content publishers
and if output does not require
> authoring tools to provide more information then they can extract from
input.

I was refering to people taking MathML name because propaganda motives. It
is not a question of optimization of tools, simply they are calling MathML
to something is not.

Elsevier people is not working with MathML standard, but at least they
alert of the modification on the DTD.

Sure you will find technical and legal stuff, but it may be better than
doing nothing waiting the break. Moreover no many time ago the W3C did an
atempt to patent policies. Sure then they though on all kind of issues.

2007 Practical case:

Author J submits paper P with MathML. He or she is using tool T he found
on the web. The source contains code cannot be proccessed by usual MathML
processor. You reject file arguing that is not MathML. "But I used a
MathML tool!" is the reply.

HTML5 was defined as anything being sent as text/html. Would MathML in
HTML to be defined in a similar imprecise way?

<math/>...</math>

<math>... <i>a supposed variable here copied and pasted from the
text</i>...</math>

<math>... E = m <msup>c 2</msup> ...</math>

<math>... some XUL code here ...</math>

...

Would we accepted as MathML anything being digestted by Gecko?


2007 Practical case b:

Body B generates tool L. Tool generates valid nice MathML. Market is using
browser F claiming MathML support for HTML5. You begin distributing some
units of L, but after some time users reclaim you because files generated
by L are not rendered by F. It is clear -to users- that tool L is flawed.
B accusses F from misleading publicity but the damage was done.

Today, any tool generating <none/>, <plus/> or <mtext/> will be incorrect
from the point of view of a HTML 5 average user. Would we rewrite those
100 tools? What will become next? And what if HTML5 is not so popular as
some predicted? A new 180º change for the 2012? What then? The *non-XML*
and *non-HTML* language that certain organization is trying to popularise?

Some control over is or not is MathML appears to be needed.

Received on Thursday, 21 December 2006 18:23:35 UTC