Une DTD pour les documents scientifiques

a écrit :
N'était-ce pas le but initial du XML

XML n'est qu'une syntaxe, et ne dit rien des langages bâtis par dessus cette syntaxe.

D'après ce que j'ai compris XML devait faciliter les échanges informatiques par la normalisation de la couche la plus basse : la syntaxe. Et c'est bien le cas puisque plus grand monde ne s'intéresse aujourd'hui à la problématique de l'analyse syntaxique, ce qui est déjà un bon point.
En revanche, en considérant le vocabulaire comme un "paramètre" (via la DTD) on pouvait au contraire s'attendre à ce que chacun invente son propre langage. C'est un peu le cas même si de nombreux efforts de normalisation (W3C, Oasis) tentent de contrecarrer cette dispersion.

En fait j'ai le sentiment que les efforts de normalisation sont également à l'origine de cette dispersion dans la mesure ou les standards qui en sortent sont présentés à chaque fois comme des langages différents. Pour des raisons psychologiques, je crois qu'il pourrait être intéressant d'inverser la tendance en déclarant que XHTML, Xlink, Xforms, SVG, MATHML... sont au contraire des composantes ou des modules d'un même effort de structuration d'un langage commun.

Je peux rejoindre ton raisonnement. Il faut aussi se souvenir que le HTML n'est qu'une DTD du SGML. Le XML n'a rien inventé.

Pour mettre un peu d'eau à ton moulin et soulever un autre danger, j'utilise tout les jours du GPX (format XML d'échange de données GPS) qui est un standard (j'ai failli écrire, de fait) topografix, donc propriétaire. Que doit-on penser de ce type de "standard". J'aime bien qu'un standard soit assis sur unr "autorité indépedante". Bien sûr, je caricature quelque peu mais la dérive peut s'étendre à d'autres aspects plus "vicieux".

Habot a parfaitement raison: le XML (en tant que refonte du SGML) a la volonté de donner à chaqyue créateur la base pour construire ses outils spécifiques (dédiés à la chimie, à lé geo. etc.)
Je dois pourtant avouer que la profilération des grammaires XML (les DTD) est source de confusion pour le novice. Comme dit, chaque grammaire se réclame "norme" à part entière.
Comment comprendre alors qu'une des forces des documents XML est de pouvoir mixer les contenus (du MathML dans du xHTML)?
Un des problèmes que les concepteurs se focalisent sur leurs problèmes spécifiques et ne fournissent que les outils appropriés (je pense spécifiquement aux feuilles XLST).
J'ambitionnais de construire ma DTD pour décrire les sorties d'un logiciel de statistique. Mais s'il faut aussi faire le(s) XLST et le CSS, c'est galère.
D'un autre côté, la DTD ultime n'existera jamais.
Au moins, l'utilisation de langages balisés est rassurant: il permet (ou permettra) tout de même une bonne (ré)utilisation. A preuve le LaTeX et xHTML produits par tbook sans trop d'efforts (au vu de la taille des XLST).

Belgeric a écrit :
une des forces des documents XML est de pouvoir mixer les contenus

XML n'est qu'une syntaxe, il n'est donc pas en son pouvoir de mixer les contenus. C'est aux outils qui traitent, éditent, visualisent, les contenus que l'on doit (ou non) la possibilité de mélanger des contenus de natures différentes. Cette aptitude ne tient qu'a la capacité des outils et des utilisateurs à interpréter des vocabulaires variés. Tout au plus (mais c'est déjà beaucoup) XML offre un socle commun de syntaxe qui simplifie l'acquisition technique des documents par les outils.

Belgeric a écrit :
la DTD ultime n'existera jamais

C'est certain, comme tu l'as évoqué, chaque domaine à ses propres besoins, et qui prétendrait répertorier tous ces besoins dans l’exhaustivité ?
Mais je crois que lorsque quelqu'un propose une extension pour un sujet particulier, s'il a l'ambition de faire largement partager son extension, alors il doit être attentif à ne pas recréer des choses déjà existantes, avec un nouveau vocabulaire. Dit autrement, supposons DTD1 et DTD2 deux DTDs documentaires largement diffusées. Si DTD1 et DTD2 sont réellement complémentaires (intersection vide ou quasiment) alors pas de problème. Si au contraire elle se superpose (intersection notable) alors il y a fort à parier qu'un jour émergera la nécessiter de bâtir des outils de traduction, et c'est contre productif.
Je reviens à Tbook. Je suppose que son créateur est un nostalgique de Latex. Mais il aurait pu tout aussi bien fonder sa description documentaire sur XHTML, MathML et SVG plutôt que d'introduire une nouvelle DTD. Il me semble qu'alors les outils de traduction incorporés à Tbook n'en auraient eu que plus de valeur.

Belgeric a écrit :
J'ambitionnais de construire ma DTD pour décrire les sorties d'un logiciel de statistique. Mais s'il faut aussi faire le(s) XLST et le CSS, c'est galère

Tu abordes la question de la présentation des documents, et finalement tu renforces me semble-t-il mon propos. Je suppose que pour décrire un document orienté statistiques il faut prendre en charge des commentaires, des formules, des tableaux de chiffres et des graphiques. Pourquoi vouloir alors créer une nouvelle DTD ? Est-ce que, au moment de transcrire tes informations dans du XML, XHTML, MathML et SVG ne sont-ils pas suffisant ?
Il se peut que tu souhaites une présentation bien à toi de la chose, mais il existe aussi des outils capables de faire une présentation décente de ces DTDs (un navigateur récent tout simplement). Si tu utilises un navigateur :
- l'étape XSLT (changement de DTD) est inutile puisque l'outil interprète directement ces DTDs
- l'étape CSS est inutile puisque l'outil dispose de règles de présentation par défaut
C'est tout bénéfice non ?

Introduire à tout va de nouvelles DTDs est un piège que tu as bien illustré, tout comme Habot l'a décrit avec ses "poupées russes".

medjai94 a écrit :
salut !!!

ne pensez vous pas que le XML est une sorte de nouveau code ASCII ? ...

La tu confond codage des caractère et document à syntaxe particulière

L'XML permet de décrire des données (donc ce morceau est un paragraphe, ce truc là est un titre), l'ASCII lui, est une table de conversion entre un caractère et un numéro...

De plus, l'ASCII est remplacé par l'Unicode. Le problème avec l'ASCII étant qu'il est limité à 255 caractère par défaut, d'où la nécessité de plusieurs tables ASCII pour couvrir tous les caractères.