XML est presque toujours utilisé à mauvais escient

Le langage XML a été inventé en 1996. A peine apparut-on que les possibilités de son application commençaient déjà à être mal comprises, et aux fins auxquelles on essayait 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 vus étaient des utilisations inappropriées ou incorrectes de XML. De plus, cette utilisation de XML démontrait une incompréhension fondamentale de ce qu'était XML.

XML est un langage de balisage. Ce n'est pas un format de données. La plupart des schémas XML ont explicitement négligé cette distinction, confondant XML avec un format de données, ce qui aboutit finalement à une erreur dans le choix de XML car c'est le format de données qui est réellement nécessaire.

Sans entrer dans trop de détails, XML est le mieux adapté pour annoter des 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, il est peu probable que le choix de XML soit justifié.

De ce point de vue, il existe un moyen simple de vérifier la qualité de réalisation du schéma XML. Prenons comme exemple un document dans le schéma prévu et supprimons-en toutes les balises et attributs. Si ce qui reste n'a pas de sens (ou s'il reste une ligne vide), alors soit votre schéma n'est pas construit correctement, soit vous n'auriez tout simplement pas dû utiliser XML.

Ci-dessous, je vais donner quelques-uns des exemples les plus courants de circuits mal construits.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Nous voyons ici un exemple d'une tentative infondée et étrange (bien que très courante) d'exprimer un simple dictionnaire clé-valeur en XML. Si vous supprimez toutes les balises et attributs, vous vous retrouverez avec une ligne vide. Essentiellement, ce document est, aussi absurde que cela puisse paraître, une annotation sémantique d'une ligne vide.

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

Pour aggraver les choses, nous n'avons pas ici simplement une annotation sémantique d'une chaîne vide comme une manière extravagante d'exprimer un dictionnaire - cette fois, le "dictionnaire" est directement codé en tant qu'attributs de l'élément racine. Cela rend l'ensemble donné de noms d'attributs sur un élément indéfini et dynamique. De plus, cela montre que tout ce que l'auteur voulait réellement exprimer était une simple syntaxe clé-valeur, mais qu'à la place il a pris la décision absolument bizarre d'appliquer XML, forçant l'utilisation d'un seul élément vide simplement comme préfixe pour utiliser la syntaxe d'attribut. Et je rencontre très souvent de tels stratagèmes.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

C'est quelque chose de mieux, mais maintenant, pour une raison quelconque, les clés sont des métadonnées et les valeurs ne le sont pas. Un regard très étrange sur les dictionnaires. Si vous supprimez toutes les balises et attributs, la moitié des informations seront perdues.

Une expression de dictionnaire correcte en XML ressemblerait à ceci :

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Mais si les gens ont pris la décision étrange d’utiliser XML comme format de données et de l’utiliser ensuite pour organiser un vocabulaire, alors ils doivent comprendre que ce qu’ils font est inapproprié et peu pratique. Il est également courant que les concepteurs choisissent par erreur XML pour créer leurs applications. Mais le plus souvent, ils aggravent les choses en utilisant XML de manière inutile sous l'une des formes décrites ci-dessus, ignorant le fait que XML n'est tout simplement pas adapté à cela.

Le pire schéma XML ? À propos, le prix pour le pire schéma XML que j'ai jamais vu, Obtient le format de fichier de configuration de provisionnement automatique pour les téléphones de téléphonie IP Polycom. De tels fichiers nécessitent le téléchargement de fichiers de requête XML via TFTP, qui... En général, 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. 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.
• Si vous souhaitez attribuer des valeurs à plusieurs instances d'un type d'enregistrement particulier, vous devez utiliser des noms d'attribut pour ce faire. qui ont des index.
• De plus, les attributs commençant par softkey., doit être placé sur des éléments <softkey/>, attributs commençant par feature., doit être placé sur des éléments <feature/> etc., malgré le fait que cela semble complètement inutile et dénué de sens à première vue.
• Et enfin, si vous espériez que le premier composant d'un nom d'attribut soit toujours le même que le nom de l'élément, rien de tel ! Par exemple, les attributs up. doit être attaché à <userpreferences/>. L'ordre d'association des noms d'attribut aux éléments est arbitraire, presque entièrement.

Documents ou données. De temps en temps, quelqu'un fait quelque chose de complètement bizarre en essayant de comparer XML et JSON, montrant ainsi qu'il ne comprend pas non plus. XML est un langage de balisage de documents. JSON est un format de données structuré, donc les comparer les uns aux autres revient à essayer de comparer le chaud avec le doux.

