XML casi siempre se aplica incorrectamente

El lenguaje XML fue inventado en 1996. Apenas apareció, ya se comenzaron a malinterpretar sus posibilidades de uso, y para los fines a los que se intentó adaptar, no era la mejor opción.

No es una exageración decir que la abrumadora mayoría de los esquemas XML que he visto representan un uso inapropiado o incorrecto de XML. Además, tal uso de XML evidenció un entendimiento fundamentalmente erróneo de lo que realmente es XML.

XML es un lenguaje de marcado. No es un formato de datos.En la mayoría de los esquemas XML, esta distinción no se tuvo en cuenta, confundiendo XML con un formato de datos, lo que en última instancia significó un error en la elección de XML, ya que en realidad se necesitaba un formato de datos.

Sin entrar en detalles, XML es más adecuado para anotar bloques de texto con estructura y metadatos. Si su principal objetivo no es trabajar con un bloque de texto, la elección de XML difícilmente estará justificada.

Desde este punto de vista, hay una forma sencilla de comprobar cuán bien hecho está un esquema XML. Tomemos como ejemplo un documento en el esquema propuesto y eliminemos todas las etiquetas y atributos. Si en lo que queda no hay sentido (o si queda una línea vacía), entonces o bien su esquema está mal construido o simplemente no debió aplicar XML.

A continuación, presentaré algunos de los ejemplos más comunes de esquemas mal construidos.

Aquí vemos un ejemplo de un intento injustificado y extraño (aunque bastante común) de expresar en lenguaje XML un simple diccionario de "clave-valor". Si se eliminan todas las etiquetas y atributos, queda una línea vacía. En esencia, este documento representa, por absurdo que parezca, una anotación semántica de una línea vacía.

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

Lo que es peor, aquí no solo tenemos una anotación semántica de una línea vacía como una forma extravagante de expresar un diccionario, esta vez el "diccionario" está codificado directamente en forma de atributos del elemento raíz. Debido a esto, el conjunto de nombres de atributos en el elemento se vuelve indefinido y dinámico. Además, está claro que lo que realmente quería expresar el autor es una simple sintaxis de "clave-valor", pero en lugar de eso, tomó la extraña decisión de aplicar XML, forzando el uso de un único elemento vacío simplemente como un prefijo para utilizar la sintaxis de atributos. Encuentro tales esquemas con mucha frecuencia.

John
  Londres

Esto ya es un progreso, pero ahora las claves son por alguna razón metadatos, mientras que los valores no lo son. Es una visión muy extraña sobre los diccionarios. Si se eliminan todas las etiquetas y atributos, se perderá la mitad de la información.

La correcta expresión de un diccionario en XML se vería aproximadamente así:

Nombre
    John
  
  
    Ciudad
    Londres

Pero si las personas toman la extraña decisión de usar XML como formato de datos y luego lo usan para organizar un diccionario, deben entender que lo que están haciendo es inapropiado e incómodo. Además, los diseñadores a menudo eligen erróneamente XML para desarrollar sus aplicaciones. Pero aún más a menudo, agravan la situación con el uso sin sentido de XML en una de las formas descritas anteriormente, ignorando el hecho de que XML simplemente no es adecuado para eso.

¿El esquema XML más horrible? Por cierto, el premio por el esquema XML más horrible que he visto, lo recibe el formato de archivo de configuración de asignación automática de recursos para teléfonos IP de voz sobre IP Polycom. Tales archivos requieren la descarga de archivos XML de solicitudes a través de TFTP, que... En fin, aquí hay un fragmento 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 desafortunada de alguien. Y no es un invento mío:

• Los elementos se utilizan simplemente como prefijos para adjuntar atributos que, en sí mismos, tienen nombres jerárquicos.
• Si es necesario asignar valores a varias instancias de un registro de un tipo específico, hay que utilizar los nombres de los atributos, que contienen índices.
• Además, los atributos que comienzan con softkey., deben colocarse en los elementos <softkey/>, los atributos que comienzan con feature., deben colocarse en los elementos <feature/> , etc., a pesar de que esto parece completamente innecesario y, a primera vista, sin sentido.
• Y, por último, si esperabas que el primer componente del nombre del atributo siempre coincidiera con el nombre del elemento, ¡nada de eso! Por ejemplo, los atributos up. deben adjuntarse a <userpreferences/>. El orden de adjuntar los nombres de los atributos a los elementos es aleatorio y prácticamente total.

