YAML es un formato de serialización de datos orientado a la legibilidad y uso en lenguajes de script. Su sencillo formato lo hace apropiado para ser leído y editado fácilmente. Y a pesar de estar orientado a los datos, puede llegar a usarse como un lenguaje de marcado ligero. Ejemplo: http://yaml.org/start.html Más información: http://es.wikipedia.org/wiki/YAML
#2 Pues venga, discútelo... no te quedes en la simple palabrería.
Te doy mis argumentos:
- Redundancia en la sintaxis (innecesaria para una máquina, necesaria para facilitar la lectura por un humano).
- Codificación en texto plano (innecesaria para una máquina, necesaria para ser leído por un humano).
- Convenciones sencillas (innecesario para una máquina, necesario para poder fácilmente aprendido por humanos).
Sobre lo primero que habías comentado de que XML se utiliza para bases de datos y transmisiones (supongo que para intentar ilustrarme), querría comentar que aunque es cierto, se le está dando un sobre-uso tremendo a una tecnología cuyo objetivo era una representación de documentos portable e independiente de la plataforma, quedando muy lejos el acceso aleatorio a la información, representación compacta y su procesamiento eficiente, que son características deseables para las BBDD, las transmisiones y la velocidad atendiendo peticiones de servicio.
Sobre YAML, la única "ventaja" que aprecio sobre XML es que el sangrado es obligatorio, lo cuál ayuda a ver la estructura en un único vistazo, pero ya que existen herramientas que sangran XML automáticamente, es como decir que Python es mejor que C porque no usa llaves... pero eso tiene otro problema a la hora de crear documentos "bien formados" (usando terminología XML), que es de sobra conocido por la comunidad de Python:
¿qué ocurre cuando el sangrado es inconsistente? y más importante todavía ¿es más fácil que pasen inadvertidos errores semánticos al no tener etiquetas de cierre (que los equivalentes de cerrar mal las etiquetas son errores sintácticos, más fáciles de detectar)?
Así que yo, con mis 2 dedos de frente, usaré XML para intercambiar documentos entre aplicaciones, archivos INI para las opciones de configuración de mis programas, BBDD relacionales para aplicaciones de acceso aleatorio y búsquedas, X.D.R. (pongo puntos para que no me salga el smiley ) para las comunicaciones, PDFs muy bonitos para presentar documentos e informes a los humanos (que somos así de tontos y nos gusta que la información nos entre por los ojos) y YAML no lo usaré ni para tomar por culo, que hoy por hoy, sin ser estándar ni ser nada, es para lo que vale
Espero que ningún desarrollador de YAML que pueda leer esto se lo tome a mal, eh? que tiene su gracia y su mérito, pero yo personalmente no le veo la utilidad ni la ventaja (sobre todo teniendo en cuenta que XML, a pesar de ser la mayor mierda que ha parido madre, ya está ahí y tiene millones de librerías que me evitan en la medida de lo posible perder el tiempo reinventando la rueda).
Venga, Hass y flashman, ahora os toca meterme caña
#6 caña? no por dios, de hexo estoy hasta cierto punto de acuerdo contigo.
El problema que tengo yo con el XML es que:
1-me parece excesivamente verboso.
2-Se abusa de el.
3-Se usa para cosas que en mi opinion no se deberia. O no me gusta como stan implementadas al menos. Un ejemplo de esto es XSL, *para mi* es un dolor hacer scripts con un lenguaje de etiquetas. No son argumentos tecnicos, al menos no 100% si no personales.
Por supuesto YAML no puede sustituir hoy por hoy en un proyecto "profesional" a XML, pero es una buena idea tirar de el para proyectos personales. Aprender cosas nuevas y usar cosas que no usas en el trabajo me parece importante.
Y la etiqueta de "con 2 de frente" es de txufla claramente
#9 bueno, XML tiene también sus cosas buenas, que antes le he echado un cubo de mierda impresionante , desde mi punto de vista son:
- Las DTD (o XML Schemas), que son una forma fácil de definir lenguajes formales con una notación estilo EBNF, sin necesidad de entrar en la complejidad de hacer parsers con YACC o similares, para validar los documentos.
- XLS (precisamente ), que permite expresar transformaciones de documentos de forma estándar, sin depender de un lenguaje de propósito general concreto. Teniendo en cuenta que una idea principal de XML es la de la portabilidad, está bien poder hacer filtros que conviertan XML a cualquier otro formato sin necesidad de recurrir a tecnologías externas.
- Namespaces: como decían en algún sitio que ya no recuerdo "we should have more of this"
Lo que no me gusta es que XML no es la panacea que nos quieren vender. Cuando nos dicen "esta aplicación trabaja con ficheros en formato XML" nos están vendiendo una moto, porque XML es simplemente una tecnología chorra que se ha estandarizado, pero lo realmente importante es la estandarización de las DTDs y los XML Schemas, que son los lenguajes en sí, no XML, que es un mero contenedor (como también podría ser YAML, SOX, las S-expressions, o cualquier otra tontería que nos inventemos ahora).
El hecho es que el contenedor es lo de menos, el trabajo importante está relacionado con el contenido (me gusta cómo ha quedado esa frase). Normalmente el parsing no termina cuando hemos construido el árbol DOM, muchos de los atributos tienen incrustados mini-lenguajes que hay que procesar (desde simples fechas hasta sabe FSM qué más) y aunque no sea así, ¿luego qué hacemos con el árbol DOM?
Hay que construir los objetos nativos de nuestro dominio (por suerte hay frameworks que se encargan de esto, que es como deberían hacerse las cosas, aunque por lo que he visto al final se suele trabajar con el DOM a pelo, con lo propenso a errores que es manipular atributos "por su nombre"), a veces hay que reemplazar referencias si nuestro dominio no es un árbol sino un grafo y por último, hacer lo que sea que tengamos que hacer. Después tendremos que recorrer todo el camino a la inversa (y si tenemos suerte el framework que hayamos escogido lo hará por nosotros).
Resumiendo: al igual que es estúpido pensar que hay un lenguaje de programación adecuado para todos los dominios, no es muy sensato pensar que hay un lenguaje de representación de datos adecuado para todo (que es la moto que nos han querido vender).
(¿cómo nos piramos del tema, no? espero que al menos alguien lo encuentre interesante y no sea un desperdicio total de espacio de almacenamiento en el servidor de meneame )
#1 XML se usa bastante para serializar datos (bases de datos, transmisiones). Los webservices tan de moda actualmente se basan en XML. YAML compite en este terreno.
Y además ya he puesto que aunque no es un lenguaje de marcado, puede actuar como tal para cosas sencillas.
Ya sé que XML se diseñó (en teoría) para humanos, pero de la teoría a la práctica hay trecho y cualquier documento medio complejo de XML se convierte en un horror, leíble, pero un horror. XML es para humanos acostumbrados a leer como una máquina.
He echado un vistazo rápido al ejemplito que pone en "Get started" y la verdad es que no me parece ni más ni menos "human friendly" que el XML. Igual profundizando más aparecen sus virtudes, pero a primera vista parece tan legible como el XML.
¿Es el XML para humanos? Pues en mi opinión depende de si el autor del esquema se ha preocupado de que así sea o no. Desde luego si trabajas con J2EE seguro que tienes que leer y escribir muchos XML. No sé, pongamos por caso un archivo de mapeo de hibernate ¿Os parece poco legible para el programador? A mí me parece que el XML es un buen punto intermedio entre máquinas y humanos. Si YAM aporta algo nuevo bienvenido sea, pero a primera vista no me parece un avance.
Comentarios
#2 Pues venga, discútelo... no te quedes en la simple palabrería.
) para las comunicaciones, PDFs muy bonitos para presentar documentos e informes a los humanos (que somos así de tontos y nos gusta que la información nos entre por los ojos) y YAML no lo usaré ni para tomar por culo, que hoy por hoy, sin ser estándar ni ser nada, es para lo que vale
Te doy mis argumentos:
- Redundancia en la sintaxis (innecesaria para una máquina, necesaria para facilitar la lectura por un humano).
- Codificación en texto plano (innecesaria para una máquina, necesaria para ser leído por un humano).
- Convenciones sencillas (innecesario para una máquina, necesario para poder fácilmente aprendido por humanos).
Y por último, el argumento definitivo:
http://www.w3.org/TR/2006/REC-xml-20060816/#sec-origin-goals mirad el punto 6
Sobre lo primero que habías comentado de que XML se utiliza para bases de datos y transmisiones (supongo que para intentar ilustrarme), querría comentar que aunque es cierto, se le está dando un sobre-uso tremendo a una tecnología cuyo objetivo era una representación de documentos portable e independiente de la plataforma, quedando muy lejos el acceso aleatorio a la información, representación compacta y su procesamiento eficiente, que son características deseables para las BBDD, las transmisiones y la velocidad atendiendo peticiones de servicio.
Sobre YAML, la única "ventaja" que aprecio sobre XML es que el sangrado es obligatorio, lo cuál ayuda a ver la estructura en un único vistazo, pero ya que existen herramientas que sangran XML automáticamente, es como decir que Python es mejor que C porque no usa llaves... pero eso tiene otro problema a la hora de crear documentos "bien formados" (usando terminología XML), que es de sobra conocido por la comunidad de Python:
¿qué ocurre cuando el sangrado es inconsistente? y más importante todavía ¿es más fácil que pasen inadvertidos errores semánticos al no tener etiquetas de cierre (que los equivalentes de cerrar mal las etiquetas son errores sintácticos, más fáciles de detectar)?
Así que yo, con mis 2 dedos de frente, usaré XML para intercambiar documentos entre aplicaciones, archivos INI para las opciones de configuración de mis programas, BBDD relacionales para aplicaciones de acceso aleatorio y búsquedas, X.D.R. (pongo puntos para que no me salga el smiley
Espero que ningún desarrollador de YAML que pueda leer esto se lo tome a mal, eh? que tiene su gracia y su mérito, pero yo personalmente no le veo la utilidad ni la ventaja (sobre todo teniendo en cuenta que XML, a pesar de ser la mayor mierda que ha parido madre, ya está ahí y tiene millones de librerías que me evitan en la medida de lo posible perder el tiempo reinventando la rueda).
Venga, Hass y flashman, ahora os toca meterme caña
#6 caña? no por dios, de hexo estoy hasta cierto punto de acuerdo contigo.
El problema que tengo yo con el XML es que:
1-me parece excesivamente verboso.
2-Se abusa de el.
3-Se usa para cosas que en mi opinion no se deberia. O no me gusta como stan implementadas al menos. Un ejemplo de esto es XSL, *para mi* es un dolor hacer scripts con un lenguaje de etiquetas. No son argumentos tecnicos, al menos no 100% si no personales.
Por supuesto YAML no puede sustituir hoy por hoy en un proyecto "profesional" a XML, pero es una buena idea tirar de el para proyectos personales. Aprender cosas nuevas y usar cosas que no usas en el trabajo me parece importante.
Y la etiqueta de "con 2 de frente" es de txufla claramente
#7 hmmmmmmm... entonces será que ya me he malacostumbrado a leer (y pensar :-p) como una máquina
#9 bueno, XML tiene también sus cosas buenas, que antes le he echado un cubo de mierda impresionante
, desde mi punto de vista son:
), que permite expresar transformaciones de documentos de forma estándar, sin depender de un lenguaje de propósito general concreto. Teniendo en cuenta que una idea principal de XML es la de la portabilidad, está bien poder hacer filtros que conviertan XML a cualquier otro formato sin necesidad de recurrir a tecnologías externas.
)
- Las DTD (o XML Schemas), que son una forma fácil de definir lenguajes formales con una notación estilo EBNF, sin necesidad de entrar en la complejidad de hacer parsers con YACC o similares, para validar los documentos.
- XLS (precisamente
- Namespaces: como decían en algún sitio que ya no recuerdo "we should have more of this"
Lo que no me gusta es que XML no es la panacea que nos quieren vender. Cuando nos dicen "esta aplicación trabaja con ficheros en formato XML" nos están vendiendo una moto, porque XML es simplemente una tecnología chorra que se ha estandarizado, pero lo realmente importante es la estandarización de las DTDs y los XML Schemas, que son los lenguajes en sí, no XML, que es un mero contenedor (como también podría ser YAML, SOX, las S-expressions, o cualquier otra tontería que nos inventemos ahora).
El hecho es que el contenedor es lo de menos, el trabajo importante está relacionado con el contenido (me gusta cómo ha quedado esa frase). Normalmente el parsing no termina cuando hemos construido el árbol DOM, muchos de los atributos tienen incrustados mini-lenguajes que hay que procesar (desde simples fechas hasta sabe FSM qué más) y aunque no sea así, ¿luego qué hacemos con el árbol DOM?
Hay que construir los objetos nativos de nuestro dominio (por suerte hay frameworks que se encargan de esto, que es como deberían hacerse las cosas, aunque por lo que he visto al final se suele trabajar con el DOM a pelo, con lo propenso a errores que es manipular atributos "por su nombre"), a veces hay que reemplazar referencias si nuestro dominio no es un árbol sino un grafo y por último, hacer lo que sea que tengamos que hacer. Después tendremos que recorrer todo el camino a la inversa (y si tenemos suerte el framework que hayamos escogido lo hará por nosotros).
Resumiendo: al igual que es estúpido pensar que hay un lenguaje de programación adecuado para todos los dominios, no es muy sensato pensar que hay un lenguaje de representación de datos adecuado para todo (que es la moto que nos han querido vender).
(¿cómo nos piramos del tema, no? espero que al menos alguien lo encuentre interesante y no sea un desperdicio total de espacio de almacenamiento en el servidor de meneame
#1 XML se usa bastante para serializar datos (bases de datos, transmisiones). Los webservices tan de moda actualmente se basan en XML. YAML compite en este terreno.
Y además ya he puesto que aunque no es un lenguaje de marcado, puede actuar como tal para cosas sencillas.
#6 A ver lo "para humanos" era una coña...
Ya sé que XML se diseñó (en teoría) para humanos, pero de la teoría a la práctica hay trecho y cualquier documento medio complejo de XML se convierte en un horror, leíble, pero un horror. XML es para humanos acostumbrados a leer como una máquina.
#1 XML no es ni por asomo tan legible como YAML para un ser humano.
Para los que tienen que usar por pelotas XML recomiendo SOX, es legible y "es" XML.
http://www.langdale.com.au/SOX/
Btw muy buenas las etiquetas
He echado un vistazo rápido al ejemplito que pone en "Get started" y la verdad es que no me parece ni más ni menos "human friendly" que el XML. Igual profundizando más aparecen sus virtudes, pero a primera vista parece tan legible como el XML.
¿Es el XML para humanos? Pues en mi opinión depende de si el autor del esquema se ha preocupado de que así sea o no. Desde luego si trabajas con J2EE seguro que tienes que leer y escribir muchos XML. No sé, pongamos por caso un archivo de mapeo de hibernate ¿Os parece poco legible para el programador? A mí me parece que el XML es un buen punto intermedio entre máquinas y humanos. Si YAM aporta algo nuevo bienvenido sea, pero a primera vista no me parece un avance.
2 cositas:
(pone la palabra mágica XML "para vender")
- XML ya es para humanos.
- Esto no es XML, ni siquiera es un lenguaje de marcado (como su nombre indica).
Así que supongo que el titular es amarillista
Neng, está bien que des información, pero mi primitivo inglés, no me da fluideza para enteder la noticia en toda su dimensión.
Gracias