XSLT y posibles alternativas [cerrado]

Eché un vistazo a XSLT para transformar un archivo XML en otro (HTML, etc.). Ahora, aunque veo que XSLT tiene beneficios (al ser una herramienta estandarizada y usada), soy reacio por un par de razones

• Los procesadores XSLT parecen ser bastante grandes / hambrientos de recursos
• XML es una mala notación para la programación y de eso se trata XSLT.

No quiero troll XSLT aquí, aunque solo quiero señalar lo que no me gusta para darle una idea de lo que esperaría de una alternativa.

Teniendo algunos antecedentes de Lisp, me pregunto si hay mejores formas para las transformaciones de la estructura de árbol basadas en algún lisp. He visto referencias a DSSSL, lamentablemente la mayoría de los enlaces sobre DSSSL están muertos, por lo que ya es difícil ver algún código que lo ilustre. ¿DSSSL todavía está en uso? Recuerdo que había instalado Openjade una vez cuando revisé cosas de docbook.

La publicación del blog de Jeff Atwood parece insinuar el uso de Ruby en lugar de XSLT.

¿Hay alguna forma sensata de hacer transformaciones XML similares a XSLT en un lenguaje de programación que no sea XML? Estaría abierto a la entrada de

• Bibliotecas útiles para lenguajes de secuencias de comandos que facilitan las transformaciones XML
• especialmente (pero no exclusivamente) lenguajes de transformación tipo lisp, o Ruby, etc.

Algunas cosas que encontré hasta ahora:

• Un par de lugares en la web han señalado a Linq como una posible alternativa. En general, tengo todo tipo de clasificaciones, también de aquellos que han tenido la mejor experiencia XSLT.
• Para el esquema http://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/ y http://www.okmij.org/ftp/Scheme/xml.html

Es difícil evaluar las tecnologías cuando no tienes una experiencia profunda de ellas, pero por supuesto es exactamente cuando tienes que tomar tus decisiones, por lo que no hay una respuesta simple a ese dilema.

Citas dos preocupaciones: rendimiento y usabilidad. Trataré de abordar ambos a continuación.

En primer lugar, el rendimiento. El rendimiento, por supuesto, depende no solo del idioma sino también de la implementación y también de la experiencia de los usuarios. Los diferentes procesadores XSLT pueden variar ampliamente en el rendimiento, y el mismo procesador puede variar ampliamente dependiendo de cómo se use (con Saxon, por ejemplo, las personas que tienen problemas de rendimiento a menudo lo usan con DOM, que es una combinación pobre , y el rendimiento puede aumentar diez veces si utiliza el modelo de árbol nativo de Saxon en su lugar). Entonces, el primer consejo es no tomar el rendimiento en rumores, medirlo; y el segundo consejo es asegurarse de que la persona que realiza la medición tenga suficiente experiencia para no cometer errores tontos. Más fácil decirlo que hacerlo.

Crudamente, puede separar los trabajos de transformación en dos categorías: simples y complejos. Para transformaciones simples, con un buen procesador XSLT, el tiempo se dedica a analizar y serializar, y el tiempo de procesamiento XSLT apenas entra en escena. Dado que cualquier otra tecnología incurrirá en los mismos costos de análisis y serialización, la elección de la tecnología de transformación no va a hacer una gran diferencia (excepto quizás muy para la codificación de muy bajo nivel usando la transmisión, pero no muchas personas pueden pagar la programación) tiempo y habilidades necesarias para implementar eso). Para transformaciones complejas en documentos grandes, comienza a tener los mismos problemas que con la programación SQL: lograr un buen rendimiento requiere una buena interacción entre las habilidades y el conocimiento del programador y las capacidades del optimizador. Al igual que con SQL, ' Es muy fácil en un lenguaje de tan alto nivel escribir algunas declaraciones simples que dan como resultado que el procesador tenga que hacer una gran cantidad de trabajo. Pero también, al igual que con SQL, los programadores que saben lo que hacen lo harán mucho mejor que los novatos.

Segundo, usabilidad. La sintaxis basada en XML para XSLT es muy desagradable para muchas personas en el primer encuentro con el lenguaje. Pero hay buenas razones y beneficios reales para hacerlo de esta manera: existe el argumento de la "plantilla", que gran parte del código consiste en XML para escribir en el documento resultante, y la mejor manera de escribir XML es en XML. Y existe el argumento de la "reflexión"; En sistemas complejos grandes, es muy común encontrar hojas de estilo que generen hojas de estilo. Luego está el argumento de "herramientas"; si está en una tienda XML, probablemente tenga muchas herramientas XML, como editores dirigidos por sintaxis, y es bueno poder usar las mismas herramientas para manejar sus programas y sus datos. Las desventajas resultan ser bastante cosméticas en comparación: hay ' s la cantidad de pulsaciones de teclas involucradas en la edición (se arregla fácilmente con una buena herramienta de edición), y está la verbosidad del código (lo que reduce su legibilidad). La verbosidad se reduce enormemente en XSLT 2.0 con la introducción de características como expresiones regulares y funciones de hoja de estilo: muchas hojas de estilo se reducen a la mitad o un tercio de tamaño cuando aprovechan al máximo XSLT 2.0.

