XML casi siempre se usa mal

El lenguaje XML se inventó en 1996. Nada más aparecer ya se habían empezado a malinterpretar las posibilidades de su aplicación, y para los fines a los que se intentaba adaptarlo no era la mejor opción.

No es exagerado decir que la gran mayoría de los esquemas XML que he visto eran usos inapropiados o incorrectos de XML. Además, este uso de XML demostró un malentendido fundamental de lo que significaba XML.

XML es un lenguaje de marcado. Este no es un formato de datos.. La mayoría de los esquemas XML han pasado por alto explícitamente esta distinción, confundiendo XML con un formato de datos, lo que en última instancia resulta en un error al elegir XML porque es el formato de datos que realmente se necesita.

Sin entrar en demasiados detalles, XML es más adecuado para anotar bloques de texto con estructura y metadatos. Si su objetivo principal no es trabajar con un bloque de texto, es poco probable que esté justificado elegir XML.

Desde este punto de vista, existe una forma sencilla de comprobar qué tan bien está elaborado el esquema XML. Tomemos como ejemplo un documento en el esquema previsto y eliminemos todas las etiquetas y atributos del mismo. Si lo que queda no tiene sentido (o si queda una línea en blanco), entonces su esquema no está creado correctamente o simplemente no debería haber usado XML.

A continuación daré algunos de los ejemplos más comunes de circuitos construidos incorrectamente.

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

Aquí vemos un ejemplo de un intento infundado y extraño (aunque muy común) de expresar un diccionario clave-valor simple en XML. Si elimina todas las etiquetas y atributos, quedará una fila vacía. En esencia, este documento es, por absurdo que parezca, una anotación semántica de una línea vacía.

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

Para empeorar las cosas, aquí no solo tenemos una anotación semántica de una cadena vacía como una forma extravagante de expresar un diccionario; esta vez el "diccionario" está codificado directamente como atributos del elemento raíz. Esto hace que el conjunto dado de nombres de atributos en un elemento sea indefinido y dinámico. Además, muestra que todo lo que el autor realmente quería expresar era una sintaxis simple de clave-valor, pero en lugar de eso tomó la decisión absolutamente extraña de aplicar XML, forzando el uso de un único elemento vacío simplemente como prefijo para usar la sintaxis de atributos. Y me encuentro con esos esquemas muy a menudo.

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

Esto es algo mejor, pero ahora por alguna razón las claves son metadatos y los valores no. Una mirada muy extraña a los diccionarios. Si elimina todas las etiquetas y atributos, se perderá la mitad de la información.

Una expresión de diccionario correcta en XML se vería así:

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

Pero si las personas han tomado la extraña decisión de utilizar XML como formato de datos y luego usarlo para organizar un vocabulario, entonces deberían comprender que lo que están haciendo es inapropiado y no conveniente. También es común que los diseñadores elijan XML por error para crear sus aplicaciones. Pero aún más a menudo empeoran las cosas al utilizar XML sin sentido 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 por el peor esquema XML que he visto en mi vida, Obtiene el formato de archivo de configuración de aprovisionamiento automático para teléfonos de telefonía IP de Polycom. Dichos archivos requieren la descarga de archivos de solicitud XML a través de TFTP, lo cual... 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="..." />

Este no es un mal chiste de alguien. Y este no es mi invento:

• Los elementos se utilizan simplemente como prefijo para adjuntar atributos, que a su vez tienen nombres jerárquicos.
• Si desea asignar valores a varias instancias de un tipo particular de registro, debe utilizar nombres de atributos para hacerlo. que tienen índices.
• Además, los atributos que comienzan con softkey., debe colocarse sobre elementos <softkey/>, atributos que comienzan con feature., debe colocarse sobre elementos <feature/> etc., a pesar de que parece completamente innecesario y, a primera vista, sin sentido.
• Y finalmente, si esperabas que el primer componente del nombre de un atributo fuera siempre el mismo que el nombre del elemento, ¡nada de eso! Por ejemplo, atributos up. debe estar unido a <userpreferences/>. El orden de adjuntar nombres de atributos a los elementos es arbitrario, casi por completo.

