Lisez-moi S.V.P. 

7 L'interface MathML

Table des matières : Le langage de balisage mathématique (MathML) version 2.0
Chapitre précédent : 6 Les caractères, les entités et les fontes
Chapitre suivant : 8 Le modèle objet de document de MathML

Pour être utile, MathML doit fonctionner correctement avec une grande variété de moteurs de rendu, de processeurs, de traducteurs et d'éditeurs. Ce chapitre aborde quelques problèmes d'interface posés par la génération et le rendu MathML. Puisque la principale raison d'être de MathML est de coder des mathématiques dans des documents Web, les problèmes d'interface les plus importants toucheront probablement liés à l'incorportation de MathML dans [HTML4] et [XHTML].

Trois types de problèmes d'interface se présentent pour incorporer MathML dans d'autres documents XML. Premièrement, MathML doit s'intégrer sémantiquement. Le balisage MathML doit être perçu comme un contenu XML valide et non comme une condition d'erreur. Cela revient essentiellement à une gestion d'espaces de nommage XML [Les espaces de nommage dans XML].

Deuxièmement, pour HTML/XHTML, le rendu MathML doit être intégré au logiciel de navigation. Certains navigateurs mettent déjà en œuvre nativement un rendu MathML et on peut s'attendre à ce que plus de navigateurs le fassent dans le futur. En même temps, d'autres navigateurs ont développé une infrastructure pour faciliter le rendu de MathML et d'autres contenus XML imbriqués par un programme tiers. L'utilisation des mécanismes spécifiques de ces navigateurs nécessite généralement un type de balisage d'interface supplémentaire pour les activer.

Troisièmement, les autres outils de génération et de traitement MathML doivent être capables de communiquer entre eux. Un certain nombre d'outils MathML ont été développés (ou sont en cours de développement), dont des éditeurs, des traducteurs, des systèmes de calcul algébrique et d'autres logiciels scientifiques. Toutefois, comme les expressions MathML tendent à être longues et sujettes à des erreurs lorsqu'elles sont entrées manuellement, et pour générer facilement le code MathML, il faut tout particulièrement s'assurer que les outils de conversion et d'édition soient conviviaux et fonctionnent ensemble de façon fiable indépendamment de la plateforme et du vendeur.

Le groupe de travail Math du W3C s'est engagé à soutenir les vendeurs de logiciels développant tous types d'outils MathML. Le groupe de travail surveille la liste de diffusion publique www-math@w3.org et essaye de répondre aux questions concernant la spécification MathML. Le groupe de travail coopère avec des groupes de développeurs et d'utilisateurs MathML. Pour une information à jour sur les outils, les applications et les activités de soutien aux utilisateurs MathML, cf. la page d'accueil du groupe de travail Math du W3C.

7.1 L'incorporation de MathML dans d'autres documents

Bien qu'on puisse utiliser MathML isolément comme langage pour l'échange d'expressions mathématiques entre des applications compatibles MathML, sa destination principale est le codage d'expressions mathématiques au sein de documents plus grands. MathML est idéal pour incorporer des expressions mathématiques dans d'autres applications XML.

En particuler, l'accent est mis ici sur la mécanique d'incorporation de MathML dans [XHTML]. XHTML est une recommandation du W3C qui établit une famille de types de document et de modules, basés sur XML, présents et futurs, reproduisant, réduisant ou étendant HTML. Bien que [HTML4] soit le langage dominant du Web au moment de la rédaction de ce document, un glissement de HTML vers XHTML est prévisible. En effet, on peut déjà produire du code XHTML dont le rendu est correct sur la plupart des agents utilisateurs HTML.

Dans la mesure où MathML et XHTML s'inscrivent dans un cadre XML commun, les espaces de nommage constituent un mécanisme normalisé pour incorporer du MathML dans XHTML. Même si certains agents utilisateurs courants permettent d'inclure directement un code MathML dans HTML comme îlots de données XML, il s'agit d'une stratégie de transition. Consultez la documentation de l'agent utilisateur pour des informations spécifiques sur son incorporation de XML dans HTML.

7.1.1 MathML et les espaces de nommage

L'incorporation de MathML au sein de documents basés sur XML, en général, et dans XHTML, en particulier, revient à gérer des espaces de nommage. Voir la recommandation du W3C Les espaces de nommage dans XML [Les espaces de nommage] pour des précisions.

Un espace de nommage XML est un ensemble de noms identifiés par une adresse URI. L'adresse URI de l'espace de nommage MathML est la suivante :

http://www.w3.org/1998/Math/MathML

En utilisant des espaces de nommage, l'incorporation d'une expression MathML dans un document XML plus grand consiste simplement à identifier le balisage MathML comme résidant dans l'espace de nommage MathML. On peut y parvenir en identifiant explicitement chaque nom d'élément MathML au moyen d'un préfixe d'espace de nommage associé, ou bien en déclarant un espace de nommage par défaut sur un élément englobant.

Pour déclarer un espace de nommage, on se sert d'un attribut xmlns ou d'un attribut préfixé avec xmlns. Si l'attribut xmlns est utilisé seul, il fixe l'espace de nommage par défaut de l'élément sur lequel il apparaît et sur tous ses sous-éléments.

Exemple :

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>...</mrow>
</math>

Si l'attribut xmlns est utilisé comme préfixe, il déclare alors un préfixe pouvant servir à associer explicitement d'autres éléments et attributs à un espace de nommage particulier.

Exemple :

<body xmlns:m="http://www.w3.org/1998/Math/MathML">
...
<m:math><m:mrow>...</m:mrow></m:math>
...
</body>

