A linguaxe XML foi inventada en 1996. Nada máis aparecer, as posibilidades da súa aplicación xa comezaron a ser mal entendidas, e para os fins aos que intentaban adaptalo non era a mellor opción.
Non é esaxerado dicir que a gran maioría dos esquemas XML que vin eran usos inadecuados ou incorrectos de XML. Ademais, este uso de XML demostrou un malentendido fundamental do que era XML.
XML é unha linguaxe de marcas. Este non é un formato de datos. A maioría dos esquemas XML pasaron por alto esta distinción, confundindo XML cun formato de datos, o que finalmente resulta nun erro ao elixir XML porque é o formato de datos que realmente se necesita.
Sen entrar en demasiados detalles, XML é o máis adecuado para anotar bloques de texto con estrutura e metadatos. Se o teu obxectivo principal non é traballar cun bloque de texto, é improbable que a elección de XML estea xustificada.
Desde este punto de vista, hai un xeito sinxelo de comprobar o ben que está feito o esquema XML. Tomemos como exemplo un documento no esquema previsto e eliminemos todas as etiquetas e atributos del. Se o que queda non ten sentido (ou se queda unha liña en branco), ou o teu esquema non está construído correctamente ou simplemente non deberías ter usado XML.
A continuación darei algúns dos exemplos máis comúns de circuítos construídos incorrectamente.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Aquí vemos un exemplo dun intento infundado e estraño (aínda que moi común) de expresar un dicionario de clave-valor sinxelo en XML. Se eliminas todas as etiquetas e atributos, quedarás cunha fila baleira. Esencialmente, este documento é, por absurdo que pareza, unha anotación semántica dunha liña baleira.
<root name="John" city="London" />Para empeorar as cousas, aquí non só temos unha anotación semántica dunha cadea baleira como unha forma extravagante de expresar un dicionario, esta vez o "dicionario" codifica directamente como atributos do elemento raíz. Isto fai que o conxunto dado de nomes de atributos nun elemento estea indefinido e dinámico. Ademais, mostra que o único que realmente quería expresar o autor era unha simple sintaxe clave-valor, pero no seu lugar tomou a decisión absolutamente estraña de aplicar XML, forzando o uso dun único elemento baleiro simplemente como prefixo para usar a sintaxe de atributos. E atópome con este tipo de esquemas moi a miúdo.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Isto é algo mellor, pero agora por algún motivo as claves son metadatos e os valores non. Unha ollada moi estraña aos dicionarios. Se eliminas todas as etiquetas e atributos, perderase a metade da información.
Unha expresión de dicionario correcta en XML sería algo así:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Pero se a xente tomou a estraña decisión de usar XML como formato de datos e despois usalo para organizar un vocabulario, entón deberían entender que o que están facendo é inadecuado e non conveniente. Tamén é común que os deseñadores elixan por erro XML para crear as súas aplicacións. Pero aínda máis a miúdo, empeoran as cousas ao usar XML sen sentido nunha das formas descritas anteriormente, ignorando o feito de que XML simplemente non é axeitado para iso.
O peor esquema XML? Por certo, o premio para o peor esquema XML que vin, Obtén o formato de ficheiro de configuración de aprovisionamento automático para teléfonos de telefonía IP de Polycom. Estes ficheiros requiren descargar ficheiros de solicitude XML a través de TFTP, que... En xeral, aquí tes un extracto dun destes ficheiros:
<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="..." />Esta non é a mala broma de alguén. E este non é o meu invento:
- os elementos utilízanse simplemente como prefixo para achegar atributos, que teñen nomes xerárquicos.
- Se queres asignar valores a varias instancias dun determinado tipo de rexistro, debes usar nomes de atributos para facelo. que teñen índices.
- Ademais, atributos que comezan por
softkey., debe colocarse sobre elementos<softkey/>, atributos que comezan porfeature., debe colocarse sobre elementos<feature/>etc., a pesar de que parece completamente innecesario e a primeira vista carente de sentido. - E, finalmente, se esperases que o primeiro compoñente dun nome de atributo fose sempre o mesmo que o nome do elemento, nada diso! Por exemplo, atributos
up.debe estar unido<userpreferences/>. A orde de anexar nomes de atributos aos elementos é arbitraria, case completamente.
Documentos ou datos. De vez en cando, alguén fai algo completamente estraño tentando comparar XML e JSON, e así demostra que tampouco o entende. XML é unha linguaxe de marcado de documentos. JSON é un formato de datos estruturados, polo que comparalos entre si é como tratar de comparalos cálidos con suaves.
O concepto de diferenza entre documentos e datos. Como análogo de XML, podemos tomar condicionalmente un documento lexible por máquina. Aínda que está pensado para ser lexible por máquina, refírese metafóricamente a documentos, e desde este punto de vista é en realidade comparable aos documentos PDF, que na maioría das veces non son lexibles por máquina.
Por exemplo, en XML a orde dos elementos importa. Pero en JSON, a orde dos pares clave-valor dentro dos obxectos carece de significado e non está definida. Se queres obter un dicionario non ordenado de pares clave-valor, non importa a orde real na que aparecen os elementos nese ficheiro. Pero pode formar moitos tipos diferentes de datos a partir destes datos. de documentos, porque hai unha determinada orde no documento. Metaforicamente, é análogo a un documento en papel, aínda que non ten dimensións físicas, a diferenza dun ficheiro impreso ou PDF.
O meu exemplo dunha representación adecuada do dicionario XML mostra a orde dos elementos no dicionario, en oposición á representación JSON. Non podo ignorar esta orde: esta linealidade é inherente ao modelo de documento e ao formato XML. Algúns poden optar por ignorar a orde ao interpretar este documento XML, pero non ten sentido discutir sobre isto xa que o problema está fóra do alcance dunha discusión sobre o propio formato. Ademais, se fai que o documento se poida ver no navegador anexándolle unha folla de estilo en cascada, verá que os elementos do dicionario aparecen nunha determinada orde e en ningunha outra.
Noutras palabras, pódese converter nun dicionario (unha peza de datos estruturados). n diversos documentos posibles (en XML, PDF, papel, etc.), onde n - o número de posibles combinacións de elementos no dicionario, e aínda non tivemos en conta outras posibles variables.
Non obstante, tamén se desprende que se quere transferir só datos, o uso dun documento lexible por máquina para iso non será efectivo. Utiliza un modelo, que neste caso é superfluo, só se interporá. Ademais, para extraer os datos de orixe, terás que escribir un programa. Apenas ten sentido usar XML para algo que non se formateará como documento nalgún momento (por exemplo, usando CSS ou XSLT, ou ambos), xa que esa é a razón principal (se non a única) para facelo. ao modelo de documento.
Ademais, xa que XML non ten concepto de números (ou expresións booleanas ou outros tipos de datos), todos os números representados neste formato considéranse só texto adicional. Para extraer datos hai que coñecer o esquema e a súa relación cos datos correspondentes que se expresan. Tamén cómpre saber cando, segundo o contexto, un determinado elemento de texto representa un número e debe converterse nun número, etc.
Así, o proceso de extracción de datos de documentos XML non é tan diferente do proceso de recoñecemento de documentos dixitalizados que conteñen, por exemplo, táboas que forman moitas páxinas de datos numéricos. Si, é posible facelo en principio, pero esta non é a forma máis óptima, excepto como último recurso, cando non hai absolutamente outras opcións. Unha solución razoable é atopar simplemente unha copia dixital dos datos orixinais que non estea incrustada nun modelo de documento que combine os datos coa súa representación textual específica.
Dito isto, non me sorprende en absoluto que XML sexa popular nos negocios. A razón diso é precisamente que o formato do documento (en papel) é comprensible e familiar para as empresas, e queren seguir utilizando un modelo familiar e comprensible. Polo mesmo motivo, as empresas usan con demasiada frecuencia documentos PDF en lugar de formatos máis lexibles pola máquina, porque aínda están ligados ao concepto de páxina impresa cun tamaño físico específico. Isto mesmo aplícase a documentos que é improbable que nunca se impriman (por exemplo, un PDF de 8000 páxinas de documentación do rexistro). Desde este punto de vista, o uso de XML nos negocios é esencialmente unha manifestación de esqueuomorfismo. A xente entende a idea metafórica dunha páxina impresa de tamaño limitado e entende como crear procesos de negocio baseados en documentos impresos. Se esa é a túa guía, os documentos sen limitacións de tamaño físico que son lexibles pola máquina (documentos XML) representan innovación ao tempo que son un documento familiar e cómodo. Isto non impide que sigan sendo un xeito incorrecto e excesivamente esceuomórfico de presentar os datos.
Ata a data, os únicos esquemas XML que coñezo que realmente podo chamar un uso válido do formato son XHTML e DocBook.
Fonte: www.habr.com