El lenguaje XML fue inventado en 1996. Apenas había aparecido antes de que las posibilidades de su aplicación comenzaran a malinterpretarse, y para los fines para los que intentaron adaptarlo, no era la mejor opción.
No sería una exageración decir que la gran mayoría de los esquemas XML que he visto son inapropiados o mal uso de XML. Además, este uso de XML atestigua un malentendido fundamental de lo que se trata principalmente XML.
XML es un lenguaje de marcado.
Este no es un formato de datos . En la mayoría de los esquemas XML, esta distinción no se tuvo en cuenta explícitamente, confundiendo XML con el formato de datos, lo que finalmente significó un error en la elección de XML, porque de hecho el formato de datos era necesario.
Sin entrar en detalles, XML es mejor para anotar bloques de texto con estructura y metadatos. Si su tarea principal no es trabajar con un bloque de texto, es poco probable que la elección de XML esté justificada.
Desde este punto de vista, hay una manera fácil de verificar qué tan bien está hecho el esquema XML. Tome, por ejemplo, el documento en el esquema propuesto y elimine todas las etiquetas y atributos del mismo. Si no tiene sentido lo que queda (o si queda una cadena vacía), entonces su esquema no está construido correctamente o simplemente no debería haber usado XML.
A continuación daré algunos de los ejemplos más comunes de circuitos construidos incorrectamente.
<rot> <item name="name" value="John" /> <item name="city" value="London" /> </rot>
Aquí vemos un ejemplo de un intento irracional y extraño (aunque muy generalizado) de expresar un diccionario clave-valor simple en XML. Si elimina todas las etiquetas y atributos, quedará una línea vacía. Básicamente, este documento es, por muy absurdo que parezca, la anotación semántica de una línea vacía.
<root name="John" city="London" />
Para empeorar las cosas, lo que tenemos aquí no es solo una anotación semántica de una cadena vacía como una forma extravagante de expresar un diccionario, esta vez el "diccionario" se codifica directamente como atributos del elemento raíz. Debido a esto, un conjunto dado de nombres de atributos en un elemento se vuelve indefinido y dinámico. Además, está claro a partir de aquí que todo lo que el autor realmente quería expresar era una sintaxis simple de valor clave, pero en su lugar tomó una decisión absolutamente extraña de usar XML, forzando el uso de un solo elemento vacío solo como un prefijo para usar sintaxis de atributo Y tales esquemas se me ocurren muy a menudo.
<rot> <item key="name">John</item> <item key="city">London</item> </rot>
Esto ya es algo mejor, pero ahora las claves son metadatos por alguna razón, pero los valores no lo son. Una mirada muy extraña a los diccionarios. Si elimina todas las etiquetas y atributos, se perderá la mitad de la información.
La expresión de diccionario correcta en XML se verá así:
<rot> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </rot>
Pero si la gente tomó la extraña decisión de usar XML como formato de datos y luego usarlo para organizar el diccionario, entonces deberían entender que lo que están haciendo es inapropiado y no conveniente. Aún a menudo, los diseñadores eligen por error XML para construir sus aplicaciones. Pero aún más a menudo, exacerban la situación por el uso sin sentido de XML en una de las formas descritas anteriormente, ignorando el hecho de que XML simplemente no es adecuado para esto.
¿El peor esquema XML? Por cierto, el premio
al peor esquema XML que he visto obtiene el formato del archivo de configuración de asignación automática de recursos para teléfonos de telefonía IP de Polycom. Dichos archivos requieren cargar archivos de solicitud XML a través de TFTP, que ... En general, aquí hay un extracto de uno de esos archivos:
<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="..." />
Esto no es una broma mala. Y este no es mi invento:
- los elementos simplemente se usan como prefijo para adjuntar atributos, que tienen nombres jerárquicos.
- Si desea asignar valores a varias instancias de un registro de un tipo determinado, debe usar los nombres de los atributos en los que hay índices .
- Además, los atributos comienzan con la
softkey. , debe colocar en los elementos <softkey/> , atributos que comienzan con la feature. , debe colocarse en los elementos <feature/> , etc., a pesar de que parece completamente redundante y a primera vista no tiene sentido.
- Y finalmente, si esperaba que el primer componente del nombre del atributo siempre coincida con el nombre del elemento, ¡nada de eso! Por ejemplo, los atributos
up. debe adjuntarse a <userpreferences/> . El orden de adjuntar nombres de atributos a los elementos es arbitrario, y casi por completo.
Documentos o datos . De vez en cuando, alguien hace cosas absolutamente extrañas, tratando de comparar XML y JSON, y mostrando así que no entiende ni a uno ni a otro. XML es un lenguaje de marcado de documentos. JSON es un formato de datos estructurado, por lo que compararlo entre sí es como tratar de comparar cálido con suave.
Para comprender esto, ayudará el concepto de la diferencia entre
documentos y datos . Como análogo de XML, puede tomar arbitrariamente un documento legible por máquina. Aunque está destinado a ser leído por una máquina, se refiere metafóricamente a los documentos, y desde este punto de vista es realmente comparable a los documentos PDF, que a menudo no son legibles por máquina.
Por ejemplo, en XML, el orden de los elementos es importante. Y en JSON, el orden de los pares clave-valor dentro de los objetos no tiene sentido y no está definido. Si desea obtener un diccionario desordenado de pares clave-valor, no importa el orden real en el que siguen los elementos de este archivo. Pero puede formar muchos
documentos diferentes a partir de estos datos, porque el documento tiene un cierto orden. Metafóricamente, este es un análogo de un documento en papel, aunque no tiene dimensiones físicas, a diferencia de una copia impresa o un archivo PDF.
En mi ejemplo de la representación correcta del diccionario en XML, se muestra el orden de los elementos en el diccionario, en contraste con la representación en el lenguaje JSON. No puedo ignorar este orden: dicha linealidad es inherente al modelo de documento y al formato XML. Al interpretar este documento XML, alguien puede decidir ignorar el orden, pero no tiene sentido discutir sobre esto, ya que este problema va más allá de discutir el formato en sí. Además, si hace que un documento sea visible en un navegador al adjuntarle una hoja de estilo en cascada, puede ver que los elementos del diccionario siguen un cierto orden y de ninguna otra manera.
En otras palabras, un diccionario (un fragmento de datos estructurados) se puede convertir en
n diferentes documentos posibles (en XML, PDF, en papel, etc.), donde
n es el número de posibles combinaciones de elementos en el diccionario, y todavía no hemos tenido en cuenta los otros posibles variables
Sin embargo, también se deduce de esto que si desea transmitir datos solo, entonces el uso de un documento legible por máquina para esto no será efectivo. Utiliza un modelo, que en este caso es superfluo, solo interferirá. Además, para extraer los datos de origen, será necesario escribir un programa. No tiene sentido usar XML para algo que en una determinada etapa no se formateará como un documento (por ejemplo, usando CSS o XSLT, o ambos), ya que esta es la razón principal (si no la única) para eso para apegarse al modelo de documento.
Además, dado que XML no tiene el concepto de números (o expresiones booleanas u otros tipos de datos), todos los números representados en este formato se consideran solo texto adicional. Para extraer los datos, se debe conocer el esquema y su relación con los datos expresados correspondientes. También es necesario saber cuándo, en función del contexto, uno u otro elemento del texto es un número, y debe convertirse a un número, etc.
Por lo tanto, el proceso de extracción de datos de documentos XML no es tan diferente del proceso de reconocimiento de documentos escaneados que contienen, por ejemplo, tablas que forman muchas páginas de datos numéricos. Sí, en principio es posible hacer esto, pero esta no es la forma más óptima, a menos que en un caso extremo, cuando no haya otras opciones. Una decisión inteligente sería simplemente encontrar una copia digital de los datos originales que no esté incrustada en el modelo del documento, en la que los datos se combinen con su representación textual específica.
Sin embargo, no me sorprende en absoluto que XML sea popular en los negocios. La razón de esto es precisamente porque el formato de los documentos (en papel) es comprensible y familiar para las empresas, y quieren continuar usando el modelo familiar y comprensible allí. Por la misma razón, en los negocios con demasiada frecuencia usan documentos en PDF en lugar de más convenientes para los formatos de procesamiento de máquinas, porque todavía están vinculados al concepto de página impresa con un cierto tamaño físico. Esto se aplica incluso a documentos que es poco probable que se impriman (por ejemplo, un archivo PDF de documentación de registro de 8,000 páginas). Desde este punto de vista, el uso de XML en los negocios es esencialmente una manifestación de esceptomorfismo. Las personas entienden la idea metafórica de una página impresa de un tamaño limitado, y entienden cómo crear procesos comerciales basados en documentos impresos. Si esta es su guía, los documentos sin un tamaño físico limitado que sean legibles por máquina (documentos XML) son una innovación, a la vez que son un análogo familiar y cómodo de un documento. Lo que no evita que sigan siendo una forma incorrecta y excesivamente escéptica de presentar datos.
Hasta la fecha, los únicos esquemas XML que sé que realmente puedo llamar el uso adecuado de este formato son XHTML y DocBook.