On peut utiliser ces deux méthodes de déclaration d'espace de nommage ensemble. Par exemple, en utilisant à la fois un préfixe d'espace de nommage global pour le document et des déclarations d'espace de nommage par défaut sur des éléments mathématiques individuels, il est possible de concentrer le balisage relatif à un espace de nommage sur l'élément de premier niveau math. Cela a également des conséquences de mise en œuvre pour certains agents utilisateurs, car associer des comportements de rendu à un élément impose actuellement d'utiliser un préfixe d'espace de nommage explicite dans ces navigateurs. Dans le même temps, beaucoup d'outils d'édition MathML ne reconnaissent pas encore les espaces de nommage, et, dans l'immédiat, il est donc aussi souhaitable de pouvoir utiliser un balisage sans préfixe.

Exemple :

<body xmlns:m="http://www.w3.org/1998/Math/MathML">
...
<m:math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>...<mrow>
</m:math>
...
</body>

7.1.1.1 Les problèmes de validation des documents

L'utilisation des préfixes d'espace de nommage pose un problème pour valider des documents incorporant du code MathML contre une définition DTD. La validation contre une définition DTD exige de connaître les noms littéraux des éléments (éventuellement préfixés) utilisés dans le document. Par contre, la recommandation pour les espaces de nommage dans XML [Les espaces de nommage] permet de changer un préfixe à des points arbitraires dans le document, puisqu'on peut déclarer un préfixe d'espace de nommage sur n'importe quel élément.

La méthode historique pour contourner cet obstacle consistait à écrire une définition DTD avec un préfixe fixe ou, dans le cas de XHTML et MathML, sans préfixe, puis à imposer l'emploi de la forme spécifiée dans tous le document. Toutefois, cet emploi est quelque peu restrictif pour une définition DTD modulaire censée être utilisé conjointement avec une autre définition DTD, ce qui est précisément le cas pour MathML dans XHTML. En essence, la définition DTD de MathML devrait allouer un préfixe à elle-même et espérer qu'aucun autre module n'utilise le même, pour ne pas risquer de conflits de noms, perdant ainsi un des atouts principaux des espaces de nommage XML.

Une stratégie pour résoudre ce problème est de permettre l'accès de chaque nom d'élément dans la définition DTD au moyen d'une référence d'entité. Ainsi, en déclarant quelques entités afin de définir le préfixe avant le chargement de la définition DTD, l'auteur du document peut choisir le préfixe, et les définitions DTD composées de plusieurs modules peuvent, sans changer les modules DTD, définir des préfixes uniques pour chaque module en évitant les conflits. La définition DTD de MathML est conçue ainsi. Cf. la Section A.6 [La définition DTD de MathML] et la [modularisation] pour des précisions.

Un autre problème se pose si on utilise des préfixes explicites sur l'élément de premier niveau math, alors qu'on utilise un espace de nommage par défaut pour les autres éléments MathML. Auquel cas, on incluera le module MathML dans XHTML en utilisant un préfixe vide. Par contre, le fichier DTD pilote qui établit l'inclusion du module MathML devra alors définir un nouvel élément appelé m:math. L'élément de premier niveau math pourra alors utiliser un préfixe explicite, afin d'associer des comportements de rendu aux navigateurs actuels, tandis que les éléments contenus n'auront pas besoin d'un préfixe explicite, pour une meilleure interopérabilité avec les outils d'édition, etc.

7.1.1.2 Les suggestions de compatibilité

Bien que les recommandations concernées du W3C décrivent complètement l'utilisation d'espaces de nommage pour imbriquer du code MathML dans d'autres applications XML, une certaine forme de pragmatisme reste toujours de mise pour l'instant. La gestion de XML, des espaces de nommage et des comportements de rendu par les agents utilisateurs courants n'est pas toujours en phase avec les recommandations du W3C. Les logiciels sont parfois antérieurs aux normes concernées ou bien celles-ci ne sont pas encore prêtes.

Pendant la période de transition, au cours de laquelle certains logiciels ne seront peut-être pas entièrement compatibles avec les espaces de nommage, quelques pratiques conventielles permettront de réduire les problèmes de compatibilité :

  1. Pour utiliser des préfixes d'espace de nommage avec un balisage MathML, choisissez m: comme préfixe conventionnel de l'espace de nommage MathML. L'utilisation d'un préfixe explicite est probablement plus sûre en ce qui concerne la compatibilité avec les agents utilisateurs actuels ;
  2. Pour utiliser des préfixes d'espace de nommage, choisissez-en un et servez-vous-en de façon cohérente dans le document ;
  3. Déclarez explicitement l'espace de nommage MathML sur tous les éléments math.

Exemples :

<body>
...
<m:math xmlns:m="http://www.w3.org/1998/Math/MathML">
<m:mrow>...<m:mrow>
</m:math>
...
</body>

Ou encore :

<body>
...
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>...<mrow>
</math>
...
</body>

Remarquez que ces seules suggestions ne suffiront peut-être pas à créer des pages Web fonctionnelles contenant du balisage MathML. Il sera sans doute nécessaire d'utiliser un balisage supplémentaire du document dans sa totalité. Il faudra peut-être aussi des travaux supplémentaires afin de rendre compatibles toutes les instances MathML dans un document avec les déclarations portant sur le document dans sa totalité. Et tout particulièrement lorsque les documents sont créés par copier-coller des expressions MathML, car les outils actuels ne pourront probablement pas rechercher les informations de l'espace de nommage global.

Consultez la page d'accueil du groupe de travail Math du W3C pour des suggestions de compatibilité et de mise en œuvre pour les navigateurs actuels et autres outils compatibles MathML.

7.1.2 L'élément de premier niveau math

