Re: mover vs latin chars with diacriticals

David Carlisle wrote:

>> or any other possibility denoting derivative. It is more, if we carefully
>> claim that Presentational MathML just render things as x^2 and x^2 without
>> disambiguating (this is the task of the <power/> tag of Content MathML for
>> example) then it may be difficult the justification for disambiguating ü
>> from ü in Presentation MathML 2.0.
>
> No, this isn't difficult at all as the situations are completely
> different.

Do you mean different from a rendering (presentational part) point of view
or from a semantic (content) point of view?

> By using mover you are clearly marking up that you are using
> a layout form denoting some operation applied to the term represented by
> u, although The exact mathematical operation isn't explict and must be
> inferred from the context. If on the other hand you use an unicode
> composite then you are just saying it's a single mathematical term
> identified by a letter than happens to have an accent.

Single mathematical term? See some Unicode examples illustrated past month.

>> Do not forget that Unicode is international standard whereas MathML is
>> just w3c recommendation.
>
> As of course are CSS and HTML. Why are you not using the ISO standard
> DSSSL for styling if you don't trust the W3C to standardise things?

HTML is already standard. Of course, w3c is not an international standard
body (that is reason that offer us *recommendations*). Since I already
explained in several ways the advantages of using international standard I
do not consider needed "repeat myself".

Regarding DSSSL, well I am using (in some sense) it when use XSL. XSL is a
"subset" of DSSSL and next version of DSSSL will be fully a superset of
XSL. DSSSL is being used in some niches (e.g. Docbook) but lacks
popularity. In XML, DSSSL is preferred over XSL in those tasks that cannot
be done via XSL. About the lack of popularity of DSSSL, I think it is
known why... ask some TUG gurú.

>> That in TeX is encoded as \dot{q} in MathML was encoded in four different
>> ways.
>
> most of the ways you showed in MathML were spurious, and of course in
> TeX it may be encoded in many other ways as well,
> \dot{q}
> \dot q
> \mathaccent "705F q
> \def\deriv#1{\dot{#1}}... \deriv{q}

I simply copied the ("spurious") code generated from different MathML
tools and pasted here.

Since I mapped a single input command, would be interesting repeat the
experiment with all different input ways you are providing just for
illustration. No more reply is needed to your weak pro-MathML argument.

> ...
> That's just the nature of things that even when marking up the same
> notation you have to account for stylistic differences in the use of
> markup syntax.

This reply fails to understand I really wrote and why I wrote it.

>> q-dot in a single Unicode way?
>
> Yes as it happens there is just one Unicode for q-dot, but Unicode also
> has issues with multiple representations as has been discussed already
> in this thread. For example c-dot has two representations U010b and
> U0063 U0307

Assuming this true (I did not check), two may be prefered over "infinite".
Your argument also appears to forget Unicode defined canolizations. Of
course, there is not similar method in MathML 2.0.

>
>> Maybe a full complete unification (an only way) was impossible, but note
>> all outputs were generated from the same input: \dot{q}.
>
> As in earlier threads, you are testing the convertors, not testing the
> languages. You could take a single MathML expression and 6 different
> MathML to TeX convertors and probably get three or four different TeX
> expressions, but that doesn't tell you anything about either language
> really.

This kind of reply misunderstands the whole point. I see not need for
replying again if I am systematically misunderstood. About "you are
testing the convertors, not testing the languages" I did sufficient
extensive comments and argumentations on why your belief is weak.

> David


Juan R.

Center for CANONICAL |SCIENCE)

Received on Thursday, 4 May 2006 11:32:08 UTC