L'avenir de XML Vous connaissez désormais XML. C'est vrai que la structure est un peu complexe, et la DTD dispose de diverses options pour définir ce que peut contenir le document. Mais ce n'est pas tout.
Prenons un secteur pour lequel l'échange de données est important, comme le secteur bancaire. Les banques utilisent des systèmes de propriété pour suivre les transactions en interne, mais si elles utilisent un format XML commun sur le Web, elles doivent alors décrire les informations sur les transactions à une autre institution ou application (telle que Quicken ou MS Money). Bien entendu, ils peuvent également représenter des données sur des pages Web. Pour information : cette balise n'existe pas. Cela s'appelle OFEX, Open Financial Exchange.
Dans certaines circonstances, si IE 4 sur un PC rencontre une balise <SOFTPKG>, une fonction sera lancée pour donner à l'utilisateur la possibilité de mettre à jour le logiciel installé. Si vous utilisez Windows 98, vous avez peut-être été témoin de cette situation, mais vous ne saviez pas qu'il s'agit d'une application XML.
Nous avons ici trois applications XML qui diffèrent des machines à additionner, des machines à écrire et des crayons qu'Andy Grove a vus dans les années 1970. Mais à l'instar des applications qui sont finalement apparues sur les PC, les avantages du XML peuvent être décrits de manière générale comme : "Lorsque vous utilisez des balises lisibles par l'homme et la machine pour décrire vos données, de bonnes choses se produisent.
" ? Je ne sais pas. Mais je ne sais pas non plus à quoi ressemblera la prochaine génération de programmes sur mon PC. Tant que les données sont ainsi étiquetées, différentes applications peuvent être générées.
Commencez-vous à réfléchir à la mesure dans laquelle cela pourrait s’étendre ?
Nous avons de nombreuses applications pratiques de XML à aborder, et j'en parlerai dans un avenir proche. Puisque nous sommes tous des utilisateurs d’Internet, l’avenir sera XSL (Extensible Style Language-
Langage de style extensible).
D'ailleurs, cette recette est bien celle de ma mère et elle est exceptionnelle. Si vous l'utilisez, ajoutez une autre demi-tasse de noix de coco râpée.
J'écris ceci parce que je me soucie vraiment de ce que vous pensez de moi. Ma préoccupation est la suivante : si vous lisez mon introduction à XML et êtes prêt à commencer à écrire vos propres documents XML. Vous commencez donc à chercher une DTD déjà établie pour représenter vos informations. Vous en trouvez un, comme indiqué ci-dessous :
<!ATTLIST fn
%attr.lang;
value CDATA #FIXED "TEXT">
<!ENTITY % attr.img "
img.type CDATA #REQUIRED
img.data ENTITY #REQUIRED">
Dès le départ, vous pensez que Jay doit être un idiot. Il n'a rien dit sur ATTLIST et ENTITY - quels qu'ils soient.
Alors parlons-en, d’abord avec un peu de patience.
Les lignes ci-dessus ne semblent peut-être pas belles, mais elles ne sont en réalité rien. Ils sont utilisés dans les DTD pour définir des attributs et des entités dans les documents XML. Quiconque connaît le HTML le sait très bien. Les attributs sont des entrées avec des balises HTML qui décrivent les balises avec plus de précision. Dans le <img src="my.gif" height="20" width="20"> qui apparaît fréquemment, il y a deux attributs : la hauteur et la largeur. Comme vous le verrez plus tard, l'utilisation d'attributs dans les documents XML est très similaire.
Il n’y a rien de nouveau non plus concernant les entités. Si vous avez utilisé &, vous connaissez déjà les bases. Une chaîne entourée de & et de points-virgules représente un autre caractère ou un autre jeu de caractères. (Une liste complète des entités ISO est disponible ici.)
Bien entendu, les attributs et entités XML ont d'autres fonctions. Cela introduit inévitablement de la syntaxe, mais pas trop. Une fois que vous savez cela, travailler avec des documents XML se fera sans effort.
Recettes simplifiées
Si vous lisez mon introduction à XML, vous vous souviendrez que les ingrédients d'une recette sont représentés par des balises simples, telles que <item>2 tasses de farine</item>. Après avoir écrit cet article, je parcourais le Web et j'ai trouvé un autre document XML sur les recettes. Les éléments de la recette sont les suivants :
<ingredientQuantity="2" Units="cups">farine</ingredient>
Cette approche présente un avantage pratique : elle facilite le contrôle des données. Avec la première approche, la balise <item> est utilisée pour contenir un tas d'informations différentes. Si je voulais extraire une liste d’ingrédients sans les quantités de chaque ingrédient, je ne le ferais pas.
Je peux obtenir des fonctionnalités similaires en utilisant la structure suivante :
<item>farine
<quantité>2</quantité>
<unités>tasses</unités>
Cela peut être géré, mais il y a deux problèmes : Premièrement, l'élément item contient un contenu mixte : du texte et d'autres balises. J'ai rapidement découvert que cette structure devait être évitée autant que possible. La seconde est que les marqueurs n’ont pratiquement aucune signification indépendante. Il est difficile d’imaginer une situation dans laquelle il n’y aurait que des unités mais pas de véritables composants. Ces éléments peuvent être décrits simplement, je préfère les considérer comme des propriétés.
La première chose à noter est que les noms d'attributs, les quantités et les unités n'ont de sens que lorsqu'ils sont traités par une application capable de les traduire.
Il faut demander à la DTD de l'autoriser avant d'être incluse dans un document valide. Pour l'élément ingrédient ci-dessus, nous avons uniquement inclus le code suivant dans la DTD :
<!ELEMENT ingrédient #PCDATA>
<!ATTLIST quantité d'ingrédient CDATA #REQUIRED>
<!ATTLIST unités d'ingrédient CDATA #REQUIRED>
La première ligne semble familière : les définitions d'éléments standard que vous verrez dans n'importe quelle DTD. Chaque ligne ATTLIST contient tour à tour les informations suivantes :
<!ATTLIST quantité d'ingrédient CDATA #REQUIRED>
Il s'agit de l'élément auquel l'attribut est attaché.
<!ATTLIST quantité d'ingrédient CDATA #REQUIRED>
Le nom de l'attribut est défini ici.
<!ATTLIST quantité d'ingrédient CDATA #REQUIRED>
Définissez le type d'attribut ici. CDATA signifie données de caractères. Cela signifie que le processeur peut obtenir le texte dans l'attribut.
<!ATTLIST ingrédients quantité CDATA #REQUIRED>
La dernière partie définit la valeur par défaut de l'attribut. Vous pouvez utiliser une valeur numérique réelle, telle que 3. De cette façon, la valeur de l'attribut pour la longueur des espaces en XML sera 3. La valeur saisie remplacera la valeur par défaut.
Dans l'exemple ci-dessus, je n'ai pas défini de quantité spécifique, mais j'ai utilisé le mot-clé XML #REQUIRED. Il indique au processeur que l'attribut secondaire doit contenir une valeur. S'il est vide, le document ne sera pas traité.
La valeur par défaut comporte deux mots-clés supplémentaires. Le premier est #FIXED - si la valeur de l'attribut reste la même dans tout le document. Supposons que je définisse un attribut de balise d'image et que toutes les images soient de la même taille, par exemple 100*50 pixels, je peux définir l'attribut comme ceci dans la DTD :
<!ATTLIST longueur de l'image CDATA #FIXED "100 px">
<!ATTLIST largeur de l'image CDATA #FIXED "50 px">
Un autre mot-clé est #IMPLIED, indiquant que la propriété peut contenir une valeur ou être vide.
Regardons les types d'attributs.
Si vous décidez d'écrire votre propre DTD, vous souhaiterez peut-être un livre expliquant le XML de toutes les combinaisons dans une instruction ATTLIST. Mais si vous empruntez DTD, vous ne connaîtrez peut-être que CDATA et trois autres attributs.
Le premier est l’identité. Cela nécessite que la valeur de l'attribut ne soit pas répétée dans le document. Quiconque a utilisé une base de données connaît la nécessité d’identifiants uniques. L'instruction DTD ATTLIST ressemble à ceci :
<!ATTLIST element_nameattribut_name ID #REQUIRED>
Il est difficile d'imaginer le type d'attribut ID sans la valeur par défaut de #REQUIRED. Dans ce cas, tout identifiant en double ou vide forcera le processeur à renvoyer une erreur. L'ID doit commencer par une lettre ou un trait de soulignement et ne peut contenir aucun espace.
Le type NMTOKEN utilise également les règles de dénomination ci-dessus. Mais la duplication est autorisée. Il sert de garantie pour la transmission des données à l'application. La plupart des langages de programmation, notamment Java et JavaScript, ne peuvent pas contenir d'espaces dans les noms de modules. Dans la plupart des cas, il est préférable de s'assurer que les propriétés respectent leurs règles.
Enfin, il existe des types d’énumération, qui ne nécessitent pas de mots-clés spécifiques. Utilisez plutôt le symbole « | » pour placer la valeur entre parenthèses, par exemple :
<!ATTLIST sibling (brother | sister) #REQUIRED>
Cette approche peut être utilisée s'il existe un nombre limité de valeurs d'attribut possibles.
Vous ne pensez pas que le cours d’aujourd’hui est ennuyeux, alors continuez à lire !