Accueil > Projets > ScientificPad / MathMLPad [fr] > Problèmes avec MathML.

Problèmes avec MathML.

Quel langage de marquage xml choisir pour ScientificPad ?

samedi 23 février 2008, par ScientificWare

Ceci est un essai, pour formaliser mon problème. D’autres auteurs d’applications ne s’embarrassent pas de ce type de question. Mais cette problématique est fondamentale.

Commençons par : ceci n’est pas une fraction \frac{a}{b}.

Il s’agit simplement de deux lettres séparées par un trait.

Cette remarque est à l’origine du retard pris (j’annonçais une première version pour septembre 2007). Construire un interpréteur (parser, parseur) XML pouvant lire du MathML ne presente pas de difficulté majeure, mais savoir ce qu’il doit lire est une autre question ! Comment les documents ScientificPad seront-ils codés en XML ?

Quels sont les moyens disponibles pour coder des textes mathématiques :
 LATEX,
 MathML,
 sérialisation TexMacs.

Dans chacune de ces solutions les formules mathématiques sont dissociées du texte soit par des balises par exemple <math></math> ou un symbole par exemple $.

Lors de l’élaboration du langage MathML (w3C), ses créateurs ont pris soin de séparer la présentation du sens. Cette approche parait à première vue être une bonne analyse, mais il me semble qu’elle est incomplète. Pourquoi ne pas aller plus loin ?

En mathématiques une fraction n’est pas liée à l’écriture de \frac{a}{b}, c’est un objet qui peut être également représenté par a/b ou bien (a ;b) et pourquoi pas a+b... ( dans ce cas 1+1=2+2=3+3=...=1). Ce ne sont que des notations ! Et il y a des habitudes qui sous-entendent des définitions. Mais ces conventions peuvent évoluées pour faciliter les calculs.

Dans ce cas, comment dois-je percevoir la commande <mfrac></mfrac> dans la recommandation MathML :

 est-ce un complément de commande de présentation,
 ou un objet spécifique aux mathématiques.

Ce que cela change :
 Le marqueur <mfrac></mfrac> défini par les recommandations MathML était utilisé par ScientificPad dans le modèle interne du document, il sera remplacé par <over></over>. En ce qui concerne les autres, j’aime bien la notation de OpenOffice dans l’éditeur mathématique.
<lsup></lsup>
<csup></csup>
<rsup></rsup>
<lsub></lsub>
<csub></csub>
<rsub></rsub>
...
 Dans ce cas, c’est à dire au niveau 1, ScientificPad est simplement un outil typographique, il décide seulement de la place des lettres les unes par rapport aux autres : structure typographique. Elle peut être complexe : paragraphe, chapitre, cadre, tableau, exposant, fraction, indice, au-dessus, au-dessous, décoré par un radical, un chapeau, un simple trait ... c’est pour cette raison que dans certains cas on doit utiliser une aborescence. L’avancée de ScientificPad est la notion continuité et de discontinuité typographique. Les auteurs de la bibliothèque javax.swing.text n’ont pas poussé leur réflexion jusqu’à son terme. En explorant les confins du code javax.swing ce manque est flagrant pour pouvoir passé à l’étape suivante et je ne suis pas sûr que tous les programmeurs aient conscience de la puissance de cette bibliothèque. Cette barrière a sauté depuis 2 ans déjà en ce qui me concerne. Ce premier niveau doit rompre avec toute allusion mathématique (dans un premier temps : pour permettre de distingué tous ses contours). Il est donc indispensable de modifier les marqueurs.
 Pour donner du sens à un texte et permettre une exportation dans d’autres formats comme TEX, LATEX, MathML, ou un traitement automatique, une deuxième couche est alors nécessaire. Ce niveau sera assuré par un compilateur/interpréteur mathématique devant s’assurer de la cohérence des objets mathématiques (Définitions). Copié sur le modèle des compilateurs/interpréteurs de langage de programmation, il travaillera en arrière plan. Si l’auteur manifeste son intention de donner un sens à son texte, des conventions d’écriture pourront être disponibles pour faciliter son travail. La partie du texte à suveiller sera alors marquée par les balises <math></math>. Mais ce système sera facultatif : là ou MathML propose un système figé, ScientificPad proposera un système évolutif. Le marqueur <math></math> déclenchera l’analyse mathématique du texte.
 Pour respecter des conventions de prononciation un quatrième niveau peut être ajouté...
 ...

Autres questions :
 Où s’arrêter ? Tout dépend des besoins ! Par exemple, quand est-il nécessaire de donner un sens ? Le lecteur donne (sans autre intervention) un sens à un texte en le lisant. Les niveaux successifs sont par contre nécessaires pour un traitement automatique du document.
 L’ordre des marqueurs a-t-il une importance ?
 L’export au format MathML est-il important ?

La notion de package de java ou de namespace de XML est intéressante. On peut imaginer un ensemble de paquet ou d’espace de définition disponible pour permettre à un utilisateur de développer un texte mathématique. Prenons comme exemple l’intégration, on peut définir par exemple 3 paquets ou espaces mathématiques :
 le paquet intégrale.riemann.guy qui regroupe les définitions et les notations de base de l’intégrale de riemann selon mon point de vue,
 le paquet intégrale.lebesgue.guy,
 le paquet intégrale.jauge.guy.

Ces paquets faisant eux-mêmes appel à d’autres paquets.

Tous les ingrédients sont disponibles dans un ouvrage mathématique :
 Titre,
 Chapitre,
 Définition,
 Proposition,
 ... .

Il ne reste plus qu’à les programmer.

Les trois étapes d’analyse du texte (Illustration Cours de compilation) :
 Analyse lexicale,
 Analyse syntaxique,
 Analyse semantique.