MathML définie un seul élément de premier niveau, ou élément racine, l'élément math, lequel encapsule chaque instance de balisage MathML au sein d'un document. Tous les autres contenus MathML doivent être contenus dans un élément math ; dit autrement, chaque expression MathML complète valide doit être contenue entre des balises <math>. L'élément math doit toujours être l'élément le plus externe d'une expression MathML, et qu'un élément math en contienne un autre constitue une condition d'erreur.

Les applications renvoyant des sous-expressions d'autres expressions MathML, par exemple, en résultat d'un copier-coller, devraient toujours les envelopper avec des balises <math>. La présence de balises <math> englobantes devrait représenter un test heuristique idéal pour identifier un document MathML. De même, les applications insérant des expressions dans d'autres expressions MathML doivent s'attacher à retirer les balises <math> des expressions internes.

L'élément math peut contenir un nombre arbitraire de sous-schémas. Par défaut, les sous-schémas sont rendus comme s'ils étaient contenus dans un élément mrow.

Les attributs de l'élément math sont les suivants :

class, id, style
Fournis pour servir avec des feuilles de style.
xref
Fourni avec id pour servir dans un traitement XSL (cf. la section 5.4 Les outils, les feuilles de style et les macro-commandes du balisage combiné)
macros
Cet attribut permet d'appeler des fichiers de définitions de macro-commandes externes. La spécification MathML ne définit pas de macro-commandes, et la plupart de leurs fonctionnalités peut être obtenue, dans MathML, par des transformations XSL [XSLT]. L'attribut macros est toutefois proposé pour permettre le développement futur de mécanismes de macro-commandes plus directs, spécifiques à MathML. La valeur de cet attribut est une séquence d'adresses URL ou URI, séparées par des blancs.
mode
L'attribut mode indique si le rendu de l'expression MathML englobée devrait avoir lieu en mode bloc ou en mode en-ligne. Les valeurs admises sont "display" et "inline" (valeur par défaut). L'utilisation de cet attribut est déconseillée en faveur du nouvel attribut display, ou de la propriété 'display' de CSS2, avec les valeurs correspondantes "block" et "inline".
display
L'attribut display remplace l'attribut déconseillé mode. Il indique si le rendu de l'expression MathML englobée devrait avoir lieu en mode bloc ou en mode en-ligne. Les valeurs admises sont "block" et "inline" (valeur par défaut).

Les attributs de l'élément math affectent l'expression englobée dans sa totalité. En quelque sorte, ils regardent vers l'intérieur. Toutefois, pour un rendu MathML correct dans un navigateur, et pour une bonne intégration dans un document XHTML, un deuxième ensemble d'attributs regardant vers l'extérieur est aussi utile.

Bien que des mécanismes généraux pour attacher des comportements de rendu aux éléments des documents XML soient en cours de développement, des grandes variations demeurent entre les stratégies et les niveaux de mise en œuvre des divers agents utilisateurs existants. Par conséquent, le reste de cette section décrit les attributs et les fonctionnalités souhaitables pour l'intégration des modules de rendu de tiers dans les agents utilisateurs :

overflow
Au cas où la négociation de la dimension n'était pas possible, ou échouait (par exemple, dans le cas d'une équation extrêmement longue), cet attribut suggère une méthode de traitement alternative au moteur de rendu. Les valeurs admises sont les suivantes :
scroll
La fenêtre fournit une zone de fenêtrage dans l'affichage complet plus grand de l'expression mathématique. Des barres de défilement horizontales et verticales s'ajoutent à la fenêtre, selon ce qui est nécessaire pour permettre le déplacement de la zone de fenêtrage à une position différente.
elide
L'affichage est abrégé en lui en ôtant suffisamment pour que le reste tienne dans la fenêtre. Par exemple, un grand polynôme s'afficherait avec + ... + entre son premier et son dernier terme. Les moteurs de rendu plus sophistiqués peuvent fournir un dispositif pour agrandir les aires élidées.
truncate
L'affichage est abrégé en le tronquant simplement sur les bords droit et bas. La signalisation de la troncature au lecteur est recommandée.
scale
Les polices servant à afficher l'expression mathématique sont choisies de façon à ce que l'expression entière loge dans la fenêtre. Remarquez que ce cas se présente seulement si l'expression est trop grande. Au cas où la fenêtre est plus grande que nécessaire, l'expression apparaît avec sa taille normale dans la fenêtre plus grande.
altimg
Cet attribut fournit une solution de repli gracieuse aux navigateurs qui ne gèrent pas les éléments incorporés. La valeur de l'attribut est une adresse URL.
alttext
Cet attribut fournit une solution de repli gracieuse aux navigateurs qui ne gèrent pas les éléments ou les images incorporés. La valeur de l'attribut est une chaîne textuelle.

7.1.3 L'invocation des processeurs MathML

Là où les navigateurs ne gèrent pas directement MathML, on prévoit un rendu MathML via des objets incorporés, tels que des modules d'extension, des appliquettes ou des applications auxilliaires. La tendance qui se dessine pour invoquer des programmes de rendu et de traitement de tiers est détaillée dans le brouillon de travail du W3C Les extensions comportementales de CSS [Les comportements].

Les extensions comportementales utilisent le mécanisme de liaison de CSS pour relier des composants exécutables aux éléments. Typiquement, les composants exécutables impliquent un code écrit qui manipule le modèle objet de document (DOM) afin d'instancier d'autres composants de traitement MathML. Avec les mises en œuvre expérimentales des extensions de comportement des agents utilisateurs actuels, il est possible de joindre des composants de traitement aux éléments math, qui s'acquittent alors du rendu du balisage MathML dans la page XHTML.

