El llenguatge XML es va inventar l'any 1996. Tan bon punt havia aparegut que les possibilitats de la seva aplicació ja s'havien començat a malinterpretar, i als efectes als quals s'intentaven adaptar, no era la millor opció.
No és exagerat dir que la gran majoria dels esquemes XML que he vist eren usos inadequats o incorrectes de XML. A més, aquest ús d'XML va demostrar un malentès fonamental del que era XML.
XML és un llenguatge de marques. Aquest no és un format de dades. La majoria dels esquemes XML han passat per alt explícitament aquesta distinció, confonent XML amb un format de dades, la qual cosa, en última instància, resulta en un error en triar XML perquè és el format de dades que realment es necessita.
Sense entrar en massa detalls, XML és el més adequat per anotar blocs de text amb estructura i metadades. Si el vostre objectiu principal no és treballar amb un bloc de text, és poc probable que es justifiqui escollir XML.
Des d'aquest punt de vista, hi ha una manera senzilla de comprovar com està fet l'esquema XML. Prenguem com a exemple un document a l'esquema previst i traiem-ne totes les etiquetes i atributs. Si el que queda no té sentit (o si queda una línia en blanc), el vostre esquema no està construït correctament o simplement no hauríeu d'haver utilitzat XML.
A continuació donaré alguns dels exemples més comuns de circuits construïts incorrectament.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Aquí veiem un exemple d'un intent infundat i estrany (encara que molt comú) d'expressar un diccionari de valors-clau senzill en XML. Si elimineu totes les etiquetes i atributs, us quedarà una fila buida. En essència, aquest document és, per absurd que sembli, una anotació semàntica d'una línia buida.
<root name="John" city="London" />Per empitjorar les coses, aquí no només tenim una anotació semàntica d'una cadena buida com una forma extravagant d'expressar un diccionari: aquesta vegada el "diccionari" està codificat directament com a atributs de l'element arrel. Això fa que el conjunt donat de noms d'atributs en un element sigui indefinit i dinàmic. A més, mostra que tot el que realment volia expressar l'autor era una simple sintaxi clau-valor, però en canvi va prendre la decisió absolutament estranya d'aplicar XML, forçant l'ús d'un únic element buit simplement com a prefix per utilitzar la sintaxi d'atributs. I em trobo amb aquests esquemes molt sovint.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Això és millor, però ara per alguna raó les claus són metadades i els valors no. Una mirada molt estranya als diccionaris. Si elimineu totes les etiquetes i atributs, es perdrà la meitat de la informació.
Una expressió de diccionari correcta en XML es veuria així:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Però si la gent ha pres l'estranya decisió d'utilitzar XML com a format de dades i després l'utilitza per organitzar un vocabulari, haurien d'entendre que el que estan fent és inadequat i no és convenient. També és habitual que els dissenyadors escullin XML per error per crear les seves aplicacions. Però encara més sovint, empitjoren les coses fent servir XML sense sentit en una de les formes descrites anteriorment, ignorant el fet que XML simplement no és adequat per a això.
El pitjor esquema XML? Per cert, el premi per el pitjor esquema XML que he vist mai, Obté el format de fitxer de configuració de subministrament automàtic per als telèfons de telefonia IP de Polycom. Aquests fitxers requereixen descarregar fitxers de sol·licitud XML mitjançant TFTP, que... En general, aquí teniu un extracte d'un d'aquests fitxers:
<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="..." />Aquesta no és una mala broma d'algú. I aquest no és el meu invent:
- Els elements simplement s'utilitzen com a prefix per adjuntar atributs, que ells mateixos tenen noms jeràrquics.
- Si voleu assignar valors a diverses instàncies d'un determinat tipus de registre, heu d'utilitzar noms d'atributs per fer-ho. que tenen índexs.
- A més, atributs que comencen per
softkey., s'han de col·locar sobre elements<softkey/>, atributs que comencen perfeature., s'han de col·locar sobre elements<feature/>etc., tot i que sembla completament innecessari i a primera vista sense sentit. - I, finalment, si tinguéssiu l'esperança que el primer component d'un nom d'atribut fos sempre el mateix que el nom de l'element, res d'això! Per exemple, els atributs
up.s'ha d'adjuntar<userpreferences/>. L'ordre d'adjuntar noms d'atributs als elements és arbitrari, gairebé completament.
Documents o dades. De tant en tant, algú fa alguna cosa completament estranya intentant comparar XML i JSON, i així demostra que tampoc ho entén. XML és un llenguatge de marcatge de documents. JSON és un format de dades estructurades, de manera que comparar-los entre ells és com intentar comparar el càlid amb el suau.
El concepte de diferència entre documents i dades. Com a anàleg de XML, podem prendre condicionalment un document llegible per màquina. Tot i que està pensat per ser llegible per màquina, es refereix metafòricament als documents, i des d'aquest punt de vista és en realitat comparable als documents PDF, que sovint no són llegibles per màquina.
Per exemple, en XML l'ordre dels elements importa. Però a JSON, l'ordre dels parells clau-valor dins dels objectes no té sentit i no està definit. Si voleu obtenir un diccionari no ordenat de parells clau-valor, no importa l'ordre real en què apareixen els elements en aquest fitxer. Però podeu formar molts tipus diferents de dades a partir d'aquestes dades. de documents, perquè hi ha un cert ordre al document. Metafòricament, és anàleg a un document en paper, encara que no té dimensions físiques, a diferència d'un fitxer impresa o PDF.
El meu exemple d'una representació adequada del diccionari XML mostra l'ordre dels elements al diccionari, a diferència de la representació JSON. No puc ignorar aquest ordre: aquesta linealitat és inherent al model de document i al format XML. Alguns poden optar per ignorar l'ordre a l'hora d'interpretar aquest document XML, però no té sentit discutir sobre això, ja que el problema està fora de l'abast d'una discussió sobre el format en si. A més, si feu que el document sigui visible al navegador adjuntant-hi un full d'estil en cascada, veureu que els elements del diccionari apareixen en un ordre determinat i en cap altre.
En altres paraules, es pot convertir un diccionari (una dada estructurada). n diversos documents possibles (en XML, PDF, paper, etc.), on n - el nombre de possibles combinacions d'elements al diccionari, i encara no hem tingut en compte altres possibles variables.
Tanmateix, també es dedueix que si només voleu transferir dades, l'ús d'un document llegible per màquina per a això no serà efectiu. Utilitza un model, que en aquest cas és superflu; només entorbarà. A més, per extreure les dades d'origen, caldrà escriure un programa. Gairebé no té sentit utilitzar XML per a alguna cosa que no es formatarà com a document en algun moment (per exemple, utilitzant CSS o XSLT, o tots dos), ja que aquesta és la raó principal (si no l'única) per fer-ho. al model de document.
A més, com que XML no té cap concepte de nombres (o expressions booleanes o altres tipus de dades), tots els números representats en aquest format es consideren només text addicional. Per extreure dades, cal conèixer l'esquema i la seva relació amb les dades corresponents que s'expressen. També cal saber quan, segons el context, un element de text concret representa un nombre i s'ha de convertir en un nombre, etc.
Així, el procés d'extracció de dades de documents XML no és tan diferent del procés de reconeixement de documents escanejats que contenen, per exemple, taules que formen moltes pàgines de dades numèriques. Sí, en principi és possible fer-ho, però aquesta no és la manera més òptima, excepte com a últim recurs, quan no hi ha absolutament cap altra opció. Una solució raonable és simplement trobar una còpia digital de les dades originals que no estigui incrustada en un model de document que combini les dades amb la seva representació textual específica.
Dit això, no em sorprèn gens que XML sigui popular als negocis. La raó d'això és precisament que el format del document (en paper) és comprensible i familiar per a les empreses, i volen continuar utilitzant un model familiar i entenedor. Per la mateixa raó, les empreses utilitzen massa sovint documents PDF en lloc de formats més llegibles per màquina, perquè encara estan lligats al concepte d'una pàgina impresa amb una mida física específica. Això fins i tot s'aplica als documents que és poc probable que s'imprimiran mai (per exemple, un PDF de 8000 pàgines de documentació del registre). Des d'aquest punt de vista, l'ús d'XML en els negocis és essencialment una manifestació d'esqueuomorfisme. La gent entén la idea metafòrica d'una pàgina impresa de mida limitada i entén com crear processos empresarials basats en documents impresos. Si aquesta és la vostra guia, els documents sense limitacions de mida física que són llegibles per màquina (documents XML) representen innovació alhora que són una contrapartida familiar i còmoda. Això no impedeix que segueixin sent una manera incorrecta i excessivament esqueuomòrfica de presentar les dades.
Fins ara, els únics esquemes XML que conec que realment puc anomenar un ús vàlid del format són XHTML i DocBook.
Font: www.habr.com