XML est presque toujours utilisé à tort

Le langage XML a été inventé en 1996. À peine était-il apparu que ses possibilités d'utilisation étaient déjà mal comprises, et pour les objectifs auxquels on tentait de l'adapter, ce n'était pas le meilleur choix.

Il n'est pas exagéré de dire que la grande majorité des schémas XML que j'ai pu voir constituaient un usage inapproprié ou incorrect de XML. De plus, cette utilisation du XML témoignait d'une mécompréhension fondamentale de ce qu'est avant tout le XML.

XML est un langage de balisage. Ce n'est pas un format de données.Dans la plupart des schémas XML, cette distinction n'était clairement pas prise en compte, confondant XML avec un format de données, ce qui signifiait en fin de compte une erreur dans le choix même de XML, car un format de données était en réalité nécessaire.

Pour faire simple, XML est le mieux adapté à l'annotation de blocs de texte avec une structure et des métadonnées. Si votre objectif principal n'est pas de travailler avec un bloc de texte, le choix de XML ne sera probablement pas justifié.

Sous cet angle, il existe un moyen simple de vérifier à quel point un schéma XML est bien fait. Prenons un exemple de document selon le schéma prévu et supprimons tous les tags et attributs. Si ce qui reste n'a pas de sens (ou si la ligne est vide), alors soit votre schéma est mal construit, soit vous n'auriez tout simplement pas dû utiliser XML.

Je vais maintenant donner quelques exemples courants de schémas mal construits.

Ici, nous voyons un exemple d'une tentative injustifiée et étrange (bien que très répandue) d'exprimer en XML un simple dictionnaire « clé-valeur ». Si nous supprimons tous les tags et attributs, il restera une ligne vide. En fait, ce document représente, aussi absurde que cela puisse paraître, une annotation sémantique d'une ligne vide.

<root name="John" city="London" />

Pire encore, il ne s'agit pas simplement d'une annotation sémantique d'une ligne vide comme une façon extravagante d'exprimer un dictionnaire - cette fois, le « dictionnaire » est directement codé sous forme d'attributs de l'élément racine. De ce fait, l'ensemble des noms d'attributs présents sur l'élément devient indéfini et dynamique. De plus, il est évident que ce que l'auteur voulait réellement exprimer, c'était une simple syntaxe « clé-valeur », mais à la place, il a opté pour une solution totalement étrange en appliquant XML, en forçant l'utilisation d'un seul élément vide simplement comme préfixe pour utiliser la syntaxe des attributs. Et de telles schémas me rencontrent très souvent.

John
  London

C'est déjà mieux, mais maintenant les clés sont pour une raison quelconque des métadonnées, alors que les valeurs ne le sont pas. Une vision plutôt étrange des dictionnaires. Si l'on supprime toutes les balises et attributs, la moitié des informations sera perdue.

Une bonne expression de dictionnaire en XML ressemblerait approximativement à ceci :

Name
    John
  
  
    City
    London

Mais si les gens ont pris la décision étrange d'utiliser XML comme format de données et d'organiser un dictionnaire avec celui-ci, ils devraient comprendre que ce qu'ils font est inapproprié et peu pratique. De nombreux concepteurs choisissent souvent à tort XML pour créer leurs applications. Mais même plus fréquemment, ils aggravent la situation par une utilisation insensée de XML sous l'une des formes décrites ci-dessus, ignorant le fait qu'XML n'est tout simplement pas adapté à cela.

Le schéma XML le plus horrible ? À propos, le prix de le schéma XML le plus horrible que j'aie jamais vu revient au format de fichier de configuration d'allocation automatique de ressources pour les téléphones de téléphonie IP Polycom. De tels fichiers nécessitent le téléchargement de fichiers XML via TFTP qui… En fait, voici un extrait d'un de ces fichiers :

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Ce n'est pas une mauvaise blague de quelqu'un. Et ce n'est pas mon invention :

• Les éléments sont simplement utilisés comme préfixe pour attacher des attributs qui ont eux-mêmes des noms hiérarchiques.
• S'il est nécessaire d'attribuer des valeurs à plusieurs instances d'un certain type d'enregistrement, il faut utiliser les noms des attributs, qui contiennent des indices..
• De plus, les attributs commençant par softkey.doivent être placés sur les éléments <softkey/>et les attributs commençant par feature.doivent être placés sur les éléments <feature/> , etc., même si cela semble totalement superflu et à première vue absurde.
• Et enfin, si vous espériez que le premier composant du nom de l'attribut coïncide toujours avec le nom de l'élément — rien de tout cela ! Par exemple, les attributs up. doivent être attachés à <userpreferences/>. L'ordre d'attachement des noms d'attributs aux éléments est arbitraire, en fait presque complètement.