Documentos o datos. De vez en cuando, alguien hace algo completamente extraño al intentar comparar XML y JSON y demostrar así que no entiende ninguno de los dos. XML es un lenguaje de marcado de documentos. JSON es un formato de datos estructurado, por lo que compararlos entre sí es como intentar comparar lo cálido con lo suave.

El concepto de diferencia entre documentos y datos. Como análogo de XML, podemos tomar condicionalmente un documento legible por máquina. Aunque está destinado a ser legible por máquina, se refiere metafóricamente a documentos y, desde este punto de vista, en realidad es comparable a los documentos PDF, que en la mayoría de los casos no son legibles por máquina.

Por ejemplo, en XML el orden de los elementos importa. Pero 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 aparecen los elementos en ese archivo. Pero puedes formar muchos tipos diferentes de datos a partir de estos datos. documentos, porque hay un cierto orden en el documento. Metafóricamente, es análogo a un documento en papel, aunque no tiene dimensiones físicas, a diferencia de una copia impresa o un archivo PDF.

Mi ejemplo de una representación de diccionario XML adecuada muestra el orden de los elementos en el diccionario, a diferencia de la representación JSON. No puedo ignorar este orden: esta linealidad es inherente al modelo del documento y al formato XML. Algunos pueden optar por ignorar el orden al interpretar este documento XML, pero no tiene sentido discutir sobre esto ya que la cuestión está más allá del alcance de una discusión sobre el formato en sí. Además, si hace que el documento sea visible en el navegador adjuntándole una hoja de estilos en cascada, verá que los elementos del diccionario aparecen en un orden determinado y en ningún otro.

En otras palabras, un diccionario (un conjunto de datos estructurados) se puede convertir en n varios documentos posibles (en XML, PDF, papel, etc.), donde n - el número de combinaciones posibles de elementos en el diccionario, y aún no hemos tenido en cuenta otras posibles variables.

Sin embargo, también se deduce que si desea transferir solo datos, entonces utilizar un documento legible por máquina no será efectivo. Utiliza un modelo, que en este caso es superfluo; sólo estorbará. Además, para extraer los datos de origen, necesitará escribir un programa. Casi no tiene sentido usar XML para algo que no será formateado como documento en algún momento (por ejemplo, usar CSS o XSLT, o ambos), ya que esa es la razón principal (si no la única) para hacerlo. al modelo de documento.

Además, dado que XML no tiene concepto de números (ni expresiones booleanas u otros tipos de datos), todos los números representados en este formato se consideran simplemente texto adicional. Para extraer datos, se debe conocer el esquema y su relación con los datos correspondientes que se expresan. También necesita saber cuándo, según el contexto, un elemento de texto en particular representa un número y debe convertirse en un número, etc.

Por 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 hacerlo, pero no es la forma más óptima, excepto como último recurso, cuando no hay absolutamente ninguna otra opción. Una solución razonable es simplemente encontrar una copia digital de los datos originales que no esté incrustada en un modelo de documento que combine los datos con su representación textual específica.

Dicho esto, no me sorprende en absoluto que XML sea popular en los negocios. La razón de esto es precisamente que el formato del documento (en papel) es comprensible y familiar para las empresas, y quieren seguir utilizando un modelo familiar y comprensible. Por la misma razón, las empresas utilizan con demasiada frecuencia documentos PDF en lugar de formatos más legibles por máquina, porque todavía están ligados al concepto de una página impresa con un tamaño físico específico. Esto se aplica incluso a documentos que probablemente nunca se imprimirán (por ejemplo, un PDF de 8000 páginas de documentación de registro). Desde este punto de vista, el uso de XML en los negocios es esencialmente una manifestación de eskeuomorfismo. La gente comprende la idea metafórica de una página impresa de tamaño limitado y comprende cómo crear procesos comerciales basados ​​en documentos impresos. Si esa es su guía, los documentos sin limitaciones de tamaño físico que son legibles por máquina (documentos XML) representan innovación y al mismo tiempo son una contraparte familiar y cómoda. Esto no impide que sigan siendo una forma incorrecta y demasiado esqueuomorfa de presentar datos.

Hasta la fecha, los únicos esquemas XML que conozco y que realmente puedo considerar un uso válido del formato son XHTML y DocBook.

Fuente: habr.com