xsl with example convertir con xml configuration-files methodology

with - XML para archivos de configuración, ¿por qué?



xpath xml (12)

¿Por qué tantos proyectos usan XML para archivos de configuración?


  1. XML es fácil de analizar. Existen varias bibliotecas de análisis XML populares, livianas, con características y / o gratuitas disponibles en la mayoría de los idiomas.
  2. XML es fácil de leer. Es un lenguaje de marcado muy legible para los humanos, por lo que es fácil para los humanos escribir tanto como para que las computadoras escriban.
  3. XML está bien especificado. Todos y su perro saben cómo escribir XML decente, por lo que no hay confusión sobre la sintaxis.
  4. XML es popular. En algún momento, algunas personas importantes ™ comenzaron a impulsar la idea de que XML era el "futuro", y mucha gente lo compró.
  5. XML es un formato bidireccional. Es decir, el espacio en blanco, los comentarios y el orden se conservan. Puede cargar, cambiar y guardar programáticamente mientras conserva el formato. Esto es importante para las herramientas que los usuarios pueden usar para configurar sus aplicaciones. Es una de las razones por las que XML originalmente despegó (el mundo se ha vuelto más técnico, por lo que esta es una necesidad menor).
  6. XML tiene validación de esquema opcional. Importante para herramientas y formatos de configuración complejos.
  7. XML tiene espacios de nombres. Esto permite que otras configuraciones o anotaciones se incrusten sin afectar el análisis sintáctico. En otros formatos de configuración, esto generalmente se hace como un truco con comentarios especiales o el nombre de la propiedad.

Como nota al margen, no estoy tratando de defender XML. Tiene sus usos, y lo usaré en un proyecto cada vez que vuelva a eso. Sin embargo, en muchos casos, y especialmente en los archivos de configuración, la única ventaja que tiene es que es un formato estandarizado, y creo que esto se ve superado por numerosas desventajas (es decir, es demasiado detallado). Sin embargo, mis preferencias personales no importan; solo estaba respondiendo por qué algunas personas podrían elegir usar XML como formato de archivo de configuración. Yo personalmente nunca lo haré


Aquí hay algunos motivos históricos:

  • El W3C pasó de construir herramientas en Perl a Java
  • La fundación Apache pasó de desarrollar herramientas en Perl a Java
  • Java tiene muchas API XML
  • La configuración, por lo tanto, se puede hacer en Java
  • La configuración a través de XML y archivos de propiedades es para desarrolladores que no son Java

JTidy configuración JTidy frente a la configuración tidy es un excelente ejemplo de esto.


Bueno ... XML es una especificación de propósito general que puede contener descripciones, información anidada y datos sobre algo. Y hay muchas API y software que pueden analizarlo y leerlo.

Por lo tanto, es muy fácil describir algo de manera formal que se conoce como plataformas cruzadas y aplicaciones.


Debido a que analizar XML es relativamente fácil, y si su esquema está claramente especificado, cualquier utilidad puede leer y escribir información fácilmente.


Es porque XML le permite básicamente crear su propio marcado semántico, que puede ser leído por un analizador integrado en prácticamente cualquier idioma. Un beneficio adicional es que el archivo de configuración escrito en XML se puede usar en proyectos donde se usan dos o más idiomas. SI tuviera que crear un archivo de configuración donde todo se definiera como variables para un idioma específico, obviamente solo funcionaría en ese idioma.


Esta es una pregunta importante.

La mayoría de las alternativas (archivos JSON, YAML, INI) son más fáciles de analizar que XML.

Además, en idiomas como Python, donde todo es fuente, es más fácil simplemente poner su configuración en un módulo de Python claramente etiquetado.

Sin embargo, algunas personas dirán que XML tiene alguna ventaja sobre JSON o Python.

Lo importante de XML es que la "universalidad" de la sintaxis XML en realidad no se aplica mucho cuando se escribe un archivo de configuración que es específico para una aplicación. Como la portabilidad de un archivo de configuración no es importante, algunos usuarios de Python escriben sus archivos de configuración en Python.

Editar

La seguridad de un archivo de configuración no importa. El argumento "configurar un programa Python en Python es un riesgo de seguridad" parece ignorar el hecho de que Python ya está instalado y ejecutándose como fuente. ¿Por qué trabajar en un hack complejo en un archivo de configuración cuando tienes el origen? Solo hackear la fuente.

Escuché que la gente dice que "alguien" podría hackear tu aplicación a través del archivo de configuración. ¿Quién es este "alguien"? El administrador de sistemas? El DBA? ¿El desarrollador? No hay muchos "misterios" misteriosos con acceso a los archivos de configuración.

Y cualquiera que pudiera piratear el archivo de configuración de Python con fines nefastos probablemente podría instalar keyloggers, certificados falsos u otras amenazas más serias.


Gracias por tus respuestas. Esta pregunta, por ingenua que pueda parecer a primera vista, no fue tan ingenua :)

Personalmente, no me gusta XML para los archivos de configuración, creo que es difícil para las personas leer y cambiar, y es difícil para las computadoras analizar porque es muy genérico y poderoso.