Les travaux sur les extensions de comportement CSS se poursuivent au W3C et on ne doit pas considérer les mises en œuvre existantes comme normalisées pour l'instant. Toutefois, c'est une piste très prometteuse en ce qui concerne l'invocation souple et puissante des processeurs MathML de tiers.

Les types MIME [RFC2045], [RFC2046] offrent une autre stratégie utilisable avec les agents utilisateurs actuels pour invoquer un moteur de rendu MathML. Leur utilité principale apparaît lors de l'appel de fichiers distincts contenant du balisage MathML depuis un élément EMBED ou OBJECT. Le document [RFC3023] assigne à MathML le type MIME application/mathml+xml. Le groupe de travail Math du W3C recommande d'utiliser l'extension de fichier normalisée .mml pour la base de registre des navigateurs.

Dans MathML 1.0, on suggérait le type MIME text/mathml. Le document RFC3023 l'a rendu obsolète.

Bien que le rendu des expressions MathML a généralement lien dans un navigateur Web, d'autres fonctions de traitement MathML se déroulent tout naturellement dans d'autres applications. Parmi les tâches les plus courantes, ouvrir une expression MathML dans un éditeur d'équation ou dans un système de calcul algébrique.

Actuellement, il n'existe aucun moyen normalisé permettant de sélectionner l'application à utiliser, parmi d'autres, pour rendre ou traiter du code MathML incorporé. Avec l'avancement des travaux de coordination entre, d'une part, les navigateurs et les objets incorporés et, d'autre part, le modèle objet de document [DOM], une fonctionnalité de ce type devrait être prioritaire. Les auteurs et les lecteurs devraient pouvoir indiquer une préférence pour l'application MathML à utiliser dans un contexte donné. Par exemple, on peut imaginer une expression MathML sur laquelle un certain mouvement de souris indiquerait au navigateur de présenter au lecteur un menu déroulant montrant les divers types de traitement MathML disponibles sur le système, et les processeurs MathML préconisés par l'auteur.

Puisque le plus souvent ce sont des outils d'édition qui génèrent le code MathML, il importe particulièrement que l'ouverture d'une expression MathML dans un éditeur soit facile à réaliser et à mettre en œuvre. Dans beaucoup de cas, il sera souhaitable que l'outil d'édition enregistre des informations à propos de son état interne en même temps que l'expression MathML, de sorte que l'auteur puisse reprendre l'édition là où il l'avait laissée. La spécification MathML ne contient pas de disposition concernant explicitement l'enregistrement des informations d'outil d'édition. Dans certains circonstances, il peut être possible d'inclure des informations d'outil d'édition applicables au document entier sous la forme de métadonnées ; les lecteurs intéressés sont invités à visiter la page de l'activité Métadonnées du W3C pour les derniers développements concernant les métadonnées et la définition des ressources. Pour coder les informations d'état d'un outil d'édition appliquées à une instance MathML particulière, les lecteurs peuvent éventuellement se servir de l'élément semantics, cf. la section 4.4.11.2 Les sémantiques (semantics).

À court terme, quelle que soit la méthodologie, on encourage les développeurs d'applications de traitement MathML incorporé à essayer d'offrir les fonctionnalités de types suivants :

7.1.4 Le mélange et la liaison de MathML et HTML

Dans le but d'intégrer complètement MathML à XHTML, il devrait non seulement être possible d'imbriquer du MathML dans du XHTML, mais aussi d'imbriquer du XHTML dans du MathML. Toutefois, la gestion du XHTML dans du MathML présente de nombreuses difficultés. Pour l'instant, la spécification MathML n'autorise donc aucun élément XHTML dans une expression MathML, quoique cela puisse changer dans une révision ultérieure de MathML.

Dans la plupart des cas, les éléments XHTML (les titres, les paragraphes, les listes, etc.) ne s'appliquent pas à certains contextes mathématiques, ou bien MathML fournit déjà des fonctionnalités équivalentes ou meilleures spécifiquement adaptées à un contenu mathématique (les tables, les changements de style mathématique, etc.). Par contre, deux exceptions sont notables : les éléments XHTML d'ancre et d'image. Pour ces fonctionnalités, MathML s'appuie sur les mécanismes XML généraux de liaison et de graphiques élaborés par d'autres activités du W3C.

7.1.4.1 Les liens

MathML ne dispose d'aucun élément correspondant à l'élément d'ancre a de XHTML. Dans XHTML, on se sert d'ancres pour faire des liens et pour fournir des emplacements où un lien peut mener. En tant qu'application XML, MathML définit les liens en utilisant le mécanisme décrit dans la recommandation candidate du W3C Le langage de liaison XML [XLink]. Au moment de la rédaction, XLink n'est pas encore une recommandation, et le lecteur est donc prévenu qu'elle est susceptible d'autres révisions. Le mécanisme de liaison MathML étant défini par rapport à la spécification de liaison XML, le même avertissement vaut aussi pour lui.

Un élément MathML est désigné comme lien par la présence d'un attribut xlink:href. Pour utiliser l'attribut xlink:href, il est également nécessaire de déclarer l'espace de nommage approprié. Ainsi, un lien MathML typique ressemblerait à :

<mrow xmlns:xlink="http://www.w3.org/1999/xlink"
      xlink:href="sample.xml">
  ...
</mrow>

MathML indique que presque tous les éléments peuvent servir d'éléments de liaison XML. Les seuls éléments ne le pouvent pas sont ceux, tel l'élément sep, dont l'existence se justifie principalement pour lever les ambiguïtés sur d'autres structures MathML et qui ne correspondent en général à aucune partie d'un rendu visuel typique. La liste complète des éléments d'exception ne pouvant pas servir d'éléments de liaison est donnée dans la table suivante :