Documentos o datos. De vez en cuando, alguien hace cosas absolutamente extrañas al intentar comparar XML y JSON, y al hacerlo, demuestra que no entiende ninguno de los dos. XML es un lenguaje de marcado de documentos. JSON, en cambio, es un formato de datos estructurados, por lo que comparar ambos es como intentar comparar lo caliente con lo blando.

Entender esto ayudará a comprender la diferencia entre documentos y datos. Como analogía, XML puede considerarse un documento legible por máquina. Aunque está destinado a ser leído por una máquina, metafóricamente se relaciona con documentos y, desde este punto de vista, es esencialmente comparable a documentos en formato PDF, que a menudo no son legibles por máquinas.

Por ejemplo, en XML, el orden de los elementos es importante. En JSON, el orden de las parejas de "clave-valor" dentro de los objetos no tiene sentido y no está definido. Si desea obtener un diccionario no ordenado de parejas de "clave-valor", el orden real en que aparecen los elementos en este archivo no importa. Sin embargo, puede formar muchos documentos diferentes a partir de estos datos , ya que en un documento hay un orden específico. Metafóricamente, esto es análogo a un documento en papel, aunque no tenga dimensiones físicas a diferencia de una impresión o un archivo PDF..

En mi ejemplo de una representación adecuada de un diccionario en XML, se muestra el orden de los elementos en el diccionario, a diferencia de la representación en JSON. No puedo ignorar este orden: tal linealidad es intrínseca al modelo de documentos y al formato XML. Alguien podría decidir ignorar el orden al interpretar este documento XML, pero discutir sobre eso es inútil, ya que la cuestión está fuera del alcance de la discusión sobre el formato en sí. Además, si se hace que el documento sea visible en el navegador, al adjuntarle una hoja de estilos en cascada, se podrá ver que los elementos del diccionario siguen un orden específico, y no de otra manera.

En otras palabras, un diccionario (fragmento de datos estructurados) puede ser transformado en n diversos documentos posibles (en formato XML, PDF, en papel, etc.), donde n — el número de combinaciones posibles de elementos en el diccionario, y aún no hemos considerado otras variables posibles.

Sin embargo, también se deduce que si solo quieres transmitir datos, usar un documento legible por máquina no será efectivo. Se utiliza un modelo que en este caso es redundante y solo estorbará. Además, para extraer los datos originales, será necesario escribir un programa. Difícilmente tiene sentido usar XML para algo que en una etapa determinada no será formateado como un documento (por ejemplo, utilizando CSS o XSLT, o ambos), ya que esa es la principal (si no la única) razón para ceñirse al modelo de documento.

Además, dado que en XML no existe el concepto de números (o expresiones booleanas, o otros tipos de datos), todos los números presentados en este formato se consideran solo texto adicional. Para extraer datos, debe conocerse el esquema y su relación con los datos expresados. También es necesario saber, según el contexto, cuándo un determinado elemento del texto representa un número y debe ser convertido en un número, etc.

Por lo tanto, el proceso de extracción de datos de documentos XML no difiere mucho del proceso de reconocimiento de documentos escaneados que contienen, por ejemplo, tablas que forman múltiples páginas de datos numéricos. Sí, es posible hacerlo en principio, pero no es el camino más óptimo, a menos que sea en el caso extremo de que no haya otras opciones. Una solución razonable sería simplemente encontrar una copia digital de los datos originales, que no estén incrustados en un modelo de documento, en el que los datos se combinan con su representación textual específica.

No me sorprende en absoluto que XML sea popular en el negocio. La razón de esto es precisamente que el formato de documentos (en papel) es comprensible y familiar para los negocios, y quieren seguir utilizando un modelo que conocen y comprenden. Por la misma razón, los negocios utilizan con demasiada frecuencia documentos en PDF en lugar de formatos más adecuados para el procesamiento automático: porque aún están atados a la idea de una página impresa con un tamaño físico determinado. Esto se aplica incluso a aquellos documentos que difícilmente se imprimirán alguna vez (por ejemplo, un archivo PDF de documentación del registro de 8000 páginas). Desde este punto de vista, el uso de XML en los negocios es en esencia una manifestación de esqueleto morfológico. La idea metafórica de una página impresa de tamaño limitado es comprensible para las personas, y entienden cómo crear procesos comerciales basados en documentos impresos. Si ese es su punto de referencia, los documentos sin un tamaño físico limitado, que son legibles por máquina —los documentos XML— representan una innovación, siendo al mismo tiempo análogos familiares y cómodos al documento. Esto no impide que sigan siendo una forma errónea y excesivamente esquelética de representar datos.

Hasta la fecha, las únicas esquemas XML que realmente puedo considerar un uso correcto de este formato son XHTML y DocBook.

Fuente: habr.com