Los archivos INI o los archivos de propiedad de Java están bien solo para las aplicaciones más básicas que requieren anidamiento. Las soluciones más comunes para agregar anidación a esos formatos son las siguientes:

level1.key1=value level1.key2=value level2.key1=value

no es un espectáculo bonito, mucha redundancia y cosas difíciles de mover entre nodos.

JSON no es un mal lenguaje, pero está diseñado para que sea fácil de analizar para las computadoras (es JavaScript válido), por lo que no se utiliza de forma desenfrenada para los archivos de configuración.

JSON se ve así:

{"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }}

En mi opinión, está demasiado lleno de comas y comillas.

YAML es bueno para los archivos de configuración, aquí hay una muestra:

invoice: 34843 date : 2001-01-23 bill-to: &id001 given : Chris family : Dumars

sin embargo, no me gusta demasiado su sintaxis, y creo que usar los espacios en blanco para definir ámbitos hace que las cosas sean un poco frágiles (piense en pegar un bloque a un nivel de anidación diferente).

Hace unos días comencé a escribir mi propio idioma para el archivo de configuración, lo Swush .

Aquí hay algunos ejemplos: como un simple par de clave-valor:

key:value key:value2 key1:value3

o como un más complejo y comentado

server{ connector{ protocol : http // HTTP or BlahTP port : 8080 # server port host : localhost /* server host name*/ } log{ output{ file : /var/log/server.log format : %t%s } } }

Swush soporta cadenas en la forma simple de arriba, o entre comillas, lo que permite espacios en blanco e incluso nuevas líneas dentro de cadenas. Voy a agregar matrices pronto, algunas como:

name [1 2 b c "Delta force"]

Hay una implementación de Java, pero se aceptan más implementaciones. :). revise el sitio para más información (cubrí la mayor parte, pero la API de Java proporciona algunas características interesantes como selectores)


La principal ventaja de XML y la razón por la que es tan popular es porque es popular en el mundo de Java y, por lo tanto, todas las aplicaciones empresariales escritas en Java lo usan, y también porque los servicios web y el jabón se basan en xml y se usan mucho en Aplicaciones empresariales.

Y hasta ahora, JSON y todos los demás formatos no son tan bien compatibles con la industria, excepto en aplicaciones ajax. Además, JSON no tiene un lenguaje de esquema o una API definida como XML.

Incluso hablando en términos generales, JSON no necesita las toneladas de cosas que xml tiene, al menos no de la misma manera, y estoy hablando en servicios web, cuando digo eso ...


Otro punto, si tiene un XSD (archivo de esquema) para describir su archivo de configuración, es trivial que su aplicación valide el archivo de configuración.


Porque XML suena genial y productivo.

Editar: No me di cuenta de que mi respuesta era tan vaga, hasta que un comentarista solicitó la definición de empresarial . Citando Wikipedia :

[...] el término "empresarial" tiene la intención de ir más allá de la preocupación de "exageración para organizaciones más pequeñas", lo que implica que el software es demasiado complejo incluso para grandes organizaciones y que se dispone de soluciones más simples y comprobadas.

Mi punto es que XML es una palabra de moda y, como tal, se está usando en exceso. A pesar de otras opiniones, XML no es fácil de analizar (basta con mirar libxml2, su paquete fuente gzipped es actualmente más de 3 MB). Debido a la cantidad de redundancia, también es molesto escribir a mano. Por ejemplo, Wikipedia enumera la configuración XML como una de las razones de la disminución de la popularidad de jabberd a favor de otras implementaciones.


Una razón que no se especificó en otras respuestas es Unicode / codificación de texto / lo que sea. ¿Necesita una cadena china en el archivo? No hay problema. Esto puede sonar trivial, pero cuando se introdujo XML, no fue así. Obviamente no en archivos INI.

Otra cosa: fue lo primero que nos dio la posibilidad de tener datos estructurados con listas, diccionarios o lo que quisieras, que es procesable por máquina y editable por humanos al mismo tiempo.

Tiene desventajas, pero ¿qué otra cosa podrías usar? Yaml se ve muy bien, pero me da miedo presentarlo en proyectos en los que trabajo porque veo en mi imaginación todos esos problemas con personas que colocan un espacio en blanco en el lugar equivocado o fusionan herramientas que no les importan.


XML es un estándar bien desarrollado y adoptado que facilita la lectura y la comprensión de los formatos de configuración propietarios.

Además, vale la pena entender que la serialización XML es una herramienta común disponible en la mayoría de los idiomas que hace que el almacenamiento de datos de objetos sea extremadamente fácil para los desarrolladores. ¿Por qué crear su propia forma de guardar una jerarquía de datos complejos cuando alguien más ya ha hecho el trabajo por usted?

.NET: http://msdn.microsoft.com/en-us/library/system.xml.serialization.aspx

PHP: http://us.php.net/serialize

Python: http://docs.python.org/library/pickle.html

Java: http://java.sun.com/developer/technicalArticles/Programming/serialization/