Les éléments MathML qui ne peuvent pas être des éléments de liaison
mprescripts none sep
malignmark maligngroup  

Remarquez que les spécifications du langage de liaison XML [XLink] et du langage de pointeur XML [XPointer] définissent aussi comment établir un lien au sein des expressions MathML. Néanmoins, il faut savoir que les logiciels actuels interpréteront ces liens correctement ou pas.

7.1.4.2 Les images

L'élément IMG n'a aucun équivalent MathML. La décision de ne pas offrir un mécanisme général MathML pour inclure des images tenait à plusieurs facteurs. Quoiqu'il en soit, le motif principal de l'absence de cette fonctionnalité pour les images est justifié par le fait que le langage MathML s'efforce péniblement de mettre à la disposition des processeurs la structure de notation et le contenu mathématique qu'il code, tandis que les informations contenues dans une image sont uniquement exploitables par un lecteur humain regardant la représentation visuelle. Ainsi, par exemple, selon le paradigme de MathML, il vaut mieux introduire des glyphes nouveaux via l'élément mglyph, lequel les identifie au moins comme glyphes, plutôt que de les inclure simplement comme images.

Finalement, hormis l'introduction de nouveaux glyphes, beaucoup de situations où l'on serait tenté d'utiliser des images se ramènent à un type de diagramme étiqueté. Par exemple, les diagrammes de nœuds, les diagrammes de Venn, les diagrammes de Dynkin, les diagrammes de Feynman et les diagrammes commutatifs compliqués tombent tous dans cette catégorie. En tant que tels, il vaudrait mieux coder leurs contenus au moyen d'une combinaison de graphique structuré et de balisage MathML. Du fait de la généralité de la structure de diagramme étiqueté, la définition d'un langage de balisage pour coder de telles structures déborde du cadre actuel de l'activité Math du W3C. Cf. les autres activités du W3C dans ce domaine à http://www.w3.org/Graphics.

7.1.5 L'utilisation de CSS avec MathML

Lorsque du code MathML est rendu dans un environnement compatible CSS, il est évidemment souhaitable de pouvoir contrôler les propriétés de style mathématique avec une feuille de style CSS. MathML 2.0 a revu en profondeur l'organisation des propriétés de style des éléments de présentation afin d'améliorer l'interaction entre les moteurs de rendu MathML et les mécanismes de style CSS. Quatre nouveaux attributs de style mathématique avec des valeurs logiques ont été introduits. Approximativement, on peut assimiler ces attributs aux sélecteurs propres des règles CSS qui affectent MathML.

Le contrôle du style mathématique n'est pas aussi simple qu'il pourrait d'abord y paraître, parce que le style mathématique et le style textuel sont très différents par essence. Dans un texte, le sens naît principalement du positionnement relatif des caractères, l'un après l'autre, pour former des mots. Ainsi, même si la fonte utilisée pour rendre le texte peut apporter des nuances de sens, la transformation des propriétés typographiques des caractères individuels laisse fondamentalement intacte la signification du texte. Par contraste, dans les expressions mathématiques, les caractères individuels dans des fontes spécifiques tendent à fonctionner comme des symboles atomiques. Ainsi, dans la même équation, un x en caractère gras italique et un x non gras sont presque toujours destinés à représenter deux symboles distincts, signifiant deux choses différentes. Dans l'usage traditionnel, il existe huit catégories typographiques de base pour les symboles. Ces catégories sont décrites par les attributs de style mathématique, principalement l'attribut mathvariant.

La disposition du texte et celle des mathématiques diffèrent aussi de manière évidente en cela que les mathématiques utilisent une disposition en deux dimensions. Par conséquent, beaucoup de paramètres de style qui affectent la disposition mathématique n'ont pas d'analogues textuels. Même en cas de propriétés analogues, les valeurs raisonnables de ces propriétés peuvent ne pas correspondre. Par exemple, la typographie mathématique traditionnelle emploie des fontes en italique pour les identificateurs à un seul caractère et des fontes droites pour ceux à plusieurs caractères. Dans un texte, l'italisation ne dépend habituellement pas du nombre de lettres dans le mot. Quoiqu'une propriété d'inclinaison de fonte puisse donc avoir un sens pour les mathématiques et pour le texte, les valeurs naturelles par défaut sont très différentes.

À cause des différences entre les styles du texte et des mathématiques, quelques aspects seulement de la disposition MathML sont de bons candidats pour un contrôle CSS. MathML 2.0 saisit les propriétés les plus importantes avec les nouveaux attributs de style mathématique, et les utilisateurs devraient autant que possible les utiliser de préférence à des approches plus directes mais moins fiables. Une feuille de style CSS de démonstration illustrant l'utilisation des attributs de style mathématique est disponible dans l'Annexe G [Une feuille de style CSS de démonstration pour MathML].

De façon générale, le modèle d'interaction CSS avec les attributs de style mathématique fonctionne comme suit. Une feuille de style CSS fournirait une règle de style telle que :

math *.[mathsize="small"] {
  font-size: 80%
}

Cette règle agit sur les propriétés CSS font-size de tous les sous-éléments de math ayant un attribut mathsize dont la valeur est "small". Un moteur de rendu MathML solliciterait alors le moteur de style de l'environnement CSS et utiliserait les valeurs renvoyées comme entrées pour ses propres algorithmes de disposition. MathML ne définit pas le mécanisme selon lequel les informations de style sont héritées de l'environnement. Toutefois, quelques règles de rendu suggéré pour l'interaction entre les propriétés de l'environnement de style ambiant et les règles de rendu spécifiques de MathML sont abordées dans la section 3.2.2 Les attributs de style mathématique communs des éléments atomiques et, plus généralement, tout au long du chapitre 3 Le balisage de présentation.