Su mención de DSSSL me deja con una sonrisa irónica. Nunca he usado DSSSL, pero las historias que escuché fueron que no tenía éxito porque su sintaxis era arcana y no estaba relacionada con la sintaxis de los datos (SGML). El uso de una sintaxis XML para XSLT estuvo fuertemente motivado por la experiencia con DSSSL.

Hay personas que aman XSLT y hay personas que lo odian. Como era de esperar, aquellos que lo usan mucho tienden a caer en la primera categoría. Aquellos a quienes no les gusta son generalmente aquellos que no han aprendido a "pensar a la manera XSLT". Podría argumentar que un lenguaje de programación no debería afectar su forma de pensar, pero lo hace: escribir en un lenguaje basado en reglas toma una mentalidad diferente de escribir en un lenguaje imperativo. La primera reacción de muchos programadores es que se sienten menos en control (describiendo el problema, en lugar de decirle a la computadora qué hacer paso a paso). Es muy similar a la reacción que solía ver cuando la gente se introdujo por primera vez a SQL. En estos días, las personas aprenden SQL antes en sus carreras, por lo que se requiere menos reajuste mental.

En última instancia, debe elegir una tecnología basada en criterios objetivos medibles, no en reacciones de amor / odio. Es difícil hacer esas mediciones. Pero hay muchas personas que usan XSLT de manera muy intensa y exitosa, por lo que no hay duda de que se puede hacer.

Sin información adicional sobre el contexto, es difícil responder.

Aún así, no entiendo por qué no quieres usar XSLT. Es la herramienta adecuada para el trabajo, y una herramienta poderosa. Se hace específicamente para transformar un XML en otro.

Los procesadores XSLT parecen ser bastante grandes / hambrientos de recursos

¿Tiene datos duros para respaldar eso? ¿Ha implementado la solución usando XSLT y descubrió que XSLT es el cuello de botella que hace que sea imposible entregar el producto mientras cumple con todos los requisitos no funcionales relacionados con el rendimiento?

Sin datos estadísticos y perfiles, no puede afirmar razonablemente que una solución dada no funcionará. ¿Son los requisitos no funcionales lo suficientemente razonables? ¿Preferiría perder, por ejemplo, diez días de trabajo de los desarrolladores para ganar unos pocos cientos de milisegundos al reemplazar XSLT por otra alternativa? ¿Hace que valga la pena?

XML es una mala notación para la programación y de eso se trata XSLT.

¿Entonces quiere transformar un XML en otro, pero no quiere usar XSLT porque "XML es una mala notación"?

Si es el hecho de que usa XML como una especie de lenguaje de programación que le molesta tanto, no lo vea como programación, sino como un montón de reglas de transformación.

Ni siquiera necesita escribir XSLT a mano. Hay muchos editores ETL que pueden permitirle asignar gráficamente un XML a otro: no se requiere programación alguna. Algunos de ellos usan XSLT como salida.

Si está utilizando XSLT para generar XML basado en el XSLT sin procesar y algunos parámetros que está pasando al motor XSLT, entonces usar un enfoque XML de plantilla es mucho más fácil de entender y mantener.

He estado en un proyecto donde se usó Moustache para reemplazar XSLT y el resultado fueron archivos XML de base mucho más simples que todos podían editar y ajustar, en lugar de que el trabajo del proyecto se pasara a una o dos almas valientes, que se quedarían en silencio total con gotas de sudor cayendo ...

El enfoque de plantilla no es adecuado para su uso cuando el XML base también es información válida por derecho propio, y ese XSLT se está utilizando para proporcionar una representación alternativa o un extracto del XML fuente.

XML no es un lenguaje de programación

XML es una forma de transferir / transportar datos.
lo que hace una instrucción XSLT es usar Xpath para consultar los datos de una manera específica y colocarlos en otro objeto / documento de transporte de datos.

Y / O

XSLT puede transformar su XML en HTML, que es otra forma de mostrar / transportar los datos contenidos en un documento XML.

Si desea cambiar el XML o crear un documento XML, puede usar cualquier cantidad de idiomas: C #, VB, Ruby, etc.

por lo general, cuando usa un archivo XSLT para transformar un documento XML, todavía tiene el documento XML original, en realidad no cambia el documento original, realmente crea uno nuevo.

He trabajado en múltiples sistemas de procesamiento XML que combinan bibliotecas XSLT con Java o C ++ para las partes en las que XSLT no es tan bueno. Hay bibliotecas que obtienen un rendimiento XSLT muy bueno incluso en archivos XML de 20 MB, sin embargo, XSLT tiene algunas limitaciones con el contexto, las variables y los patrones de cadena realmente complejos. En cada sistema en el que he trabajado se hicieron algunas cosas en Java / C ++ porque el contexto era importante o alguna expresión compleja de expresiones regulares ayudó. Mi conclusión es que XSLT más algún código adicional en el idioma de su elección es una buena manera de transformar XML.