Les auteurs devraient également lire la partie Développeur : elle contient de plus amples informations sur le contenu des fichiers XML.
C.1 Est-ce que XML remplace HTML ?
§ Non, XML en soi ne remplace pas HTML : il constitue en fait une alternative qui vous permet de définir vos propres éléments de balisage. HTML devrait encore être utilisé pendant un certain temps. Les DTD pour HTML seront ensuite disponibles au format XML ainsi qu’au format original SGML. XML est conçu pour rendre l’écriture de DTD plus facile qu’avec SGML complet (voir les questions sur les DTD pour savoir ce que c’est et pourquoi vous n’en voulez pas).
Des travaux en cours devraient conduire à la conception de versions XML de DTD HTML et autres DTD connues, mais ceci ne pourra se faire avant que des logiciels plus fiables ne soient disponibles. Surveillez les annonces sur comp.text.sgml, comp.text.xml, XML-L et xml-dev.
C.2 A quoi ressemble l’intérieur d’un document XML ?
La structure de base ressemble énormément à celle de la plupart des applications de SGML y compris HTML. Les documents XML peuvent être très simples, sans déclaration de type de document, et avec un balisage de votre conception directement imbriqué :
<?xml version="1.0" standalone="yes"?>
<conversation>
<greeting>Hello, world!</greeting>
<response>Stop the planet, I want to get off!</response>
</conversation>Ces documents peuvent également être plus complexes, avec une DTD donnée, et peut-être un sous-ensemble interne et une structure plus complexe :
<?xml version="1.0" standalone="no" encoding="UTF-8"?>
<!DOCTYPE titlepage SYSTEM "http://www.frisket.org/dtds/typo.dtd"
[<!ENTITY % active.links "INCLUDE">]>
<titlepage>
<white-space type="vertical" amount="36"/>
<title font="Baskerville" size="24/30"
alignment="centered">Hello, world!</title>
<white-space type="vertical" amount="12"/>
<!-- In some copies the following decoration is
hand-colored, presumably by the author -->
<image location="http://www.foo.bar/fleuron.eps" type="URL" alignment="centered"/>
<white-space type="vertical" amount="24"/>
<author font="Baskerville" size="18/22" style="italic">Vitam capias</author>
</titlepage>Ils peuvent également se situer à mi-chemin entre ces deux options : cela dépendra essentiellement de la façon dont vous définirez votre type de document (ou celui que vous utiliserez) et de son usage. Voir la question sur les fichiers valides et bien formés.
C.3 Comment XML traite-t-il les espaces blancs présents dans mes documents ?
§ Les règles de SGML concernant les espaces blancs ou séparateurs ont été modifiées pour XML. Ainsi, tous les séparateurs, y compris les sauts de lignes, les tabulations et les espaces normaux, même entre les éléments où aucun texte ne peut apparaître, passent tels quels dans l’application (navigateur, logiciel de formatage, visionneur, etc). Cela signifie que :
– les séparateurs « insignifiants » entre les éléments de structure (les éléments qui ne peuvent contenir que d’autres éléments et non pas du texte, parfois appelés « contenus élémentaires ») passeront dans l’application (avec du SGML intégral, les séparateurs sont supprimés) ;
– les séparateurs « signifiants » entre les éléments qui peuvent contenir à la fois du texte et du balisage (« contenu mixte » ou PCDATA [parsed character data, données textuelles analysées]) passeront dans l’application comme auparavant.
<chapter>
<section>
<title>
My title for Section
1.
</title>
<para>
...
</para>
</section>
</chapter>§ Le parser doit toutefois indiquer à l’application si tel séparateur est apparu dans tel contenu élémentaire, s’il est connu. (Les utilisateurs de SGML intégral reconnaîtront peut-être que cette information n’apparaît pas dans le ESIS Element Structure Information Set), mais elle figure bel et bien dans le grove (Graph representation of Property Values).) Dans l’exemple ci-dessus, l’application recevra tous les sauts de ligne, tabulations et espaces entre les éléments ainsi que ceux emboïtés dans le titre de section. Il revient à l’application (navigateur, logiciel de formatage, visionneur, etc.) de décider du type de séparateur à supprimer ou à garder.
C.4 Quelles parties d’un document XML dépendent de la casse ?
Tous les éléments de fichiers XML, balisage comme texte, dépendent de la casse. Ceci diffère considérablement du HTML et de la plupart des autres types de documents SGML. Cette contrainte a été mise en place pour permettre le balisage dans des écritures en alphabet non Latin et pour éviter des problèmes avec le traitement des différences entre minuscules et majuscules pour des écritures qui ne connaissent pas une telle différence.
– Les noms de type d’éléments (utilisés dans les balises de début et les balises de fin) dépendent de la casse : vous devez être très rigoureux dans leurs libellés (utilisation ou DTD) que vous choisissiez les minuscules ou les majuscules ; il est donc impossible de dire <BODY> . . . </body> : les majuscules et minuscules doivent correspondre ; par conséquent, <IMG/> et <img/> sont deux types d’élément différents ;
– dans le cas des fichiers bien formés sans DTD, la première occurrence d’un nom de type d’élément en définit la casse ;
– les noms d’attributs dépendent eux aussi de la casse et correspondent aux éléments : par exemple, <PIC width="7in"/> et <PIC WIDTH="6in"/> dans un même fichier définissent deux attributs distincts, puisque la casse de width et WIDTH les différencie ;
– les valeurs des attributs dépendent elles aussi de la casse. Les valeurs des données textuelles (ex. : HRef="MyFile.SGML") n’ont pas changé, mais les attributs ID et IDREF dépendent désormais de la casse et ne basculent plus en majuscules pour permettre la comparaison ;
– tous les noms d’entité (p.ex. Á) et le contenu de vos données (votre texte) sont dépendantes de la casse, comme avant.
C.5 Comment faire pour que mes fichiers HTML fonctionnent en XML ?
§ Ils doivent être bien formés (voir ci-dessous) et associés à une feuille de style. Une DTD est facultative avec XML, mais les fichiers HTML convertis au format XML doivent aujourd’hui de toute façon n’avoir aucune DTD : il n’existe encore aucune version XML des actuelles DTD HTML de type SGML (en cours de développement) parce qu’elles doivent être considérablement modifiées pour ne plus dépendre des fonctions du SGML exclues du XML.
Il est nécessaire de convertir les fichiers HTML existants afin qu’ils soient bien formés, XML interdisant la suppression des balises de fermeture (absence de
, etc.), autorisée dans la plupart des DTD HTML. De nombreux éditeurs HTML produisent déjà du XML presque bien formé (mais pas tout à fait). Pour se préparer à XML, le programme HTML Tidy est recommandé pour nettoyer certaines erreurs de formatage tolérées ou produites par des éditeurs HTML trop tolérants.
Si vous voulez transformer vos fichiers HTML en un autre type de DTD, le site pilote de CommerceNet (http://www.xmlx.com/) permet l’échange des DTD XML et le serveur pilote FPI (http://www.ucc.ie/cgi-bin/public) vous propose plusieurs DTD courantes à partir desquelles commencer.
Si vous avez créé vos fichiers HTML conformément à une des nombreuses Définitions de Type de Document (DTD) HTML et qu’ils sont valides, ces fichiers peuvent alors être convertis de la façon suivante :
– remplacez la déclaration DOCTYPE et tout sous-ensemble interne (en fait tout ce qui se trouve dans le premier ensemble de chevrons <!DOCTYPE HTML...>) par la déclaration XML <?xml version="1.0" standalone="yes"?> ;
– changez tous les éléments EMPTY (ex. : <ISINDEX>, <BASE>, <META>, <LINK>, <NEXTID> et <RANGE> dans l’en-tête, et <IMG>, <BR>, <HR>, <FRAME>, <WBR>, <BASEFONT>, <SPACER>, <AUDIOSCOPE>, <AREA>, <PARAM>, <KEYGEN>, <COL>, <LIMITTEXT>, <SPOT>, <TAB>, <OVER>, <RIGHT>, <LEFT>, <CHOOSE>, <ATOP> et <OF> dans le corps) de façon à ce qu’ils se terminent par "/>", par exemple <IMG SRC="mypic.gif" alt="Picture"/> ;
– § assurez-vous que les balises de fin de tous les éléments non vides sont bien présentes et correctes ; ex. : chaque <P> doit avoir un </P>, etc. Si votre HTML a été créé par un éditeur conformant, ceci peut être automatisé par un programme normaliseur comme sgmlnorm (partie de SP) ou par la fonction SGML-normalize d’un éditeur comme Emacs/psgml ;
– masquez tous les caractères qui ne servent pas au balisage < et & (c’est à dire les literal), en < et & respectivement ;
– assurez-vous que toutes les valeurs des attributs sont entre apostrophes (") ;
– assurez-vous que toutes les occurrences de tous les noms d’élément entre balises de début et de fin respectent la même casse (respect des majuscules et des minuscules) et ce dans tout le fichier ;
– assurez-vous que toutes les occurrences de tous les noms d’attribut possèdent la même casse et ce dans tout le fichier.
Soyez conscients que de nombreux navigateurs HTML pourraient ne pas accepter les éléments EMPTY XML avec barre oblique ; les changements ci-dessus ne sont donc pas rétro-compatibles (lors de la conversion de XML en HTML). La solution est d’ajouter une balise de fin fictive à tous les éléments EMPTY, de sorte que <IMG src="foo.gif"> devienne <IMG src="foo.gif"></IMG>.
§ Si vous avez beaucoup de fichiers HTML valides, vous pourriez écrire un script dans un système de conversion SGML (tel que Omnimark, Balise, SGMLC, ou un système utilisant une des bibliothèques SGML de Perl, Python ou Tcl) ; vous pourriez également utiliser des macros (d’un éditeur comme emacs) si vous savez ce que vous faites.
Si vos fichiers HTML ne sont pas valides (les fichiers HTML créés par la plupart des éditeurs WYSIWYG ne sont pas valides), ils devront être convertis manuellement. Même si les défauts sont réguliers et constants, les fichiers pourraient être en fait bien formés, et vous pourriez alors écrire un programme ou un script comme on l’a dit ci-dessus. Pour juger de l’invalidité ou de la non-conformité, vérifiez les points suivants :
– les fichiers contiennent-ils des erreurs de syntaxe de balisage ? Par exemple, y a-t-il des barres obliques inverses à la place des barres obliques dans les balises de fin ? ou des éléments qui s’imbriquent incorrectement (ex. : <B>un élément qui commence<I>dans un élément</B> mais se termine en dehors</I>) ?
– les fichiers contiennent-ils un balisage qui entre en conflit avec les DTD HTML, tel que des en-têtes dans des paragraphes ou des listes d’éléments en dehors des environnements de liste ?
– les fichiers utilisent-ils des éléments qui ne figurent dans aucune DTD ? Bien que la transformation en fichier bien formé sans DTD soit simple (parce que vous n’avez pas à définir les éléments à l’avance) la plupart des extensions de programmes propriétaires - propres à chaque navigateur - n’ont jamais été formellement définies ; il est donc souvent impossible de savoir où elles peuvent être utilisées à bon escient
Le balisage valide mais insignifiant ou inutile devra peut-être être modifié avant la conversion (répétitions de paragraphes vides, de sauts de ligne, de tableaux vides, d’images GIF vides servant à l’espacement, etc.) car XML utilise des feuilles de style, vous n’en aurez donc pas besoin.
Voir les règles pour des fichiers XML « bien formés » pour plus amples informations sur les points à vérifier en XML lors de la conversion.
C.6 Y a-t-il une version XML de HTML ?
Il y a des versions XML de la DTD HTML en préparation, mais aucune n’est encore prête :
– Ben Trafford est en train de développer une version XML de HTML 3.2
– J’ai personnellement démarré l’écriture d’une version XML d’HTML Pro, mais ce n’est pas facile et j’aimerais que l’on me convinque que c’est utile !
– XHTML (Extensible HyperText Markup Language) est un projet du W3C. « Les spécifications définissent XHTML 1.0, une reformulation de HTML 4.0 comme une application XML 1.0, et trois DTD correspondant à celles définies par HTML 4.0. La sémantique des éléments et de leurs attributs est définie dans les W3C Recommendation for HTML 4.0. Cette sémantique sert de base à de futures extensions d’XHTML. La compatibilité avec des agents HTML existants est possible à condition de respecter un petit ensemble de recommandations. »
C.7 Si XML est un sous-ensemble de SGML, puis-je directement utiliser les fichiers XML avec des outils SGML ?
§ Oui, à condition que vous utilisiez un logiciel qui reconnaît les nouvelles WebSGML AQdaptations à la norme ISO 8879 (fonctions nécessaires pour supporter XML : forme particulière des éléments EMPTY ; certains aspects de la déclaration SGML tels que NAMECASE GENERAL NO ; déclarations d’attributs multiples, etc.).
¶ Une autre façon est d’utiliser une DTD SGML qui vous permette de créer un fichier SGML (mais une DTD qui n’utilise pas d’éléments vides) ; supprimer ensuite la DocType Declaration de façon qu’il devienne un fichier XML sans DTD bien formé.
§ Aujourd’hui, peu d’outils permettent de garder intacts les fichiers XML à cause du format de ces éléments EMPTY, mais ça bouge. L’analyseur nsgmls dispose d’une option de conformité XML, introduite pour être utilisée avec Jade par ailleurs, les premiers éditeurs et analyseurs spécifiques pour XML sont en usage (voir la question sur les logiciels).
C.8 Je suis habitué à utiliser HTML. Est-ce que je peux apprendre XML facilement ?
§ Oui, très facilement. Mais aujourd’hui, il manque toujours des cours, des outils simples et plus d’exemples de documents XML. Des documents XML bien formés peuvent paraître similaires à HTML excepté pour de petits mais très importants points de syntaxe.
¶ La principale différence est que XML doit coller aux règles. Les navigateurs HTML en revanche vous permettent de créer du HTML dégradé car ils ignorent les informations erronées : avec XML, ou bien votre fichier est correct, ou bien ile ne marche pas !
C.9 XML pourra-t-il utiliser des alphabets non-latins ?
Oui, les spécifications XML indiquent explicitement que XML utilise la norme internationale de codage des caractères sur 31 bits ISO 10646, qui couvre la plupart des langages humains (et quelques langages non-humains). Ceci est actuellement conforme à Unicode.
Les spécifications indiquent (2.2) : « Tous les processeurs XML devront accepter les codages UTF-8 et UTF-16 de la norme ISO 10646... » UTF-8 est un codage d’Unicode en caractères 8-bit : les 128 premiers caractères sont identiques au codage ASCII, les suivants sont utilisés pour coder le reste d’Unicode en séquences de 2 à 6 octets. Dans sa forme mono-octet UTF-8 est donc identique à la norme ISO 646 IRV (ASCII) ; vous pouvez donc continuer à utiliser le code ASCII pour l’anglais ou toute autre langue non accentuée en utilisant l’alphabet latin. À noter que UTF-8 est incompatible avec la norme ISO 8859-1 (ISO Latin-1) au-delà du code 126 décimal (la fin d’ASCII). UTF-16 est semblable à UTF-8 mais avec une méthode de représentation des 16 plans suivants de 64 000 caractères comme deux caractères de 16 bits.
« ... Les mécanismes qui signalent lequel des deux est utilisé et qui mettent d’autres codages en jeu, [...] sont traités lors des débats sur le codage des caractères. » Les spécifications XML expliquent comment indiquer dans un fichier XML le codage du jeu de caractères utilisé.
L’utilisation d’UCS-4 peut seulement être spécifiée en SGML ou XML quand les adaptations WebSGML à la norme ISO 8879 sont mises en place : ceci permet d’utiliser des nombres supérieurs à huit octets dans la déclaration SGML.
« Quel que soit le codage utilisé, tous les caractères du jeu de caractères de la norme ISO 10646 peuvent être définis avec l’équivalent décimal ou hexadécimal de leur chaîne d’octets. » Donc, quel que soit le jeu de caractères que vous utilisez, vous pouvez toujours définir des caractères spécifiques d’un autre endroit du répertoire de codage en utilisant &#dddd; (code de caractères décimal) ou &#xHHHH; (code de caractères hexadécimal, en majuscule). La terminologie, comme les nombres, peut porter à confusion : voir ISO 10646 Concept Dictionary. Rick Jelliffe a "XML-isé" les ensembles d’entité caractères ISO.
C.10 Qu’est-ce qu’une définition de type de document (DTD) ? Où en obtenir une ?
§ Une DTD est un fichier (ou plusieurs fichiers à utiliser ensemble), écrit en XML, qui contient une définition formelle d’un type particulier de document. Elle définit les noms qui peuvent être utilisés pour les types d’éléments, où ils peuvent apparaître et comment ils s’arrangent les uns par rapport aux autres. Par exemple, si vous voulez qu’un type de document décrive des <LIST> qui contiennent des <ITEM>, une partie de votre DTD devra contenir quelque chose comme :
<!ELEMENT list (item)+>
<!ELEMENT item (#pcdata)>Ceci définit une liste comme un type élément contenant un ou plusieurs items (c’est le rôle du signe plus) et des items commes des types éléments ne contenant que du texte. XML est le langage formel de spécification utilisé par les processeurs pour analyser automatiquement une DTD et utiliser ensuite cette information pour identifier la place de chaque type d’élément et la relation qui lie ces éléments, afin de permettre l’utilisation des feuilles de style, des navigateurs, des moteurs de recherche, des bases de données, des sous-programmes d’impression, ou d’autres applications. Les instructions ci-dessus vous permettent de créer des listes qui sont conservées sous la forme :
<List><Item>Chocolate</Item><Item>Music</Item><Item>Surfing</Item></List>La façon dont la liste apparaît sur l’écran ou sur papier dépend de votre feuille de style : vous n’avez normalement rien à mettre en XML pour affecter la mise en page comme il fallait le faire en HTML avant les feuilles de style.
En fait une DTD donne à l’avance aux applications l’information des noms et structures qui peuvent être utilisés dans un type de document particulier. Utiliser une DTD signifie que tous les documents appartenant à un type particulier seront construits et nommés de façon conforme.
§ Il existe déjà des milliers de DTD SGML dans tous les domaines (voir les pages Web SGML pour des exemples). Nombre de ces DTD peuvent être téléchargées et utilisées librement. Vous pouvez aussi écrire vos propres DTD. Pour cela, comme pour tout langage, vous devez auparavant l’apprendre (voir ar exemple : Developing SGML DTDs par Maler et el Andaloussi, Prentice Hall, 1997, 0-13-309881-8). Cependant XML est beaucoup plus simple que SGML intégral : voir la liste de restrictions qui montre ce qui a été supprimé. Les DTD SGML existantes doivent être converties au format XML pour être utilisées dans des systèmes XML : lire la question concernant la conversion des DTD SGML au format XML. Attendez-vous à voir des annonces de DTD connues disponibles au format XML.
C.11 Je reste attentif à des alternatives aux DTD. Qu’est-ce qu’un schéma ?
Bob DuCharme écrit : « Beaucoup de développeurs XML ne sont pas satisfaits de la syntaxe des déclarations de balises décrites dans les spécifications, pour deux raison. Premièrement, ils pensent que si les documents XML sont si bons pour décrire la structure des informations, alors la description d’une structure de type de document (ses « schémas ») devrait être dans un document XML et non écrite avec sa propre syntaxe. En plus d’être plus consistent, ceci permettrait plus facilement d’éditer et manipuler le schéma avec des outils habituels de manipulation de documents. Deuxièmeement, ils pensent que la notation traditionnelle des DTD ne donne pas aux définisseurs de schémas la puissance nécessaire pour imposer assez de contrainte sur les données — par exemple, la possibilité de dire qu’un certain type élément doit toujours avoir une valeur positive, qu’il ne peut pas être vide ou qu’il peut faire partie d’une liste au choix. Ceci faciliterait le développemennt de logiciels utilisant ces données car le développeur aurait moins de code de détection d’erreurs à écrire. »
Note : Les utilisateurs ayant une formation en informatique ou en bases de données devraient prendre conscience que les systèmes SGML — y compris XML — ne sont pas des systèmes de gestion de bases de données : ce sont des systèmes de balisage de textes. Bien qu’il y ait beaucoup de points communs, comme ceux décrits ici, certains concepts des uns peuvent ne pas exister dans les autres : XML n’a pas les mêmes possibilités que les bases de données, tout comme DBMS n’a pas de possibilités de balisage..
« Plusieurs groupes ont soumis au W3C des propositions alternatives pour exprimer les schémas de type de document. En plus d’offrir des contraintes de schémas comme le typage des données et les autres décrites ici, beaucoup s’appuient sur les tendances actuelles en logiciel telles que les méthodologies orientées-objets. Le groupe de travail sur les schémas du W3C est en train d’analyser ces propositions et de déveloper sa propre proposition basée sur les meilleurs possibilités suggérées dans les propositions existantes ou par les membres du Schema Working Group. »
C.12 Comment XML modifiera-t-il les liens de mes documents ?
§ Les possibilités de liens hypertextes des systèmes XML sont beaucoup plus développées que celles du HTML, ce qui vous permettra de faire plus de choses avec eux. Les liens existants de type HREF continueront à être utilisables, mais la nouvelle technologie de liaison est basée sur les enseignements tirés du développement d’autres standards utilisant des hypertextes tels que TEI et HyTime. Cette technologie autorise des liens bi-directionnels et multi-branches, ainsi que des liens vers une sélection de texte (dans vos documents ou autres) et non vers un point unique. SGML connaît déjà ces applications dans des navigateurs tels que DynaText, Panorama et Multidoc Pro et ce depuis de nombreuses années en les utilisant, on gagne expérience et compétence considérables.
Les documents XML Linking Specification (XLink) et XML Extended Pointer Specification (XPointer) contiennent des spécifications provisoires détaillées. Un lien XML peut être soit une URL, soit un pointeur étendu de style TEI : TEI-style Extended Pointer (XPointer), soit les deux. Une URL seule est supposée être une ressource (comme avec HTML) ; si un pointeur étendu suit cette URL, on suppose qu’il est une sous-ressource de cette URL ; un pointeur étendu seul est supposé s’appliquer au document courant
Un XPointer est toujours précédé par un des symboles #, ?, ou |. Les symboles # et ? ont les mêmes fonctions que dans les applications HTML ; le symbole | signifie que la sous-ressource peut-être trouvée en appliquant le XPointer à la ressource, mais la méthode à utiliser dépend de l’application.
La TEI Extended Pointer Notation (EPN) est beaucoup plus puissante que « l’adresse fragmentée » à la fin de certaines URL. Elle permet en effet de spécifier l’emplacement d’une fin de lien en utilisant la structure du document et/ou les points fixes, connus comme les ID. Par exemple, l’expression la seconde occurrence liée du mot « XPointer » deux paragraphes plus haut pourrait avoir pour référence http://www.ucc.ie/xml/faq.sgml#ID(faq-hypertext)CHILD(2,*)(6,*), ce qui signifie le sixième sous-objet dans le deuxième sous-objet après l’élément dont l’ID est faq-hypertext. Compter les objets depuis le début de cette question dans la version SGML (qui a l’ID "faq-hypertext") :
le titre de la question :
le deuxième paragraphe : la donnée textuelle depuis le début du paragraphe jusqu’au premier élément de balisage :
l’élément de balisage :
l’élément de texte :
and
l’élément de balisage :
le paragraphe suivant de donnée textuelle :
documents contain a detailed specification. An XML link can be either a URL or a TEI-style Extended Pointer (
et l’élément de balisage suivant :
XPointer
Si vous lisez ce fichier avec Panorama ou MultiDoc Pro vous pouvez cliquer sur le bouton de renvoi en surbrillance au début de la phrase d’exemple. Les emplacements de tous les liens qui s’y réfèrent s’afficheront alors en EPN (Extended Pointer Notation), y compris le mot « XPointer » mentionné. Réaliser ceci avec un navigateur HTML n’est pas très significatif, le navigateur HTML ne supportant pas les liaisons bidirectionnelles ou les EPN. David Megginson a développé une fonction supplémentaire pour Emacs/psgml qui déduira un XPointer pour tout emplacement dans un fichier SGML ou XML.
C.13 Puis-je faire des maths avec XML ?
Oui, si le type de document que vous utilisez est prévu pour les mathématiques. La communauté des utilisateurs de mathématiques développe actuellement un logiciel et il existe une proposition MathML au W3C, qui est une application XML native. Il serait également possible de créer des fragments XML à partir de l’application obsolète HTML3, HTML Pro, ISO 12083 Math, ou OpenMath, ou d’une application de votre propre conception. Il existe déjà des navigateurs qui affichent des maths intégrées à SGML (ex. : DynaText, Panorama, Multidoc Pro).
La complexité de ces expressions mathématiques peut varier d’expressions telles que voire pour afficher en pleine-page des équations telles que :
Si vous utilisez un navigateur HTML pour lire ceci, les équations ci-dessus n’apparaissent peut-être pas correctement. Le plugin Techexplorer d’IBM peut être utilisé avec les navigateurs HTML courants pour afficher les maths de TeX. Le navigateur Amaya sur le W3C dispose d’un affichage MathML expérimental.
C.14 Comment XML gère-t-il les méta-données ?
§ Parce que XML permet de définir votre propre langage de balisage, vous pouvez utiliser pleinement les caractéristiques d’hypertexte étendu (voir la question sur les liens) de XML pour stocker ou lier des méta-données dans n’importe quel format (p. ex.ISO 11179, Dublin Core, Warwick Framework, Resource Description Framework (RDF) et Platform for Internet Content Selection (PICS)).
Étant une architecture et non une application, XML ne comporte aucun élément prédéfini. Ce n’est donc pas le rôle de XML de spécifier si et comment les auteurs devraient ou ne devraient pas implémenter des méta-données. Vous êtes donc libre d’utiliser la méthode qui vous convient, des simples attributs à l’inclusion de tous les registres de méta-données de Dublin Core/Warwick Framework. Les éditeurs de navigateurs pourraient également proposer leurs propres recommandations en matière d’architecture ou leurs méthodes.
C.15 Puis-je utiliser Java, ActiveX, etc. dans des fichiers XML ?
Ceci dépend des caractéristiques propres au navigateur. XML a pour fonction de décrire l’information ; les langages de script et les langages pour fonctionnalités intégrées sont les logiciels qui permettent à l’information d’être traitée par l’utilisateur final.
XML lui-même permet de définir le balisage nécessaire à l’implémentation de langages de script : en tant que standard neutre il n’encourage ni ne décourage leur utilisation et ne favorise pas un langage plutôt qu’un autre ; la porte est donc ouverte. Des développements sont en cours : voir les suggestions de John Tigue pour la normalisation de l’API pour Java à propos d’XML.
Les langages de script sont donnés dans le cadre d’une proposition pour un Extensible Style Language (XSL) (voir la question sur les feuilles de style).
C.16 Puis-je utiliser Java pour créer ou gérer des fichiers XML ?
Oui, n’importe quel langage de programmation peut être utilisé pour sortir des données de n’importe quel source au format XML. Il y a un nombre croissant de produits amont ou aval pour environnements de programmation et de gestion de données qui permettent d’automatiser ceci.
Mark Watson écrit, article 344c3443.4494773@news.infonex.net : « J’ai affiché les spécifs d’une boîte à outils Java pour la création de dcouments XML à partir de requètes de bases de données relationelles et pour les sauvegardes/restaurations de documents XML sur/depuis des fichiers locaux, et pour le transport à travers des sockets RMI, CORBA, IIOP. Les spécifs sont à www.markwatson.com/XMLdb_0_1.htm. » Il y a une série de tutoriels Java (avec code source et explications) disponibles à http://developerlife.com. Ces tutoriels montrent aux développeurs Java2 comment utiliser les parseurs IBM, Sun et OpenXML pour écrire des programmes Java qui utilisent XML.
C.17 Comment contrôler la présentation ?
§ L’utilisation d’une feuille de style est obligatoire en XML. Certains navigateurs offrent peut-être de simples styles par défaut pour des éléments courants comme contenant des
§ La norme internationale de feuilles de style pour les documents SGML est DSSSL, Document Style and Semantics Specification Language (ISO 10179). Elle offre des langages du genre de Scheme pour les feuilles de style et la conversion de documents et est implémenté dans le logiciel de formatage Jade. Les CSS (Cascading Stylesheet Specifications) offrent une syntaxe simple pour attribuer des styles aux éléments et ont été implémentées en partie dans certains navigateurs HTML. Une nouvelle ébauche de (XSL) Extensible Style Language a été conçu pour une utilisation spécifique avec XML . Elle utilise la syntaxe XML (une feuille de style XSL est en fait un fichier XML) mais combine les fonctions de formatage de DSSSL et de CSS (HTML) et bénéficie déjà du soutien de nombreux distributeurs importants.
Le XML Styler expérimental d’Arbortext donne des détails sur la façon de l’utiliser avec XML. Il faut aussi les commandes ActiveX et XSL codebase.
Plusieurs systèmes et implémentations de feuilles de style propriétaires pré-existantes sont aussi disponibles. La plupart sont largement intégrés à la communauté de documentation technique (et par conséquent supportés par un ou plusieurs produits) :
– chez Inso Corps (dont la compagnie originelle, EBT, a inventé la majorité des concepts de la technologie actuelle des feuilles de style), les navigateur et serveur DynaText et DynaWeb ;
– la DTD pour feuille de style Synex telle qu’utilisée dans Panorama et MultiDoc Pro ;
– la norme militaire américaine FOSI (Formatted Output Specification Instance) implémentée dans ADEPT·Editor d’Arbortext et ailleurs ;
– Author/Editor de SoftQuad utilise un autre système de feuille de style contrôlable par l’utilisateur.
§ La plupart des fournisseurs de navigateurs et de serveurs semblent migrer vers XML mais, vu la grande base de systèmes déjà installés, cela ne se fera sans doute pas très vite.
C.18 Comment utiliser les graphiques en XML ?
§ Les graphiques sont simplement des liens vers une image plutôt que vers un texte, ils peuvent donc être créés de n’importe quelle manière supportée par les spécifications XLink et XPointer (voir une question précédente), même en utilisant une syntaxe similaire aux images HTML existantes. On peut aussi en faire en utilisant le mécanisme intégré d’XML NOTATION et ENTITY de la meme façon qu’en SGML standard. Cependant, les spécifications de liaison offrent un meilleur contrôle sur les liens de traversée et leur activation. Un auteur peut donc, par exemple, choisir de faire apparaître une image lors du chargement de la page, sur simple clic de l’utilisateur, ou dans une autre fenêtre, sans avoir à modifier le script. Il revient aux concepteurs de navigateurs de choisir les formats de fichiers graphiques qui seront supportés : XML ne comporte aucune restriction. L’utilisation des formats GIF, JPG, TIFF et CGM au minimum seraient logiques : il y a certaines tendances à la création d’une norme de graphiques vectoriels pour réseau (voir paragraphe suivant).
Peter Murray-Rust précise : « Les formats GIF et JPEG traitent des bitmaps (représentation en pixels des images). Les graphiques vectoriels (échelonnables) sont discutés par l’activité graphique du W3C (voir http://www.w3.org/Graphics/Activity). Quand un consensus aboutira, il sera alors possible de transmettre une représentation graphique au sein même du fichier XML. Ceci signifie, pour la plupart des objets graphiques, un temps de téléchargement considérablement réduit et une mise à l’échelle sans perte de définition.. »
Note :
On ne peut pas emboîter un fichier graphique (pas plus qu’un autre fichier binaire [non textuel]) directement dans un fichier XML car n’importe quel octet ressemblant à une marque serait mal interprété. Il faut s’y référer par des liens (voir ci-dessous).
Bob DuCharme ajoute : « Toutes les données dans une entité de document XML doivent être du XML parsable. Vous pouvez définir une entité externe soit en tant qu’entité parsée (XML parsable) soit en tant qu’entité non parsée (n’importe quoi d’autre). Les entités non parsées peuvent être utilisées pour les fichiers images, les fichiers sons, les fichiers vidéo ou tout ce que vous voulez. Elles ne peuvent être appelées qu’à partir d’un document en tant que valeur d’un attribut (de la même façon qu’une image Bitmap d’une page web en HTML est l’attribut src de l’élément ) et n’ont pas en tant que partie du document courant. Dans un document XML, cet attribut doit être déclaré de type ENTITY et la déclaration d’entité doit spécifier une NOTATION déclarée. En effet, si l’entité n’est pas du XML, le processeur XML doit savoir ce dont il s’agit. Par exemple, dans le document suivant, l’entité colliepic est déclarée comme ayant une notation JPEG et est utilisée en tant que valeur de l’attribut picfile de l’élément vide dog.
<?xml version="1.0"?>
<!DOCTYPE dog [
<!NOTATION JPEG SYSTEM "Joint Photographic Experts Group">
<!ENTITY colliepic SYSTEM "lassie.jpg" NDATA JPEG>
<!ELEMENT dog EMPTY>
<!ATTLIST dog picfile ENTITY #REQUIRED>
]>
<dog picfile="colliepic"/>Les spécifications de liaison XLink et XPointer décrivent d’autres manières de pointer vers un fichier non-XML tel qu’un graphique. Ces spécifications permettent de mieux contrôler la position, le traitement et l’apparence d’une entité externe dans un document XML. »
On pourrait toutefois inclure un fichier binaire transformé et codé en texte comme une section CDATA, en utilisant quelque chose comme UUencode avec des marques ] et > supprimées du jeu de façon qu’elles ne puissent ni être utilisées, ni mal interprétèes.