Documents ou données.De temps en temps, quelqu'un fait des choses totalement étranges en tentant de comparer XML et JSON, montrant ainsi qu'il ne comprend ni l'un ni l'autre. XML est un langage de balisage de documents. JSON, en revanche, représente un format de données structurées, donc les comparer l'un à l'autre est comme essayer de comparer le chaud et le doux.

Comprendre cela aidera à saisir la différence entre documents et données.Comme analogue, on peut considérer XML comme un document lisible par machine. Même s'il est destiné à être lu par une machine, il se réfère métaphoriquement à des documents et, de ce point de vue, est en fait comparable à des documents au format PDF, qui ne sont souvent pas lisibles par machine.

Par exemple, en XML, l'ordre des éléments a de l'importance. Alors qu'en JSON, l'ordre des paires "clé-valeur" à l'intérieur des objets n'a pas de sens et n'est pas défini. Si vous souhaitez obtenir un dictionnaire non ordonné de paires "clé-valeur", l'ordre réel dans lequel les éléments apparaissent dans ce fichier n'a pas d'importance. Mais vous pouvez former à partir de ces données de nombreux documents,car dans un document, il y a un ordre défini. Métaphoriquement, c'est l'analogie d'un document sur papier, même s'il n'a pas de dimensions physiques contrairement à une impression ou un fichier PDF.

Dans mon exemple de présentation correcte d'un dictionnaire en XML, l'ordre des éléments dans le dictionnaire est montré, contrairement à la présentation en JSON. Je ne peux pas ignorer cet ordre : cette linéarité appartient intrinsèquement au modèle de documents et au format XML. Quelqu'un peut décider d'ignorer cet ordre lors de l'interprétation de ce document XML, mais il est inutile de discuter de cela, car cette question dépasse le cadre de la discussion sur le format lui-même. De plus, si on rend le document consultable dans un navigateur en y attachant une feuille de style en cascade, on pourra voir que les éléments du dictionnaire suivent un certain ordre, et aucun autre.

En d'autres termes, le dictionnaire (un fragment de données structurées) peut être transformé en n différents documents possibles (au format XML, PDF, sur papier, etc.), où n — le nombre possible de combinaisons d'éléments dans le dictionnaire, et nous n'avons même pas encore pris en compte d'autres variables possibles.

Il en découle également que si vous souhaitez transmettre uniquement des données, l'utilisation d'un document lisible par machine ne sera pas efficace. Il utilise un modèle qui, dans ce cas, est superflu et ne fait que compliquer les choses. De plus, pour extraire les données d'origine, il faudra écrire un programme. Il est peu judicieux d'utiliser XML pour quelque chose qui, à un certain stade, ne sera pas formaté sous forme de document (par exemple, à l'aide de CSS ou XSLT, ou les deux), car c'est la principale (sinon la seule) raison de s'en tenir à un modèle de document.

De plus, puisque le XML n'a pas de notion de nombres (ou d'expressions booléennes, ou d'autres types de données), tous les nombres présentés dans ce format ne sont considérés que comme du texte supplémentaire. Pour extraire des données, le schéma et son lien avec les données exprimées correspondantes doivent être connus. Il est également nécessaire de savoir, en fonction du contexte, quand un certain élément de texte représente un nombre, et qu'il doit être converti en nombre, etc.

Ainsi, le processus d'extraction de données à partir de documents XML ne diffère pas beaucoup de celui de la reconnaissance de documents numérisés, contenant par exemple des tableaux, formant de nombreuses pages de données numériques. Oui, c'est en principe possible, mais ce n'est pas le moyen le plus optimal, sauf dans les cas extrêmes, lorsque toutes les autres options sont épuisées. Une solution raisonnable serait de simplement trouver une copie numérique des données originales, non intégrées dans le modèle de document où les données sont combinées avec leur représentation textuelle spécifique.

Il ne me surprend donc pas du tout que l'XML soit populaire dans le monde des affaires. La raison en est précisément que le format des documents (sur papier) est clair et familier pour les entreprises, qui souhaitent continuer à utiliser un modèle familier et compréhensible. Pour la même raison, les PDF sont souvent utilisés au lieu de formats plus adaptés au traitement machine, car ils restent ancrés dans la notion de page imprimée de taille physique déterminée. Cela concerne même des documents qui ne seront probablement jamais imprimés (comme un fichier PDF de documentation d'un registre de 8000 pages). De ce point de vue, l'utilisation de l'XML dans les affaires est essentiellement une manifestation de skeuomorphisme. Les gens comprennent l'idée métaphorique de la page imprimée de taille limitée et savent comment créer des processus commerciaux basés sur des documents imprimés. Si c'est votre référence, des documents sans taille physique limitée, machinables - les documents XML - représentent une innovation tout en étant une alternative familière et confortable au document. Cela ne les empêche pas d'être une façon incorrecte et excessivement skeuomorphe de représenter des données.

À ce jour, les seules schémas XML que je peux véritablement considérer comme une application correcte de ce format sont XHTML et DocBook.

Source : habr.com