<\/a><\/noindex>Desde este punto de vista, hay una forma sencilla de comprobar cu\u00e1n bien hecho est\u00e1 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\u00ednea vac\u00eda), entonces o bien su esquema est\u00e1 mal construido o simplemente no debi\u00f3 aplicar XML.<\/p>\n
A continuaci\u00f3n, presentar\u00e9 algunos de los ejemplos m\u00e1s comunes de esquemas mal construidos.<\/p>\n
<\/code><\/pre>\n\nAqu\u00ed vemos un ejemplo de un intento injustificado y extra\u00f1o (aunque bastante com\u00fan) de expresar en lenguaje XML un simple diccionario de \"clave-valor\". Si se eliminan todas las etiquetas y atributos, queda una l\u00ednea vac\u00eda. En esencia, este documento representa, por absurdo que parezca, una anotaci\u00f3n sem\u00e1ntica de una l\u00ednea vac\u00eda.<\/p>\n
<root name=\"John\" city=\"London\" \/><\/code><\/pre>\n\nLo que es peor, aqu\u00ed no solo tenemos una anotaci\u00f3n sem\u00e1ntica de una l\u00ednea vac\u00eda como una forma extravagante de expresar un diccionario, esta vez el \"diccionario\" est\u00e1 codificado directamente en forma de atributos del elemento ra\u00edz. Debido a esto, el conjunto de nombres de atributos en el elemento se vuelve indefinido y din\u00e1mico. Adem\u00e1s, est\u00e1 claro que lo que realmente quer\u00eda expresar el autor es una simple sintaxis de \"clave-valor\", pero en lugar de eso, tom\u00f3 la extra\u00f1a decisi\u00f3n de aplicar XML, forzando el uso de un \u00fanico elemento vac\u00edo simplemente como un prefijo para utilizar la sintaxis de atributos. Encuentro tales esquemas con mucha frecuencia.<\/p>\n
John\n Londres<\/code><\/pre>\n\nEsto ya es un progreso, pero ahora las claves son por alguna raz\u00f3n metadatos, mientras que los valores no lo son. Es una visi\u00f3n muy extra\u00f1a sobre los diccionarios. Si se eliminan todas las etiquetas y atributos, se perder\u00e1 la mitad de la informaci\u00f3n.<\/p>\n
La correcta expresi\u00f3n de un diccionario en XML se ver\u00eda aproximadamente as\u00ed:<\/p>\n
Nombre\n John\n \n \n Ciudad\n Londres<\/code><\/pre>\n\nPero si las personas toman la extra\u00f1a decisi\u00f3n de usar XML como formato de datos y luego lo usan para organizar un diccionario, deben entender que lo que est\u00e1n haciendo es inapropiado e inc\u00f3modo. Adem\u00e1s, los dise\u00f1adores a menudo eligen err\u00f3neamente XML para desarrollar sus aplicaciones. Pero a\u00fan m\u00e1s a menudo, agravan la situaci\u00f3n 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.<\/p>\n
\u00bfEl esquema XML m\u00e1s horrible?<\/b> Por cierto, el premio por el esquema XML m\u00e1s horrible que he visto,<\/i> lo recibe el formato de archivo de configuraci\u00f3n de asignaci\u00f3n autom\u00e1tica de recursos para tel\u00e9fonos IP de voz sobre IP Polycom. Tales archivos requieren la descarga de archivos XML de solicitudes a trav\u00e9s de TFTP, que... En fin, aqu\u00ed hay un fragmento de uno de esos archivos:<\/p>\n<softkey\n softkey.feature.directories=\"0\"\n softkey.feature.buddies=\"0\"\n softkey.feature.forward=\"0\"\n softkey.feature.meetnow=\"0\"\n softkey.feature.redial=\"1\"\n softkey.feature.search=\"1\"\n\n softkey.1.enable=\"1\"\n softkey.1.use.idle=\"1\"\n softkey.1.label=\"Foo\"\n softkey.1.insert=\"1\"\n softkey.1.action=\"...\"\n\n softkey.2.enable=\"1\"\n softkey.2.use.idle=\"1\"\n softkey.2.label=\"Bar\"\n softkey.2.insert=\"2\"\n softkey.2.action=\"...\" \/><\/code><\/pre>\n\nEsto no es una broma desafortunada de alguien. Y no es un invento m\u00edo:<\/p>\n
\nLos elementos se utilizan simplemente como prefijos para adjuntar atributos que, en s\u00ed mismos, tienen nombres jer\u00e1rquicos.\n<\/li>\n Si es necesario asignar valores a varias instancias de un registro de un tipo espec\u00edfico, hay que utilizar los nombres de los atributos, que contienen \u00edndices<\/i>.\n<\/li>\nAdem\u00e1s, los atributos que comienzan con softkey.<\/code>, deben colocarse en los elementos <softkey\/><\/code>, los atributos que comienzan con feature.<\/code>, deben colocarse en los elementos <feature\/><\/code> , etc., a pesar de que esto parece completamente innecesario y, a primera vista, sin sentido.\n<\/li>\nY, por \u00faltimo, si esperabas que el primer componente del nombre del atributo siempre coincidiera con el nombre del elemento, \u00a1nada de eso! Por ejemplo, los atributos up.<\/code> deben adjuntarse a <userpreferences\/><\/code>. El orden de adjuntar los nombres de los atributos a los elementos es aleatorio y pr\u00e1cticamente total.\n<\/li>\n<\/ul>\n\nDocumentos o datos<\/b>. De vez en cuando, alguien hace cosas absolutamente extra\u00f1as 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.<\/p>\n
Entender esto ayudar\u00e1 a comprender la diferencia entre documentos y datos<\/i>. Como analog\u00eda, XML puede considerarse un documento legible por m\u00e1quina. Aunque est\u00e1 destinado a ser le\u00eddo por una m\u00e1quina, metaf\u00f3ricamente 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\u00e1quinas. <\/p>\n
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\u00e1 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\u00edfico. Metaf\u00f3ricamente, esto es an\u00e1logo a un documento en papel, aunque no tenga dimensiones f\u00edsicas a diferencia de una impresi\u00f3n o un archivo PDF.<\/i>.<\/p>\n
En mi ejemplo de una representaci\u00f3n adecuada de un diccionario en XML, se muestra el orden de los elementos en el diccionario, a diferencia de la representaci\u00f3n en JSON. No puedo ignorar este orden: tal linealidad es intr\u00ednseca al modelo de documentos y al formato XML. Alguien podr\u00eda decidir ignorar el orden al interpretar este documento XML, pero discutir sobre eso es in\u00fatil, ya que la cuesti\u00f3n est\u00e1 fuera del alcance de la discusi\u00f3n sobre el formato en s\u00ed. Adem\u00e1s, si se hace que el documento sea visible en el navegador, al adjuntarle una hoja de estilos en cascada, se podr\u00e1 ver que los elementos del diccionario siguen un orden espec\u00edfico, y no de otra manera.<\/p>\n
En otras palabras, un diccionario (fragmento de datos estructurados) puede ser transformado en n<\/i> diversos documentos posibles (en formato XML, PDF, en papel, etc.), donde n<\/i> \u2014 el n\u00famero de combinaciones posibles de elementos en el diccionario, y a\u00fan no hemos considerado otras variables posibles.<\/p>\n
Sin embargo, tambi\u00e9n se deduce que si solo quieres transmitir datos, usar un documento legible por m\u00e1quina no ser\u00e1 efectivo. Se utiliza un modelo que en este caso es redundante y solo estorbar\u00e1. Adem\u00e1s, para extraer los datos originales, ser\u00e1 necesario escribir un programa. Dif\u00edcilmente tiene sentido usar XML para algo que en una etapa determinada no ser\u00e1 formateado como un documento (por ejemplo, utilizando CSS o XSLT, o ambos), ya que esa es la principal (si no la \u00fanica) raz\u00f3n para ce\u00f1irse al modelo de documento.<\/p>\n
Adem\u00e1s, dado que en XML no existe el concepto de n\u00fameros (o expresiones booleanas, o otros tipos de datos), todos los n\u00fameros presentados en este formato se consideran solo texto adicional. Para extraer datos, debe conocerse el esquema y su relaci\u00f3n con los datos expresados. Tambi\u00e9n es necesario saber, seg\u00fan el contexto, cu\u00e1ndo un determinado elemento del texto representa un n\u00famero y debe ser convertido en un n\u00famero, etc.<\/p>\n
Por lo tanto, el proceso de extracci\u00f3n de datos de documentos XML no difiere mucho del proceso de reconocimiento de documentos escaneados que contienen, por ejemplo, tablas que forman m\u00faltiples p\u00e1ginas de datos num\u00e9ricos. S\u00ed, es posible hacerlo en principio, pero no es el camino m\u00e1s \u00f3ptimo, a menos que sea en el caso extremo de que no haya otras opciones. Una soluci\u00f3n razonable ser\u00eda simplemente encontrar una copia digital de los datos originales, que no est\u00e9n incrustados en un modelo de documento, en el que los datos se combinan con su representaci\u00f3n textual espec\u00edfica.<\/p>\n
No me sorprende en absoluto que XML sea popular en el negocio. La raz\u00f3n 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\u00f3n, los negocios utilizan con demasiada frecuencia documentos en PDF en lugar de formatos m\u00e1s adecuados para el procesamiento autom\u00e1tico: porque a\u00fan est\u00e1n atados a la idea de una p\u00e1gina impresa con un tama\u00f1o f\u00edsico determinado. Esto se aplica incluso a aquellos documentos que dif\u00edcilmente se imprimir\u00e1n alguna vez (por ejemplo, un archivo PDF de documentaci\u00f3n del registro de 8000 p\u00e1ginas). Desde este punto de vista, el uso de XML en los negocios es en esencia una manifestaci\u00f3n de esqueleto morfol\u00f3gico. La idea metaf\u00f3rica de una p\u00e1gina impresa de tama\u00f1o limitado es comprensible para las personas, y entienden c\u00f3mo crear procesos comerciales basados en documentos impresos. Si ese es su punto de referencia, los documentos sin un tama\u00f1o f\u00edsico limitado, que son legibles por m\u00e1quina \u2014los documentos XML\u2014 representan una innovaci\u00f3n, siendo al mismo tiempo an\u00e1logos familiares y c\u00f3modos al documento. Esto no impide que sigan siendo una forma err\u00f3nea y excesivamente esquel\u00e9tica de representar datos.<\/p>\n
Hasta la fecha, las \u00fanicas esquemas XML que realmente puedo considerar un uso correcto de este formato son XHTML y DocBook.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f\u0437\u044b\u043a XML \u0431\u044b\u043b \u0438\u0437\u043e\u0431\u0440\u0435\u0442\u0435\u043d \u0432 1996 \u0433\u043e\u0434\u0443. \u0415\u0434\u0432\u0430 \u043e\u043d \u0443\u0441\u043f\u0435\u043b \u043f\u043e\u044f\u0432\u0438\u0442\u044c\u0441\u044f, \u043a\u0430\u043a \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0443\u0436\u0435 \u043d\u0430\u0447\u0430\u043b\u0438 \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c \u043d\u0435\u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e, \u0438 \u0434\u043b\u044f \u0442\u0435\u0445 \u0446\u0435\u043b\u0435\u0439, \u043a \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0435\u0433\u043e \u043f\u044b\u0442\u0430\u043b\u0438\u0441\u044c \u0430\u0434\u0430\u043f\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c, \u043e\u043d \u0431\u044b\u043b \u043d\u0435 \u043b\u0443\u0447\u0448\u0438\u043c \u0432\u044b\u0431\u043e\u0440\u043e\u043c. \u041d\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u0440\u0435\u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0435\u043c \u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u0447\u0442\u043e \u043f\u043e\u0434\u0430\u0432\u043b\u044f\u044e\u0449\u0435\u0435 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0441\u0445\u0435\u043c XML, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u0435 \u0434\u043e\u0432\u043e\u0434\u0438\u043b\u043e\u0441\u044c \u0432\u0438\u0434\u0435\u0442\u044c, \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u043b\u0438 \u0441\u043e\u0431\u043e\u0439 \u043d\u0435\u0446\u0435\u043b\u0435\u0441\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u043e\u0435 \u0438\u043b\u0438 \u043d\u0435\u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 XML. \u0411\u043e\u043b\u0435\u0435 \u0442\u043e\u0433\u043e, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":52641,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52640","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"XML](\"\/wp-content\/uploads\/2019\/11\/8152077415a94ef74806af230ef44bd7.jpg\")