Le concept de la différence entre documents et données. Comme analogue de XML, nous pouvons sous condition prendre un document lisible par machine. Bien qu’il soit destiné à être lisible par une machine, il fait référence métaphoriquement à des documents, et de ce point de vue est en réalité comparable aux documents PDF, qui ne sont le plus souvent pas lisibles par une machine.

Par exemple, en XML, l'ordre des éléments est important. Mais en JSON, l’ordre des paires clé-valeur au sein des objets n’a aucun 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 de nombreux types de données différents à partir de ces données. documents, car il y a un certain ordre dans le document. Métaphoriquement, il est analogue à un document sur papier, bien qu'il n'ait pas de dimensions physiques, contrairement à une impression ou à un fichier PDF.

Mon exemple de représentation de dictionnaire XML appropriée montre l'ordre des éléments dans le dictionnaire, par opposition à la représentation JSON. Je ne peux ignorer cet ordre : cette linéarité est inhérente au modèle de document et au format XML. Certains peuvent choisir d'ignorer l'ordre lors de l'interprétation de ce document XML, mais cela ne sert à rien de discuter puisque la question dépasse le cadre d'une discussion sur le format lui-même. De plus, si vous rendez le document visible dans le navigateur en y attachant une feuille de style en cascade, vous verrez que les éléments du dictionnaire apparaissent dans un certain ordre et dans aucun autre.

En d’autres termes, un dictionnaire (une donnée structurée) peut être converti en n divers documents possibles (en XML, PDF, papier, etc.), où n - le nombre de combinaisons possibles d'éléments dans le dictionnaire, et nous n'avons pas encore pris en compte les autres variables possibles.

Cependant, il s'ensuit également que si vous souhaitez transférer 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, il ne fera que gêner. De plus, pour extraire les données sources, vous devrez écrire un programme. Il ne sert à rien d'utiliser XML pour quelque chose qui ne sera pas formaté comme un document à un moment donné (par exemple, en utilisant CSS ou XSLT, ou les deux), puisque c'est la raison principale (sinon la seule) de le faire. au modèle de document.

De plus, étant donné que XML n'a pas de concept de nombres (ni d'expressions booléennes, ni d'autres types de données), tous les nombres représentés dans ce format sont considérés comme du simple texte supplémentaire. Pour extraire des données, le schéma et sa relation avec les données correspondantes exprimées doivent être connus. Vous devez également savoir quand, en fonction du contexte, un élément de texte particulier représente un nombre et doit être converti en nombre, etc.

Ainsi, le processus d'extraction de données à partir de documents XML n'est pas si différent du processus de reconnaissance de documents numérisés contenant, par exemple, des tableaux formant plusieurs pages de données numériques. Oui, cela est possible en principe, mais ce n'est pas la méthode la plus optimale, sauf en dernier recours, lorsqu'il n'y a absolument aucune autre option. Une solution raisonnable consiste simplement à trouver une copie numérique des données originales qui ne soit pas intégrée dans un modèle de document combinant les données avec leur représentation textuelle spécifique.

Cela dit, cela ne me surprend pas du tout que XML soit populaire dans les entreprises. La raison en est précisément que le format du document (sur papier) est compréhensible et familier aux entreprises, et qu'elles souhaitent continuer à utiliser un modèle familier et compréhensible. Pour la même raison, les entreprises utilisent trop souvent des documents PDF au lieu de formats plus lisibles par machine, car ils sont toujours liés au concept de page imprimée ayant une taille physique spécifique. Cela s'applique même aux documents qui ne seront probablement jamais imprimés (par exemple, un PDF de 8000 XNUMX pages de documentation du registre). De ce point de vue, l’utilisation de XML en entreprise est essentiellement une manifestation de skeuomorphisme. Les gens comprennent l'idée métaphorique d'une page imprimée de taille limitée et comprennent comment créer des processus métier basés sur des documents imprimés. Si tel est votre guide, les documents sans limitation de taille physique et lisibles par machine (les documents XML) représentent l'innovation tout en étant une contrepartie de document familière et confortable. Cela ne les empêche pas de rester une manière incorrecte et trop skeuomorphique de présenter les données.

À ce jour, les seuls schémas XML que je connaisse et que je peux réellement qualifier d'utilisation valide du format sont XHTML et DocBook.

Source: habr.com