Néanmoins, il faut insister sur les précautions à prendre lors de l'écriture de feuilles de style CSS pour MathML. Dans la mesure où la modification des propriétés typographiques des symboles mathématiques peut changer la signification d'une équation, on devrait écrire une feuille de style de telle sorte que les changements des styles typographiques pour la totalité du document n'affectent pas les expressions MathML imbriquées. On minimise ce risque en utilisant les attributs de style mathématique MathML 2.0 comme sélecteurs des règles CSS.

Un autre piège à éviter : utiliser CSS pour fournir les informations de style typographique nécessaires à la compréhension correcte d'une expression. Les expressions dont la signification dépend de CSS ne seront pas portables sur des environnements non-CSS, tels que les systèmes de calcul algébrique. En utilisant les valeurs logiques des nouveaux attributs de style mathématique MathML 2.0 comme sélecteurs des règles CSS, on peut être sûr que les informations de style nécessaires à la signification d'une expression seront directement codées dans MathML.

MathML 2.0 n'indique pas comment les informations de style devraient être traitées par l'agent utilisateur, parce qu'il y a beaucoup d'environnements MathML non-CSS et parce que l'accès aux informations CSS par les différents agents utilisateurs et moteurs de rendu varie beaucoup. En général, on conseille toutefois vivement aux développeurs de fournir une gestion CSS pour MathML la plus complète possible.

7.2 La conformité

Les informations sont de plus en plus générées, traitées et rendues par des outils logiciels. La croissance exponentielle du Web alimente le développement de systèmes avancés pour la recherce, le classement et l'interconnexion automatiques des informations. Ainsi, bien qu'un utilisateur humain puisse écrire ou lire du code MathML, le futur de MathML est grandement lié à la possibilité de le traiter par des outils logiciels.

Il existe beaucoup de types différents d'éditeurs, de traducteurs, de processeurs et de moteurs de rendu MathML. La gestion MathML varie énormément entre les applications. Par exemple, les problèmes qui surviennent avec un analyseur validant conforme MathML sont très différents de ceux d'un éditeur d'équation conforme MathML.

Dans cette section, on fournit un guide permettant de décrire les différents types de gestion MathML et de quantifier l'étendue de la gestion MathML d'une application donnée. Les développeurs, les utilisateurs et les lecteurs sont invités à suivre ces directives pour la caractérisation des produits. Ce guide est destiné à faciliter la réutilisation et l'interopérabilité entre les applications MathML en caractérisant précisément leurs capacités en termes quantifiables.

Le groupe de travail Math du W3C tient des directives de conformité MathML 2.0. Consultez ce document pour les mises à jour ultérieures concernant les activité et ressources de conformité.

7.2.1 La conformité MathML

Une expression MathML valide est une structure XML déterminée par la définition DTD de MathML ainsi que par les conditions supplémentaires données dans cette spécification.

Définissons un processeur MathML comme étant toute application capable d'accepter, de produire ou de faire la navette avec une expression MathML valide. Un exemple d'application susceptible de faire la navette avec une expression MathML serait celui d'un éditeur écrivant un nouveau fichier même si aucune modification n'a lieu.

On définit trois formes de conformité MathML :

  1. Un processeur MathML conforme en entrée doit accepter toutes les expressions MathML valides et les traduire fidèlement dans une forme spécifique permettant le déroulement des opérations natives de l'application ;
  2. Un processeur MathML conforme en sortie doit générer du code MathML représentant fidèlement toutes les données spécifiques de l'application ;
  3. Un processeur MathML conforme en navette doit préserver l'équivalence MathML. Deux expressions MathML sont équivalentes si et seulement si les deux expressions ont la même interprétation (selon la définition DTD de MathML et la spécification), en toutes circonstances, pour n'importe quel processeur MathML. L'équivalence élément par élément est abordée ailleurs dans ce document.

Hormis les définitions précédentes, la spécification MathML n'impose aucun processeur individuel. Elle contient des documents consultatifs afin de guider les développeurs ; par exemple, beaucoup de règles de rendu suggéré parsèment le chapitre 3 [Le balisage de présentation]. En général, les développeurs ont toutefois une grande latitude d'interprétation du type de mise en œuvre MathML significatif pour leur propre application particulière.

Pour éclairer la différence entre conformité et interprétation de ce qui est significatif, voyons quelques exemples :

  1. Pour une conformité MathML en entrée, un analyseur validant doit seulement accepter les expressions et renvoyer une valeur "true" pour celles dont le code MathML est valide. Notamment, il n'a pas besoin de rendre ou d'interpréter les expressions MathML du tout ;
  2. Une interface de calcul algébrique MathML basée sur le balisage du contenu peut choisir d'ignorer tout le balisage de présentation. Si l'interface accepte toutes les expressions MathML valides, y compris celles contenant un balisage de présentation, il serait techniquement correct de caractériser l'application comme MathML conforme en entrée ;
  3. Un éditeur d'équations peut avoir une représentation des données interne facilitant l'exportation de certaines équations, mais pas d'autres, sous forme de code MathML. Si l'éditeur exporte les équations simples comme étant valides pour MathML et affiche juste un message d'erreur pour signaler l'échec de la conversion des autres, celui-ci est techniquement encore conforme MathML en sortie.

7.2.1.1 La suite de tests et le validateur MathML

Comme le montrent les exemples précédents, le concept de conformité MathML implique souvent un jugement à propos des parties du langage qui sont utilement mises en œuvre par opposition aux parties qui sont juste traitées correctement en ce qui concerne les définitions de conformité. Un mécanisme est nécessaire pour définir quantitativement quelles parties de MathML sont mises en œuvre de façon significative par une application donnée. À cet effet, le groupe de travail Math du W3C fournit une suite de tests.

La suite de tests se compose d'un grand nombre d'expressions MathML classées selon la catégorie de balisage et l'élément MathML dominant à tester. L'existence de cette suite de tests rend possible, par exemple, la caractérisation quantitative de l'interface de calcul algébrique hypothétique, mentionnée précédemment, en disant qu'il s'agit d'un processeur MathML conforme en entrée, qui met en œuvre significativement un balisage de contenu MathML, en comprenant toutes les expressions de la section balisage de contenu de la suite de tests.

Les développeurs qui choisissent de ne pas mettre en œuvre significativement des parties de la spécification MathML sont invités à détailler les parties omises en se référant aux catégories spécifiques de la suite de tests.

Pour les processeurs MathML conformes en sortie, il existe aussi un validateur MathML accessible par le Web. Les développeurs de processeurs MathML conformes en sortie sont invités à utiliser ce validateur pour vérifier leurs sorties.

Les utilisateurs d'applications MathML, qui souhaitent vérifier les affirmation selon lesquelles l'application met en œuvre telles parties de la spécification, sont invités à utiliser les suites de tests comme partie intégrante de leurs processus de décision.

7.2.1.2 Les fonctionnalités déconseillées de MathML 1.x

MathML 2.0 contient un certain nombre de fonctionnalités de MathML 1.x dont l'utilisation est maintenant déconseillée. Les points suivants définissent ce qu'est une fonctionnalité déconseillée et clarifient la relation entre fonctionnalités déconseillées et conformité avec MathML 2.0.

  1. Pour être conforme MathML en sortie, un outil d'édition ne doit pas générer de balisage MathML contenant des fonctionnalités déconseillées ;
  2. Pour être conforme MathML en entrée, un outil de rendu/lecture doit gérer les fonctionnalités déconseillées, s'il faut qu'il soit conforme avec MathML 1.x. Il n'est pas tenu de gérer les fonctionnalités déconseillées pour être considéré conforme avec MathML 2.0. Néanmoins, la gestion des formes anciennes, autant que possible et quel que soit l'outil, est encouragée ;
  3. Pour être conforme MathML en navette, un processeur a seulement besoin de préserver l'équivalence MathML sur les expressions ne contenant pas de fonctionnalités déconseillées.

7.2.2 La gestion des erreurs

Si une application MathML conforme en entrée reçoit une entrée contenant un ou plusieurs éléments dont le nombre ou le type des attributs, ou les schémas de sous-éléments, sont illégaux, elle devrait malgré tout essayer de rendre l'entrée entière de façon intelligible, c'est-à-dire, de restituer normalement les parties valides de cette entrée et de produire des messages d'erreurs (rendus comme s'ils étaient englobés dans des éléments merror) à la place des expressions invalides.

Les applications MathML conformes en sortie, ainsi les éditeurs et les traducteurs, peuvent choisir de générer des expressions merror pour signaler les erreurs de leurs entrées. C'est en général préférable que de générer du code MathML valide mais potentiellement erronné.

7.2.3 Les attributs de données non définies

Les attributs MathML décrits dans la spécification MathML sont indispensables au balisages de contenu et de présentation. Idéalement, les attributs MathML devraient former une liste ouverte, de sorte que les utilisateurs puissent ajouter des attributs spécifiques à des moteurs de rendu. Malheureusement, cela n'est pas possible dans les limites d'une seule définition DTD XML. Bien qu'on puisse le faire en étendant la définition DTD standard, certains auteurs voudront utiliser des attributs non normalisés pour tirer partie de capacités spécifiques du moteur de rendu tout en restant strictement conforme à la définition DTD standard.

Pour y parvenir, la spécification MathML 1.0 admettait l'attribut other sur tous les éléments, lequel servait de connecteur pour transmettre des informations spécifiques du moteur de rendu. En particulier, il était prévu comme connecteur pour la transmission d'informations aux moteurs de rendu sonores, aux systèmes de calcul algébrique et pour un filtrage dans des mécanismes de macro-commande/d'extension futurs. Cette approche du problème tenait à des raisons historiques, en lorgnant du côté du langage PostScript, par exemple, où les commentaires servent couramment à passer des informations ne faisant pas partie de PostScript.

Cependant, dans l'intervalle, le développement d'un mécanisme d'espace de nommage XML a rendu obsolète l'utilisation de l'attribut other. Dans MathML 2.0, l'utilisation de l'attribut other est déconseillée en faveur des préfixes d'espaces de nommage pour identifier les attributs non-MathML.

Par exemple, dans MathML 1.0, si d'autres informations étaient utilisées dans la mise en œuvre spécifique d'un moteur de rendu de l'élément maction (cf. la section 3.6.1 L'adjonction d'une action à une sous-expression (maction)), il était recommandé de les passer avec l'attribut other :

<maction actiontype="highlight" other="color='#ff0000'"> expression </maction>

Dans MathML 2.0, on utiliserait l'attribut color d'un autre espace de nommage :

<body xmlns:my="http://www.example.com/MathML/extensions">
...
<maction actiontype="highlight" my:color="#ff0000"> expression </maction>
...
</body>

Remarquez que l'intention d'autoriser des attributs non normalisés n'est pas d'encourager les développeurs de logiciels à prendre ce mécanisme pour une faille permettant de contourner les conventions essentielles du balisage MathML. Les auteurs et les applications devraient employer judicieusement les attributs non normalisés.

7.3 Les extensions futures

Si le langage MathML doit rester utile dans le futur, il est à prévoir qu'il sera étendu et révisé de diverses façons. Certaines extensions sont aisément prévisibles, par exemple, au fur et à mesure de l'avancement des travaux sur les extensions comportementales à CSS, il faudra vraissemblablement étendre MathML aussi.

De même, plusieurs types de fonctionnalités constituent des candidats plutôt évidents pour de futures extensions MathML. Ce sont les macro-commandes, les feuilles de style et peut-être une fonction générale pour les diagrammes étiquetés. Quoiqu'il en soit, d'autres extensions MathML souhaitables émergeront sans doute seulement avec l'utilisation courante de MathML. Pour ces extensions, le groupe de travail Math du W3C s'appuie sur l'architecture extensible de XML et le bon sens de la communauté du Web au sens large.

7.3.1 Les macro-commandes et les feuilles de style

Le développement des mécanismes de feuille de style pour XML fait partie de l'activité XML continue du World Wide Web Consortium. Les spécifications XSL et CSS concourrent à une meilleure prise en compte des mathématiques.

En particulier, les transformations XSLT [XSLT] auront vraisemblablement un grand impact sur le développement ultérieur de MathML. Les macro-commandes ont traditionnellement beaucoup contribué à la convivialité et à l'efficacité des codages mathématiques. D'autres travaux pour développer des applications XSLT spécialement adaptées à MathML sont clairement à fournir.

Voici quelques-unes des utilisations possibles des capacités des macro-commandes :

L'abréviation
L'abréviation est une utilisation courante des macro-commandes. Les auteurs ayant besoin de répéter une notation compliquée mais constante peuvent définir une macro-commande. Cela facilite beaucoup l'édition manuelle. Les macro-commandes qui permettent de remplacer des paramètres facilitent plus encore cette utilisation.
L'extension du balisage de contenu
En définissant des macro-commandes d'objets sémantiques, par exemple un coefficient binomial ou une fonction de Bessel, on peut effectivement étendre le balisage de contenu MathML. Une telle macro-commande pourrait inclure une liaison sémantique explicite, ou une application externe pourrait facilement ajouter une liaison de ce type. Les disciplines définies strictement devraient pouvoir introduire facilement un balisage de contenu normalisé en utilisant des ensembles de macro-commandes normalisés. Par exemple, le projet OpentMath pourrait publier des ensembles de macro-commandes permettant de joindre un balisage de contenu OpenMath.
Le contrôle du rendu et du style
Les macro-commandes sont souvent employées simplement comme moyen de contrôler le style et le comportement de rendu en remplaçant les définitions de macro-commandes de niveau supérieur. Cela se révèle particulièrement important pour contrôler le comportement de rendu des balises de contenu MathML en fonction du contexte. Une telle macro-commande a également la capacité nécessaire pour lier des rendus aux extensions XML du noyau MathML définies par l'utilisateur.
L'accessibilité
Les feuilles de style contrôlées par le lecteur sont importantes pour l'accessibilité de MathML. Par exemple, un lecteur écoutant un moteur de rendu sonore pourrait écouter, par défaut, un bout de balisage de présentation MathML, lu comme D indice x exposant 2 de f. Sachant que le contexte est celui d'un calcul à variables multiples, le lecteur voudra peut-être utiliser une feuille de style ou un ensemble de macro-commandes pour instruire le moteur de rendu de restituer cet élément <msubsup> par dérivée seconde par rapport à x de f.

7.3.2 Les extensions XML de MathML

Le jeu d'éléments et d'attributs défini dans la spécification MathML est indispensable au rendu des expressions mathématiques courantes. Il faut reconnaître que ce jeu d'éléments ne couvre pas entièrement la notation mathématique, que sont continuellement inventées des notations nouvelles et que souvent des sous-communautés au sein des mathématiques ont des notations spécialisées, et en outre, que l'extension explicite d'une norme est un processus nécessairement lent et conservateur. Cela implique que la norme MathML pourrait ne jamais couvrir explicitement toutes les formes de présentations utilisées par toutes les sous-communautés d'auteurs et de lecteurs des mathématiques, et à plus forte raison, coder tous les contenus mathématiques.

Afin de faciliter l'utilisation de MathML par le plus large public possible et de permettre son évolution en douceur pour englober plus de formes de notation et plus de contenus mathématiques (le cas échéant, avec une prise en charge par des extensions explicites de la norme), le jeu de balises et d'attributs est ouvert, au sens décrit dans cette section.

MathML est décrit par une définition DTD XML, ce qui limite nécessairement les éléments et attributs à ceux apparaissant dans la définition DTD. Les moteurs de rendu souhaitant accepter des éléments ou des attributs non normalisés et les auteurs souhaitant les inclure dans leurs documents devraient accepter ou produire des documents conformes à une définition DTD XML étendue de manière adéquate, la définition DTD normalisée de MathML en constituant un sous-ensemble.

Les moteurs de rendu MathML conformes peuvent accepter, sans obligation, des éléments et attributs non normalisés pour les rendre d'une manière ou d'une autre. Si le moteur de rendu n'accepte aucune ou une partie des balises non normalisées, on recommande de les gérer comme des erreurs, comme décrit précédemment pour les éléments avec un nombre erronné d'arguments, ou bien de rendre leurs arguments comme si c'étaient ceux d'un élément mrow, et dans l'un ou l'autre cas, en rendant normalement toutes les parties normalisées de l'entrée.

Table des matières : Le langage de balisage mathématique (MathML) version 2.0
Chapitre précédent : 6 Les caractères, les entités et les fontes
Chapitre suivant : 8 Le modèle objet de document de MathML